SPF, DKIM, and DMARC: The Complete Email Authentication Guide

SPF, DKIM, and DMARC are the three DNS-based protocols that prove your emails are legitimate. Without them, anyone can send email claiming to be from your domain. Mail servers at Google, Microsoft, and Yahoo use these records to decide whether to deliver, quarantine, or reject your messages — and since 2024, having them configured is no longer optional for bulk senders.

Why Email Authentication Matters

Email was designed without authentication. The original SMTP protocol from 1982 allows any server to claim any sender address — a design flaw that has enabled decades of spoofing and phishing attacks. Authentication protocols were developed to close this gap by publishing verifiable records in DNS that receiving servers can check.

Without authentication, your domain is vulnerable to spoofing. Attackers can send phishing emails that appear to come from your address, damaging your brand and putting your customers at risk. Even if you never send spam yourself, a spoofed domain can land your legitimate mail in junk folders because ISPs associate your domain with suspicious activity.

In February 2024, Google and Yahoo introduced new requirements for bulk senders: SPF or DKIM must pass, DMARC must be present, and one-click unsubscribe must be supported. Senders who do not meet these requirements see their messages rejected or routed to spam. For a broader look at how authentication fits into overall deliverability, see our email deliverability guide.

SPF: Sender Policy Framework

SPF lets you publish a list of IP addresses and hostnames that are authorized to send email on behalf of your domain. When a receiving server gets a message claiming to be from [email protected], it looks up the SPF record for example.com and checks whether the sending server's IP is on the authorized list. If it is not, the check fails.

SPF is published as a DNS TXT record on your domain. A typical record looks like this:

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com mx ~all

Breaking this down: v=spf1 identifies the record version. ip4:203.0.113.0/24 authorizes a specific IP range. include:_spf.google.com pulls in Google's authorized sending IPs (used when sending through Google Workspace). mx authorizes the servers listed in your MX records. ~all is a soft fail — messages from unauthorized IPs are marked suspicious but not rejected outright.

The all mechanism at the end controls what happens to mail that does not match any earlier mechanism. -all is a hard fail (reject), ~all is a soft fail (mark), and ?all is neutral (no opinion). Most senders start with ~all and move to -all once they are confident their SPF record is complete.

One critical constraint: SPF records are limited to 10 DNS lookups. Each include, mx, and a mechanism triggers a lookup. Exceeding 10 causes a permanent error (permerror), which many receivers treat as a fail. If you use multiple email services, you may need to flatten your SPF record to stay within the limit.

DKIM: DomainKeys Identified Mail

DKIM adds a cryptographic signature to every outgoing message. The signature is generated using a private key held by your mail server and can be verified by anyone who retrieves the corresponding public key from your DNS. This proves two things: the message was sent by a server that controls your domain, and the message content has not been altered in transit.

The signature appears as a DKIM-Signature header in the email. It references a selector — a label that identifies which key pair was used — and the domain. The receiving server constructs a DNS query using the selector and domain to retrieve the public key, then uses it to verify the signature.

To set up DKIM, you generate a public/private key pair (typically 2048-bit RSA) and publish the public key as a DNS TXT record at a subdomain in this format:

selector._domainkey.example.com  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

The selector can be any string — common choices are default,google, or a date like 2025q1. Using a date-based selector makes key rotation easier: you publish the new key under a new selector, update your mail server to sign with the new key, then remove the old record after a few days.

Most email service providers (Google Workspace, Microsoft 365, SendGrid, Mailgun) generate DKIM keys for you and provide the DNS record to publish. If you run your own mail server, you can generate keys with opendkim-genkey or openssl.

DMARC: Domain-based Message Authentication

DMARC ties SPF and DKIM together and tells receiving servers what to do when authentication fails. It also enables reporting — you receive aggregate and forensic reports from participating mail providers showing you exactly which messages passed or failed authentication and why.

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

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

The p tag is the policy. p=none means monitor only — take no action on failing messages but send reports. p=quarantine routes failing messages to the spam folder. p=reject tells the receiving server to drop the message entirely. Most senders start at p=none, review reports, then graduate to p=quarantine and eventually p=reject.

The rua tag specifies where aggregate reports are sent (daily XML summaries). The ruf tag specifies where forensic reports go (individual message failure reports). Aggregate reports are essential for monitoring — they show you all the sources sending mail from your domain, including services you may have forgotten about.

