SPF, DKIM, and DMARC: DNS Records for Email Authentication

Email has a fundamental trust problem. The SMTP protocol, designed in 1982, lets anyone send email claiming to be from any address. There is no built-in way to verify that an email from [email protected] actually came from your company's mail server. Attackers exploit this to send phishing emails, business email compromise (BEC) attacks, and spam that appears to come from legitimate domains.

SPF, DKIM, and DMARC are three DNS-based mechanisms that work together to solve this problem. They let domain owners declare which servers are authorized to send email on their behalf and tell receiving servers what to do with messages that fail authentication. All three are implemented as DNS TXT records, making DNS the backbone of email authentication. For foundational DNS knowledge, see our DNS guide.

Why Email Authentication Matters

Without authentication, anyone can send an email with your domain in the "From" address. The recipient's mail server has no way to know it is forged. This enables:

Phishing attacks where attackers impersonate your domain to trick recipients into revealing credentials or clicking malicious links.

Business email compromise where attackers pose as executives or vendors to redirect wire transfers or extract sensitive data.

Brand damage when spam sent from forged addresses causes your domain to be blacklisted or flagged by spam filters.

Deliverability problems when legitimate email from your domain lands in spam folders because receiving servers can't verify it is real.

Google, Microsoft, and Yahoo all require SPF and DKIM authentication for bulk email delivery as of 2024. Gmail and Yahoo also require DMARC. Without these records, your legitimate email is increasingly likely to be rejected or filtered.

SPF (Sender Policy Framework)

SPF lets you publish a list of IP addresses and servers that are authorized to send email for your domain. Receiving servers check this list when they get an email claiming to be from your domain.

How SPF Works

When a mail server receives an email from [email protected], it looks up the SPF record for yourdomain.com in DNS. The SPF record lists the IP addresses that are allowed to send email for that domain. If the sending server's IP matches one of the authorized addresses, the SPF check passes. If not, it fails.

SPF specifically checks the "envelope from" address (the Return-Path header), not the "From" header that users see. This distinction matters and is one reason SPF alone is not sufficient.

SPF Record Syntax

An SPF record is a TXT record at your domain's root. Here is a typical example:

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:sendgrid.net -all

Breaking this down:

• v=spf1 identifies this as an SPF record.
• ip4:203.0.113.0/24 authorizes a specific IP range.
• include:_spf.google.com authorizes all IPs listed in Google Workspace's SPF record.
• include:sendgrid.net authorizes SendGrid's sending IPs.
• -all means reject (hard fail) email from any IP not listed. Use ~all for soft fail (accept but mark as suspicious) during initial setup.

The 10-Lookup Limit

SPF has a critical limitation: the DNS lookup limit. Evaluating an SPF record is allowed a maximum of 10 DNS lookups. Each include, a, mx, and redirect mechanism counts as one lookup. Nested includes (an included record that itself includes other records) count toward the same limit.

This limit catches many organizations by surprise. If you use Google Workspace, SendGrid, Mailchimp, HubSpot, and a few other services, you can easily exceed 10 lookups. When the limit is exceeded, the SPF check returns a "permerror" and the evaluation fails.

