Most explanations of these three records get the same thing wrong, and it is the thing that matters. SPF does not check the address in the From line. DKIM does not necessarily check it either. DMARC is what makes either of them apply to the address a human reads, and the mechanism that does it — alignment — usually gets one hurried sentence.
Here is the precise version. The source specifications are public: SPF is RFC 7208, DKIM is RFC 6376, DMARC is RFC 7489.
SPF authorizes servers, not people
A domain publishes a DNS TXT record listing the hosts allowed to send mail for it:
v=spf1 ip4:198.51.100.7 include:_spf.provider.example -all
A receiving server takes the domain from the envelope sender — the address in the SMTP MAIL FROM command, also called the Return-Path — looks up its SPF record, and asks whether the connecting IP is authorized. The trailing qualifier decides everything unlisted: -all is a fail, ~all a softfail, ?all neutral.
The envelope sender is usually not the address the recipient sees. A provider or forwarder can put its own bounce domain in MAIL FROM while leaving your name in the From header. SPF then authorizes that provider and says nothing about you.
Forwarding breaks SPF. The message arrives from the forwarder's IP, which your domain never authorized. The Sender Rewriting Scheme patches this by rewriting the envelope sender at the forwarding hop.
One operational limit: an SPF check may perform at most ten DNS-querying terms. Chain enough include: records from enough vendors and the result is a permanent error rather than a pass.
DKIM signs the message itself
The sending system picks a set of headers, hashes them with the body, signs the hash with a private key, and attaches a DKIM-Signature header. The tags that matter are d= (signing domain), s= (selector), h= (signed headers), bh= (body hash), and b= (signature). The verifier fetches the public key from a DNS TXT record at selector._domainkey.example.com and checks it.
A pass proves the signing domain took responsibility, and that the signed headers and body were not altered afterwards.
Because the signature rides inside the message, DKIM survives a plain forward that SPF cannot. What breaks it is modification — a mailing list that appends a footer or prefixes the subject invalidates the signature it just relayed. And note the gap: the signing domain is chosen by whoever signs, so a message can carry a flawless signature from a domain unrelated to the From line.
DMARC ties both to the visible From address
DMARC is a TXT record at _dmarc under your domain:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
It defines what counts as a pass, states what receivers should do about failures, and asks for reports.
Alignment is the part most explainers skip
DMARC evaluates against the domain in the From header, the one displayed to the reader. A message passes if at least one of these holds:
- SPF passed and the envelope-sender domain is aligned with the From domain, or
- DKIM passed and the signature's
d=domain is aligned with the From domain.
One branch is enough. Both unaligned is a DMARC failure, even when SPF and DKIM each technically passed.
Alignment has two settings, chosen separately per mechanism with aspf= and adkim=. Relaxed, the default, requires only that the organizational domains match, so bounces.mail.example.com aligns with example.com. Strict requires an exact match.
This is where the common misreading lives. "SPF passed" is not "DMARC passed." Send through a provider that uses its own bounce domain and you get an SPF pass that is unaligned and therefore worth nothing to DMARC. What rescues you is a DKIM signature carrying your own domain — which is why providers ask you to publish selector records, not just an include:.
The policy tag is a request to receivers, not a switch on their systems. p=none asks for nothing but reports, p=quarantine asks them to treat failures as suspicious, p=reject asks them to refuse; sp= sets a separate policy for subdomains. rua= collects aggregate reports — periodic summaries grouped by sending source and result, with no message content. Starting at p=none with rua set is how most people find the forgotten systems sending as their domain.
What all three passing actually proves
That the From domain was not forged by someone the domain owner did not authorize. That is the whole claim.
It does not mean the message is wanted, honest, or safe — anyone can register a lookalike domain and authenticate it perfectly. Enforcement has costs too: p=reject breaks indirect flows that modify messages in transit. The Authenticated Received Chain exists to repair that, by letting an intermediary vouch for the result it saw, but honouring it is the receiver's call.
Why this makes agent email a project
Giving an AI agent "its own email address" sounds like creating a mailbox. The DNS work is the visible half — a domain you control, an SPF record covering every sending path within the lookup budget, DKIM signing with the selector published, and a DMARC record whose alignment actually holds for the provider you picked.
The invisible half is that none of this produces reputation. Authentication makes you identifiable, and being identifiable is what lets a receiving system hold your history against you. A fresh identity has no history, which is the profile filters treat most cautiously — why your email lands in spam covers what happens after the records are right.
RelayLink's answer is to skip the mailbox. The assistant connects to an MCP server and never holds mail credentials; the relay sends the notification email, so these records are its problem rather than yours. The trade is real — you do not control the sending domain, and inherit its reputation. RelayLink versus a DIY agent email account sets out both sides; if you would rather publish no records at all, connect your assistant — the recipient needs nothing but an email address.