These three DNS-based authentication standards tell receiving mail servers that your emails are legitimate – that you are who you say you are. Without them, even transactional emails like password resets, order confirmations, and contact form notifications get flagged or silently dropped.
This guide walks you through exactly how email authentication works, how to set up each record step by step, common mistakes that break everything, and how to verify your setup using free tools. Whether you are on Google Workspace, Microsoft 365, or AWS SES, this covers your provider too.
How Email Authentication Actually Works
When you send an email, the receiving server does not just look at your “From” address. It performs a series of checks to verify you are authorized to send email for that domain. Think of it like a three-layer ID check at a venue entrance.
SPF says who is allowed to send. DKIM proves the email was not tampered with. DMARC tells receivers what to do when checks fail – and sends you reports about it.
Here is the flow from send to inbox:
- You send an email from your mail server
- The receiving server looks up your domain’s SPF record to check if your sending IP is authorized
- It checks the email’s DKIM signature against your public key in DNS to verify the message has not been altered
- It checks your DMARC record to see if SPF and/or DKIM passed, and what to do if they did not
- Based on all three checks, the server decides: deliver, quarantine (spam folder), or reject
If any of these records are missing or misconfigured, you are essentially sending emails with no ID. Some servers will still accept them. Others will not. And since 2024, Gmail and Yahoo have made all three mandatory for bulk senders.
Part 1: SPF (Sender Policy Framework)
SPF is a DNS TXT record that lists every IP address and mail server authorized to send email for your domain. If an email arrives from a server not on that list, SPF fails.
SPF Record Syntax Explained
A basic SPF record looks like this:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all
Breaking this down:
| Part | Meaning |
|---|---|
| v=spf1 | SPF version – always starts with this |
| include:_spf.google.com | Authorize all Google Workspace sending IPs |
| include:sendgrid.net | Authorize SendGrid to send on your behalf |
| ip4:203.0.113.10 | Authorize a specific IP address directly |
| ~all | Soft fail for anything not listed (goes to spam) |
| -all | Hard fail for anything not listed (reject outright) |
| +all | Pass everything – NEVER use this, it means anyone can send |
How to Set Up Your SPF Record
- Log in to your domain registrar or DNS provider (Cloudflare, GoDaddy, Namecheap, etc.)
- Go to DNS management and add a new TXT record
- Set the name/host to @ (or leave blank, depending on your provider)
- Set the value to your SPF record string
- Set TTL to 3600 (1 hour) or your provider’s default
- Save and wait for DNS propagation (usually 15-60 minutes)
The SPF Lookup Limit – The #1 Trap
SPF has a hard limit of 10 DNS lookups per evaluation. Every include: statement triggers at least one lookup, and some (like Google’s) trigger multiple nested ones.
If your SPF record exceeds 10 DNS lookups, the entire record is invalid – even if every sender is listed correctly. The spec calls this a “permerror” and most mail servers treat it as a failure.
Common culprits that eat lookups fast:
- Google Workspace: 4-5 lookups
- Microsoft 365: 3-4 lookups
- SendGrid: 1-2 lookups
- Mailchimp: 1-2 lookups
- HubSpot: 1-2 lookups
- Zendesk: 1-2 lookups
Add four services and you can easily hit 10. The solution is to use a service like dmarcian.com or Skysnag that flattens your SPF record into individual IP addresses, eliminating the nested lookup chain. This keeps you under the limit even when you use many sending services.
Part 2: DKIM (DomainKeys Identified Mail)
DKIM adds a digital signature to every outgoing email. This signature is generated using a private key stored on your mail server. Receiving servers verify the signature using your public key published in DNS. If the email was modified in transit – even a single character changed – the signature check fails.
How DKIM Signing Works
Your mail server signs the email headers (From, Subject, Date) and body using a private key. It adds a DKIM-Signature header to the email. The receiving server looks up your public key at a DNS address like:
google._domainkey.yourdomain.com
The “google” part is the selector – a label that distinguishes different DKIM keys for the same domain. You can have multiple selectors for multiple sending services (one for Google, one for SendGrid, etc.).
Setting Up DKIM – Provider by Provider
Google Workspace
- In Google Admin Console, go to Apps > Google Workspace > Gmail
- Click “Authenticate email”
- Select your domain and click “Generate new record”
- Google shows you a TXT record with a selector like
google._domainkey - Add that TXT record to your DNS
- Wait for propagation, then click “Start authentication” in Google Admin
Microsoft 365
- Go to Microsoft 365 Defender portal (security.microsoft.com)
- Navigate to Email and Collaboration > Policies and Rules > Threat policies > Email authentication settings
- Select DKIM and choose your domain
- Click “Enable” – M365 creates two CNAME records for you to add to DNS
- Add both CNAME records (they point to Microsoft’s key infrastructure)
- Once propagated, toggle DKIM to “Enabled” in the portal
AWS SES
- In AWS SES console, go to Verified identities
- Select your domain and go to the DKIM tab
- SES offers Easy DKIM (2048-bit, three CNAME records) – this is the recommended option
- Add the three CNAME records to your DNS
- SES auto-detects when they propagate and activates DKIM
Common DKIM Mistake: Wrong Selector
Each sending service uses a different selector. If you set up DKIM for Google but forget to add a DKIM record for SendGrid, emails sent through SendGrid will fail DKIM checks even though Google looks fine. Always check your DKIM setup for every service you use to send email.
Part 3: DMARC (Domain-based Message Authentication, Reporting and Conformance)
DMARC is the policy layer that sits on top of SPF and DKIM. It tells receiving servers what to do when emails fail authentication, and crucially, it sends you reports about what is happening with your domain’s email.
DMARC Record Syntax
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; pct=100; adkim=r; aspf=r
| Tag | Meaning | Values |
|---|---|---|
| v=DMARC1 | Version – always this | Fixed |
| p= | Policy for failing emails | none, quarantine, reject |
| rua= | Where to send aggregate reports | mailto: address |
| ruf= | Where to send forensic reports | mailto: address |
| pct= | Percentage of mail to apply policy to | 1-100 (default 100) |
| adkim= | DKIM alignment mode | r (relaxed), s (strict) |
| aspf= | SPF alignment mode | r (relaxed), s (strict) |
DMARC Migration Timeline – Do Not Rush to Reject
Moving straight to p=reject will break your email if any legitimate senders are not properly authenticated. Use a phased approach:
| Phase | Duration | Policy | Goal |
|---|---|---|---|
| 1 – Monitor | 2-4 weeks | p=none | Get reports, identify all senders |
| 2 – Quarantine | 2-4 weeks | p=quarantine; pct=10 | Test with small percentage |
| 3 – Scale up | 2-4 weeks | p=quarantine; pct=100 | Full quarantine enforcement |
| 4 – Enforce | Ongoing | p=reject | Maximum protection |
Read the aggregate reports during Phase 1. They show every IP that sent email claiming to be your domain – legitimate senders, mailing lists, and any spoofing attempts. Fix your SPF/DKIM for all legitimate senders before tightening the policy.
Where to Add Your DMARC Record
DMARC is always a TXT record at _dmarc.yourdomain.com. The underscore prefix is mandatory. Add it through your DNS provider just like SPF.
BIMI: Brand Indicators for Message Identification
BIMI is an optional fourth layer that displays your brand logo in the inbox next to your email in supporting mail clients (Gmail, Apple Mail, Yahoo). It requires a DMARC policy of p=quarantine or p=reject, and for Gmail specifically, a Verified Mark Certificate (VMC) from a certificate authority like Entrust or DigiCert.
Requirements for BIMI:
- DMARC with p=quarantine or p=reject at 100% enforcement
- SVG logo file (specific SVG profile called “SVG Tiny PS”)
- Logo hosted on HTTPS
- VMC certificate for Gmail support (optional for other clients)
- BIMI TXT record at
default._bimi.yourdomain.com
BIMI is worth setting up once you have your DMARC fully enforced, as it provides immediate visual trust signals to your recipients.
Tools to Verify and Monitor Your Setup
Google Postmaster Tools
Google Postmaster Tools (postmaster.google.com) is a free dashboard that shows you how Gmail sees your domain. After verifying your domain ownership, you get access to:
- Domain Reputation – High, Medium, Low, or Bad. Bad means your emails go to spam automatically.
- IP Reputation – Reputation of the specific IPs sending your email
- Spam Rate – Percentage of your emails marked as spam by Gmail users. Keep this below 0.10%. Above 0.30% triggers filtering.
- Authentication – Percentage of emails passing DKIM, SPF, and DMARC
- Delivery Errors – Bounce codes and counts
- Encryption – Whether emails use TLS in transit
Check Postmaster Tools weekly when you are first setting up authentication. Once everything is green and stable, monthly reviews are sufficient.
dmarcian.com
dmarcian is the best tool for reading and analyzing DMARC aggregate reports. The raw XML reports that land in your inbox are nearly unreadable. dmarcian parses them, maps sending IPs, and shows you exactly which emails pass and which fail – and why.
Their free tier handles small volumes. The paid plans are worth it during initial setup and for ongoing monitoring of any domain that sends significant email volume.
MXToolbox
MXToolbox (mxtoolbox.com) is the fastest way to check if your domain is on any email blacklists. Their “Email Blacklist Check” tool queries over 100 blacklist databases simultaneously. If you land on a blacklist, MXToolbox links you directly to the removal process for each one.
Run the blacklist check immediately if you see a sudden drop in email delivery rates. Also useful for checking your SPF and DKIM records are published correctly.
Mail-Tester.com
Mail-Tester gives you a score out of 10 for a specific email you send to their test address. Send a real email from your actual mail client or plugin to their temporary address, then check the results. You get a detailed breakdown of:
- SPF, DKIM, and DMARC pass/fail status
- Spam trigger words in subject or body
- Blacklist status
- HTML quality and broken links
- Text-to-image ratio
- Unsubscribe link presence
Aim for 9/10 or above. A score below 7 means your emails will struggle to reach inboxes at most providers.
Common Mistakes That Break Email Authentication
Multiple SPF Records
You can only have ONE SPF TXT record per domain. If you accidentally add a second one (common when changing hosting providers), the SPF check becomes a “permerror” – which many servers treat as a failure.
Fix: Combine everything into a single TXT record with multiple include: statements separated by spaces.
Using -all Too Early
Setting -all (hard fail) before you have added all your legitimate sending services to SPF will cause those emails to be rejected. Start with ~all (soft fail) until you are confident your SPF record is complete.
Forgetting Third-Party Senders
Every service that sends email using your domain name must be included in your SPF record and must have DKIM set up. Common ones people forget: customer support platforms (Zendesk, Freshdesk), CRMs (HubSpot, Salesforce), transactional email services (Postmark, Mailgun), and marketing automation tools.
DMARC Alignment Failures
DMARC requires “alignment” – the domain in the From header must match the domain used for SPF and/or DKIM. If you send from support@yourdomain.com but your email is processed by a subdomain like mail.yourdomain.com, relaxed alignment (the default) handles this fine. Strict alignment (adkim=s; aspf=s) requires exact matches and is rarely necessary.
Gmail and Yahoo 2024 Requirements
Starting February 2024, Gmail and Yahoo introduced mandatory requirements for bulk senders (anyone sending more than 5,000 emails per day to Gmail):
- SPF or DKIM authentication (both strongly recommended)
- DMARC policy of at least p=none
- Keep spam complaint rate below 0.10%
- One-click unsubscribe header in all marketing email (
List-Unsubscribe-Post: List-Unsubscribe=One-Click) - Valid unsubscribe link that processes within two days
Even if you send fewer than 5,000 emails per day, these requirements are now effectively industry standards. Setting them up properly protects all senders, not just bulk mailers.
Domain Warm-Up and Bounce Handling
Domain Warm-Up
If you are sending email from a new domain or IP address, you cannot blast 10,000 emails on day one. Mail servers track the sending history of every domain and IP. A brand-new domain with sudden high volume looks exactly like a spam operation.
Warm up gradually over 4-6 weeks:
| Week | Daily Send Volume |
|---|---|
| Week 1 | 50-100 |
| Week 2 | 200-500 |
| Week 3 | 1,000-2,000 |
| Week 4 | 5,000-10,000 |
| Week 5+ | Scale as needed |
Send to your most engaged subscribers first – people who open your emails regularly. High engagement signals during warm-up build domain reputation faster.
Bounce Handling
Hard bounces (invalid addresses) must be removed from your list immediately. A hard bounce rate above 2% signals to ISPs that you have an unhealthy list, which damages your sender reputation. Most email platforms handle this automatically, but check your bounce reports weekly when you are actively building your list.
Soft bounces (temporary issues – full mailbox, server down) should be retried 2-3 times over 24-48 hours. If the address continues to soft bounce across multiple campaigns, treat it like a hard bounce and remove it.
Provider-Specific Setup Guides
Google Workspace – Complete Setup Checklist
- SPF: Add
v=spf1 include:_spf.google.com ~allas a TXT record at your domain root - DKIM: Generate in Google Admin > Apps > Gmail > Authenticate email. Add the TXT record, then click Start Authentication
- DMARC: Add a TXT record at
_dmarc.yourdomain.comstarting with p=none and aggregate report address - Postmaster Tools: Verify your domain and monitor sender reputation weekly
Microsoft 365 – Complete Setup Checklist
- SPF: Microsoft 365 uses
include:spf.protection.outlook.com - DKIM: Enable in Microsoft 365 Defender > Email authentication settings > DKIM. Add the two CNAME records Microsoft provides
- DMARC: Add to DNS at
_dmarc.yourdomain.com - Microsoft also supports DMARC aggregate report reading in their Defender portal
AWS SES – Complete Setup Checklist
- SPF: SES uses a custom MAIL FROM domain. You add an SPF record for your custom MAIL FROM subdomain (e.g.,
mail.yourdomain.com) that includes SES IP ranges - DKIM: Use Easy DKIM in SES console. Add the three CNAME records provided
- DMARC: Standard setup at
_dmarc.yourdomain.com - SES requires moving out of sandbox before you can send to unverified addresses. Submit a sending limit increase request in the SES console
Troubleshooting Guide: When Authentication Still Fails
| Problem | Likely Cause | Fix |
|---|---|---|
| SPF fails on all email | SPF record missing or wrong TXT name | Check TXT record is at @ or root domain, not a subdomain |
| SPF passes but DMARC fails | Alignment mismatch | Check that SPF domain matches From domain (relaxed mode) |
| DKIM fails despite record existing | Wrong selector in DNS | Check the selector in email headers matches the DNS record name |
| DKIM fails for forwarded email | Content modification in transit | This is normal – DMARC passes if SPF passes. DKIM and forwarding do not mix well. |
| DMARC reports show unknown senders | Third-party service not configured | Identify the sending IP from the report and add to SPF/DKIM |
| SPF permerror | Too many DNS lookups (over 10) | Use SPF flattening service (dmarcian, Skysnag) |
| Emails pass all checks but still go to spam | Content/reputation issue | Check Mail-Tester score, review content for spam triggers, check blacklists |
Your Email Authentication Checklist
- SPF record published at domain root as TXT
- Only one SPF record exists for the domain
- All sending services included in SPF
- SPF lookup count verified under 10 (use MXToolbox SPF checker)
- DKIM set up for every sending service (Google, SendGrid, etc.)
- DMARC record at _dmarc.yourdomain.com
- Aggregate reports going to a monitored address
- Google Postmaster Tools verified and showing green
- Mail-Tester score above 9/10
- No blacklist hits in MXToolbox
- One-click unsubscribe header in all marketing emails
Authentication is not a one-time setup. Each time you add a new service that sends email on your behalf, check whether it is in your SPF record and whether DKIM is configured for it. Set a quarterly calendar reminder to run the full checklist.
Series Navigation
This post is part of the Website Owner’s Toolkit – a 21-part series covering every essential service your website needs.
Return to the series hub: Essential Services Every Website Owner Needs (Complete Guide)
Related posts in this series:
