SPF, DKIM, DMARC: The Complete Email Authentication Guide

In February 2024, Google and Yahoo rolled out new requirements for bulk email senders: authenticate with SPF and DKIM, publish a DMARC record, or watch your emails get rejected. It wasn't a suggestion. It was a deadline, and senders who missed it saw their deliverability drop overnight.

But email authentication isn't just a compliance checkbox for high-volume senders. If you own a domain and anyone sends email from it — even if "anyone" is just you sending invoices — SPF, DKIM, and DMARC protect you from having your domain impersonated, your reputation damaged, and your messages lost to spam folders.

The problem is that these protocols are genuinely confusing. They interact in non-obvious ways, the syntax is unforgiving, and a small mistake can break your email without any visible error. This guide aims to cut through the confusion.

The big picture: how the three protocols work together

Before diving into each protocol, it helps to understand how they fit together. Think of them as three layers of the same defense:

• SPF answers the question: "Is this server authorized to send email for this domain?"
• DKIM answers: "Was this email tampered with after it was sent?"
• DMARC answers: "What should happen when SPF or DKIM fails, and does the email actually align with the domain it claims to be from?"

SPF and DKIM are the authentication mechanisms. DMARC is the policy layer that ties them together and adds reporting. You need all three. SPF without DMARC doesn't tell receivers what to do with failures. DMARC without SPF or DKIM has nothing to authenticate against. They're a package deal.

SPF: Sender Policy Framework

What SPF does

SPF is a DNS TXT record that lists every server (by IP address or hostname) that is authorized to send email on behalf of your domain. When a receiving mail server gets an email claiming to be from your domain, it looks up your SPF record and checks whether the sending server's IP is on the list.

A typical SPF record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.5 -all

This says: Google Workspace, SendGrid, and the IP 203.0.113.5 are allowed to send email for this domain. Everyone else should be rejected (-all).

The enforcement mechanism matters

The all mechanism at the end of your SPF record is where most of the value lives:

• -all (hard fail) — reject emails from unauthorized servers. This is what you want.
• ~all (soft fail) — mark as suspicious but deliver anyway. Fine as a transitional step, but weak as a permanent policy.
• ?all (neutral) — effectively no enforcement. Barely better than not having SPF at all.

You can check your current SPF configuration with our free SPF checker.

Common SPF mistakes

Too many DNS lookups. SPF has a hard limit of 10 DNS lookups. Each include:, a:, mx:, and redirect counts as one lookup. Nested includes (an include that itself includes other domains) count toward the limit too. Exceed 10 and SPF validation fails entirely with a "permerror." This is the single most common SPF problem I see.

Multiple SPF records. You can only have one SPF TXT record per domain. If you have two (maybe from different service providers each telling you to "add this SPF record"), SPF validation fails. Combine them into a single record.

Forgetting a sending service. You set up SPF with your email provider's include, but you also send email through a marketing tool, a transactional email service, a CRM, and a help desk. If any of these aren't in your SPF record, emails they send will fail SPF checks.

DKIM: DomainKeys Identified Mail

What DKIM does

DKIM adds a cryptographic signature to outgoing emails. The sending server signs parts of the message (headers and body) using a private key. The corresponding public key is published as a DNS TXT record. When a receiving server gets the email, it looks up the public key and verifies the signature.

If the signature is valid, the receiver knows two things: the email genuinely came from a server that holds the private key for that domain, and the message wasn't altered in transit.

How DKIM records look

DKIM public keys are published as TXT records at a specific subdomain:

selector._domainkey.yourdomain.com

The "selector" is a label chosen by the sending service. Google Workspace uses google, SendGrid uses something like s1, Mailchimp uses something else. Each sending service has its own selector and key pair.

The TXT record value contains the public key in a format like:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQ...

Common DKIM pitfalls

Forgetting to publish the DNS record. DKIM requires both configuration on the sending server (to sign messages) and a DNS record (so receivers can verify). Setting up signing without publishing the key, or publishing the key without enabling signing, both result in DKIM failure.

Key rotation. DKIM keys should be rotated periodically (at least annually). Some providers handle this automatically. Others require manual rotation. If you rotate the key on the sending side but forget to update the DNS record, every signed email fails verification until you fix it.

Modifying emails after signing. Mailing list software, forwarding services, and some security gateways can modify message headers or body after DKIM signing. This breaks the signature. It's not always avoidable, which is one reason DMARC checks both SPF and DKIM — if one fails due to forwarding, the other can still pass.

DMARC: the policy layer

What DMARC does

DMARC sits on top of SPF and DKIM and adds two critical things: alignment and policy.

Alignment means the domain in the email's visible "From" header must match the domain used in SPF or DKIM authentication. Without DMARC, a spammer could pass SPF using their own domain while spoofing yours in the From header — technically passing SPF while still impersonating you. DMARC closes that loophole.

Policy tells receiving servers what to do when authentication fails:

