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

Three DNS-based protocols exist to stop this: SPF, DKIM, and DMARC. Together, they allow receiving mail servers to verify that an email genuinely came from your domain. When properly configured, they prevent spoofing, improve your email deliverability, and protect your brand reputation.

This guide explains how each protocol works, how to configure them, and the common mistakes that undermine their effectiveness.

Why Email Authentication Matters

Email spoofing is not just an annoyance. It has real business consequences:

• Phishing attacks — Attackers send emails that look like they come from your domain to steal credentials from your customers, partners, or employees
• Brand damage — When phishing emails carry your domain name, victims associate the fraud with your company
• Deliverability problems — Without authentication, legitimate emails from your domain are more likely to land in spam folders
• Compliance requirements — Many industries require email authentication as part of their security standards
• Financial loss — Business email compromise (BEC) attacks caused over $2.7 billion in losses in 2023 alone

SPF: Sender Policy Framework

SPF lets you publish a list of IP addresses and servers that are authorized to send email on behalf of your domain. When a receiving server gets an email from your domain, it checks the SPF record to verify the sender.

How SPF Works

1. 1You publish a TXT record in your DNS with a list of authorized senders
2. 2Someone sends an email claiming to be from your domain
3. 3The receiving server looks up your SPF record
4. 4It checks whether the sending server's IP is in the authorized list
5. 5If yes, SPF passes. If no, SPF fails.

SPF Record Syntax

Breakdown:

• v=spf1 — Version identifier (required)
• include:_spf.google.com — Authorize Google Workspace servers
• include:sendgrid.net — Authorize SendGrid for transactional emails
• ip4:203.0.113.5 — Authorize a specific IP address
• -all — Reject all other senders (hard fail)

Qualifier options:

• -all (hard fail) — Unauthorized senders should be rejected. Recommended.
• ~all (soft fail) — Unauthorized senders should be flagged but not rejected. Use during initial setup.
• ?all (neutral) — No policy. Provides no protection.

Common SPF Mistakes

• Using ~all instead of -all — Soft fail provides weak protection. Switch to hard fail once you have verified all legitimate senders.
• Too many DNS lookups — SPF has a 10 DNS lookup limit. Exceeding it causes SPF to fail for all emails. Consolidate includes where possible.
• Forgetting a sender — If you use multiple email services (Google Workspace, Mailchimp, your web server), each must be in the SPF record.
• Multiple SPF records — You can only have one SPF TXT record per domain. Multiple records cause unpredictable behavior.

DKIM: DomainKeys Identified Mail

DKIM adds a cryptographic signature to outgoing emails. The receiving server can verify this signature using a public key published in your DNS. This proves the email was not modified in transit and genuinely came from your infrastructure.

How DKIM Works

1. 1Your mail server signs outgoing emails with a private key
2. 2The signature is added as a DKIM-Signature header
3. 3You publish the corresponding public key as a DNS TXT record
4. 4The receiving server looks up the public key and verifies the signature
5. 5If the signature matches, DKIM passes

DKIM DNS Record

Breakdown:

• selector — A name you choose (e.g., google, sendgrid, default)
• _domainkey — Required subdomain
• v=DKIM1 — Version
• k=rsa — Key type
• p=... — Public key (base64 encoded)

DKIM Best Practices

• Use 2048-bit RSA keys minimum (1024-bit is deprecated)
• Rotate keys at least once per year
• Configure DKIM for every email service you use (each gets its own selector)
• Test with a DKIM validator after setup

DMARC: Domain-based Message Authentication

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

How DMARC Works

1. 1You publish a DMARC TXT record in your DNS
2. 2A receiving server checks both SPF and DKIM for incoming email
3. 3DMARC requires at least one of them to pass AND align with the From domain
4. 4Based on your DMARC policy, the server takes action on failures
5. 5The server sends aggregate reports to the address you specify

DMARC Record Syntax

Parameters:

• v=DMARC1 — Version (required)
• p=reject — Policy for failures: none (monitor), quarantine (spam folder), or reject (block)
• rua=mailto:... — Address for aggregate reports
• pct=100 — Apply policy to 100% of emails

DMARC Deployment Path

Do not jump straight to p=reject. Follow this graduated approach:

1. 1Week 1-2: p=none; rua=mailto:dmarc@example.com — Monitor only. Review reports to identify all legitimate senders.
2. 2Week 3-4: p=quarantine; pct=25 — Start quarantining 25% of failing emails. Watch for false positives.
3. 3Week 5-6: p=quarantine; pct=100 — Quarantine all failures. Verify no legitimate email is affected.
4. 4Week 7+: p=reject; pct=100 — Full protection. Unauthorized emails are rejected outright.

Reading DMARC Reports

DMARC aggregate reports are XML files sent to the address in your rua tag. They show:

• Which IPs sent email for your domain
• Whether SPF and DKIM passed or failed for each sender
• How many emails were affected
• What action the receiving server took

Use a DMARC report analyzer (many free options exist) to parse these reports into readable dashboards.

The Complete Setup Checklist

1. 1Inventory all services that send email for your domain
2. 2Configure SPF with all authorized senders and -all
3. 3Enable DKIM signing for each email service
4. 4Publish DKIM public keys in DNS
5. 5Start DMARC with p=none and monitoring
6. 6Review DMARC reports weekly for two weeks
7. 7Escalate to p=quarantine, then p=reject
8. 8Test deliverability to Gmail, Outlook, and Yahoo
9. 9Document your email infrastructure for future changes
10. 10Monitor ongoing with regular DMARC reports

Verify Your Setup

You can verify your email authentication configuration in several ways:

• ZeriFlow scan — Checks SPF, DKIM, and DMARC records automatically and reports exactly what is missing or misconfigured
• Send a test email — Email a Gmail account and click "Show original" to see authentication results
• DNS lookup tools — Query your TXT records directly to verify syntax

Properly configuring SPF, DKIM, and DMARC takes about an hour and protects your domain indefinitely. It is one of the highest-ROI security investments any business can make. Run a free ZeriFlow scan to see where your email authentication stands today.

Further Reading

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

<!-- zf-internal-links -->