SPF, DKIM, DMARC: Email Authentication Explained

Email authentication is the layer that tells inbox providers your mail is legitimate. If your domain doesn't have SPF, DKIM, and DMARC configured correctly, every email you send is treated as suspicious by default — landing in spam, getting silently dropped, or in worst cases being spoofed by attackers pretending to be you.

The good news: setting up all three is a one-time job that takes an hour, and the deliverability gain is enormous. This guide explains what each one does, how they fit together, and how to set them up correctly.

Why Email Authentication Matters

SMTP — the protocol email runs on — was designed in the 1980s with no built-in way to verify the sender. Anyone can send email claiming to be from any domain. SPF, DKIM, and DMARC are three separate standards that, layered together, let receiving servers cryptographically verify the sender and decide what to do if verification fails.

Without authentication:

• Gmail, Outlook, Yahoo, and Apple Mail aggressively filter or block your sends
• Attackers can spoof your domain to phish your customers or partners
• Your bounce rate appears higher than it really is
• Email warmup on a new domain becomes nearly impossible

Since 2024, Gmail and Yahoo require all bulk senders (5,000+ messages/day to their domains) to have SPF, DKIM, and DMARC configured. Without them, your mail simply doesn't arrive.

SPF (Sender Policy Framework)

SPF is a list of authorized sending servers for your domain, published as a TXT record in your domain's DNS. When a receiving server gets an email claiming to be fromyou@yourdomain.com, it checks the IP address that delivered the message against your SPF record. If the IP isn't on the list, the mail is suspicious.

A typical SPF record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

This says: "Mail from this domain may come from Google Workspace and SendGrid. Anything else, soft-fail."

Common SPF mistakes

• Multiple SPF records. RFC 7208 allows only one TXT record per domain starting with v=spf1. Multiple records is the most common SPF error and causes silent authentication failures.
• Exceeding 10 DNS lookups. SPF resolves include: mechanisms recursively. More than 10 lookups makes the record fail with a permanent error. Use SPF flatteners only as a last resort.
• Using +all. This tells receivers any server is authorized — effectively turning off SPF. Use ~all (soft-fail) or -all (hard-fail) instead.

DKIM (DomainKeys Identified Mail)

DKIM is a cryptographic signature added to the headers of every email you send. The public key is published in your DNS as a TXT record; the private key is held by your ESP (or your own mail server). Receivers verify the signature against the public key — if it matches, they know the message wasn't modified in transit and was sent by someone who controls your domain's DKIM key.

SPF only checks the connecting IP. DKIM checks the message itself. That's why both are needed: SPF can fail when mail is forwarded (the forwarding server isn't on your SPF list), but DKIM survives forwarding because the signature travels with the message.

Setting up DKIM

Most ESPs (SendGrid, Mailchimp, Brevo, Klaviyo) generate DKIM keys for you and provide the DNS records to add. You typically add a CNAME or TXT record at a subdomain like s1._domainkey.yourdomain.com. After publication, verify activation in your ESP's sender authentication panel.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC is the policy layer on top of SPF and DKIM. It tells receiving servers what to do when a message fails SPF or DKIM checks for your domain — and where to send reports about it.

A starter DMARC record:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

This says: "Don't change handling based on DMARC failures yet (p=none), but send aggregate reports to dmarc@yourdomain.com so I can see what's happening."

DMARC has three policy levels:

Don't skip straight to p=reject. Run p=none for at least two weeks, review aggregate reports (forwarded by services like Postmark's DMARC Digests or Dmarcian), fix any legitimate sources that are failing, then move to p=quarantine and eventually p=reject.

How They Work Together

Each one closes a different gap:

• SPF — "Did this come from an authorized server?"
• DKIM — "Was the message modified, and was it signed by the domain owner?"
• DMARC — "What should I do when SPF or DKIM fails, and how do I tell the domain owner?"

Inbox providers run all three checks. A message that passes all three is trusted. One that fails any of them is treated with suspicion — exactly how, depends on your DMARC policy.

Step-by-Step Setup Order

1. Inventory your sending sources. Every service that sends email on behalf of your domain — your ESP, your transactional provider, Google Workspace, support tools, billing platforms — needs to be authenticated.
2. Configure SPF. Combine all your authorized sources into a single TXT record. Validate with an SPF checker (MXToolbox, dmarcian).
3. Configure DKIM for each source. Each ESP has its own DKIM panel — add the DNS records they generate, verify activation in each one.
4. Publish DMARC at p=none. Add an rua mailbox to receive aggregate reports.
5. Monitor reports for 2–4 weeks. Look for legitimate sending sources that are failing — usually older marketing tools or scripts you forgot about.
6. Move to p=quarantine after a clean week of reports.
7. Move to p=reject after another clean week. You now have full domain protection.

Common Mistakes

• Setting up SPF/DKIM but skipping DMARC. Without DMARC, receivers don't know what to do on failure — and you have no visibility into spoofing attempts.
• Jumping straight to p=reject. One unauthenticated legitimate source and you lose mail you needed delivered. Always start at p=none.
• Forgetting subdomains. A DMARC record at the apex covers the apex only; use sp= for subdomain policy or publish DMARC at each subdomain.
• Authenticating the envelope but not the visible from. DMARC checks alignment between the visible From: address and the SPF/DKIM domain. Misalignment fails DMARC even when SPF and DKIM individually pass.

The Bottom Line

SPF, DKIM, and DMARC aren't optional anymore. They're table stakes for any domain that sends email at scale, and the gap between properly authenticated mail and unauthenticated mail in inbox placement is enormous. Spend the hour to set them up, spend two weeks at p=none watching the reports, then ratchet up the policy. Once they're live, deliverability gets noticeably better and stays that way — and attackers can't spoof your domain to phish your customers.