SPF, DKIM & DMARC: The Complete Authentication Guide | EmailGuide.dev

Why Email Authentication Matters

In February 2024, Google and Yahoo began enforcing strict authentication requirements for anyone sending more than 5,000 emails per day. These requirements mandate that bulk senders properly configure SPF, DKIM, and DMARC on their sending domains. If your domain fails these checks, your messages won't just land in spam — they may be rejected entirely at the gateway, never reaching the recipient at all.

Even if you send fewer than 5,000 emails per day, authentication is critical. Without it, anyone can spoof your domain, sending phishing emails that appear to come from your brand. Authentication protects your reputation, your customers, and your deliverability. Mailbox providers like Gmail, Outlook, and Yahoo use authentication signals as a baseline trust factor when deciding where to place your messages.

The bottom line: email authentication is no longer a nice-to-have. It's table stakes. If you haven't configured all three protocols, you're leaving your domain exposed and your deliverability at risk.

SPF: Sender Policy Framework

SPF allows you to declare which mail servers are authorized to send email on behalf of your domain. When a receiving server gets an email claiming to be from your domain, it checks your DNS for an SPF record. If the sending server's IP address matches one of the authorized sources, SPF passes. If not, the message fails SPF.

SPF Record Syntax

An SPF record is a DNS TXT record published on your domain. Here's a typical example for a company that sends through Google Workspace and SendGrid:

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

Let's break down each part:

v=spf1 — This identifies the record as an SPF record. It must always appear first.
include:_spf.google.com — This delegates authorization to Google's SPF record, which lists all of Google Workspace's sending IPs.
include:sendgrid.net — This delegates authorization to SendGrid's IP ranges.
-all — This is the "fail" qualifier, meaning any server not explicitly authorized should be rejected.

SPF Mechanisms

SPF supports several mechanisms for authorizing senders:

include: — Delegates to another domain's SPF record. This is the most common mechanism for authorizing third-party services.
a — Authorizes the IP address(es) associated with your domain's A record.
mx — Authorizes the IP address(es) of your domain's MX (mail exchange) servers.
ip4: and ip6: — Explicitly authorize a specific IPv4 or IPv6 address or range (e.g., ip4:192.168.1.0/24).

~all vs -all

The qualifier at the end of your SPF record determines what happens when a server doesn't match any authorized source:

-all (hard fail) — The message should be rejected. This is the strictest and most secure option. Use this once you're confident all legitimate sources are listed.
~all (soft fail) — The message should be accepted but marked as suspicious. This is a safer starting point while you're auditing your sending sources.
?all (neutral) — No opinion. Rarely used and provides no real protection.

The 10 DNS Lookup Limit

