Email authentication setup: SPF, DKIM and DMARC
Gmail, Yahoo and Microsoft now check who is allowed to send email for your domain. If SPF, DKIM and DMARC aren’t set up correctly, your emails go to spam or are rejected, and anyone can send email that looks like it came from you.
The short answer
Email authentication is three DNS records that prove your emails are really from you: SPF lists the servers allowed to send for your domain, DKIM adds a signature that proves each email wasn’t changed, and DMARC tells receivers what to do when a message fails. Google has required them for bulk senders since 2024 [1], and Microsoft since May 2025 [2]. We configure all three for every service that sends email for you.
What’s included
- A list of every service that sends email for your domain: your mailboxes, website, CRM, invoicing, marketing tool and helpdesk.
- One correct SPF record covering all of them, within the 10-lookup limit.
- DKIM signing switched on for each sender, with 2048-bit keys where the service allows it.
- A DMARC record with reporting, starting at monitoring and moving to protection once everything passes.
- Alignment checks, so each sender passes DMARC with your domain, not the provider’s.
- A short written report: what we found, what we changed, and what each record does.
How we do it
- Check your current DNS records and send test emails from each service to see what passes and fails today.
- Plan the changes, so no legitimate email is blocked while we fix things.
- Publish the SPF, DKIM and DMARC records at your DNS provider (or give you exact copy-and-paste values).
- Test again from every sender until all pass, including alignment.
- Tighten DMARC from monitoring to quarantine or reject when the reports show everything is authenticated.
Why it matters now
Since February 2024, Gmail requires senders of 5,000 or more messages a day to authenticate with SPF, DKIM and DMARC, and since November 2025 it has been rejecting non-compliant messages outright [1]. Microsoft followed on 5 May 2025: domains sending more than 5,000 emails a day to Outlook.com, Hotmail and Live addresses must pass all three, or their messages are rejected with the error "550 5.7.515" [2].
Even if you send far less, authentication is what Gmail and Outlook use to decide whether to trust your domain. A small business with one misconfigured record can see its quotes and invoices land in spam just as easily.
The most common problems we fix
- Two SPF records instead of one, which makes SPF fail completely [3].
- SPF with more than 10 DNS lookups after adding one service too many [3].
- A marketing or CRM tool sending "on behalf of" your domain without DKIM, so it fails DMARC alignment.
- A DMARC record copied from a template with no reporting address, so nobody sees the failures.
- Old services still listed in SPF years after you stopped using them.
Common questions
Do I need all three records?
Yes. SPF and DKIM prove your email is genuine; DMARC ties them to the address people see and tells receivers what to do with failures. The Gmail and Outlook rules for larger senders require all three [1][2].
Will this stop my emails for a while?
No. We start DMARC in monitoring mode, which blocks nothing, and only move to quarantine or reject once the reports show all your legitimate email passes.
Where do the records go?
At whoever runs your domain’s DNS: often your domain registrar, Cloudflare, or your hosting company. We can make the changes with access, or send you the exact values to paste.
Sources
Numbers in this guide come from these studies and publications. Links open the original.
- Email sender guidelines FAQGoogle Workspace Admin Help (Gmail)Requirements for senders of 5,000+ messages a day to Gmail since February 2024; stricter enforcement, including rejections, since November 2025.
- Strengthening Email Ecosystem: Outlook’s New Requirements for High-Volume SendersMicrosoft Defender for Office 365 blog, Microsoft Tech Community, 2025Since 5 May 2025: SPF, DKIM and DMARC required for domains sending 5,000+ emails a day to Outlook.com, Hotmail and Live.
- RFC 7208: Sender Policy Framework (SPF)IETF, 2014