Under RFC 9989 §5.4, a DMARC pass does not guarantee inbox placement. It establishes an aligned domain-authentication result for a message. A receiving service can still reject the message for another reason, accept it into spam, place it in the inbox or apply later user-specific handling.
This boundary matters because the wrong diagnosis creates the wrong change. DNS cannot repair poor consent, sustained complaints or unwanted content. Conversely, reputation work does not fix an unaligned authentication path.
Separate the stages of delivery
Use four distinct measurements:
- Stage: Authentication; Question: Did SPF or DKIM pass, and did at least one passing identity align with From?
- Stage: Acceptance; Question: Did the receiving server accept the message during SMTP?
- Stage: Placement; Question: After acceptance, where did the receiver place or expose the message?
- Stage: Engagement; Question: What did the recipient do, and how reliable is that measurement?
Positive SMTP completion after end-of-data is specified in RFC 5321 §4.2.5. A message can pass authentication and fail acceptance. It can be accepted and placed in spam. It can reach the inbox and receive no useful engagement. Do not describe all four outcomes as deliverability.
Read a fictional diagnostic table
The following cases are synthetic. They illustrate how to choose the next investigation without claiming observed performance.
- Observation: DMARC; Case A: Pass; Case B: Pass; Case C: Fail
- Observation: SMTP; Case A: Accepted; Case B: Accepted; Case C: Rejected with authentication-related response
- Observation: Placement; Case A: Spam; Case B: Inbox; Case C: No delivered copy available
- Observation: Complaints or recipient signals; Case A: Elevated complaints; Case B: Normal for the defined cohort; Case C: Not applicable to rejected message
- Observation: Next focus; Case A: Consent, expectations, reputation, content and sending patterns; Case B: Continue monitoring comparable traffic; Case C: Identity chain, signing, SPF path and provider response
In Case A, changing DMARC from none to reject does not address why authenticated messages are unwanted. Investigate list provenance, suppression, frequency, content and provider feedback. In Case C, inbox testing cannot begin until the authentication-related rejection is understood.
Use authentication as a prerequisite, not a reputation shortcut
Mailbox providers publish requirements and recommendations for senders, such as Google’s guidelines for personal Gmail recipients. Those requirements can include SPF, DKIM, DMARC, valid DNS, transport practices, complaint controls and easy unsubscribe for applicable traffic. Meeting one requirement does not waive the others.
Authentication is valuable because it creates stable domain identity and helps receivers attribute mail. It does not purchase reputation, prove recipient consent or guarantee favourable treatment. Reputation and classification decisions are receiver-specific and can vary by traffic stream, recipient and time.
Do not infer causation from a simultaneous DNS change and placement change. A sending programme can change volume, audience, content and infrastructure at the same time. Record interventions and compare like-for-like cohorts before drawing a conclusion.
Diagnose with evidence from the relevant receiver
Start with the actual SMTP response and trusted authentication results within the boundary specified by RFC 8601 §7.1. If the message was rejected, the code and accompanying text can identify a category, but the code alone is not a complete diagnosis. Provider documentation and sending logs are needed to interpret it.
If the message was accepted, use available provider telemetry, seed testing with stated limitations, recipient reports and controlled campaign data. A test mailbox is evidence about that mailbox and message, not a universal prediction for every recipient.
For authentication, record From, the evaluated SPF identity, every DKIM d= domain, alignment and the applicable policy. For programme health, record traffic stream, volume, complaint information, suppression behaviour, list origin, content changes and timing.
Treat engagement metrics carefully
Open rate is not a reliable standalone proxy for inbox placement or human attention. Apple’s Mail Privacy Protection downloads remote content in the background regardless of engagement. Mailchimp’s open-tracking guidance also documents blocked tracking images and client-format limitations. Clicks can also include automated security scanning, as described in Mailchimp’s bot-activity guidance.
Define the population and measurement method. Combine delivery responses, complaints, unsubscribe behaviour, provider evidence and business outcomes. Avoid claiming improvement from one metric without a comparable baseline and an explanation of confounding changes.
Avoid DNS changes that target the wrong problem
Do not add another SPF include because an authenticated campaign lands in spam. Do not weaken alignment to chase placement. Do not publish duplicate SPF records. Do not move to reject solely because a test message reached an inbox.
DNS changes should solve a demonstrated identity or policy problem. Sending-practice changes should solve consent, frequency, content, segmentation or reputation problems. Sometimes both workstreams are needed, but they should retain separate owners and evidence.
Build a joint diagnostic record
A useful case record contains:
- the exact sender, From domain and traffic stream;
- a representative message and trusted authentication results;
- SMTP response and timestamp;
- observed placement with method and limitations;
- complaint, suppression and recipient evidence available for that cohort;
- recent technical and programme changes;
- a hypothesis, owner, intervention and review date.
This format turns the question "Did DMARC fix deliverability?" into testable questions. Did authentication improve? Did acceptance change? Did placement change for comparable mail? Did recipient response improve without shifting the audience?
For the identity evidence, use the email identity-chain guide. For a monitoring baseline, continue with the DMARC monitoring-policy guide.
Keep the conclusion within the evidence
For Case A, retain the authenticated-but-spam observation and investigate the stated complaint evidence; for Case C, preserve the actual rejection before investigating inbox placement. Compare the same measurement method and cohort across changes. Automated opens or clicks are not proof of a human action. These cases are fictional, not campaign measurements or promises of improvement.