SPF, DKIM, and DMARC Explained

Email authentication sounds complicated, but it boils down to three protocols working together: SPF, DKIM, and DMARC. Each one answers a different question about an incoming email, and together they tell mailbox providers (Gmail, Outlook, etc.) whether to trust a message.

SPF: Who is allowed to send?

SPF (Sender Policy Framework) is a DNS TXT record that lists the servers authorized to send email for your domain. When a receiving server gets an email from your domain, it checks your SPF record to see if the sending server's IP address is on the list.

An SPF record looks like this:

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

This says: allow Google Workspace and SendGrid to send mail for us, and reject (-all) everyone else. The key constraint is that SPF evaluation is limited to 10 DNS lookups — each include:, a:, mx:, and redirect= costs one lookup.

DKIM: Was the message tampered with?

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing email. The sending server signs the message with a private key, and publishes the corresponding public key in DNS. The receiving server looks up the public key and verifies the signature.

DKIM keys are published at <selector>._domainkey.yourdomain.com. Each sending service uses its own selector (e.g., google, s1, k1), so you can have multiple DKIM keys for different mail streams.

A DKIM pass means the message content hasn't been altered since it was signed. A DKIM fail could mean the message was modified in transit (common with mailing lists) or the signing key is missing/rotated.

DMARC: What should happen when authentication fails?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together. It tells receiving servers what to do when a message fails authentication: none (do nothing, just report), quarantine (send to spam), or reject (block entirely).

DMARC also introduces the concept of alignment: for SPF to count toward DMARC, the domain in the envelope sender must match the From domain. For DKIM, the d= domain in the signature must match the From domain.

A DMARC record looks like this:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; aspf=r; adkim=r

How alignment works

Alignment is the key concept that makes DMARC more than just "check SPF and DKIM." Even if SPF passes, DMARC can fail if the domains don't align. There are two alignment modes:

• Relaxed (r): The authenticated domain and the From domain must share the same organizational domain. mail.example.com aligns with example.com.
• Strict (s): The authenticated domain must exactly match the From domain. mail.example.com does not align with example.com.

For most organizations, relaxed alignment is the right choice. It allows subdomains to authenticate on behalf of the parent domain, which is how most email services work.

Quick setup checklist

1. SPF: Publish a TXT record at your root domain listing all authorized senders. End with -all or ~all. Keep lookups under 10.
2. DKIM: Enable DKIM signing in each sending service (Google Workspace, SendGrid, etc.) and publish the public key records they provide.
3. DMARC: Start with p=none and rua= reporting. Monitor reports for 2-4 weeks, fix alignment issues, then move to p=quarantine and eventually p=reject.

The goal isn't to set everything to maximum enforcement on day one — it's to build a feedback loop where you can see what's happening, fix problems, and gradually tighten the policy.