SPF, DKIM, and DMARC Explained: The DNS Records That Decide If Your Email Gets Delivered

The short answer

SPF, DKIM, and DMARC are three separate DNS TXT records that let a receiving mail server verify a message genuinely came from your domain. Without them, anyone on the internet can put your domain in the From line and the receiver has no authoritative or cryptographic way to tell your real mail from a forgery. The result cuts both ways: spoofed mail impersonating your company gets through, and your own legitimate invoices, quotes, and password resets increasingly land in spam because they arrive as unverifiable claims. Since February 2024, Google and Yahoo require all three records from bulk senders, and both providers filter unauthenticated mail far more aggressively across the board.

The three records divide the work. SPF publishes the list of IP addresses allowed to send for your domain, checked against the message's envelope sender. DKIM attaches a cryptographic signature to each message and publishes the matching public key in your DNS, proving the mail was authorized by your domain and not altered in transit. DMARC ties both results back to the From address your recipient actually reads, tells receivers what to do when a message fails (nothing, quarantine, or reject), and sends you reports. None is sufficient on its own: SPF and DKIM authenticate technical identifiers the recipient never sees, and only DMARC connects that to the visible From header a human trusts.

What Each Record Actually Does

SPF (Sender Policy Framework, RFC 7208) is a single TXT record at your domain root that lists the servers allowed to send mail using your domain in the SMTP envelope. A typical record reads v=spf1 include:_spf.google.com ip4:203.0.113.10 -all. Each mechanism (include, ip4, a, mx) authorizes a source, and the final qualifier governs everything unmatched: -all is a hard fail, ~all a softfail. A receiving server reads the envelope MAIL FROM domain, queries its SPF record, and checks whether the connecting IP is authorized.

DKIM (DomainKeys Identified Mail, RFC 6376) adds a digital signature. Your outbound server hashes selected headers plus the message body and signs them with a private key, inserting a DKIM-Signature header. The matching public key lives in DNS at selector._domainkey.yourdomain.com as v=DKIM1; k=rsa; p=<base64 key>. The selector lets you run several keys at once and rotate them. Because the signature covers the content, DKIM proves both that your domain vouched for the message and that nothing was altered along the way.

DMARC (RFC 7489) is a TXT record at _dmarc.yourdomain.com such as v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com. It does two jobs: it sets a policy (none, quarantine, or reject) telling receivers how to treat mail that fails authentication, and it requests reports. Critically, DMARC only counts an SPF or DKIM pass if the authenticated domain aligns with the domain in the visible From header, which is exactly what closes the spoofing gap the other two leave open.

• SPF is a DNS TXT record listing authorized sending IPs, checked against the envelope sender, not the From header
• DKIM is a cryptographic signature in the message plus a public key in DNS, proving integrity and origin
• DMARC is a policy record that ties SPF/DKIM results to the visible From address and requests reports
• SPF and DKIM each answer a different question; DMARC decides what a failure means
• All three are plain DNS TXT records, with no software installed on the recipient's side
• Only DMARC carries an enforcement action; SPF and DKIM just produce a pass or fail signal

