SPF, DKIM, and DMARC Explained: The Email Authentication Guide for 2026
Every mailbox provider asks the same two questions about an incoming message: did this really come from the domain it claims? and does that domain send mail people want? SPF, DKIM, and DMARC answer the first question. Get them wrong and the second question never matters — unauthenticated mail goes to spam or gets rejected outright.
This guide explains what each protocol does, the DNS records involved, and a rollout order that won't break your own mail.
SPF: authorizing servers by IP
SPF (RFC 7208) is a TXT record on your domain listing the servers allowed to send mail for it. When a receiver gets a message claiming to be from billing@acme.com, it looks up acme.com's SPF record and checks whether the connecting IP is authorized.
A typical record:
acme.com. TXT "v=spf1 include:_spf.mailblastr.com ~all"
The include: pulls in your email provider's authorized IP ranges; ~all (softfail) tells receivers to treat everything else with suspicion. Two rules save hours of debugging:
- One SPF record per domain. Multiple
v=spf1records are a permanent error. Merge providers into a single record with multipleinclude:terms. - Stay under 10 DNS lookups. Every
include:costs lookups; past 10, receivers returnpermerrorand your SPF silently stops working.
SPF's weakness: it breaks on forwarding. When a message is forwarded, the forwarding server's IP isn't in your record. That's exactly the gap DKIM covers.
DKIM: signing the message itself
DKIM (RFC 6376) attaches a cryptographic signature to every message, generated with a private key your email provider holds. Receivers fetch the matching public key from a DNS record like:
mb1._domainkey.acme.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."
If the signature verifies, the receiver knows two things: the message was authorized by the domain owner, and the signed content wasn't modified in transit. Because the signature travels with the message, DKIM survives forwarding.
Use 2048-bit keys (1024-bit is deprecated by most providers) and rotate them periodically — provider-managed DKIM handles rotation for you.
DMARC: policy and reporting on top
SPF and DKIM authenticate, but neither tells receivers what to do on failure — and neither checks that the authenticated domain actually matches the From: header your reader sees. DMARC (RFC 7489) does both, through alignment: the domain that passed SPF or DKIM must match the From: domain.
_dmarc.acme.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@acme.com; adkim=r; aspf=r"
p=is your policy:none(just report),quarantine(send failures to spam),reject(refuse them).rua=receives aggregate reports — XML summaries of who is sending as your domain and whether they authenticate.
The rollout order that doesn't break anything
- Set up SPF and DKIM for every legitimate sender — your email platform, your helpdesk, your billing tool. Each needs its own DKIM signature or SPF include.
- Publish DMARC at
p=nonewith reporting. Nothing changes in delivery; you start receiving data. - Read two to four weeks of reports. Find every source sending as your domain. Authenticate the legitimate ones you forgot (there are always some).
- Move to
p=quarantine, thenp=reject. Once reports show clean alignment, tighten. Many teams sit atp=quarantine; pct=100for a month beforereject.
Since February 2024, Gmail and Yahoo require SPF and DKIM for bulk senders, DMARC (at least p=none) above roughly 5,000 messages/day, aligned From: domains, and one-click unsubscribe on marketing mail. These are rejection criteria, not suggestions.
What a provider should automate
You should never hand-assemble these records. When you add a domain on MailBlastr, the dashboard generates the exact SPF, DKIM, and DMARC records, offers one-click setup on Cloudflare, GoDaddy, and Namecheap via Domain Connect, verifies propagation, and then continuously monitors authentication on every send. The DNS records docs cover the manual records for any other DNS host.
Authentication is table stakes, not a growth hack — but it is the one piece of email infrastructure where a missing TXT record can zero your delivery rate overnight. Set it up once, properly, and start sending on a domain mailbox providers can trust.
Frequently asked questions
Do I need all three of SPF, DKIM, and DMARC?
Yes, if you send any meaningful volume. Gmail and Yahoo have required SPF and DKIM (plus DMARC for senders above roughly 5,000 emails/day to their users) since February 2024. Even below that threshold, missing authentication is the single most common reason mail lands in spam.
What is the difference between SPF and DKIM?
SPF authorizes sending servers by IP — a receiver checks whether the connecting server is listed in your domain's SPF record. DKIM signs the message itself with a private key, and receivers verify the signature against the public key in your DNS. SPF breaks on forwarding; DKIM survives it. That's why you want both.
What DMARC policy should I start with?
Start at p=none with a rua= reporting address so you see who is sending as your domain without affecting delivery. Once reports show only legitimate sources authenticating, move to p=quarantine, then p=reject. Rushing straight to p=reject before aligning every legitimate sender is how teams break their own invoices and password resets.
Does a strict DMARC policy improve deliverability?
Indirectly, yes. DMARC at enforcement (quarantine or reject) prevents spoofing of your domain, which protects your domain reputation over time — and domain reputation is the main input mailbox providers use to route your mail. Some providers also treat an enforced DMARC policy as a positive trust signal on its own.
Can my email provider set these records for me?
A good one automates most of it. MailBlastr generates the exact SPF, DKIM, and DMARC records for each sending domain and offers one-click DNS setup on Cloudflare, GoDaddy, and Namecheap, then verifies propagation for you.