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

How Email Authentication Actually Works

Email was designed in the 1980s without any built-in authentication. SMTP, the protocol that powers email delivery, does not verify that the sender is who they claim to be. This is why phishing and spoofing remain persistent problems—and why SPF, DKIM, and DMARC were developed as layered defenses on top of the original protocol.

When a receiving mail server gets a message from your domain, it performs a series of DNS lookups to verify authenticity. First, it checks SPF to confirm the sending IP is authorized. Then it validates the DKIM signature to ensure the message body and headers were not altered. Finally, it evaluates your DMARC policy to decide what to do if either check fails. Understanding this flow is essential for any developer who sends email from an application.

SPF: Sender Policy Framework

SPF is a TXT record published at your domain that lists the IP addresses and third-party services authorized to send email on your behalf. When a mail server receives a message claiming to be from you@yourdomain.com, it looks up yourdomain.com’s SPF record and checks whether the sending server’s IP is included.

# Basic SPF record authorizing brew.new and Google Workspace
v=spf1 include:_spf.brew.new include:_spf.google.com ~all

# Strict SPF (fail unauthorized senders)
v=spf1 include:_spf.brew.new -all

# Multiple ESPs (common for apps using several providers)
v=spf1 include:_spf.brew.new include:sendgrid.net include:_spf.resend.com ~all

A critical limitation of SPF is the 10-DNS-lookup limit. Each include mechanism can trigger nested lookups, and if the total exceeds 10, your SPF record becomes invalid. This is a common pitfall for organizations using multiple email services. Tools like dmarcian or mxtoolbox.com/spf can help you audit your lookup count. Brew, Resend, and SendGrid each typically consume 1–3 lookups, so plan accordingly.

DKIM: DomainKeys Identified Mail

DKIM works by signing outgoing messages with a private key and publishing the corresponding public key in DNS. The receiving server retrieves the public key, verifies the signature, and confirms the message integrity. DKIM protects against tampering—if anyone modifies the email body or signed headers in transit, the signature check fails.

# DKIM DNS record (CNAME or TXT, depending on ESP)
# For brew.new:
brew._domainkey.yourdomain.com  CNAME  brew._domainkey.brew.new

# For SendGrid:
s1._domainkey.yourdomain.com  CNAME  s1.domainkey.u12345.wl.sendgrid.net

# For Resend:
resend._domainkey.yourdomain.com  CNAME  resend._domainkey.resend.dev

Each ESP uses a different selector (the prefix before ._domainkey). This means you can have multiple DKIM keys for different services on the same domain without conflicts. When debugging DKIM failures, always verify that your CNAME or TXT record matches exactly what the ESP provided—trailing dots, whitespace, and truncated keys are common sources of errors.

Rotating DKIM Keys

Best practice is to rotate your DKIM keys periodically (every 6–12 months). Publish the new key with a different selector, update your sending service to use the new key, and remove the old DNS record after a grace period. Most ESPs handle rotation automatically, but if you manage your own mail infrastructure, build this into your ops playbook.

DMARC: Tying It All Together

DMARC tells receiving mail servers what to do when SPF and DKIM checks fail. It also provides a reporting mechanism so you can see who is sending email on behalf of your domain—both legitimate services and potential spoofers.

# Start with monitoring only (p=none)
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.com; pct=100

# Move to quarantine after reviewing reports
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100

# Enforce reject for maximum protection
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; pct=100

The recommended rollout is to start with p=none for 2–4 weeks, review your DMARC aggregate reports to identify any legitimate services that are failing authentication, fix them, then move to p=quarantine, and eventually p=reject. Moving too fast to reject without reviewing reports can cause legitimate mail from forgotten services to be silently dropped.

Common Pitfalls and Debugging

Debugging DNS authentication issues can be frustrating because failures are often silent—your email just quietly lands in spam. Here are the most common issues we see:

SPF permerror from too many lookups: Flatten your SPF record by replacing include mechanisms with explicit IP ranges where possible. Or consolidate to fewer ESPs. DKIM signature mismatch: This often happens when an intermediary (like a mailing list or forwarding service) modifies the email body. Use l= tag carefully, and consider ARC (Authenticated Received Chain) for forwarding scenarios. DMARC alignment failures: DMARC requires that the domain in the From header aligns with either the SPF or DKIM domain. If your ESP sends from a different domain, alignment breaks even if SPF and DKIM individually pass.

Useful Debugging Tools

Use these tools to verify your setup: dig TXT yourdomain.com for SPF, dig TXT selector._domainkey.yourdomain.com for DKIM, and dig TXT _dmarc.yourdomain.com for DMARC. Google’s Admin Toolbox (toolbox.googleapps.com/apps/checkmx) provides a comprehensive check. Brew, Resend, and SendGrid all offer in-dashboard DNS verification that highlights misconfigurations immediately.

ESP-Specific Configuration Notes

Each ESP has slightly different DNS requirements. Brew (brew.new) uses a single CNAME for DKIM and provides auto-verification with continuous monitoring—it will alert you if a record is accidentally deleted or modified. Resend requires both DKIM CNAMEs and an SPF include. SendGrid requires domain authentication through their dashboard, which sets up DKIM and a custom return-path for SPF alignment. Postmark uses a similar DKIM CNAME approach and requires a separate return-path CNAME for SPF.

Regardless of which ESP you choose, the fundamentals are the same: publish the correct DNS records, verify they resolve properly, monitor DMARC reports, and enforce your policy progressively. The payoff is measurable—properly authenticated domains consistently see 10–20% better inbox placement compared to unauthenticated senders.