Every cold email guide tells you to "set up your SPF and DKIM records." Most of them stop there. DMARC gets a brief mention; DANE almost never comes up. The result is a generation of outbound operators who have published partial authentication and think they are done. They are not done. The remote MTA can tell.
This post is the full tour: what each of the four authentication standards proves, how they compose, what happens when one is missing, and why DANE specifically is the detail that separates thoughtful infrastructure from box-ticking.
SPF — Sender Policy Framework
SPF is the oldest of the four and the simplest. It is a DNS TXT record at the sending domain that lists the IPs or hostnames allowed to send mail claiming to be from that domain.
Concretely, a record like:
v=spf1 ip4:203.0.113.10 -all
says: "mail claiming to be from this domain must come from 203.0.113.10, and anything else should be hard-rejected." The receiving MTA looks up the sender's domain, pulls the SPF record, and checks whether the connecting IP matches.
What SPF proves
SPF proves that the connecting IP is on a list you published. It does not prove that the message was signed by you, and it breaks the moment mail is forwarded (the forwarding server becomes the new connecting IP, and it is not in your SPF). SPF alone is necessary but not sufficient.
Common SPF mistakes
- Including +all or ?all. This makes the record useless; any IP passes. Use -all for hard-fail.
- Chaining too many include: directives. SPF has a 10-lookup limit; exceed it and the record silently fails.
- Mixing multiple SPF records on the same domain. Only one is allowed. Two records = record is ignored.
DKIM — DomainKeys Identified Mail
DKIM adds a cryptographic signature to each outgoing email. The signature is produced by the sending MTA using a private key, and verified by the receiving MTA against a public key published in DNS.
A DKIM record lives at <selector>._domainkey.<domain>. The selector is arbitrary (often default or mail) and lets you rotate keys by publishing new selectors.
What DKIM proves
DKIM proves two things: (1) the message was actually signed by someone holding the private key for this domain, and (2) the message body and key headers have not been tampered with in transit.
Unlike SPF, DKIM survives forwarding — the signature is computed over the message itself, not the connection. This is why DKIM matters more than SPF for modern deliverability. Every major inbox provider treats a DKIM failure as a strong negative signal.
Common DKIM mistakes
- Using 1024-bit keys in 2026. 2048-bit is the minimum, and 1024-bit is now treated as suspicious by several major providers.
- Never rotating the key. Rotate every 6 months at minimum. Publish a new selector, wait for propagation, switch the MTA to sign with the new key, keep the old one published for 7 days in case of in-flight mail, then remove.
- Signing with one selector but publishing a different one in DNS. This happens more often than it should — usually because someone copy-pasted the wrong public key.
DMARC — Domain-based Message Authentication
DMARC is the policy layer. It tells receiving MTAs what to do when SPF or DKIM fails, and where to send reports about authentication results.
A DMARC record at _dmarc.<domain> looks like:
v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc-reports@example.com
Breakdown:
- p=reject — if authentication fails, reject the message.
- sp=reject — same policy for subdomains.
- adkim=s — DKIM must align strictly (the signing domain must match the From: domain exactly, not just share a parent).
- aspf=s — SPF must align strictly.
- rua — where to send aggregate reports.
What DMARC proves
DMARC proves that the domain in the visible From: header is the same domain that was authenticated. Without alignment, a spammer can pass SPF and DKIM against one domain while showing a different one in the From: header — classic phishing. DMARC closes that loophole.
DMARC rollout, in order
- Publish p=none with rua reporting. Collect reports for 14 days to see who is sending as you.
- Investigate anything unexpected in the reports. Legitimate services you forgot about will show up here.
- Move to p=quarantine. Watch reports for another 14 days.
- Move to p=reject. This is the final state.
Never jump straight to p=reject on day one. You will bounce legitimate mail from forgotten systems (HR tools, SaaS notifications, third-party senders) and it will take you days to figure out why.
DANE — DNS-based Authentication of Named Entities
DANE is the one most cold-email providers skip, which is why we give it the most space here.
DANE ties a server's TLS certificate to a DNS record (specifically, a TLSA record). The receiving MTA looks up the DANE record before opening a TLS connection to your mail server. If the certificate presented during TLS doesn't match the DANE record, the receiver aborts — proving that the connection is not being downgraded by a man-in-the-middle.
A DANE TLSA record at _25._tcp.mail.<domain> (port 25, TCP, mail subdomain) looks like:
_25._tcp.mail.example.com. IN TLSA 3 1 1 abc123...
What DANE proves
DANE proves that the TLS connection you established is the one the DNS zone owner intended. Without DANE, a network-level attacker can strip TLS (downgrade attack), present a fake certificate, or inject a rogue MTA — and STARTTLS alone will not catch it.
Why most providers skip DANE
Three reasons, in decreasing legitimacy:
- DANE requires DNSSEC on the parent zone. If your DNS hosting does not support DNSSEC, you cannot publish DANE records that the receiving MTA will trust.
- DANE requires your mail server's hostname and certificate to be under tight operational control. When the cert rotates, the TLSA record rotates with it. On shared infrastructure where the certificate is managed by the provider for many tenants, this is operationally hard.
- Most providers simply do not bother because nobody asks.
DANE adoption is still minority among cold-email providers in 2026. Google, Microsoft, and Fastmail all check DANE when present and treat a valid DANE match as a positive signal. Not having DANE is not fatal — most mail still flows fine without it — but it is a small, cumulative advantage that stacks with the rest.
How the four compose
Read from the bottom up:
- DANE: proves the TLS session is authentic (no downgrade, no MITM).
- SPF: proves the sending IP is authorized.
- DKIM: proves the message was signed and has not been tampered with.
- DMARC: enforces that the From: domain matches the authenticated domain and defines what happens on failure.
Each covers a different attack surface. SPF without DKIM is trivially defeated by spoofing the envelope sender. DKIM without DMARC can be bypassed with a different From: header. DMARC without DANE is defensible at the application layer but vulnerable at the TLS layer. All four together is the state-of-the-art for 2026, and every major receiver scores them additively.
How SendChief handles this
On SendChief, all four are auto-configured during provisioning. SPF is published with the dedicated VPS IP, DKIM keys are generated per domain and rotated on schedule, DMARC starts at p=none with reporting enabled, and DANE TLSA records are published against the Let's Encrypt certificate chain with DNSSEC on the parent zone. The admin can move DMARC from p=none to p=reject whenever their reporting window looks clean.
The operationally-hard part about DANE is the reason most providers skip it. On infrastructure where your VPS, your DNS, and your certificate are all under one umbrella, DANE stops being hard and starts being a detail.
Diagnostics
Before sending a campaign, verify your stack:
- SPF: dig TXT and look for a v=spf1 record that lists exactly your sending IP and ends in -all.
- DKIM: send a test message to a Gmail account and view the original; check "Authentication-Results" for dkim=pass.
- DMARC: dig TXT _dmarc. and verify your policy.
- DANE: dig TLSA _25._tcp.mail. and verify a record exists.
- Also run a test against a service like mail-tester.com or MXToolbox to catch anything you missed.
If any of the four is missing or broken, fix it before your next send. It is the cheapest, most impactful deliverability work you can do — and it is free.