What is the difference between SPF, DKIM, and DMARC?

SPF, DKIM, and DMARC are three email authentication standards that are frequently confused because they all deal with sender identity, but each solves a distinct technical problem. If you only remember one thing: SPF authorizes servers, DKIM signs messages, and DMARC tells receivers what to do when the first two disagree with the From header. Understanding the differences matters because mailbox providers like Gmail, Yahoo, and Microsoft evaluate all three independently and penalize domains that misconfigure any of them.

The envelope vs. the letter

Email has two "from" addresses. The SMTP envelope sender (also called MAIL FROM, Return-Path, or bounce address) is the address used during the SMTP transaction. The message From header is the human-readable address your recipient actually sees. Spammers historically exploited the fact that these can differ — spoofing the visible From while using their own envelope sender.

SPF authenticates the envelope sender. DKIM authenticates the message body and selected headers (including the From header, if the signer chose to include it). DMARC stitches them back together by requiring at least one of SPF or DKIM to pass AND align with the organizational domain in the From header.

SPF in one paragraph

SPF (RFC 7208) is a DNS TXT record at the root of your domain that lists the IP addresses and hostnames permitted to send mail on your behalf. A receiving server takes the envelope sender domain, looks up its SPF record, and checks whether the connecting IP matches.

example.com. IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all"

Key constraints: a maximum of 10 DNS lookups (includes, redirects, a, mx, ptr, exists), a single TXT record, and a final qualifier — -all (hardfail), ~all (softfail), ?all (neutral), or +all (never do this). SPF breaks when mail is forwarded because the forwarder becomes the connecting IP, and it does nothing for the visible From header.

DKIM in one paragraph

DKIM (RFC 6376) adds a cryptographic signature to outgoing mail. Your mail server signs selected headers and the body using a private key; the receiver fetches the matching public key from DNS at selector._domainkey.example.com and verifies. A typical header looks like:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
  s=s1; h=from:to:subject:date; bh=...; b=...

Use 2048-bit RSA keys in 2026 — 1024-bit is still accepted by major providers but considered weak. Ed25519 is emerging but not yet universally supported. DKIM survives forwarding (as long as the forwarder does not modify signed headers or the body), which is why it is the backbone of DMARC alignment for mailing lists and relays.

DMARC in one paragraph

DMARC (RFC 7489) is a policy layer. It says: "If SPF or DKIM passes AND the passing domain aligns with my From header, deliver. Otherwise, apply my policy."

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

Alignment is the critical concept. SPF alignment means the envelope domain matches the From domain (aspf=r for relaxed, aspf=s for strict). DKIM alignment means the d= tag in the signature matches the From domain. DMARC does not require both; one aligned pass is enough.

A quick comparison table

| Property | SPF | DKIM | DMARC | |----------|-----|------|-------| | What it authenticates | Envelope sender IP | Message headers + body | Alignment with From header | | DNS record location | Domain apex TXT | selector._domainkey TXT | _dmarc subdomain TXT | | Survives forwarding | No | Usually yes | Inherits from SPF/DKIM | | Breaks on mailing lists | Often | Sometimes | Depends on the list | | Primary RFC | 7208 | 6376 | 7489 | | Key rotation needed | No | Yes (every 6-12 months) | No |

When each one fails in the real world

An SPF hardfail (-all) on a domain that uses Mailchimp without an include statement will silently drop marketing emails. A DKIM signature with a misaligned d= tag — often caused by sending through a third-party ESP that signs with its own domain — will technically pass DKIM but fail DMARC alignment. A DMARC record set to p=reject before you have cleaned up all sending sources will bounce legitimate transactional mail from your billing platform, CRM, and HR system.

The order you should deploy them

1. Publish SPF with ~all (softfail) so misconfigurations do not cause immediate delivery failures.
2. Configure DKIM on every sending service. Generate a fresh 2048-bit key per service where possible.
3. Publish DMARC with p=none and rua= reporting. Let two to four weeks of aggregate reports accumulate.
4. Analyze the reports. Fix any legitimate source that is failing alignment.
5. Move DMARC to p=quarantine; pct=10 and watch for user-reported breakage.
6. Gradually increase pct to 100 over several weeks.
7. Move to p=reject once you are confident no legitimate mail is failing.

Troubleshooting the common confusion

"My SPF passes but DMARC fails." This means SPF authenticated the envelope domain, but the envelope domain does not align with the From header. Typical cause: a marketing platform sends with bounce.provider.com as envelope sender while the From is your domain. Fix by signing with DKIM d=example.com.

"My DKIM signature says d=sendgrid.net — is that a problem?" Yes, for DMARC. The customer needs to set up a custom DKIM with their own domain as the d= value. Most ESPs support this but do not enable it by default.

"I deleted an old SPF record and now email is broken." SPF DNS changes take up to the record TTL to propagate. If you had a TTL of 86400 seconds, give it 24 hours.

When to use IntoDNS.ai

You can verify all three records by hand with dig, but cross-checking alignment, lookup count, selector discovery, and DMARC policy coverage in a single view is tedious. Run your domain through IntoDNS.ai to see SPF, DKIM, and DMARC results side by side, get a score for each, and receive specific fix suggestions if any of the three is misaligned. It also flags subtle issues like missing rua= reporting, policy misalignment between subdomains, and SPF records that exceed the 10-lookup limit.

Where ARC fits in

ARC (Authenticated Received Chain, RFC 8617) is a fourth standard that most operators overlook. It exists because SPF and DKIM often break when mail is forwarded or relayed through a mailing list. ARC lets each intermediary cryptographically attest to the authentication results it saw before modifying the message. Downstream receivers can then trust the original SPF and DKIM even if the current-hop checks fail.

An ARC-sealed message has three additional headers:

ARC-Authentication-Results: i=1; mx.forwarder.com; spf=pass [email protected]; dkim=pass header.d=example.com
ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.com; s=s1; ...
ARC-Seal: i=1; a=rsa-sha256; d=forwarder.com; s=s1; cv=none; ...

ARC does not replace SPF/DKIM/DMARC — it complements them. Google, Microsoft, and major mailing list platforms all sign ARC headers in 2026. If you run your own forwarder or list, signing ARC meaningfully improves downstream deliverability. If you do not, ARC still benefits you by preserving authentication across forwarders you rely on.

Reporting and visibility

All three standards are useful only if you watch the output. SPF and DKIM have no native reporting mechanism — a failure just means the message fails and, if DMARC is in play, triggers DMARC action. DMARC itself has two reporting channels:

• rua= aggregate reports: daily XML summaries from each receiver, showing per-IP counts of pass and fail. Essential.
• ruf= forensic (per-message) reports: one XML per failing message. Few receivers still send these due to privacy concerns. Omit.

Parse aggregate reports weekly. Any unknown IP with significant volume is either a forgotten internal sender or a spoofer. Either way, it deserves investigation.