Check email deliverability without promising an inbox

Keep the stages separate

An application creating an email, a sending service accepting it and a recipient reading it are different events. A successful API or SMTP response is useful operational evidence, but it does not by itself show which mailbox folder received the message or whether the person used it.

Choose reporting words that match the evidence. A provider may expose accepted, delivered, deferred or bounced states with its own definitions. Keep those definitions beside the report and investigate a result that the service cannot confirm, instead of translating every success code into inbox delivery.

Understand the identities around the message

SPF describes which sending systems are authorised for a domain used in the mail transaction. DKIM supplies a domain-linked signature for message content and selected headers. DMARC adds a policy and alignment framework connecting authentication to the visible From domain. The standards linked below explain those roles in detail.

For a publication, the practical task is to establish which service sends the mail, which domains it uses and who controls their configuration. Copying a DNS record from another organisation does not establish that relationship. Authentication is necessary operational work, not a guarantee of placement or engagement.

Review the receiving provider’s requirements

Receiving providers publish their own sender guidance. Google’s guidelines for mail to personal Gmail accounts address authentication, TLS, message format and sending behaviour, with additional requirements for higher-volume senders. Consult the current guidance for the destinations and scale you operate rather than relying on a remembered threshold.

Use a recognisable, authorised sender and an appropriate route for replies. Keep the promised newsletter, and the way people join it, consistent with what you send. Review repeated failures and complaints instead of treating more sending as a remedy for an unexplained problem.

Read each signal at its own evidence level

Before filling in an incident, decide what each available signal can establish. The rows below restate the limits already given in this guide. They add no provider rules, and any provider’s own definitions stay beside the report.

• Application request: the application attempted an operation. It does not show that the sending service took the message.
• Acceptance response from the service (API or SMTP): useful operational evidence of acceptance. By itself it does not show which mailbox folder received the message or whether the person used it.
• Deferred or bounced event: a state reported with that provider’s own definition. Each is a different investigation from a message found in a spam folder, and neither is evidence of inbox delivery.
• Authentication results in a received copy: how that copy presented against the intended sender configuration. They are necessary operational work, not a guarantee of placement or engagement.
• Observed folder in one controlled account: where that particular message was found, in that account, when it was checked. One successful test is valuable, but it does not justify promising that every future reader will receive every issue in the inbox.
• No recipient-side observation yet: leave placement unresolved and retain any acceptance or provider-event evidence separately.
• Write each finding at the highest level you actually observed, and no higher.

Worked example: the service says sent, the reader sees nothing

Imagine a small newsletter team receives an acceptance response from its sending service while a controlled recipient cannot find the message immediately. The team first checks the exact request and the provider status. If the message is deferred or bounced, that is a different investigation from a message found in a spam folder.

For a message that arrives, inspect the authentication results in the received copy and compare them with the intended sender configuration. Record the observed folder and account as part of that particular test. One successful test is valuable, but it does not justify promising that every future reader will receive every issue in the inbox.

Keep an incident record with evidence levels

A small team can investigate an apparent missing message more effectively if it records the same fields each time. Keep recipient-specific values private, and use a redacted version when sharing an example.

• The intended operation and the publication or message type involved.
• The controlled test account and approximate observation time, in the private record.
• The sending-service response and its documented meaning.
• Any later provider event, including deferral or bounce, with its own meaning.
• Authentication results from a received copy, when one is available.
• The observed location of that particular message and what was checked.
• The unresolved question and the next controlled action, without an automatic resend.

A hypothetical incident timeline

The incident below is invented to show how the record is filled. It uses a fictional publication, a controlled test mailbox called Account A (its real address would stay in the private record) and relative times only. No real campaign, provider log, address or measured result sits behind it, and it establishes nothing about how any real sender performs.

• Step 1, request: the team’s application asks the sending service to send a test copy of a fictional issue to Account A. Evidence level: the application’s own request log. Nothing about the recipient is established.
• Step 2, service response: the service reports that it accepted the request. Evidence level: acceptance. The team files the provider’s own definition of that word with the record.
• Step 3, first look: shortly afterwards the reviewer checks Account A and cannot find the message. Evidence level: one observation at one moment, which is not yet a finding that the message is missing.
• Step 4, status check: the reviewer looks up the provider’s status for that exact request, not a similar one. The timeline now branches on what that status reports.

Branches after the status check

Each branch below ends at the evidence level actually reached. None ends in a conclusion about future readers.

• Branch A, accepted with no later event: the record stays at acceptance level and is marked unresolved. The next controlled action is to check again at a planned later time and to look in the other folders of Account A. There is no automatic resend, because a second copy would blur which message was observed.
• Branch B, deferred: the reviewer notes the event and the meaning the provider’s documentation gives it, then rechecks at a planned time. Until a later event or an observation appears, the record claims neither delivery nor failure.
• Branch C, bounced: the reviewer copies the provider’s bounce record, with its own documented meaning, into the private record and investigates the reason it gives. This is a different investigation from a spam-folder question. If the address concerned ever belonged to a real reader instead of a controlled test account, the email validation guide discusses the limits of certainty about addresses.
• Branch D, message found: the reviewer records the observed folder and account, then inspects the authentication results in the received copy and compares them with the intended sender configuration. Branch D1 is a message in the junk folder; Branch D2 is a message in the inbox. In both, the finding is limited to that copy, in that account, at that time.

The same record, filled in for two branches

Both records are hypothetical and follow the seven fields listed above. Bracketed values stand for details that would stay in the private record. Branch D1 first:

• Operation and message type: test copy of an issue of a fictional publication.
• Account and time: Account A [address kept private], checked shortly after the request.
• Service response: accepted, with the provider’s definition filed beside it.
• Later provider event: none seen when checked.
• Authentication results: read from the received copy; in this invented case they match the intended sender configuration.
• Observed location: the junk folder of Account A, after the other folders were also checked.
• Open question and next action: this evidence cannot explain why the copy was filed there. Repeat the controlled test with a second controlled account, review recent failure and complaint records, and confirm that the sender and the signup promise are consistent. No automatic resend.

Reading the second record: Branch C

Branch C fills the same fields differently: the service accepted the request, then reported a bounce with its documented meaning. In this scenario no received copy is available for authentication inspection and no recipient folder was observed. The next question is what the provider’s recorded reason establishes; the person responsible investigates it before any controlled next action.

Notice what both records leave out: any statement that the sender is healthy or unhealthy. They hold what was observed, at which level, and what is still unknown.

Connect delivery to the rest of the operation

A technically authenticated message still needs a clear purpose, usable links and a way for readers to stop. The unsubscribe guide covers that operational path, and the welcome guide helps make the first messages recognisable.

Use click analysis to discuss engagement carefully, and keep technical diagnostics separate from editorial outcomes. Do not publish subscriber addresses, provider secrets or recipient-specific access links in a troubleshooting example.