A protocol-level reference for engineers operating production mail infrastructure. Covers SPF, DKIM, DMARC, ARC, BIMI, MTA-STS, and DANE — from DNS record syntax to verification logic, alignment semantics, failure taxonomy, and operational runbooks.
SPF, DKIM, and DMARC are independent protocols that combine into a layered authentication framework.
Each solves a different piece of the sender-identity problem. DMARC is the policy layer that ties SPF and DKIM
to the human-visible From: header domain.
Answers: "Is this IP authorized to send for this envelope domain?"
MAIL FROM (return-path), not the From: header.Answers: "Was this message actually sent by the claimed signing domain, unmodified?"
selector._domainkey.domain.Answers: "What should receivers do if SPF and DKIM both fail to align with the From: domain?"
_dmarc.domain.d= must match From:.
SPF is a DNS-based authorization list for sending IPs. The receiving MTA checks the MAIL FROM domain's
TXT record against the connecting IP. Simple concept, subtle operational pitfalls.
example.com. IN TXT "v=spf1 ip4:203.0.113.0/24 ip6:2001:db8::/32 include:_spf.google.com include:spf.protection.outlook.com mx a:relay.example.com -all"
│ │ │ │ │ │ │ │
│ │ │ │ │ │ │ └─ hard fail everything else
│ │ │ │ │ │ └─ allow A record of relay.example.com
│ │ │ │ │ └─ allow domain's MX hosts
│ │ │ │ └─ include O365 SPF
│ │ │ └─ include Google Workspace SPF
│ │ └─ allow this IPv6 block
│ └─ allow this IPv4 CIDR
└─ version (required, must be first)| Mechanism | Syntax | What It Matches | DNS Lookups |
|---|---|---|---|
ip4 | ip4:203.0.113.0/24 | Connecting IP in CIDR range | 0 |
ip6 | ip6:2001:db8::/32 | Connecting IPv6 in range | 0 |
a | a or a:host.example.com | IP matches A/AAAA record of domain | 1 |
mx | mx or mx:example.com | IP matches an MX host of domain | 1 + 1 per MX |
include | include:_spf.google.com | Delegate to another SPF record | 1 + recursive |
redirect | redirect=_spf.example.com | Replace entire policy with another record | 1 + recursive |
exists | exists:%{i}._spf.example.com | True if A record exists for macro-expanded name | 1 |
all | -all / ~all / ?all | Match everything (catch-all at end) | 0 |
| Qualifier | Meaning | DMARC Effect | Recommendation |
|---|---|---|---|
+ (Pass) | Authorized (default if omitted) | SPF pass | Implicit on mechanisms |
- (Fail) | Explicitly unauthorized | SPF fail | Use for production -all |
~ (SoftFail) | Unauthorized but transitional | SPF fail for DMARC | Only during rollout / testing |
? (Neutral) | No assertion | SPF fail for DMARC | Rarely useful |
The 10-lookup limit is real and ruthless. SPF evaluation must not cause more than 10 DNS lookups
(includes include, a, mx, redirect, exists —
but NOT ip4/ip6). Exceeding it returns permerror, which DMARC treats as a fail.
Nested include chains from SaaS providers are the #1 cause.
v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:spf.brevo.com mx -all
# _spf.google.com itself chains 3 more includes = total ~9-10 lookupsv=spf1 ip4:209.85.128.0/17 ip4:74.125.0.0/16 ip4:64.233.160.0/19 ip4:108.177.8.0/21
ip4:172.217.0.0/16 ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/14
ip4:167.89.0.0/17 ip4:149.72.0.0/16 -all
# WARNING: Provider IPs change. Automate re-flattening on a schedule or use a dedicated subdomain per provider.Better approach: subdomain delegation. Instead of flattening, send via subdomains with isolated SPF:
marketing.example.com → v=spf1 include:sendgrid.net -all,
transactional.example.com → v=spf1 include:_spf.google.com -all.
Each subdomain stays well under 10 lookups and DMARC alignment still works with relaxed mode.
DKIM adds a cryptographic signature to outbound messages. The receiving MTA retrieves the public key from DNS and verifies the signature over the specified headers and body hash. Unlike SPF, DKIM survives forwarding as long as the signed content is not modified.
DKIM-Signature: v=1; # Version (always 1)
a=rsa-sha256; # Algorithm (rsa-sha256 or ed25519-sha256)
d=example.com; # Signing domain (DMARC aligns against this)
s=s2026; # Selector (DNS lookup: s2026._domainkey.example.com)
c=relaxed/relaxed; # Canonicalization: header/body
q=dns/txt; # Query method
t=1739620800; # Timestamp (Unix epoch, signing time)
x=1740225600; # Expiration (optional, 7 days later here)
h=from:to:subject:date:message-id: # Signed headers (order matters)
mime-version:content-type;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; # Body hash (SHA-256)
b=LjIGMtqFkFqJCZ9sdoMcyBPuv... # Signature (Base64)# RSA 2048-bit key
s2026._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2K4PavXoNY8eGK2u..."
# Ed25519 key (much shorter, gaining adoption)
s2026ed._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo="
# Key with testing flag (t=y means verifiers should treat failures leniently)
stest._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; t=y; p=MIIBIjAN..."
# Revoked key (empty p= signals key is no longer valid)
sold._domainkey.example.com. 3600 IN TXT "v=DKIM1; p="| Mode | Headers | Body | Recommendation |
|---|---|---|---|
simple/simple |
No changes allowed | Only trailing empty lines ignored | Strictest, breaks on any modification |
relaxed/relaxed |
Lowercased, whitespace folded | Whitespace normalized, trailing lines removed | Use this. Tolerates common MTA reformatting |
relaxed/simple |
Relaxed | Strict | Compromise; rarely needed |
From — required by RFC 6376, DMARC alignment keyTo, Subject, Date — core identity/contentMessage-ID — traceabilityMIME-Version, Content-Type — body interpretationReply-To, Cc — prevents tamperingIn-Reply-To, References — threading integrityList-Unsubscribe — anti-phishingReceived or relay-added headers — they change in transits2026b._domainkey TXT record with new public key. Old key still active.s2026b. Old signatures still verify against old DNS key.p= (empty). Messages with stale cached old key now fail DKIM (which is fine — they're old).RSA key size matters. 1024-bit RSA keys are considered weak and will be rejected by some receivers. Use 2048-bit minimum. Note: 2048-bit keys exceed the 255-byte TXT string limit — split across multiple strings in the TXT record (most DNS providers handle this automatically).
Ed25519 is the future. Much smaller keys (~44 bytes vs ~400 for RSA-2048), no TXT splitting needed, faster to sign/verify. Support is growing but not universal. Consider dual-signing with both RSA and Ed25519 during transition.
DMARC is the policy and reporting layer. It checks whether SPF or DKIM results align with the
From: header domain, and tells receivers what to do on failure. Without DMARC, SPF and DKIM results
are advisory — receivers decide independently what to do.
# Monitoring only (start here)
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-forensic@example.com"
# Quarantine policy with strict DKIM, relaxed SPF
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; sp=quarantine; adkim=s; aspf=r; pct=100; rua=mailto:dmarc-agg@example.com; fo=1"
# Full reject (target state for mature domains)
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-forensic@example.com; fo=1"| Tag | Values | Default | Purpose |
|---|---|---|---|
v | DMARC1 | required | Version identifier (must be first tag) |
p | none / quarantine / reject | required | Policy for domain |
sp | none / quarantine / reject | falls back to p | Policy for subdomains |
adkim | r (relaxed) / s (strict) | r | DKIM alignment mode |
aspf | r (relaxed) / s (strict) | r | SPF alignment mode |
pct | 0–100 | 100 | % of messages subject to policy (for gradual rollout) |
rua | mailto:addr | none | Aggregate report destination (daily XML) |
ruf | mailto:addr | none | Forensic/failure report destination (per-message) |
fo | 0 / 1 / d / s | 0 | Failure reporting options: 0=both fail, 1=either fails, d=DKIM fail, s=SPF fail |
ri | seconds | 86400 | Aggregate report interval (most receivers ignore this) |
Organizational domain match. Subdomains of the From: domain are accepted.
From: user@mail.example.comd=example.com → alignedbounce.example.com → alignedExact domain match required. No subdomain tolerance.
From: user@mail.example.comd=example.com → not alignedd=mail.example.com → alignedp=none; rua=mailto:... — Collect reports for 2-4 weeks. Identify all legitimate senders.p=quarantine; pct=10 — Quarantine 10% of failures. Monitor rua reports for false positives.p=quarantine; pct=50 then pct=100 — Gradually increase enforcement. Fix remaining senders.p=reject; pct=25 then pct=100 — Hard reject unauthorized messages. Final target state.<feedback>
<report_metadata>
<org_name>google.com</org_name>
<date_range><begin>1739577600</begin><end>1739664000</end></date_range>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<p>quarantine</p>
<sp>quarantine</sp>
<adkim>s</adkim>
<aspf>r</aspf>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>203.0.113.45</source_ip>
<count>1482</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<row>
<source_ip>198.51.100.99</source_ip>
<count>23</count>
<policy_evaluated>
<disposition>quarantine</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
</record>
</feedback>Cross-domain rua reporting requires authorization. If your DMARC record sends reports to a different domain
(rua=mailto:reports@monitoring.net), the target domain must publish a TXT record:
example.com._report._dmarc.monitoring.net. IN TXT "v=DMARC1"
ARC preserves authentication results across forwarding hops where SPF and DKIM would otherwise break. Each intermediary adds a set of three headers forming a verifiable chain of custody.
ARC-Authentication-Results (AAR) — snapshot of auth results at this hopARC-Message-Signature (AMS) — DKIM-like signature of the message at this hopARC-Seal (AS) — signature over the chain of all previous ARC sets + this AAREach set is numbered (i=1, i=2, ...) forming an ordered chain.
Subject or body (breaks DKIM).forward, alias expansion)ARC-Seal: i=1; a=rsa-sha256; cv=none; d=forwarder.net; s=arc2026;
b=dOdFEyhrk/...
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=forwarder.net; s=arc2026;
h=from:to:subject:date:message-id;
bh=2jUSOH9NhtVGCQWNr9BrI...;
b=Kf8mMGUa7/...
ARC-Authentication-Results: i=1; forwarder.net;
dkim=pass header.d=example.com header.s=s2026;
spf=pass smtp.mailfrom=example.com;
dmarc=pass header.from=example.com
# cv= values: "none" (first hop), "pass" (chain valid), "fail" (chain broken)
BIMI displays a brand logo next to authenticated messages in supporting email clients.
It requires DMARC p=quarantine or p=reject as a prerequisite.
# Basic (logo only, some providers require VMC)
default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/brand/logo.svg"
# With Verified Mark Certificate (required by Gmail, Apple Mail)
default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/brand/logo.svg; a=https://example.com/brand/vmc.pem"quarantine or reject (not none)SPF/DKIM/DMARC authenticate the sender. MTA-STS and DANE authenticate the transport channel, preventing TLS downgrade and man-in-the-middle attacks on SMTP connections.
HTTPS-based policy that tells senders: "only deliver to my MX hosts over verified TLS."
_mta-sts.example.com. IN TXT "v=STSv1; id=20260215"https://mta-sts.example.com/.well-known/mta-sts.txtenforce/testing/none)id value whenever you update the HTTPS policy fileversion: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
mx: *.example.com
max_age: 604800DNSSEC-based certificate pinning for SMTP. Stronger than MTA-STS but requires DNSSEC.
# Usage=3 (DANE-EE), Selector=1 (SubjectPublicKeyInfo), Matching=1 (SHA-256)
_25._tcp.mx1.example.com. IN TLSA 3 1 1 (
2bb183af2b1c057d0f256891c...
)_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"
# Reports include:
# - Negotiation failures (certificate errors, protocol mismatches)
# - MTA-STS policy validation failures
# - DANE/TLSA validation failuresAlways validate DNS records before and after changes. A single typo in an SPF record can cause permerror for your entire domain. These commands should be muscle memory.
# SPF record
dig +short TXT example.com | grep spf
# DKIM public key (replace selector)
dig +short TXT s2026._domainkey.example.com
# DMARC policy
dig +short TXT _dmarc.example.com
# BIMI record
dig +short TXT default._bimi.example.com
# MTA-STS policy indicator
dig +short TXT _mta-sts.example.com
# TLS-RPT
dig +short TXT _smtp._tls.example.com
# MX records (for SPF mx mechanism validation)
dig +short MX example.com
# DANE/TLSA
dig +short TLSA _25._tcp.mx1.example.com
# Check for multiple TXT records (common misconfiguration)
dig TXT example.com +noall +answer | grep -c "v=spf1"
# Should return 1. Multiple SPF records = permerror.Authentication-Results: mx.google.com;
dkim=pass header.i=@example.com header.s=s2026 header.b=LjIGMt;
spf=pass (google.com: domain of bounce@example.com designates 203.0.113.45 as permitted sender) smtp.mailfrom=bounce@example.com;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com
# Key fields to check:
# dkim=pass/fail + header.d= (signing domain) + header.s= (selector)
# spf=pass/fail + smtp.mailfrom= (envelope sender)
# dmarc=pass/fail + header.from= (RFC5322 From) + dis= (disposition applied)| Tool / Service | Purpose | Notes |
|---|---|---|
dig / drill | Raw DNS queries | Essential. Check TXT, MX, TLSA records directly. |
opendkim-testkey | Validate DKIM key publication | opendkim-testkey -d example.com -s s2026 -vvv |
spfquery / pyspf | SPF record evaluation | Test specific IP against domain's SPF policy |
| Mail-tester.com | Send a test email, get full report | Quick deliverability and auth check |
| MXToolbox | Online DNS/SPF/DKIM/DMARC checker | Good for quick validation, shows lookup count |
| dmarcian / Valimail | DMARC aggregate report analysis | Parses rua XML into dashboards |
swaks | Swiss Army Knife for SMTP | swaks --to test@example.com --from me@example.com --server mx.example.com |
| Google Postmaster Tools | Reputation and auth metrics for Gmail | Domain-level DKIM/SPF/DMARC pass rates |
Most email authentication failures come from a small set of misconfigurations. Learn to recognize these patterns
in aggregate reports and Authentication-Results headers.
| Symptom | Auth-Results | Root Cause | Fix |
|---|---|---|---|
| SPF permerror | spf=permerror |
>10 DNS lookups, syntax error, or multiple SPF TXT records | Flatten includes, remove duplicates, use subdomain delegation |
| SPF fail on forwarded mail | spf=fail |
Forwarding server IP not in sender's SPF | Implement SRS on forwarder, rely on DKIM + ARC for DMARC |
| DKIM fail: body hash mismatch | dkim=fail (body hash did not verify) |
Message body modified in transit (footer added, encoding changed) | Fix intermediary, use l= body length tag (risky), or ARC |
| DKIM fail: key not found | dkim=fail (no key for signature) |
DNS key record missing, wrong selector, or propagation delay | Verify dig TXT selector._domainkey.domain, wait for TTL |
| DMARC fail: alignment | dmarc=fail, but spf=pass and/or dkim=pass |
SPF domain or DKIM d= doesn't match From: domain |
Sign with d= matching From: domain, or use relaxed alignment |
| DMARC fail: third-party sender | dmarc=fail |
SaaS sends with your From: but no DKIM delegation |
Have vendor sign with your domain via CNAME'd DKIM selector |
| Sporadic DKIM temperror | dkim=temperror |
DNS timeout for key lookup, often under receiver load | Low TTL on key record, ensure nameserver reliability, add redundancy |
| SaaS SPF include bloat | spf=permerror |
5+ SaaS vendors each adding include: chains |
Dedicate subdomains per vendor, or flatten with automated tooling |
Predefined runbooks for the most common authentication incidents. Separate immediate mitigation from root cause investigation.
pct=0 if widespread legitimate breakage while fixing.p= (empty). Remove record after 30 days.mail.example.com) for the vendor._domainkey namespace.Authentication-Results shows all-pass.[ ] SPF record published with -all (hard fail), lookup count verified < 10
[ ] No duplicate SPF TXT records on same domain
[ ] DKIM signing enabled on all outbound paths with 2048-bit+ RSA or Ed25519
[ ] DKIM key rotation schedule documented (quarterly or on compromise)
[ ] All DKIM selectors verified via dig + opendkim-testkey
[ ] DMARC record at p=reject (or quarantine minimum) with rua configured
[ ] DMARC aggregate reports ingested and monitored (not just collected)
[ ] Subdomain policy (sp=) explicitly set, not relying on inheritance assumptions
[ ] SaaS vendors sending as your domain have DKIM CNAME delegation, not just SPF
[ ] ARC signing enabled on any forwarding/relay infrastructure you operate
[ ] MTA-STS policy published and mode=enforce for receiving domains
[ ] TLS-RPT record configured to receive transport failure reports
[ ] BIMI record published (if DMARC at reject and VMC obtained)
[ ] Null SPF on domains that don't send email: "v=spf1 -all"
[ ] Null DMARC on non-sending domains: "v=DMARC1; p=reject; sp=reject"
[ ] DNS records version-controlled with automated deploymentDon't forget non-sending domains. Every domain you own that does not send email should still have
v=spf1 -all and v=DMARC1; p=reject to prevent spoofing. Attackers specifically target
unprotected parked and legacy domains.
; === SPF ===
example.com. IN TXT "v=spf1 ip4:203.0.113.0/24 include:_spf.google.com -all"
; === DKIM ===
s2026._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQE..."
s2026ed._domainkey.example.com. IN TXT "v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQH..."
; === DMARC ===
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=r; fo=1; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-forensic@example.com"
; === BIMI ===
default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/.well-known/logo.svg; a=https://example.com/.well-known/vmc.pem"
; === MTA-STS ===
_mta-sts.example.com. IN TXT "v=STSv1; id=20260215t1"
; === TLS-RPT ===
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"
; === Non-sending subdomain protection ===
parked.example.com. IN TXT "v=spf1 -all"
_dmarc.parked.example.com. IN TXT "v=DMARC1; p=reject"