Solutions include using ip4 and ip6 mechanisms directly (they don't count as lookups), consolidating sending services, or using SPF flattening tools that resolve includes to IP addresses at publish time.

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to outgoing email messages. The receiving server verifies the signature using a public key published in DNS.

How DKIM Works

When your mail server sends an email, it generates a digital signature of specific email headers and the body using a private key. This signature is added to the email as a DKIM-Signature header.

The receiving server extracts the domain and "selector" from the DKIM-Signature header, looks up the corresponding public key in DNS, and verifies the signature. If the signature is valid, the receiving server knows two things: the email was sent by someone with access to the private key, and the signed portions of the message have not been modified in transit.

DKIM DNS Record

The DKIM public key is published as a TXT record at a specific subdomain:

selector._domainkey.yourdomain.com

The selector is a label chosen by you or your email provider. Google Workspace uses google as the selector. Other providers use their own conventions. The record looks like:

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

• v=DKIM1 identifies this as a DKIM record.
• k=rsa specifies the key type.
• p= contains the public key.

Each sending service needs its own DKIM key pair and selector. If you send email through Google Workspace and SendGrid, you will have two separate DKIM records with different selectors.

DKIM Advantages Over SPF

DKIM survives forwarding. When an email is forwarded, the sending IP changes (breaking SPF), but the DKIM signature remains attached to the message. This makes DKIM more reliable than SPF for messages that pass through forwarding services or mailing lists.

DKIM also verifies message integrity. If someone modifies the email content after it was signed, the signature check fails.

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

DMARC ties SPF and DKIM together and adds a policy layer. It tells receiving servers what to do when an email fails authentication and provides a reporting mechanism so you can see who is sending email using your domain.

How DMARC Works

DMARC checks that at least one of SPF or DKIM passes and that the passing mechanism aligns with the "From" domain the user sees.

Alignment is the key concept. SPF alignment means the domain in the Return-Path matches the domain in the "From" header. DKIM alignment means the domain in the DKIM signature (d= tag) matches the "From" header domain. Without alignment, an attacker could pass SPF using their own domain's SPF record while forging your domain in the "From" header.

DMARC Record Syntax

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

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

• v=DMARC1 identifies this as a DMARC record.
• p=reject is the policy. Options are none (monitor only), quarantine (send to spam), or reject (block entirely).
• rua= specifies where to send aggregate reports (daily summaries of authentication results).
• ruf= specifies where to send forensic reports (details on individual failures).
• pct=100 applies the policy to 100% of email. Lower values let you phase in enforcement gradually.

DMARC Rollout Strategy

Going straight to p=reject without preparation will block legitimate email that isn't properly authenticated. The standard rollout approach is:

How All Three Work Together

SPF, DKIM, and DMARC are complementary. Each addresses a different weakness.

When an email arrives, the receiving server:

1. Checks SPF by comparing the sending IP to the SPF record.
2. Checks DKIM by verifying the message signature against the DNS public key.
3. Checks DMARC by verifying that at least one of SPF or DKIM passed with alignment, then applies the domain owner's policy.

All three must be configured for full protection. SPF and DKIM without DMARC leaves no policy enforcement. DMARC without SPF and DKIM has nothing to evaluate.

Checking Your Records

You can verify your email authentication records using dig or nslookup. For detailed instructions on DNS lookups, see our guide to checking DNS records.

# Check SPF
dig yourdomain.com TXT | grep spf

# Check DKIM (replace "selector" with your actual selector)
dig selector._domainkey.yourdomain.com TXT

# Check DMARC
dig _dmarc.yourdomain.com TXT

Online tools like MXToolbox, Google's Check MX, and dmarcanalyzer.com provide detailed analysis of your email authentication setup without needing command-line access.

Common Mistakes

Multiple SPF records. A domain must have exactly one SPF record. If you have two TXT records that both start with v=spf1, SPF evaluation fails. When adding a new sending service, add it to your existing SPF record rather than creating a second one.

Exceeding the SPF lookup limit. As discussed above, exceeding 10 DNS lookups causes a permerror. Audit your includes regularly and consolidate where possible.

Missing DKIM for third-party senders. Every service that sends email on your behalf needs its own DKIM configuration. If you set up DKIM for Google Workspace but not for your marketing platform, emails from that platform will fail DKIM checks.

Jumping straight to DMARC reject. Enforcing p=reject without first monitoring with p=none will block legitimate email you didn't know about. Always follow the phased rollout.

Not monitoring reports. Publishing a DMARC record without reading the reports defeats the purpose. Aggregate reports show you who is sending email as your domain, including unauthorized senders. Use a DMARC report analyzer to process the XML reports into readable dashboards.

Forgetting about record types. SPF, DKIM, and DMARC are all TXT records. When troubleshooting, check TXT records specifically, not just A or MX records.

References

• RFC 7208 - Sender Policy Framework (SPF)
• RFC 6376 - DomainKeys Identified Mail (DKIM)
• RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• Google - Email Sender Guidelines