DMARC also enforces alignment. For a message to pass DMARC, either SPF or DKIM must pass and the authenticated domain must align with the From header domain. Strict alignment requires an exact match; relaxed alignment (the default) allows organizational domain matches.

How SPF, DKIM, and DMARC Work Together

The three protocols form a layered authentication chain. SPF verifies the sending server is authorized. DKIM verifies the message content and sender identity cryptographically. DMARC enforces a policy based on the results of both and requires that the authenticated domain matches the visible From address.

A message passes DMARC if at least one of the following is true: SPF passes and the SPF-authenticated domain aligns with the From domain, or DKIM passes and the DKIM-signing domain aligns with the From domain. This means you can pass DMARC with just DKIM even if SPF fails — which is important for forwarded mail, where SPF often breaks because the forwarding server's IP is not in the original sender's SPF record.

When a message fails DMARC, the receiving server applies the policy in your DMARC record. At p=none, the message is delivered normally but a failure report is generated. At p=quarantine, it goes to spam. At p=reject, it is dropped and the sender receives a bounce. The pct tag lets you apply the policy to a percentage of failing messages — useful for gradual rollout.

Step-by-Step Setup Guide

Follow these steps in order. Rushing to a strict DMARC policy before your SPF and DKIM are fully configured will cause legitimate mail to be rejected.

1. Publish your SPF record. Identify every service that sends email from your domain — your mail server, marketing platform, CRM, transactional email provider. Add each one to your SPF record using ip4, include, or mx mechanisms. End with ~all.
2. Generate and publish DKIM keys. For each sending service, generate a 2048-bit key pair (or use the keys your provider generates). Publish the public key as a DNS TXT record at selector._domainkey.yourdomain.com. Enable DKIM signing in each service.
3. Publish a DMARC record with p=none. Start monitoring before enforcing. Set p=none and configure rua to receive aggregate reports. Wait at least two weeks and review the reports.
4. Review DMARC reports. Use a DMARC report analyzer (Postmark, Dmarcian, or Google Postmaster Tools) to identify sources that are failing authentication. Fix any SPF or DKIM issues you find.
5. Move to p=quarantine, then p=reject. Once your reports show that all legitimate mail is passing authentication, update your policy to p=quarantine. Monitor for another two weeks, then move to p=reject for maximum protection.

Common Authentication Mistakes

Exceeding the SPF 10-lookup limit. Every include, mx, and a mechanism in your SPF record triggers a DNS lookup. The limit is 10. If you exceed it, the SPF check returns a permerror, which many receivers treat as a fail. Audit your SPF record regularly and flatten it (replace include mechanisms with explicit IP ranges) if you are approaching the limit.

Never rotating DKIM keys. DKIM private keys should be rotated periodically — at least annually, or immediately if you suspect a compromise. Use date-based selectors to make rotation seamless: publish the new key, update your mail server, then remove the old DNS record after a few days.

Staying at p=none forever. A DMARC policy of p=none provides no protection — it only generates reports. Many organizations publish a DMARC record to satisfy requirements but never move beyond p=none. Without enforcement, your domain remains vulnerable to spoofing.

Missing subdomain policies. Your DMARC record covers your root domain, but subdomains inherit the policy only if you set sp=reject (subdomain policy). If you have subdomains that should never send email, set sp=reject to prevent them from being spoofed even if your root domain policy is still at p=quarantine.

Authentication vs Verification

Authentication and verification are related but distinct concepts. Authentication (SPF, DKIM, DMARC) proves that a message was sent by an authorized server and has not been tampered with. It says nothing about whether the recipient address actually exists or will accept the message.

Verification checks whether an email address is real, active, and deliverable. It involves syntax validation, MX record lookup, and SMTP handshake checks. A message can be perfectly authenticated and still bounce because the recipient address does not exist. For a complete walkthrough of the verification pipeline, see our guide to how email verification works.

For production use cases — sending to large lists, running outbound campaigns, or integrating email into your product — you need both. Authentication protects your domain reputation. Verification provides current address-level evidence that can reduce avoidable list risk, but it does not predict every bounce. Peopledat provides a dashboard-based bulk verification workflow for lists you already own.