How to Read SPF, DKIM and DMARC Results in an Email Header

Email headers often contain SPF, DKIM and DMARC results. These mechanisms provide evidence about the domains and systems involved in delivery. They do not inspect every kind of deception and do not prove that a message, sender or link is safe.

This guide explains the result summary produced by the Once Email email header analyser. The analyser reads pasted text locally in the browser. It performs no DNS, reputation, malware or live policy lookup.

SPF: was this system authorised for an envelope domain?

Sender Policy Framework lets a domain publish which systems are authorised to send using an SPF identity. A receiving system compares the connecting sender with that published policy and records a result such as pass, fail, softfail, neutral or none.

SPF is not simply a check of the address a person sees in the visible From field. DMARC uses the SPF result for the SMTP MAIL FROM identity and then evaluates whether its domain aligns with the visible author domain.

Forwarding can complicate SPF because the forwarding server becomes the system connecting to the final receiver. A failed SPF result therefore needs context; it is not by itself a complete verdict about the message.

DKIM: did a signed part of the message validate?

DomainKeys Identified Mail adds a cryptographic signature associated with a signing domain. A receiver retrieves the public key from DNS and checks whether the signed header fields and body still validate.

A DKIM pass is evidence that the signed material validated for the signing domain. It does not establish that the display name is honest, that every visible element was signed, or that a linked website is safe. Mailing systems can also legitimately modify messages in ways that break a signature.

DMARC: does authenticated identity align with the visible author domain?

DMARC builds on SPF and DKIM. It compares an authenticated SPF or DKIM domain with the domain in the visible From address and applies the domain owner's published policy and receiver policy.

The current IETF specification, RFC 9989, explains that DMARC authenticates domain-level identifiers and does not address display-name attacks or analyse message content. It replaced the older RFC 7489 in May 2026.

What changed in the 2026 DMARC revision

RFC 9989 is not evidence that every message system suddenly changed behaviour in 2026. It consolidates the current protocol definition, explicitly obsoletes RFC 7489 and RFC 9091, and separates aggregate and failure-report formats into companion specifications. The practical reading rule remains stable: a DMARC pass means an aligned SPF or DKIM identity authorised use of the visible author domain. It is not a reputation score, an identity check on the person who wrote the message or a scan of links and attachments.

This distinction matters when interpreting “new DMARC requirements” in product announcements. A provider may change its delivery policy or bulk-sender requirements independently of the base protocol. For example, Gmail's sender guidelines apply different authentication requirements by sending volume. Treat provider policy, protocol validation and message safety as three separate layers.

A DMARC pass means at least one supported authentication path passed with the required alignment. It does not mean the author is personally verified, the account has not been compromised, or the message is harmless.

Reading Authentication-Results

A simplified header might look like this:

Authentication-Results: mx.example;
  spf=pass smtp.mailfrom=mailer.example;
  dkim=pass header.d=mailer.example;
  dmarc=pass header.from=mailer.example

Review these values together:

1. Which server wrote the Authentication-Results field?
2. Which domain passed SPF?
3. Which domain signed with DKIM?
4. Which domain appears in the visible From address?
5. Does DMARC report alignment, failure or no policy?
6. Does the delivery route make sense for the sender you expected?

Headers can contain several result fields because multiple systems processed the message. The newest trusted receiver's result is often the most relevant, but deciding which intermediary is trusted requires knowledge of the mailbox provider and delivery path.

Why a pass is not a safety guarantee

An attacker can authenticate a domain they control. A legitimate sender's account can be compromised. A correctly authenticated message can still contain a misleading request, malicious attachment or dangerous link.

The Gmail sender guidelines require different authentication controls depending on sending volume and describe authentication as a deliverability and anti-abuse measure. They do not turn authentication into a general content-safety verdict.

If a message asks for credentials, money, urgent action or sensitive files, verify the request through a known contact channel. Do not rely on the From name or a green authentication result alone.

Use the analyser conservatively

Paste header fields only, not the message body or attachments. Compare the analyser's summary with the context in which the message arrived. Treat missing, malformed or conflicting evidence as a reason for additional verification, not as automatic proof of fraud.

For incident response, domain configuration or high-impact decisions, use your mailbox provider's original message view and consult a qualified email administrator or security professional.