How to read an inbox placement report without overclaiming

First confirm what was tested

Before circulating a screenshot, check the sender, sending service, message version, date and selected test accounts. A reassuring report from a director's mailbox does not validate an ATS-generated campaign sent by a different service.

Keep the report reference with that context. Without it, a green dashboard can turn into an unsupported statement that “email is fixed”.

Separate the kinds of result

For a missing result, check sending success, timing and the service's own status explanation before drawing a conclusion. Keep it marked as unresolved if you cannot establish what happened.

Read by recipient environment

Candidate updates and client business development can reach very different receiving systems. Look for a pattern in relevant test accounts, but do not equate a personal Outlook.com address with every Microsoft 365 tenant.

If a real client confirms quarantine, keep that evidence even when the seed report looks healthy. Their administrator may be able to inspect the actual receiving decision. Microsoft's message trace documentation explains why a Delivered status can still require examination of filtering events.

A worked example for an agency

The following is a hypothetical decision exercise, not an observed test result.

An agency tests its candidate update from the ATS. Most seed accounts show inbox placement; one group shows spam. An ordinary mailbox version of the same message then looks different.

The useful conclusion is narrow: the routes produced different observations under those test conditions. It is not proof that the ATS is broken, that a provider blocks recruitment agencies, or that buying another mailbox will repair the campaign.

The next useful record would contain:

1. Which route produced each message and whether the visible sender matched.
2. The actual authentication results recorded for both messages.
3. Differences in tracking links, message formatting and attachments.
4. A single proposed change for the authorised administrator to evaluate.
5. A comparable follow-up and any real recipient evidence.

Use the test record template to keep the comparison clear. Our header explainer can help read recorded results locally, but does not establish whether a header is trusted.

Authentication is a foundation, not the verdict

SPF, DKIM and DMARC answer authentication questions. Google's sender guidance also addresses message formatting, recipient expectations and reported spam. An authenticated message can still be unwelcome or filtered.

If a pass is recorded, check that the relevant identity aligns with your visible sending domain rather than assuming any pass is enough. If this distinction is unclear, use the authentication guide before changing DNS.

Turn the report into a decision

Finish with four short statements: what was observed, what remains unknown, what will change, and how you will check it. “Retest next week” is not a complete action unless someone owns it and knows what comparison to make.

A repeatable process is more useful than a screenshot passed around without context. If your current evidence already identifies a configuration error, resolve it before commissioning more placement tests.