SPF, DKIM and DMARC: What Each Record Actually Does

SPF, DKIM and DMARC get discussed as a single bundle so often that it's easy to lose track of what each one is individually checking. They solve three different problems, they fail in three different ways, and understanding the mechanism (not just the acronym) is what makes misconfigurations obvious instead of mysterious.

SPF: who is allowed to send as this domain

Sender Policy Framework is a TXT record listing the mail servers authorized to send on behalf of a domain. When a message arrives, the receiving server looks at the envelope-from address (the technical return-path, not necessarily what's shown in the inbox), fetches the domain's SPF record, and checks whether the connecting server's IP is on the allowed list. SPF records support up to 10 DNS lookups, and chaining too many include: mechanisms is a common way to silently break the record. The record ends in a qualifier: -all means "reject anything not listed," ~all is a softer "mark as suspicious," and using both a domain's own record and a second unrelated one is invalid: a domain may only have one SPF record.

example.com.  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.yourprovider.com -all"

DKIM: proving the message wasn't altered in transit

DomainKeys Identified Mail works differently: it doesn't check where a message came from, it checks whether the message content matches what was sent. The sending server generates a public/private key pair, publishes the public half as a TXT record at a selector subdomain, and signs each outgoing message with the private key. The signature covers a hash of the body and a set of headers. The receiving server fetches the public key from DNS using the selector named in the message's DKIM-Signature header and verifies the hash. If even one covered header or a byte of the body changes after signing, verification fails.

selector1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
  h=from:to:subject:date; bh=<body-hash>; b=<signature>

DMARC: telling receivers what to do when the two disagree

DMARC doesn't add a third independent check. It sits on top of SPF and DKIM and adds a policy plus a reporting channel. A message passes DMARC if at least one of SPF or DKIM passes and is aligned, meaning the domain that check passed for matches the domain shown in the visible From header. p=none only monitors, p=quarantine asks receivers to send failures to spam, and p=reject asks them to refuse the message outright. rua= gives an address for aggregate reports so you can see, in bulk, what's passing and failing across every source claiming to send as your domain.

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100; adkim=s; aspf=s"

Why alignment breaks more often than the records themselves

• Sending through a third-party platform often means the envelope-from domain belongs to that platform, not yours. SPF passes for their domain, not the one in your From header, so alignment fails unless it's configured correctly.
• Publishing SPF and DMARC but forgetting the DKIM selector record leaves the domain with only one working leg, fine until that one path changes.
• A subdomain without its own DMARC record inherits the parent's policy unless sp= is set separately, which surprises teams who assumed subdomains were isolated.
• Mail forwarding rewrites the envelope-from, which breaks SPF at the final hop. This is why DKIM, which survives forwarding, matters even when SPF is solid.
• Publishing two SPF TXT records instead of merging them into one is invalid per the spec and causes unpredictable results across receivers.

A worked example: two providers, one domain

Say mail.example.com sends through two different platforms: one for outbound sequences, one for transactional receipts. SPF needs both platforms' include mechanisms in a single merged record. DKIM needs a distinct selector published for each platform, since each signs with its own key. DMARC then evaluates whichever leg is present on a given message: a sequencing platform message might align on DKIM only, and a transactional message might align on both. As long as one aligned pass occurs per message and the merged SPF record stays under the ten-lookup ceiling, DMARC reports clean.