Rejected, deferred, or placed as spam? Diagnose the earliest email failure

Preserve the message journey before changing it

Record campaign and template version, audience source, send timestamp, recipient provider, envelope sender, visible From, IP and domains, message ID, provider SMTP response and enhanced status code, retry history, raw received headers when available, authentication results, link domains, unsubscribe state, and relevant change log. Separate generated, submitted, accepted, deferred, rejected, bounced later, placed in spam during a controlled observation, and simply not found. These states occur at different steps. The mail-flow incident ladder starts at message generation and climbs only after each earlier step is supported. Do not rotate domains, rewrite content, and clean the list simultaneously; multiple uncontrolled changes make causal evidence disappear.

Evidence: Google Gmail Help; Yahoo

Rung one: confirm the system sent what the editor approved

Compare the scheduled audience, generated MIME artifact, envelope addresses, visible headers, HTML and text parts, URLs, attachments, unsubscribe headers, and actual submission logs. Look for empty fields, duplicate sends, malformed headers, excessive size, encoding errors, unsafe redirects, or a test mode that never transmitted. Verify that suppression and category rules were applied before generation. A dashboard marked delivered may mean accepted by the next server, not placed in an inbox. This rung is supported when the defect reproduces before the mailbox provider evaluates reputation. Correct the generation or queue, cancel remaining copies, and preserve a fixed artifact for the next rung.

Evidence: Internet Engineering Task Force; Messaging, Malware and Mobile Anti-Abuse Working Group

Rung two: reconcile domain authorization and alignment

Inspect authoritative DNS, SPF evaluation, DKIM signatures and selector retrieval, DMARC alignment and policy, reverse DNS, transport security, and all legitimate senders. Compare received Authentication-Results rather than trusting setup badges. Segment failures by sending system, selector, IP, domain, and provider. A new vendor or expired selector can create partial failure while aggregate reporting looks normal. Gmail and Yahoo publish provider requirements, especially for higher-volume senders; verify current official language. Repair unauthorized or misaligned streams cautiously, observe propagation, retest, and avoid policy enforcement that rejects a legitimate forgotten source before it is reconciled.

Evidence: Google Gmail Help; Yahoo

Rung three: read provider responses by cohort

Group SMTP codes and delays by mailbox provider, IP, domain, message category, acquisition source, and time. Permanent recipient errors, temporary resource deferrals, rate limits, and policy blocks are not interchangeable. Consult the provider's official error documentation linked from operational guidance where available. Check volume spikes, retry behavior, complaint evidence, invalid addresses, infrastructure changes, and shared-provider incidents. An issue confined to one provider suggests different evidence from a failure across all destinations. Do not hammer temporary errors with aggressive retries or move to a fresh domain to escape history. Follow provider limits, pause abnormal streams, and let a controlled retest distinguish a resolved configuration from continuing reputation harm.

Evidence: Google Gmail Help; Yahoo

Rung four: distinguish observed placement from assumed placement

If the provider accepted the message, inspect controlled inboxes and available provider tools while acknowledging their limits. Seed placement is anecdotal, and open tracking may be obscured or automated. Compare complaint, unsubscribe, reply, verified click, resource access, and direct support feedback. Review sender recognition, subject accuracy, text and link reputation, accessibility, and whether content resembles the signup promise. A spam-folder observation can support but not quantify a population outcome. If authentication and transport are sound yet complaints concentrate in one acquisition source, the earlier permission decision may be the real failure. Stop that source rather than polishing HTML around unwanted mail.

Evidence: Google Gmail Help; Messaging, Malware and Mobile Anti-Abuse Working Group

Rung five: verify the recipient still controls the relationship

Test visible unsubscribe and, where applicable, RFC 8058 one-click behavior through suppression and queued jobs. Examine complaint feedback, stale or purchased data, signup copy, cadence change, brand change, and re-import. A broken exit can turn dissatisfaction into provider complaints and continued mail. It is also an incident independent of placement. Gmail and Yahoo rules and M3AAWG practice make list and expectation quality central. Do not ask recipients to rescue reputation through artificial replies, safe-sender requests, or misleading engagement campaigns. Relevance begins with permission and a useful message; recipient choice is not a performance hack.

Evidence: Internet Engineering Task Force; Messaging, Malware and Mobile Anti-Abuse Working Group

Fix one earliest rung and rerun the same path

The next action is to fill the incident ladder for one affected cohort, record supporting and contradicting evidence, and pause sending when identity, permission, or suppression is uncertain. Apply one reversible correction, send the preserved test artifact through the same intended route, and compare the same provider evidence. Limits remain: proprietary filtering prevents complete explanations, logs expire, seed tests are narrow, and simultaneous external changes can confound results. Close the incident with affected scope, root cause, remediation, retest, owner, and prevention trigger. A temporary improvement after switching domains is not proof and may conceal rather than repair the original fault.