SPF, DKIM, and DMARC: A Plain-English Guide to Email Authentication

Why Email Authentication Matters

If your notification emails are landing in spam — or getting rejected outright — missing authentication records are frequently the cause. SPF, DKIM, and DMARC are the three pillars of modern email authentication. Together they tell receiving mail servers that your messages are legitimate, reducing spam folder placement and protecting your domain from being spoofed by bad actors.

This guide explains each standard in plain English, what it does, and how to implement it.

SPF: Sender Policy Framework

SPF lets you publish a list of IP addresses and mail servers authorized to send email on behalf of your domain. You do this via a DNS TXT record on your domain.

When a receiving server gets an email claiming to be from yourcompany.com, it checks your domain's DNS for an SPF record and verifies whether the sending IP is on your approved list. If it's not, the message may be flagged or rejected.

Example SPF record:

v=spf1 include:sendgrid.net include:amazonses.com ~all

This record says: "Messages from SendGrid or Amazon SES are authorized to send for this domain. Treat anything else as suspicious (~all means softfail)."

Important SPF limits: SPF has a 10 DNS lookup limit. If you use many third-party senders, you may need to consolidate or use SPF flattening tools to stay within the limit.

DKIM: DomainKeys Identified Mail

DKIM adds a cryptographic signature to outgoing messages. Your mail server signs each email with a private key; receiving servers verify the signature using a public key you've published in DNS.

This confirms two things:

• The message genuinely came from a server authorized by your domain.
• The message content was not altered in transit.

DKIM is configured as a DNS TXT record containing your public key, typically under a selector subdomain:

selector1._domainkey.yourcompany.com

Your email service provider (ESP) will generate the key pair and give you the exact DNS record to add. Most modern ESPs make DKIM setup straightforward with step-by-step instructions.

DMARC: Domain-based Message Authentication, Reporting & Conformance

DMARC builds on SPF and DKIM by letting you specify a policy — what should happen to messages that fail authentication — and request reports from receiving servers about what they're seeing.

DMARC policies are:

• none: Monitor only. Messages that fail aren't affected, but you receive reports.
• quarantine: Failed messages are sent to spam/junk.
• reject: Failed messages are outright rejected.

Example DMARC record:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.com; pct=100

Start with p=none to monitor without affecting delivery, review the reports, and only move to quarantine or reject once you're confident all legitimate sending sources pass authentication.

How the Three Work Together

Standard	What It Verifies	Where It Lives
SPF	Sending IP is authorized	DNS TXT record
DKIM	Message is signed and unaltered	DNS TXT record + mail server config
DMARC	Policy + alignment + reporting	DNS TXT record

DMARC also introduces alignment — it checks that the domain in the From header matches the domains validated by SPF and DKIM. This prevents spoofing even when SPF or DKIM pass on a different domain.

Implementation Checklist

1. Publish an SPF record covering all your sending sources.
2. Enable and configure DKIM in your ESP; add the provided DNS record.
3. Add a DMARC record starting with p=none and a reporting address.
4. Monitor DMARC reports for a few weeks using a tool like Google Postmaster Tools or a DMARC analyzer.
5. Gradually tighten your DMARC policy to quarantine then reject.

Proper authentication is no longer optional — major inbox providers including Google and Yahoo now require it for bulk senders. Set it up correctly and you'll see measurable improvements in inbox placement.