# Email Deliverability: Diagnose Problems Before Your Next Send

> This is the Markdown version of this article, built for AI assistants and agents. The human page is at https://www.spaceoffice.ai/blog/email-deliverability.

By the Space Office team · Published 2026-10-10 · Updated 2026-10-10 · 17 min read · Category: Guide

Email deliverability is the ability of your email to reach the intended recipient's inbox. Diagnose problems by separating server acceptance from inbox placement, then checking the affected provider, authentication, recipient permission, unsubscribe handling, and recent sending changes. A delivered event alone does not prove inbox placement. In Space Office, Phosphorus can prepare an email preflight from approved evidence, and Hydrogen coordinates and reviews the findings. The human account owner approves DNS changes and sending decisions. No checklist or specialist can guarantee that a mailbox provider will place a message in the inbox.

![Email deliverability review with a Space Office email specialist checking a message route before Hydrogen and a human approve the next send](https://www.spaceoffice.ai/blog/email-deliverability/cover-v1.webp)

_Diagnose the sending path, prepare evidence, and let the account owner decide when another send is appropriate._

## Key takeaways

- Start with the affected provider and message stream; a sitewide average can hide one failing route.
- Keep delivery, inbox placement, recipient complaints, and business outcomes as separate observations.
- Verify authentication on an actual received message, alongside the email platform's domain settings.
- Check recipient permission and working suppression before considering another marketing send.
- Give Phosphorus evidence and a bounded question; Hydrogen reviews the packet, and a person owns the final decision.

If your sending route works and you need to plan the campaign itself, use the [email marketing guide and worksheet](/blog/email-marketing) to choose an audience, write a useful sequence, and measure the next action. This guide focuses on investigating delivery problems and checking the sending path.

## Start email deliverability diagnosis with the missing evidence

The first useful question is specific: which messages failed to reach which recipients, through which sending route, during which period? A newsletter owner reporting fewer clicks and a product team reporting missing password resets may have different problems. Name the stream, provider, campaign or event, and time window before changing anything. Write down what prompted the investigation: recipient reports, delivery errors, a provider warning, or a change in an engagement metric. The trigger is evidence to investigate, not the diagnosis itself.

Delivery and placement describe different stages. [Twilio SendGrid's metric definitions](https://www.twilio.com/docs/sendgrid/ui/analytics-and-reporting/deliverability-insights) explain that its delivered metric records acceptance by the recipient's mailbox provider; that provider subsequently decides where to put the message. Therefore, a high delivery percentage cannot establish a high inbox-placement percentage. Record the metric's definition, numerator, denominator, and reporting window before comparing dashboards. Do not rename a platform's acceptance metric as an inbox rate in a stakeholder report.

| Observation | What it establishes | Useful next evidence |
| --- | --- | --- |
| Provider accepted a message | The sending platform recorded acceptance at that stage; placement remains a separate question. | A recipient's received message and folder report, with the original headers where available. |
| Campaign contains rejected or deferred events | Some attempts did not complete as intended; the event text determines what happened. | Full response text, timestamps, provider, sending route, and the platform's later status. |
| Several recipients report missing email | Those people could not find the expected message; the sample does not describe the whole list. | Confirm addresses, intended send events, suppression status, timing, and where recipients looked. |
| Clicks or conversions decreased | The measured outcome changed; the reason remains open. | Delivery evidence alongside audience, message, offer, tracking, and website changes. |

Use each observation to choose the next check. These are diagnostic distinctions, not universal performance benchmarks.

Keep an unknowns column. If nobody has inspected a received message, mark placement unknown. If provider data is missing, state that limitation. Two test inboxes can reveal a reproducible configuration problem without representing every subscriber. Likewise, a recipient screenshot is useful evidence about that recipient, not proof of a domain-wide failure. This discipline keeps an investigation focused and makes the eventual change easier to defend.

![An email specialist and a human inspect message authentication beside an accepted-message server and separate inbox and warning trays](https://www.spaceoffice.ai/blog/email-deliverability/diagnosis-scene-v1.webp)

_Acceptance logs, recipient observations, and authentication results answer different questions._

## How to test email deliverability before changing the send path

Choose a recent affected send and a comparable earlier send. Keep the same message purpose and recipient provider where possible. A transactional receipt is a poor baseline for a promotional announcement, even when both use the same brand. Ask the account owner for narrowly scoped exports and examples. Remove unrelated recipient details from the working packet and keep access to account settings with the people authorized to use it. A specialist can analyze an export without acquiring permission to change the account.

1. Identify the route. Record the sending application, visible From domain, message purpose, and any provider-managed infrastructure. Include the campaign or event identifier so the account owner can find the original record.
2. Capture event evidence. Export the attempted, accepted, rejected, and still-pending counts using the platform's own definitions. Save representative error text and the period's timezone. Keep repeat attempts distinguishable from unique messages.
3. Request message evidence. Obtain a received test or recipient-provided example through an authorized channel. Preserve its authentication results and relevant headers; a screenshot of the email body cannot show those checks.
4. Explain the audience. Record how recipients subscribed, which message they expected, the latest suppression update, and whether the audience selection changed. A large row count says nothing about permission or current expectations.
5. List recent changes. Include platform migration, sender identity, domain configuration, volume, template, segmentation, and unsubscribe processing. Record who changed each item and when instead of relying on a vague memory of the last campaign.

Turn the packet into one sentence that can be tested: for example, “The new newsletter route shows failed authentication in received examples, while the older route passes.” That is narrower and more useful than “our domain is damaged.” Attach the examples and explain the uncertainty. If the two routes sent to different audiences, say so. If no comparable earlier message exists, the first job is to capture a baseline, not to manufacture one from unrelated traffic.

For a controlled test, use the same sending application, From identity, and message stream as the affected campaign. Send only to test addresses you control or to people who agreed to the test. Record the provider response, where the message appeared, and the received authentication results. A generic test sent through a different route can pass while the production route remains misconfigured. Repeat the same checks after an approved change so the before-and-after evidence stays comparable.

| Test or evidence | Useful finding | What it cannot establish |
| --- | --- | --- |
| Provider event log | Whether the receiving server accepted, deferred, or rejected the checked messages | Which folder an accepted message reached |
| Received message headers | Authentication results for that message and sending route | Permission, content quality, or placement for all subscribers |
| Controlled inbox or seed test | Placement in the tested mailbox at the test time | The placement rate across your actual audience |
| Controlled unsubscribe test | Whether the tested marketing subscription is suppressed afterward | That every connected list or future import preserves suppression |

Read each test result within its scope; no single score proves inbox placement for every recipient.

![Email diagnosis moves through Observe, Authenticate, Diagnose, and Review: compare provider records, check identity, investigate the evidence, and let the owner approve the next step](https://www.spaceoffice.ai/blog/email-deliverability/diagnostic-workflow-v1.webp)
Phone layout: ![Email diagnosis moves through Observe, Authenticate, Diagnose, and Review: compare provider records, check identity, investigate the evidence, and let the owner approve the next step](https://www.spaceoffice.ai/blog/email-deliverability/diagnostic-workflow-mobile-v1.webp)

_A bounded investigation produces a documented next decision, including a decision to wait for missing evidence._

## Check authentication against the actual recipient provider

Authentication establishes facts about a message's sending identity; it does not establish that a recipient wants the message. SPF authorizes sending infrastructure for a domain. DKIM adds a verifiable signature. DMARC checks the visible From domain against a passing SPF or DKIM identity and publishes handling policy. [Yahoo's authentication explanation](https://senders.yahooinc.com/faqs/) describes these mechanisms together. In a review packet, record the result for the actual message rather than merely writing that all three records exist.

| Recipient provider | Authentication requirement | Other checks to include |
| --- | --- | --- |
| Personal Gmail | All senders: SPF or DKIM. Bulk senders: SPF and DKIM plus DMARC, with p=none permitted; the From domain must align with passing SPF or DKIM. | Valid forward and reverse DNS, TLS, and the applicable message and unsubscribe requirements. |
| Yahoo | All senders: at least SPF or DKIM. Bulk senders: both, plus passing DMARC with a valid policy of at least p=none and aligned identity. | Valid forward and reverse DNS, applicable format requirements, complaint monitoring, and easy unsubscribe. |

Provider requirements checked October 10, 2026. Consult the linked requirements for full scope and updates.

The matrix summarizes [Google's sender guidelines](https://support.google.com/mail/answer/81126?hl=en) and [Yahoo's requirements](https://senders.yahooinc.com/best-practices/). Keep their scopes separate. Google's [sender FAQ](https://support.google.com/mail/answer/14229414?hl=en) describes bulk senders as reaching close to 5,000 messages or more to personal Gmail accounts in 24 hours, aggregates the same primary domain and its subdomains, and says bulk status is permanent once assigned. [Yahoo does not publish a numeric bulk-sender threshold](https://senders.yahooinc.com/faqs/). Do not apply Gmail's number to Yahoo or treat moving traffic between subdomains as a classification workaround.

A useful configuration review has two pieces: the platform says the intended domain is configured, and a message sent through the intended route shows the expected authentication outcome. Ask the owner to compare the visible sender identity with the authentication results. If they differ from the intended setup, record the mismatch and obtain platform-specific help. Do not paste a generic DNS record from a blog into production or delete an existing sender's record to make a new platform's screen look green.

For a concrete example, [Mailchimp distinguishes domain verification from domain authentication](https://mailchimp.com/help/set-up-email-domain-authentication/). Verification confirms access to an email address; authentication involves domain configuration. Its documented manual setup currently uses two CNAME records and one TXT record. Those are Mailchimp instructions, not a universal recipe. The DNS owner should use the exact values issued for their account, check existing dependencies, perform approved changes, and confirm the resulting message. Keep the previous configuration and change record so a mistaken edit can be investigated.

## Verify audience permission and the unsubscribe result

Treat recipient selection as part of the send path. Ask why each segment expects this particular type of message now. A purchase receipt, a product-update subscription, and a newsletter signup express different relationships. Document the permitted message purpose before combining lists. For this workflow, use people who requested the relevant mail; omit purchased contacts and any segment whose permission cannot be established. An address that exists is not evidence that its owner asked for a campaign.

Google requires one-click unsubscribe and a visible body link for bulk marketing and subscribed messages. Yahoo requires functioning one-click unsubscribe for those bulk messages, a visible body link, and honoring requests within two days. Its [requirements page](https://senders.yahooinc.com/best-practices/) recommends the POST method while also accepting mailto. For a shared implementation that satisfies Gmail's one-click specification, check the platform's RFC 8058 support rather than assuming an ordinary footer link is sufficient.

[RFC 8058](https://www.rfc-editor.org/rfc/rfc8058.html) specifies List-Unsubscribe and List-Unsubscribe-Post headers, an HTTPS POST operation, and a valid DKIM signature covering those headers. The recipient should not have to log in or complete a confirmation page for that operation. Ask the platform owner to test with a controlled subscription, inspect the received message, exercise the intended unsubscribe path, and verify the resulting suppression. A link that opens successfully has not yet proved that future sending will stop.

Write the expected result before testing: this controlled subscriber should leave the relevant marketing audience and remain suppressed when that audience is rebuilt. Check imports, scheduled campaigns, and connected applications that might reintroduce the address. Keep necessary operational messages distinguishable from promotional subscriptions. If suppression cannot be confirmed, pause the affected marketing send and resolve the workflow. Generating more persuasive copy cannot repair a subscription system that ignores the recipient's decision.

![Sender review checklist covers Identity, Audience, Exit, and Monitor: check authentication, permission and suppression, a working unsubscribe path, and owner-controlled stop rules](https://www.spaceoffice.ai/blog/email-deliverability/sender-checklist-v1.webp)
Phone layout: ![Sender review checklist covers Identity, Audience, Exit, and Monitor: check authentication, permission and suppression, a working unsubscribe path, and owner-controlled stop rules](https://www.spaceoffice.ai/blog/email-deliverability/sender-checklist-mobile-v1.webp)

_These four checks organize the preflight. They do not replace the complete requirements of the receiving provider._

## Worked example: investigate a newsletter migration

Consider an illustrative software company moving a requested product newsletter to a new email platform. This is a teaching example, not a Space Office customer result. The team observes more failed events after migration. The next newsletter is queued, but the account owner holds it while gathering evidence. Password-reset mail uses a separate application and has no observed change; the investigation begins with the newsletter route rather than assuming every company message is affected.

| Illustrative observation | Working interpretation | Next action |
| --- | --- | --- |
| The old platform recorded 980 accepted messages from 1,000 attempts; the new one recorded 920 from 1,000. | Acceptance changed from 98% to 92%, a six-percentage-point decrease. Inbox placement was not measured. | Compare provider-specific response text and determine whether attempted messages are counted consistently. |
| The new route's received test shows an unexpected authentication identity. | There is a concrete configuration question; the test does not yet explain every failed event. | Have the domain owner compare the issued platform settings with the actual message results. |
| A controlled subscriber uses the opt-out, but still appears in a rebuilt campaign audience. | Suppression is not demonstrated end to end. | Stop the campaign and repair the audience rebuild before any approved retry. |

Invented numbers and observations illustrate the diagnosis process. They are not a deliverability benchmark or a promised outcome.

The arithmetic is simple: 980 divided by 1,000 is 98%; 920 divided by 1,000 is 92%. The difference describes acceptance in these two batches. It says nothing about how many accepted messages reached an inbox, and it does not prove migration caused the change. The audiences, timing, and provider mix may differ. Keep the recorded facts separate from the hypothesis that the new route's authentication or suppression configuration needs repair.

The owner now has two reviewable tasks. First, ask the platform and DNS owners to resolve the authentication mismatch and capture fresh message evidence. Second, repair the suppression flow and repeat the controlled unsubscribe test. Give each task an owner and acceptance check. Neither task requires sending another full campaign to discover whether the fix worked. After the checks pass, a person can consider a limited, appropriate next send to recipients who requested the newsletter, using the platform's guidance and the team's monitoring plan.

Keep a timestamped record of each approved change and the evidence collected afterward. If authentication passes but the receiving provider still rejects messages, preserve the response and escalate that specific problem. Do not declare the incident solved because one test arrived. Conversely, do not keep rewriting subject lines when the evidence points to an infrastructure setting. The useful outcome is a narrower diagnosis and a defensible next action, even if that action is to wait for the provider's support team.

## Give Phosphorus a bounded preflight and keep the decision human

The [Space Office live roster](/agents) identifies Phosphorus as the Email Marketing Specialist, with responsibilities covering send-path classification, authentication, list hygiene, reputation monitoring, and GO or NO-GO preflight. Hydrogen coordinates specialist work and reviews outputs before delivery. A useful request is: review this newsletter route using the attached evidence, identify unresolved checks, and prepare a recommendation for the account owner. That request produces a review packet instead of granting open-ended permission to modify infrastructure or send campaigns.

1. The customer supplies the purpose, approved audience criteria, platform documentation, selected event exports, received-message examples, and authorized account context. State which data is unavailable and which systems may be inspected.
2. Phosphorus organizes the evidence by sending route and provider, checks the preflight against current documentation, and separates observed failures from hypotheses. Any missing evidence stays visible in the recommendation.
3. Hydrogen reviews the packet against the brief, asks for unresolved claims to be corrected, and coordinates the handoff. The output includes proposed changes, their owners, verification steps, and a clear reason for GO or NO-GO.
4. The human account owner approves any DNS or platform change, checks the resulting evidence, and makes the next-send decision. A NO-GO remains a stop until the stated issue is resolved and reviewed again.

Access is an explicit input. The role description does not connect an email account, authorize DNS changes, import recipients, or publish a campaign automatically. If only exports are available, the specialist's conclusion should say that live configuration could not be independently checked. If the owner can provide a received-message sample but no provider dashboard, use that sample within its limits. A smaller honest report is more useful than a complete-looking report filled with assumed passes.

For this diagnostic task, Phosphorus can handle the email-specific review without adding a copy specialist just to enlarge the team. If the owner later identifies a separate writing need, Nitrogen can draft a clearer subscription explanation or message from approved facts. Keep that writing assignment separate from technical approval. See [how Space Office work is coordinated](/how-it-works), or [describe the existing setup](/contact) before deciding which access and specialist support are appropriate.

![Phosphorus presents a controlled-send setup beside Hydrogen while the human account owner reviews unresolved checks](https://www.spaceoffice.ai/blog/email-deliverability/review-scene-v1.webp)

_Specialist analysis and review by Hydrogen prepare the decision; the account owner approves changes and sending._

## Measure the next send without inventing a recovery claim

Before the next approved send, write the conditions that would make the owner pause again. Tie them to the actual incident: recurring authentication failure, repeated rejection text, an unresolved suppression test, or a new provider warning. Specify who watches the evidence and how they can stop the affected campaign. Do not borrow a universal volume ramp or recovery deadline from a different sender. The relevant starting point is this account's observed behavior and the provider's guidance.

Track complaints using each provider's definition. [Google recommends](https://support.google.com/mail/answer/81126?hl=en) keeping Postmaster spam rates below 0.10% and avoiding 0.30% or higher. [Yahoo requires](https://senders.yahooinc.com/best-practices/) rates below 0.3% and says its calculation uses mail delivered to the inbox. These are provider-specific signals, not interchangeable campaign percentages. Label an unavailable rate as unavailable and keep raw observations beside the dashboard value wherever the platform provides them.

Use a short incident log with the time, message stream, provider, accepted and failed counts, representative responses, configuration checks, recipient reports, and owner decision. Compare like periods and audiences when possible. Also record successful unsubscribe tests and any changes to selection rules. Report what improved and what remains unknown: “The observed authentication failure is resolved in the checked messages; wider inbox placement has not been measured” is a stronger statement than “deliverability fixed.” Continue watching the next relevant sends without treating a single result as a permanent guarantee.

## Make email deliverability a repeatable review decision

Good email deliverability work starts with a narrow question and ends with evidence the owner can inspect. Identify the affected route, distinguish acceptance from placement, verify identity and recipient expectations, and test that opting out actually changes future sending. Then make the smallest justified change and record its result. This method cannot control a mailbox provider's judgment, but it can stop a team from repeatedly sending through an unresolved problem.

For a Space Office workflow, begin with one Phosphorus preflight and Hydrogen's review of the findings. Give the owner a concrete recommendation, the supporting messages and logs, and the conditions that still require a NO-GO. When that packet is complete, the human can decide whether to change settings, request more help, or authorize a careful next send. The goal is accountable, requested communication with a traceable decision behind it.

## Sources and review notes

Reviewed against the linked primary sources on the checked dates. Search features and citations are selected by their respective platforms; no placement is guaranteed.

- [Google: Email sender guidelines](https://support.google.com/mail/answer/81126?hl=en) — checked 2026-10-10
- [Google: Email sender guidelines FAQ](https://support.google.com/mail/answer/14229414?hl=en) — checked 2026-10-10
- [Yahoo Sender Hub: Sender Requirements and Recommendations](https://senders.yahooinc.com/best-practices/) — checked 2026-10-10
- [Yahoo Sender Hub: FAQs](https://senders.yahooinc.com/faqs/) — checked 2026-10-10
- [Mailchimp: Set Up Email Domain Authentication](https://mailchimp.com/help/set-up-email-domain-authentication/) — checked 2026-10-10
- [Twilio SendGrid: Deliverability Insights](https://www.twilio.com/docs/sendgrid/ui/analytics-and-reporting/deliverability-insights) — checked 2026-10-10
- [RFC 8058: Signaling One-Click Functionality for List Email Headers](https://www.rfc-editor.org/rfc/rfc8058.html) — checked 2026-10-10

## Frequently asked questions

### What is email deliverability?

Email deliverability is the ability of an email to reach its intended recipient's inbox. It differs from a platform's delivery metric, which may record only acceptance by the receiving provider. Diagnose it with sending events, authentication evidence, recipient observations, and provider-specific signals. No single dashboard percentage proves that every accepted message reached an inbox.

### How do I test email deliverability?

Test the actual sending route with controlled recipients. Compare the provider's acceptance or rejection records, received authentication results, observed inbox or spam placement, and unsubscribe suppression. Record the time and settings, then repeat comparable checks after an approved change. An inbox-placement test describes the mailboxes it tested; it does not guarantee the result for your entire audience.

### Why can a message be delivered but missing from the inbox?

A delivered event can mean the receiving provider accepted the message before deciding its placement. Start with the actual message record and a recipient's report rather than assuming the folder. Confirm the address, expected send, timing, and suppression status. Ask for a received example if one exists, and keep the conclusion limited to the evidence collected.

### Does passing SPF, DKIM, and DMARC guarantee inbox placement?

No. Authentication checks the message's sending identity; it does not demonstrate that the recipient requested it or determine the receiving provider's final placement. Keep authentication results alongside audience, unsubscribe, and provider evidence. A passing test is an important configuration observation, but it cannot replace monitoring or the account owner's judgment about whether another campaign is appropriate.

### Should a small team copy a bulk sender's recovery schedule?

No fixed recovery schedule fits every route or incident. First establish whether the problem concerns configuration, audience selection, suppression, provider rejection, or a metric interpretation. Follow the platform's guidance for the actual account and define the conditions for pausing. An illustrative ramp from another sender is not evidence that your account is ready for the same volume.

### Can Space Office diagnose the problem without changing my email account?

Phosphorus can prepare a bounded preflight from the exports, message examples, and authorized context you provide. Hydrogen coordinates and reviews the findings. When live access is absent, the report should state which checks could not be confirmed. The human account owner approves infrastructure changes and sending decisions; the review does not automatically connect accounts or authorize publication.

---

Related: [A reviewed lead-generation workflow](https://www.spaceoffice.ai/blog/ai-agents-for-lead-generation) · [Choose a bounded AI-agent use case](https://www.spaceoffice.ai/blog/ai-agent-use-cases) · [AI support for newsletter operators](https://www.spaceoffice.ai/blog/ai-team-for-newsletter-operators) · [Meet the live Space Office specialists](https://www.spaceoffice.ai/agents)

---

Space Office — hire 24 live AI specialists coordinated by Hydrogen, an always-on AI project manager that reviews every output before delivery. The $60/month base includes Hydrogen and two specialists; additional specialists, dedicated compute, and AI usage cost extra. Learn more: https://www.spaceoffice.ai