Editorial standards
How this site gets written.
A marketing site is an argument, and an argument is only worth as much as its sourcing. These are the rules this one is written to, and they are specific enough that you can check whether they were followed.
Standards
Every number is measured
Where this site states a figure, it came from a measurement rather than an estimate, and the page says what it was measured against. The performance figures on the home page were taken against a live mailbox of 26,930 messages while the product was being built, and the page says so on the block that carries them.
No number here is rounded up into a better one. In practice that means:
-
A range is published as a range.
So token refresh is 382 to 432 ms, rather than "under half a second".
-
A timing that varies is marked as approximate.
It isn't given a precision it doesn't have.
-
A limit that is ours is labelled as ours.
Not a provider's, because the difference matters to anyone deciding whether they can live with it.
-
No measurement, no claim.
Where nothing was measured, nothing is stated.
The rule behind the ledger
The claim-and-evidence blocks used across this site may only contain checkable facts. A row containing an adjective has broken the device, so adjectives do not go in one. It is a deliberately awkward rule, because the awkwardness is what stops it becoming decoration.
Sources
Sourcing and attribution
Claims about somebody else's product or policy link to that organisation's own documentation, not to a blog post summarising it. The set-up guides carry a sources list at the end for exactly this reason: when we tell you Microsoft disabled Basic Authentication for IMAP on 1 October 2022, you can go and read Microsoft saying it.
Primary sources are preferred over commentary. Where a provider's own documentation is wrong, which has happened at least once here, the page says the documentation is wrong, says what was measured instead, and says how it was measured.
Links are checked before publication. A dead source is a broken claim.
We publish the limits
Every substantive page on this site carries a section saying what the product does not do. Not a caveat at the bottom of a feature list: a heading, in the flow of the page, in the same size type as everything else.
This is partly a matter of honesty and partly self-interest. A customer who signs up despite a clearly stated limitation stays; a customer who discovers it in week 2 asks for their money back and tells someone.
So the limits are written at the same time as the claims, by the same person, and they are as specific: "a Microsoft 365 shared or delegated mailbox cannot be connected" rather than "some restrictions apply".
Every price and limit is stated once
Every price and every daily call limit is defined in exactly one place in this site's code: Pro per mailbox, and the 3, 5 or 10 person Team Access tiers per account. It is read from there everywhere it appears, on every page, in the structured data and in the AI discovery files. A figure cannot disagree between 2 pages, because there is only one of it.
This is a direct response to something we found while researching the competition: a site advertising one price and billing another, and showing 2 different daily ceilings, in 2 different units, on 2 different pages of the same product. If you ever find this site contradicting itself about a number, that is a bug and we would like to hear about it.
Machinery
What is checked before a page ships
A set of automated checks runs over the whole site before every deploy, and the deploy does not go ahead while one of them fails. They are not a substitute for reading the page. They catch the things a reader cannot see, which is where a site like this goes wrong.
-
The tool surface is compared with the server's own registration code.
Every tool this site names must be one the server registers, with the same safety class. A number written next to the word "tool" must be one the server accounts for.
-
The prices and limits are compared with the server's source.
The daily allowances, the rolling window and every retention period published here must equal the constants the server enforces.
-
The text of every page is swept.
For the punctuation and phrasing a text generator leaves behind, for a page title or description longer than a search result shows, and for structured data that does not parse.
-
The dates are watched.
A claim that we read somebody else's documentation on a given day is warned about after 90 days and refused after 365, because by then the sentence is false rather than stale. Our own reviewed dates are held to the same thresholds.
-
Images and colour are measured on the rendered page.
Every image at the size it is actually drawn, at 2 screen widths, and every text-and-background pairing in the palette against WCAG 2.2.
The rule behind the checks
Nothing factual is typed twice. Every fact about the product, with where it came from and when it was measured, lives in one file. Every page, the structured data and the AI discovery files read from it, so a figure changed there changes everywhere, and a figure typed anywhere else is a bug.
Where this site makes a claim about a competitor, the competitor's own sentence is recorded beside the cell it supports, with the day it was read.
Corrections
Review dates and corrections
Every page shows who wrote it, when it was published, and when it was last reviewed and by whom. The guides and articles also end with a box about the author.
Those dates are maintained. When a page changes substantively, the reviewed date changes with it, and the page's structured data reports the same date. The change is listed, dated, in an update log at the foot of the page. So a page carrying a recent review date has been recently looked at.
When we get something wrong, we correct it on the page rather than quietly deleting it, and material corrections are noted. A correction that leaves no trace is indistinguishable from never having been wrong, which is convenient for us and useless to you.
What we will not publish
-
Invented figures.
No benchmark we did not run, and no number without a source.
-
Fabricated testimonials, ratings or logos.
There is no "4.9 out of 5" on this site, no greyed-out review badges, and no customer logos we do not have. When there is nothing real to show, we show the measurements instead.
-
Manufactured urgency.
No countdowns, no fake scarcity, no discount that expires when you reload the page.
-
Comparisons we cannot support.
Where this site says a competitor does something, it is something recorded and checkable, not something assumed.
-
Claims about security we have not built.
The security page says what it will not pretend, and the threat model marks every attack we know of as mitigated, partially, or not solved.
Contact
Telling us something is wrong
If a fact on this site is out of date, unsupported, or simply incorrect, write to support@mailbox-mcp.com and say which page and which sentence.
Provider behaviour changes, and the guides on this site describe provider behaviour, so some of what is written here will go out of date without anyone doing anything wrong. Being told about it early is worth more to us than being right in public, and corrections are made without argument about who noticed.
Content is written and reviewed by Mark McNeece, founder of BSolve IT Limited. On a company of this size the writer and the reviewer are the same person, and it is better to declare that than to imply an editorial board that does not exist.