SPF, DKIM and DMARC: what each result means

WHAT THIS GUIDE ANSWERS

What do SPF, DKIM and DMARC results actually tell me about an email, and what should I check when a message passes one test but not another?

SKY / EXPLANATORY MODELILLUSTRATIVE · NOT A LIVE TRACE

Three identifiers, two authentication paths, one recipient decision

01SMTP envelope / SPFMAIL FROM domain (or HELO when relevant) + connecting IP → evaluate the domain's SPF policy; produce a message-specific result.

02DKIM signatureSignature d= domain + s= selector → look up the DNS public key and verify the signed message; produce a separate result.

03Visible FromExtract the author domain in the message's From header; this is DMARC's alignment reference.

04DMARC alignment gateCompare the From domain with only passing SPF and DKIM identities; relaxed or strict alignment applies, and either aligned path is sufficient.

05Recipient handling and placementApply the published preference to DMARC failures as local policy permits, then distinguish SMTP acceptance/rejection from later filtering and Inbox/Junk placement.

01 / THE EVIDENCE

One email, several identities

Email uses more than one sender identity. During SMTP, MAIL FROM identifies the envelope sender domain, often used for bounces; the message's visible From header names the author a reader sees. SPF normally evaluates the MAIL FROM identity, while HELO/EHLO is relevant when the reverse-path is empty. A message can therefore pass SPF for one domain while displaying another in From. ^[1]

DMARC takes the domain in the visible RFC 5322 From header as its reference point. It asks whether a validated SPF identity or validated DKIM signing domain is aligned with that author domain. SPF and DKIM results alone do not answer that question: they authenticate domain-level identifiers, not whether the displayed From matches. ^[2]^[3]

02 / THE EVIDENCE

SPF: a published policy is not a message result

An SPF TXT record is a domain owner's declaration of which hosts are authorized to use a domain in the SMTP MAIL FROM or HELO identity. The receiver evaluates the connecting client IP against that policy and produces a result such as pass, fail, softfail, neutral, none, temperror or permerror. A record's existence is a DNS fact; an SPF pass is a result for a particular message, IP address and checked identity. ^[1]

A pass means the client is authorized for the identity SPF checked; it does not say the visible From domain is authenticated. For example, a legitimate sending platform can use an envelope domain of its own and receive SPF=pass, while the message displays your brand's domain. DMARC alignment is a separate comparison, not something implied by a passing SPF result. ^[1]^[3]

03 / THE EVIDENCE

DKIM: the d= domain behind a verified signature

A DKIM-Signature includes a d= tag naming the signing domain and an s= selector used to find the public key in DNS. The receiver uses that key to verify the signature over specified message headers and body content. A successful result means the signature checks against the key and signed content; it identifies the signing domain as taking responsibility for the signature, not necessarily the author shown in From. ^[2]

DNS may contain the selector's public-key record and yet a particular message can fail verification—for example, if the signature is invalid or signed content changed. Conversely, a valid DKIM signature can belong to a platform or domain different from the visible From. DMARC tests alignment between the passing signature's d= domain and From; it does not treat mere DKIM-key publication as a pass. ^[2]^[3]

04 / THE EVIDENCE

DMARC: at least one passing, aligned route

DMARC passes when at least one authenticated identifier aligns with the From author domain: either an SPF pass for the relevant envelope domain or a DKIM pass for a signature's d= domain. Relaxed alignment allows the same organizational domain; strict alignment requires an exact domain match. A failing or unaligned SPF result does not automatically fail DMARC if a DKIM signature passes and aligns, and vice versa. ^[3]

A DMARC policy record is another DNS object, normally published at _dmarc for the domain. Its p= tag expresses the domain owner's preference for mail that fails DMARC; p=none expresses no handling preference, rather than proving authentication. Provider rules are audience-specific: Google's personal Gmail guidance calls for SPF, DKIM and DMARC for bulk senders; Yahoo's bulk-sender guidance requires SPF, DKIM and a valid DMARC policy of at least p=none, with relaxed alignment acceptable. Check the current provider guidance for your recipient mix. ^[3]^[5]^[6]

