What the mailbox proves (and what it doesn’t): SPF, DKIM, and DMARC

A green check is not a wire approval

Sam Ortiz, Riverstone’s finance clerk, gets mail that shows From: finance@riverstone.example and asks for a wire approval. The inbox paints a green check. Priya asks Maya the only question that matters: what did the check actually prove? A familiar display name and a checkmark are not the same fact.

Mail carries more than one name. The visible From is the RFC 5322 From header. Its domain is the Author Domain, the name a person thinks sent the message. The envelope is separate: SMTP MAIL FROM is the return address, and HELO or EHLO is the name the sending host announced. DKIM adds a third name, the signing domain in the signature. This lesson names those identities. It does not walk the whole SMTP state machine. F3 already taught that DNS publishes records for a name. F4 taught that authentication is not the same as a person’s intent. Read F4 if that split is still fuzzy.

SPF authorizes a host, not the visible From

SPF, the Sender Policy Framework, is how a domain publishes which hosts may use its name in MAIL FROM, and in HELO when the envelope sender is empty. The receiver compares the connecting host’s IP address with that DNS policy. RFC 7208, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1, is the Standards Track specification from April 2014. It obsoletes RFC 4408. Later RFCs update it. This lesson does not restate those updates.

Treat the common results as a host-authorization answer for that identity. Pass means the domain explicitly authorized the client. Fail means it explicitly did not. Softfail is a weaker “probably not authorized.” None means the verifier did not find a usable SPF record. None of those results proves a human meant to send the visible From, or that the message body is honest. SPF does not authorize the address the reader sees in the header.

• Pass: this host is authorized for the checked identity.
• Fail: this host is explicitly not authorized.
• Softfail: the domain says this host is probably not authorized.
• None: no usable SPF record was found. That is not a pass.

DKIM ties a signing domain to signed bytes

DKIM, DomainKeys Identified Mail, lets a signing domain claim responsibility for selected message content. The sender attaches a cryptographic signature. The receiver fetches the matching public key from DNS and checks that the signed headers and body still match. RFC 6376, DomainKeys Identified Mail (DKIM) Signatures, is Internet Standard STD 76, September 2011. It obsoletes RFC 4871 and RFC 5672.

A valid signature associates the signing domain with the bytes that were signed. It does not prove the display name is honest, and it does not prove a person typed the message. A mailbox, a vendor, or a stolen key can sign. If the visible From domain and the signing domain differ, say so. Do not collapse them into “the email is authenticated.”

DMARC asks whether those names align

DMARC checks whether the Author Domain lines up with an identifier SPF or DKIM already authenticated, then publishes a handling preference and a request for reports. The current specification is RFC 9989, Domain-based Message Authentication, Reporting, and Conformance (DMARC), a Proposed Standard from May 2026. It obsoletes RFC 7489 and RFC 9091. RFC 7489 (March 2015, Informational) is only a historical predecessor. Teach and operate from RFC 9989. The version tag on the DNS record is still v=DMARC1.

Alignment is plain: relaxed means the authenticated domain and the Author Domain share the same organizational domain, the name at the top of that administrative namespace. Strict means the two names are identical. The DNS record chooses with adkim and aspf. Both default to relaxed. A pass needs an aligned SPF pass or an aligned DKIM pass, not merely some check somewhere.

The same record can ask receivers what to do when validation fails. p=none means the domain offers no handling preference. That is monitoring mode when aggregate reports are also coming in. p=quarantine means the owner considers the failure suspicious. p=reject means the owner considers the use of the name not valid. Receivers may still apply their own judgment. Aggregate reports are RFC 9990 (May 2026). Failure reports for individual messages are RFC 9991 (May 2026). Publishing a policy and never reading the reports is not the control.

A pass still leaves room for phishing

RFC 9989 section 2.2 says DMARC directly combats exact-domain spoofing of the Author Domain. It does not solve every fraudulent message. Visually similar cousin domains are out of scope: a pass for riverstone.example says nothing about riverst0ne.example. Display-name attacks are out of scope too. The header can show “Riverstone Finance” while the address is someone else’s domain. Section 11.4 says the same thing again.

Two more gaps matter on a real queue. A compromised legitimate mailbox can send a fraudulent wire request that passes SPF, DKIM, and DMARC, because the domain owner really did authorize that host and that key. And a pass does not inspect content. RFC 9989 section 2.4 puts content analysis out of scope. A DMARC pass validates authorized use of the Author Domain for that message. It does not assert that the message is safe or that the domain owner is virtuous.

Indirect mail can fail the other way. Mailing lists and forwarders often break a signature or change the path SPF sees. RFC 9989 section 7 is the interoperability warning: p=reject can discard legitimate mail the domain owner still wants. That is a reason to monitor before you enforce, not a reason to skip authentication. Email authentication also does not replace MFA or a person’s report of a suspicious message.

Harbor Mail: monitor, then enforce

Riverstone’s synthetic mail domain for this exercise is harbor.example, operated as Harbor Mail. It is not a customer domain and not a place to paste an employer’s records. Maya’s cadence is an inventory, not a slogan. List who sends as harbor.example: the finance app, the payroll vendor, the customer-notice tool. Publish SPF for those hosts. Sign with DKIM aligned to the Author Domain. Then publish a DMARC record at _dmarc.harbor.example with v=DMARC1, p=none, and an rua address that can receive aggregate reports.

RFC 9989 section 5 tells domain owners to start at p=none so missed servers and third-party senders show up in reports before mail is rejected. Read the aggregate reports. Fix legitimate streams that are unaligned. Only then consider quarantine or reject. When you do enforce, keep aligned DKIM in place: forwarding breaks SPF more often than it breaks a signature that still verifies. Domains that host people who post to mailing lists should not jump to p=reject. p=reject on harbor.example does not stop a cousin domain. It does not make a passed message safe to pay.