SPF has a critical constraint: a single SPF record can trigger a maximum of 10 DNS lookups during evaluation. Every include:, a, mx, and redirect mechanism counts as a lookup. Nested includes (an included domain's SPF record that itself includes other domains) also count. If your SPF record exceeds 10 lookups, the entire evaluation fails with a "permerror," and your emails may be rejected.

This limit is a common pain point for companies that use many third-party services. If you send through Google Workspace, SendGrid, Mailchimp, and a CRM that sends email, you can hit 10 lookups quickly.

Common ESP Includes

Here are the SPF include values for the most widely used email service providers:

Google Workspace: include:_spf.google.com
Microsoft 365: include:spf.protection.outlook.com
SendGrid: include:sendgrid.net
Mailchimp: include:servers.mcsv.net
Amazon SES: include:amazonses.com
Postmark: include:spf.mtasv.net
Mailgun: include:mailgun.org

DKIM: DomainKeys Identified Mail

DKIM adds a cryptographic signature to every outgoing email. This signature is generated using a private key held by the sending server and can be verified by anyone using a public key published in your DNS. DKIM proves two things: (1) the email was actually sent by an authorized server for your domain, and (2) the message was not tampered with in transit.

Key Generation and Selector Naming

When you set up DKIM with an ESP, the service generates a public/private key pair. The private key stays on the sending server and is used to sign outgoing messages. The public key is published in your DNS as a TXT or CNAME record.

DKIM uses "selectors" to allow multiple keys per domain. A selector is a label that identifies which key to use. The DNS record is published at selector._domainkey.yourdomain.com. For example, if your selector is s1, the record lives at s1._domainkey.yourdomain.com. Common selector naming conventions include:

selector1._domainkey and selector2._domainkey — Used by Microsoft 365
google._domainkey — Used by Google Workspace
s1._domainkey and s2._domainkey — Common with SendGrid
k1._domainkey — Used by Mailchimp

DNS Record Format

Depending on your ESP, you'll publish the DKIM key as either a TXT record (containing the full public key) or a CNAME record (pointing to a key hosted by the ESP). CNAME records are more common because they allow the ESP to rotate keys without requiring you to update your DNS.

A DKIM TXT record looks like this:

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

What DKIM Signs

DKIM doesn't sign the entire email — it signs a specific set of header fields and the message body. The h= tag in the DKIM signature specifies which headers are signed. Commonly signed headers include:

from — The sender's address (always signed)
to — The recipient address
subject — The email subject line
date — The send date
message-id — The unique message identifier
content-type — The MIME type of the message

If any of these signed headers are modified after sending (for example, by a mailing list that prepends "[List Name]" to the subject), the DKIM signature will fail verification.

Key Rotation Best Practices

DKIM keys should be rotated periodically to limit the impact of a potential key compromise. Best practices include:

Rotate keys every 6 to 12 months.
Use 2048-bit RSA keys (1024-bit is still accepted but increasingly considered weak).
When rotating, publish the new key first, wait for DNS propagation (24-48 hours), then switch your signing to the new key, and finally remove the old key after a grace period.
Use CNAME-based DKIM when possible so your ESP can manage rotation automatically.

DMARC: Domain-based Message Authentication, Reporting & Conformance

DMARC ties SPF and DKIM together and adds a policy layer that tells receiving servers what to do when authentication fails. It also provides a reporting mechanism so you can monitor who is sending email on behalf of your domain.

DMARC Policy Levels

The p= tag defines your DMARC policy — the action receivers should take when a message fails both SPF and DKIM alignment:

p=none — Monitor only. No action is taken on failing messages, but you receive reports. This is the starting point for every new DMARC deployment.
p=quarantine — Failing messages are sent to the spam/junk folder. Use this once you've reviewed reports and are confident your legitimate sources pass authentication.
p=reject — Failing messages are rejected entirely. This is the goal state — it prevents unauthorized senders from delivering email using your domain.

Reporting: rua and ruf Tags

DMARC reports are invaluable for understanding your email ecosystem:

rua (Aggregate Reports) — Daily XML reports summarizing authentication results for all messages sent using your domain. Set this to a mailbox you monitor: rua=mailto:dmarc-reports@yourdomain.com
ruf (Forensic Reports) — Detailed reports for individual message failures. These contain more sensitive information and are less commonly used: ruf=mailto:dmarc-forensics@yourdomain.com

A complete DMARC record might look like this:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.com; pct=100

Gradual Rollout with pct

The pct= tag lets you apply your DMARC policy to only a percentage of failing messages. For example, pct=25 means only 25% of messages that fail DMARC will be subject to your p= policy — the rest are treated as if the policy were none. This is useful for gradually tightening your policy:

Start at p=quarantine; pct=10
Increase to pct=25, then pct=50, then pct=100
Once stable at p=quarantine; pct=100, move to p=reject; pct=10 and repeat

Alignment Modes

DMARC checks that the domain in the From: header aligns with the domain authenticated by SPF and/or DKIM. There are two alignment modes:

Relaxed (default): The organizational domain must match. For example, mail.example.com aligns with example.com. Set with adkim=r (for DKIM) and aspf=r (for SPF).
Strict: The exact domain must match. mail.example.com does NOT align with example.com. Set with adkim=s and aspf=s.

Most organizations should use relaxed alignment. Strict alignment can cause legitimate failures, especially when subdomains are involved.

Subdomain Policy with sp=

The sp= tag lets you set a separate policy for subdomains. This is useful if your subdomains have different sending patterns. For example, sp=reject on your root domain's DMARC record means all subdomains that don't have their own DMARC records will inherit the reject policy, even if the root policy is quarantine.

Troubleshooting Common Issues

SPF Permerror: Too Many DNS Lookups

If your SPF record exceeds 10 DNS lookups, it results in a permerror that causes SPF to fail for all messages. Solutions include:

Flatten your SPF record: Replace include: mechanisms with the actual IP addresses they resolve to. Be cautious — you'll need to update these whenever the ESP changes their IPs.
Consolidate sending services: Reduce the number of third-party services authorized to send on your domain.
Use subdomains: Move different services to different subdomains (e.g., marketing.example.com, transactional.example.com), each with its own SPF record.
SPF flattening services: Tools like AutoSPF or SPF compression services dynamically manage your record to stay within limits.

DKIM Signature Mismatch

DKIM verification can fail for several reasons:

DNS propagation delays: If you just published your DKIM key, wait 24-48 hours for full propagation before sending.
Header modification: Mailing lists, forwarding services, or security gateways that modify signed headers (especially Subject or From) will break the signature.
Body modification: Any system that appends footers, modifies links, or rewrites content will invalidate the DKIM body hash.
Key mismatch: Ensure the selector in the DKIM signature header matches the selector in your DNS record.

DMARC Alignment Failures

The most common cause of DMARC alignment failures is email forwarding. When someone forwards your email, the envelope sender changes but the From: header stays the same. This breaks SPF alignment because the forwarding server's IP isn't in your SPF record. DKIM typically survives forwarding (as long as the content isn't modified), which is why having DKIM properly configured is essential — it's your safety net for forwarded messages.

Other common alignment issues include:

Sending from a subdomain without matching DKIM/SPF configuration
Using a shared ESP IP that signs with the ESP's domain rather than yours
Legacy systems or forgotten services still sending email on your domain

Testing Tools

Before going live — and periodically after — validate your authentication setup with these tools:

MXToolbox: Offers dedicated SPF, DKIM, and DMARC lookup tools. Enter your domain and get a detailed analysis of each record, including warnings about common misconfigurations.
dmarcian: A DMARC-focused platform that provides record analysis, aggregate report processing, and visual dashboards for monitoring your DMARC deployment over time.
Google Admin Toolbox (Check MX): A free tool from Google that verifies your DNS records, including SPF, DKIM, and DMARC, and flags issues that could affect delivery to Gmail.
mail-tester.com: Send a test email to a unique address and receive a detailed score covering authentication, content, and blacklist status. Great for a quick end-to-end check.
DMARC Analyzer: Processes your DMARC aggregate reports and presents them in a human-readable dashboard, making it easy to identify unauthorized senders.

Summary: The Authentication Roadmap

Setting up email authentication is a process, not a one-time task. Here's the recommended roadmap:

Audit your sending sources. Identify every service, server, and application that sends email using your domain.
Configure SPF. Add all legitimate senders to your SPF record. Start with ~all (soft fail) while testing.
Configure DKIM. Set up DKIM signing for every sending source. Publish the public keys in DNS.
Deploy DMARC at p=none. Publish a DMARC record with p=none and an rua address to start collecting reports.
Monitor reports for 2-4 weeks. Review DMARC aggregate reports to identify any legitimate sources that are failing authentication.
Fix any gaps. Update SPF and DKIM for any legitimate senders that are failing.
Tighten SPF to -all. Switch from soft fail to hard fail once all sources pass.
Move DMARC to p=quarantine. Use the pct tag to gradually increase enforcement.
Move DMARC to p=reject. This is the ultimate goal — full protection against spoofing.

Email authentication is the foundation of deliverability. Without it, every other optimization you make is built on shaky ground. Set up all three protocols, monitor your reports, and steadily tighten your policies until you reach full enforcement.

SPF, DKIM & DMARC: The Complete Guide