How the Three Work Together (and Why One Isn't Enough)

The detail that trips up almost everyone is that SPF and DKIM authenticate identifiers the recipient never sees. SPF validates the RFC 5321 envelope sender (the Return-Path / MAIL FROM), and DKIM validates whatever domain sits in the signature's d= tag. Neither one, by itself, has anything to do with the From address a person reads in their inbox (the RFC 5322 From header). A spammer can send from their own domain, pass SPF and DKIM perfectly for that domain, and still forge your company in the visible From line.

DMARC closes that gap with alignment. A message passes DMARC only if SPF or DKIM passes and the passing domain matches the From header domain. SPF alignment compares the envelope-from domain to the From domain; DKIM alignment compares the signature d= to the From domain. You choose relaxed mode (r, the default, where subdomains of the same organizational domain count) or strict mode (s, exact match). Only one of the two needs to pass and align, which is why a forwarded message that breaks SPF can still survive on an intact DKIM signature.

In practice a receiving server runs all three in sequence: SPF on connection, DKIM on the signature, then DMARC to reconcile those results against the From header and apply your policy. If SPF fails but DKIM passes and aligns, DMARC passes. If neither aligns, DMARC applies your p= action and logs it in the aggregate report. The layering is deliberate: SPF handles the simple IP case cheaply, DKIM survives relays and forwarding, and DMARC turns two technical checks into a policy about your brand.

• SPF checks the envelope sender (Return-Path); DKIM checks the signing domain (d=); neither checks the From line alone
• DMARC passes when SPF or DKIM passes AND aligns with the From domain, and only one needs to align
• Relaxed alignment (default) allows subdomains; strict alignment requires an exact domain match
• DKIM alignment is usually the more durable one because signatures survive forwarding that breaks SPF
• A message can pass SPF and DKIM yet fail DMARC if those passes are for a different domain than From
• Each inbound message runs the checks in order: SPF, then DKIM, then DMARC reconciliation

How to Read an SPF, DKIM, or DMARC Record

You can pull any of these records with a DNS query: dig TXT example.com for SPF, dig TXT _dmarc.example.com for DMARC, and dig TXT selector._domainkey.example.com for DKIM, where the selector comes from the s= tag of a DKIM-Signature header on a real message from that domain. Any public DNS lookup tool works the same way. Every value is a space- or semicolon-delimited list of tags read left to right.

In an SPF record like v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.0/24 -all, v=spf1 marks it as SPF, each include pulls in another provider's authorized IPs, ip4/ip6 list literal ranges, and the trailing qualifier governs everything unmatched: -all hard fail, ~all softfail, ?all neutral, and +all (never use it) passes everyone. Count the DNS-querying mechanisms too, because include, a, mx, exists, and ptr each cost a lookup and the spec caps you at ten.

A DKIM record reads v=DKIM1; k=rsa; p=<long base64 string>, where p= is the public key and an empty p= means the key was revoked. For DMARC, the operational tags are the ones to check: p= is the enforcement level, sp= overrides policy for subdomains, pct= applies the policy to only a sample of mail, adkim/aspf set alignment strictness, and rua=/ruf= are the addresses that receive aggregate and failure reports. If rua= is missing, you are enforcing blind with no visibility into what you're blocking.

• Query with dig TXT domain (SPF), dig TXT _dmarc.domain (DMARC), dig TXT selector._domainkey.domain (DKIM)
• Find a DKIM selector in the s= tag of the DKIM-Signature header on a message the domain sent
• SPF qualifiers: -all hard fail, ~all softfail, ?all neutral, +all anyone (a red flag)
• DKIM: p= holds the public key, and a blank p= means the key is revoked
• DMARC: read p=, pct=, adkim/aspf, and confirm rua= exists so reports actually arrive
• Exactly one valid SPF record and one DMARC record may exist per domain; extras invalidate the check

Common Misconfigurations That Break Delivery

The single most common SPF error is publishing two records. The spec permits exactly one TXT record beginning with v=spf1; when a domain carries both a Microsoft 365 record and a leftover Google record, evaluation returns PermError and every check effectively fails. The next most common is exceeding the ten-DNS-lookup limit: each include for a marketing platform, CRM, or invoicing tool adds lookups, and nesting them silently blows past ten, again producing PermError. Trimming unused providers or flattening includes into ip4 ranges fixes it.

On DMARC, the biggest mistake is jumping straight to p=reject before monitoring. Every legitimate service that sends as your domain (CRM, ticketing system, payroll, e-signature tool) must be authorized in SPF and signing with aligned DKIM first, or reject will bounce your own invoices and password resets. Publishing p=none with a rua= address for a few weeks surfaces exactly which senders fail before you turn on enforcement. Other frequent errors: the DMARC record placed at the root instead of _dmarc, multiple DMARC records, or no rua= so you never learn what is breaking.

DKIM tends to break quietly. A 1024-bit key is now considered weak; a base64 p= value split across DNS fields with stray spaces will not parse; and a mailing list or a footer-appending gateway that modifies the body invalidates the body hash (bh=) and fails the signature. Forwarding is the classic false alarm, because it breaks SPF (the forwarder's IP is not authorized), which is precisely why you want a valid, aligned DKIM signature as the durable fallback.

• Two v=spf1 records cause PermError; there must be exactly one SPF and one DMARC record per domain
• SPF silently fails past ten DNS lookups, usually from nested includes for third-party senders
• p=reject before monitoring bounces your own mail from CRMs, payroll, and e-sign tools
• A missing rua= means enforcement runs blind, with no report of which senders are failing
• 1024-bit DKIM keys are weak; use 2048-bit and never let the base64 key be line-broken or spaced
• Body-modifying gateways and mailing lists break the DKIM body hash; forwarding breaks SPF but not DKIM

How to Add and Roll Out the Records Safely

All three are added wherever your DNS is hosted, usually your registrar or a provider like Cloudflare or Route 53, as TXT records. Start with SPF: collect the include value from every service that sends on your behalf (your mail platform gives you one, as does each marketing, CRM, or transactional provider), combine them into a single v=spf1 ... -all record, and verify you are under ten lookups. Then enable DKIM in your mail platform; most now hand you a CNAME (or a TXT selector) to publish, and CNAME delegation lets the provider rotate keys for you without further DNS edits.

Deploy DMARC last and in stages. Publish v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com first: this changes nothing about delivery but starts the daily aggregate reports flowing. Read those reports (they are XML, and a report analyzer makes them legible) for two to four weeks until every legitimate source shows SPF or DKIM passing and aligned. Then tighten to p=quarantine, optionally with pct=25 stepped upward, and finally to p=reject once the reports are clean. Rushing this sequence is what causes the horror stories; done in order it is low-risk.

After each change, confirm propagation with dig or a public lookup tool, remembering that DNS TTL means changes can take up to a day to be visible everywhere. Then send a test message to a mailbox at a major provider and inspect the Authentication-Results header, which spells out spf=pass, dkim=pass, and dmarc=pass (or the failure and its reason). That header is the ground truth: it tells you what a real receiver saw, not merely what your record claims.

• Add all three as TXT records: SPF at the root, DKIM at selector._domainkey, DMARC at _dmarc
• Consolidate every sending service into one SPF record and keep it under ten DNS lookups
• Prefer CNAME-delegated DKIM so your mail provider can rotate keys without new DNS edits
• Roll DMARC out as p=none, then p=quarantine (with pct=), then p=reject, driven by report data
• Allow up to the record's TTL for changes to propagate before testing
• Verify with the Authentication-Results header on a real test message, which shows what receivers actually see

Why Missing These Records Sends Mail to Spam

Receiving providers score inbound mail on reputation, and authentication is now a gating input rather than a bonus. A message with no SPF, no DKIM, and no DMARC arrives as an unverifiable claim: the receiver cannot confirm the domain in From authorized it, so it falls back on weaker signals like content heuristics and IP reputation and is far more likely to filter to spam or reject outright. Authenticated mail from a domain with a clean sending history, by contrast, builds a reputation the receiver can actually attribute to you.

Since February 2024, Google and Yahoo require bulk senders (roughly 5,000 or more messages a day to their users) to publish SPF, DKIM, and a DMARC record of at least p=none, alongside one-click unsubscribe and a spam-complaint rate held under 0.3 percent. Mail that misses the bar is throttled or rejected. Even below that threshold both providers keep raising the floor, so a small business that never sends 5,000 messages still benefits directly: the same records that satisfy the bulk rules are what keep routine invoices, quotes, and password resets out of the junk folder.

There is a security dimension that maps straight back to deliverability. Without DMARC at enforcement, attackers can spoof your exact domain in phishing aimed at your customers or staff, and the resulting complaints and blocklistings degrade your real mail's reputation. Publishing p=reject, once tested, both stops the spoof and protects the sending reputation you depend on. Enforced DMARC is additionally the prerequisite for BIMI, which can display your verified logo next to authenticated mail in supporting inboxes.

• Unauthenticated mail is treated as an unverifiable claim and filtered on weaker, less forgiving signals
• Google and Yahoo (Feb 2024) require SPF, DKIM, and DMARC for bulk senders, plus one-click unsubscribe and under 0.3% spam complaints
• The same records that satisfy bulk rules keep a small business's routine transactional mail out of spam
• Domain spoofing generates complaints and blocklistings that damage your legitimate sending reputation
• Enforced DMARC (p=reject) both blocks spoofing and protects deliverability
• Enforced DMARC is the prerequisite for BIMI logo display in supporting mailboxes

Frequently asked questions