05 / THE EVIDENCE

A pass is not an Inbox guarantee

Authentication answers a limited identity question, not whether a message is wanted, safe, or worthy of Inbox placement. The DMARC standard says the receiver's final handling remains a matter of local policy and that a receiver may reject or quarantine even a DMARC-passing message. Google likewise says authentication makes messages less likely to be rejected or marked as spam; that is not a placement guarantee. ^[3]^[5]

Keep the SMTP handoff distinct from mailbox placement. A positive completion reply after message data—commonly 250—means the receiving SMTP server accepted responsibility for delivering the message or properly reporting a later failure. It does not prove the message reached the Inbox, avoided Junk, or remained visible. To diagnose delivery, match the authentication evidence to the receiver's SMTP response and recipient-side outcome. ^[4]

ILLUSTRATIVE / SYNTHETIC

Fictional illustration — not a live DNS test

Example only. No customer message, real mailbox or live account data is shown.

01Visible header: From: Billing <billing@example.com>

02SMTP envelope: MAIL FROM:<bounce@mailer.example.net>

03DNS and message result: SPF policy exists for mailer.example.net; SPF=pass for this message.

04DKIM-Signature: d=mail.example.com; s=txn1; receiver result: DKIM=pass.

05DMARC record: _dmarc.example.com TXT "v=DMARC1; p=none; aspf=r; adkim=r".

SPF passes for mailer.example.net, but that domain is not aligned with the visible example.com From domain. DKIM passes for mail.example.com, which shares example.com's organizational domain under relaxed alignment; therefore DMARC passes by the DKIM path. With p=none the published policy expresses no preference for handling DMARC failures. None of these results establishes Inbox placement: a final SMTP 250 is a handoff of responsibility, not evidence of where the message later appears.

FROM EXPLANATION TO INVESTIGATION

What to check next

01Preserve the original message and receiver-generated Authentication-Results header; record the exact From domain, spf= result and smtp.mailfrom, plus each dkim= result, header.d and selector.
02Capture the SMTP transcript or sending-platform event, including client IP, envelope sender and the final reply after DATA; separate acceptance from a later bounce or recipient-side filtering outcome.
03Check DNS for the SPF TXT record on the actual MAIL FROM domain (or relevant HELO identity), each selector._domainkey.<d= domain> public-key record, and the _dmarc.<From domain> policy record; note lookup time and resolver.
04For every SPF or DKIM pass, compare its authenticated domain with the From author domain using the published strict or relaxed alignment mode; identify which aligned path, if any, makes DMARC pass.
05Verify that a present record is syntactically usable and that the observed receiver result matches it; collect the recipient's Inbox/Junk view or provider-side evidence before concluding placement.

PRIMARY REFERENCES

Check the source

Standards and provider documentation are linked beside the claims they support. Provider policies can change; check the current document before changing a live sending program.

[1]
RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 SPF identities (MAIL FROM and HELO), DNS authorization policy, and message evaluation result meanings.
[2]
RFC 6376: DomainKeys Identified Mail (DKIM) Signatures DKIM d= signing-domain identifier, selector-based DNS key lookup, signature verification, and its distinction from author identity.
[3]
RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC) Current DMARC mechanism; visible From author domain, SPF/DKIM identifiers, strict/relaxed alignment, pass/fail, p= policy, and local recipient handling.
[4]
RFC 5321: Simple Mail Transfer Protocol (SMTP) A positive reply after message data transfers responsibility to the receiving SMTP server; it does not report Inbox placement.
[5]
Email sender guidelines — Gmail Help Google's published sender authentication requirements for personal Gmail accounts, including bulk senders, and the limited effect of authentication on spam/rejection likelihood.
[6]
Sender Requirements & Recommendations — Yahoo Sender Hub Yahoo's published bulk-sender requirements for SPF, DKIM, DMARC policy, and relaxed alignment.