• p=none — do nothing (monitor only). Useful when you're first deploying DMARC and want to see reports without affecting delivery.
• p=quarantine — send failed emails to spam. A good middle ground that catches most spoofing while giving you a safety net if legitimate email accidentally fails.
• p=reject — block failed emails outright. Maximum protection. Spoofed emails never reach the recipient.

Check your current setup with our free DMARC checker.

The DMARC record

DMARC is published as a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100

Key tags:

• p — the policy (none, quarantine, reject)
• rua — where to send aggregate reports (XML summaries of who's sending email from your domain)
• ruf — where to send forensic reports (details on individual failures, not supported by all providers)
• pct — what percentage of failing emails the policy applies to (useful for gradual rollout)

DMARC aggregate reports

This is DMARC's secret weapon and the part most people don't use enough. Aggregate reports are XML files that receiving mail servers send to the address in your rua tag. They tell you exactly which servers sent email using your domain, whether those emails passed or failed SPF and DKIM, and what the sending volumes look like.

Reading raw XML reports is painful. Services like dmarcian, Postmark's DMARC Digests, or EasyDMARC parse them into readable dashboards. Even if you don't want to pay for a parsing service, the reports are invaluable during the initial deployment phase — they show you every legitimate sending source so you can make sure your SPF and DKIM are complete before moving from p=none to p=reject.

Deployment roadmap: from zero to full enforcement

Don't try to go from no email authentication to p=reject in a single afternoon. Here's the safe, staged approach:

Week 1: Inventory and SPF

1. List every service that sends email from your domain (email provider, marketing tool, transactional email, CRM, help desk, etc.)
2. Create or update your SPF record to include all of them
3. Use ~all (soft fail) initially, not -all
4. Verify with our SPF checker — confirm it's valid and under the 10-lookup limit

Week 2: DKIM

1. Enable DKIM signing for each sending service (Google Workspace, SendGrid, Mailchimp, etc. all have instructions in their docs)
2. Publish the DKIM public key DNS records for each selector
3. Send test emails and check headers to confirm DKIM signatures are present and valid

Week 3: DMARC in monitor mode

1. Publish a DMARC record with p=none and a rua address for reports
2. Wait 1-2 weeks for aggregate reports to accumulate
3. Review the reports: are any legitimate sending sources failing SPF or DKIM? Fix them.

Week 5: Tighten enforcement

1. Once reports confirm all legitimate email passes authentication, upgrade DMARC to p=quarantine
2. Upgrade SPF from ~all to -all
3. Monitor reports for another 2 weeks

Week 7+: Full enforcement

1. Upgrade DMARC to p=reject
2. Set up continuous email security monitoring to catch any future changes to SPF, DKIM, or DMARC records
3. Continue reviewing DMARC aggregate reports monthly

The whole process takes about two months if you're methodical. Rushing it risks breaking legitimate email. Being patient with the monitoring phase is what separates smooth deployments from panicked rollbacks.

Why monitoring email authentication matters after setup

Deploying SPF, DKIM, and DMARC is not the end. It's the beginning. Here's why ongoing monitoring is essential:

New sending services. Every time you add a new tool that sends email (a new CRM, a ticketing system, a marketing automation platform), you need to update your SPF record and set up DKIM. If you forget, emails from the new service fail authentication and go to spam. Email security monitoring alerts you if your SPF or DMARC record changes unexpectedly.

Accidental modifications. Someone on your team edits a DNS record and inadvertently breaks the SPF record. Or a provider migration resets your DKIM keys. Without monitoring, you might not notice for weeks — until someone mentions they haven't received your emails in a while.

Policy drift. You deployed DMARC at p=reject. Six months later, a colleague sets it back to p=none to troubleshoot a deliverability issue and forgets to revert it. Your domain is now unprotected against spoofing, and nobody knows.

Evolving requirements. Email providers periodically tighten their requirements. What passed last year might not pass next year. Monitoring keeps you aware of your current state so you can adapt proactively.

Quick reference: email authentication checklist

Run a free DNS health check to see how many of these your domain currently passes.

Wrapping up

Email authentication is one of those things that's easy to put off and painful to fix after the fact. The good news: the setup itself isn't complicated. It's meticulous — you need to account for every sending source, get the syntax right, and test before enforcing — but none of the individual steps are difficult.

The critical part is what comes after: monitoring. SPF, DKIM, and DMARC records live in DNS. DNS changes. People edit records. Providers rotate keys. Configurations drift. A monitoring tool that watches your email authentication records and alerts you when something changes is the only way to ensure the protection you set up today is still working six months from now.

DNSMonit monitors SPF, DMARC, and all your DNS records with every check. The free plan covers 3 domains with daily checks. The lifetime plan at $39 covers unlimited domains at 15-minute intervals. It's a fraction of what a deliverability crisis costs.

Your domain's reputation is built email by email. Don't let a misconfigured TXT record undo it.