Email authentication in 2026: how to set up SPF, DKIM and DMARC before your emails stop arriving

Google, Microsoft and Yahoo now reject unauthenticated email. This guide walks you through setting up SPF, DKIM and DMARC, with concrete DNS examples for common providers.

Your emails are probably arriving fine. Until one day they aren't.

That's what happened to thousands of domain owners in 2025 when Microsoft started enforcing email authentication for Outlook.com, Hotmail.com and Live.com. Senders without proper SPF, DKIM and DMARC records suddenly got a 550 5.7.515 rejection, a cryptic error meaning "your domain doesn't prove it's allowed to send this email." Google and Yahoo had already tightened their rules in February 2024. The message is clear: unauthenticated email is on borrowed time.

The good news: setting up email authentication is straightforward. Three DNS records, a bit of patience for propagation, and you're done. This guide walks you through it: accessible enough for site owners, detailed enough for developers managing client domains.

What you'll learn:

  • What SPF, DKIM and DMARC do and why all three matter
  • Which providers are enforcing authentication and what happens when you fail
  • Step-by-step DNS setup for each protocol
  • WordPress-specific pitfalls (and how to fix them)
  • How to test and verify your configuration

Table of contents

Why email authentication matters right now

Three things changed in the past two years.

Google announced strict sender requirements in February 2024 and escalated to active SMTP-level rejection in November 2025. If you send more than 5,000 messages per day to Gmail addresses, you need valid SPF, DKIM and a DMARC record. Smaller senders still need at least SPF or DKIM. Non-compliant mail now gets a hard bounce; it never reaches any folder.

Microsoft followed in May 2025. Their announcement on the Microsoft Defender blog made it explicit: domains sending more than 5,000 emails per day to Outlook.com, Hotmail.com and Live.com must have SPF, DKIM and DMARC configured. Fail, and recipients see nothing; your email gets a 550 5.7.515 bounce.

Yahoo aligned with Google's requirements at the same time, requiring authentication for bulk senders across Yahoo Mail and AOL.

The 5,000-per-day threshold sounds high, but it catches more senders than you'd expect. WooCommerce order confirmations, newsletter campaigns, password reset flows: they add up. And the threshold only applies to the strictest rules. Even low-volume senders benefit, because missing authentication is one of the strongest spam signals across all providers.

The three protocols: SPF, DKIM and DMARC

Think of email authentication as three layers of proof that an email actually came from who it claims.

SPF (Sender Policy Framework) lets you declare which mail servers are allowed to send email for your domain. It's a DNS TXT record that lists approved IP addresses and services. When a receiving server gets an email from your domain, it checks the SPF record to see if the sending server is on the list.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each outgoing email. The sending server signs the message with a private key; the receiving server checks the signature against a public key published in your DNS. If the signature matches, the email hasn't been tampered with in transit.

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together. It tells receiving servers what to do when authentication fails: nothing (none), quarantine the message, or reject it. DMARC also checks alignment, meaning the domain in the From header must match the domain that passed SPF or DKIM.

You need all three. SPF alone can be spoofed via header manipulation. DKIM alone doesn't tell receivers what to do with failures. DMARC without SPF or DKIM has nothing to align against.

Setting up SPF

SPF is a single DNS TXT record on your root domain. It starts with v=spf1, lists your authorized senders, and ends with an all mechanism.

A basic SPF record for a domain using Google Workspace:

v=spf1 include:_spf.google.com ~all

For Microsoft 365:

v=spf1 include:spf.protection.outlook.com ~all

If you use a transactional email service alongside your regular email (Mailgun, SendGrid, Postmark), add their include as well:

v=spf1 include:_spf.google.com include:_netblocks.mailgun.org ~all

The ~all at the end is a soft fail: it tells receivers "anything not on this list is suspicious but don't hard-reject it yet." Once you've confirmed your setup works, you can switch to -all (hard fail) for stricter enforcement.

The 10-lookup limit

SPF has a hard limit: a maximum of 10 DNS lookups per evaluation. Each include, a, mx and redirect mechanism counts as one lookup, and nested includes count too. Exceed 10 and the entire SPF check fails with a permerror.

In practice, this limit becomes a problem when you stack multiple services. Google Workspace alone uses 3-4 lookups behind its include. Add Microsoft 365, a marketing platform and a transactional sender, and you're over the limit before you know it.

How to stay under:

  • Use ip4 and ip6 mechanisms where possible, since they don't count toward the lookup limit
  • Remove services you no longer use
  • Consider an SPF-flattening service if you genuinely need many providers (tools like autospf.com automate this)

Critical rule: one SPF record per domain

Your domain can have only one SPF TXT record. Multiple SPF records cause both to fail. If you're adding a new service, merge its include into your existing record rather than creating a second one.

Setting up DKIM

DKIM requires two things: your email provider generates a key pair, and you publish the public key in DNS.

The DNS record is a TXT record at selector._domainkey.yourdomain.com. The selector is a label chosen by your email provider; it identifies which key pair to use.

Google Workspace

Google Workspace lets you generate a DKIM key in the Admin Console under Apps → Google Workspace → Gmail → Authenticate email. You'll get a TXT record to add to your DNS. The default selector is google, so the record goes at:

google._domainkey.yourdomain.com

Google's DKIM setup documentation walks through each step. Choose a 2048-bit key, as it's the current recommendation and Google defaults to it.

Microsoft 365

Microsoft uses CNAME records instead of TXT records. You create two CNAME entries pointing to Microsoft's DKIM infrastructure. The format follows the Microsoft DKIM configuration guide:

selector1._domainkey.yourdomain.com → selector1-yourdomain-com._domainkey.yourdomain.onmicrosoft.com
selector2._domainkey.yourdomain.com → selector2-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

After adding both CNAMEs, enable DKIM signing in the Microsoft 365 Defender portal. Both selectors should stay in DNS, since Microsoft rotates between them automatically.

Transactional email services

Mailgun, SendGrid, Postmark and Amazon SES all provide DKIM records during domain verification. The process is similar: add the DNS records they give you, verify in their dashboard, done. Each provider's documentation is clear on this, so follow their specific instructions rather than guessing at the syntax.

Key size: 2048-bit minimum

Use 2048-bit keys. The older 1024-bit keys are considered weak and some security scanners flag them. Most providers default to 2048-bit now. If your DNS provider doesn't support TXT records longer than 255 characters, you may need to split the key across multiple strings, but that's rare with modern DNS hosts.

Setting up DMARC

DMARC is a TXT record at _dmarc.yourdomain.com. A starting configuration:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

The p=none policy tells receivers to send you reports but take no action on failing emails. This is where you start. Always.

The rollout path

Rushing to p=reject without data is how you block your own legitimate email. The recommended approach:

  1. p=none: monitor for 2-4 weeks. Read the aggregate reports to identify all services sending email on your behalf.
  2. p=quarantine: failing emails go to spam. Watch your delivery rates for another 2-4 weeks.
  3. p=reject: failing emails get blocked. This is the end goal and the strongest protection against spoofing.

Understanding DMARC reports

The rua tag specifies where aggregate reports are sent: XML files that tell you which IPs sent email using your domain and whether SPF/DKIM passed. Raw XML is hard to read. Free tools that parse them into something useful:

The ruf tag sends forensic (per-message) failure reports. Most large providers don't send these for privacy reasons, so rua is the one that matters in practice.

DMARC alignment

This is where it gets slightly technical. DMARC requires alignment: the domain in the visible From header must match either the SPF-authenticated domain (the envelope sender) or the DKIM-signing domain. If your form plugin sends email with a From address on yourdomain.com but the actual sending server authenticates as mailgun.org, DKIM alignment saves you, because Mailgun signs with your domain's DKIM key. Without DKIM, SPF alone won't align, and DMARC fails even though SPF passed.

That's why you need both SPF and DKIM, not just one.

WordPress sites: a common blind spot

WordPress has a specific problem with email authentication. By default, wp_mail() uses PHP's built-in mail() function, which sends email directly from the web server. The From address might say wordpress@yourdomain.com, but the email actually originates from your hosting server's IP, which likely isn't in your SPF record. There's no DKIM signature either.

The result: your contact form confirmations, WooCommerce order emails and password resets fail authentication checks. They end up in spam or get rejected entirely. If you've ever dealt with WordPress not sending email, missing authentication is often the underlying cause. This has been a known issue in WordPress core since 2012, and it still isn't fixed at the platform level.

The fix: route WordPress email through SMTP

An SMTP plugin connects WordPress to a proper email service that handles authentication for you. The main options:

  • WP Mail SMTP: the most popular choice. Supports Google Workspace, Microsoft 365, SendGrid, Mailgun, Postmark, Amazon SES and generic SMTP.
  • FluentSMTP: free, lightweight, supports the same providers. Good if you don't need the extra features of WP Mail SMTP Pro.
  • Post SMTP: includes email logging and failure notifications.

Configure the plugin to send through whatever email service you've set up SPF and DKIM for. The emails then pass authentication because they go through an authorized server with proper DKIM signing, not through PHP's mail().

Testing your setup

Don't assume it works. Verify.

MXToolbox: enter your domain and check SPF, DKIM and DMARC records individually. Shows syntax errors, lookup counts and warnings.

Google Admin Toolbox Check MX: checks DNS configuration for common misconfigurations. Particularly useful for Google Workspace setups.

mail-tester.com: send a test email to a generated address and get a detailed score. Checks SPF, DKIM, DMARC, spam content and blacklists in one go. The most practical "does my email actually work?" test.

After setup, send test emails to a Gmail address and check the headers. In Gmail, click the three dots → "Show original." You should see spf=pass, dkim=pass and dmarc=pass. If any show fail, go back to the specific protocol's setup.

Common mistakes that break authentication

Multiple SPF records. Adding a second TXT record starting with v=spf1 instead of merging into the existing one. Both records become invalid.

Forgetting the transactional sender. You set up SPF for Google Workspace but your WordPress site sends through SendGrid. SendGrid's servers aren't in your SPF record. Result: SPF fails for every automated email.

DMARC at p=reject on day one. You miss a legitimate sending source (a CRM, a billing system, an old marketing tool) and that email stops arriving. Always start with p=none.

Stale DNS records. You switched from Mailgun to Postmark six months ago but the old DKIM record is still in DNS. It won't cause failures, but it clutters your zone and confuses anyone auditing it later.

SPF lookup limit exceeded. You stack five services with include mechanisms and wonder why SPF evaluation returns permerror. Check your lookup count with MXToolbox before adding new services.

Cloudflare proxy on email records. If you use Cloudflare, all email-related TXT and CNAME records must be set to "DNS only" (the grey cloud icon). Proxied DKIM CNAME records break validation because receiving servers can't retrieve the public key through Cloudflare's proxy.

When authentication alone isn't enough

SPF, DKIM and DMARC prove that an email is authorized and unaltered. They don't guarantee delivery. A properly authenticated email can still land in spam if the content triggers filters, if the sending IP has a poor reputation, or if the recipient's server has additional rules.

For WordPress sites that send a handful of transactional emails per day (order confirmations, contact form notifications, password resets), authentication is usually the single biggest improvement you can make. But if you're sending at volume (newsletters, marketing campaigns), you also need to monitor your sender reputation through Google Postmaster Tools and follow deliverability best practices: clean lists, consistent sending patterns, proper unsubscribe handling.

Email authentication is the floor, not the ceiling. But without that floor, nothing else matters, because your emails won't arrive at all.

Key takeaways:

  • SPF, DKIM and DMARC are now mandatory for reliable email delivery to Gmail, Outlook and Yahoo
  • WordPress sites need an SMTP plugin to send authenticated email; wp_mail() alone doesn't cut it
  • Start DMARC at p=none, monitor reports, then tighten gradually
  • One SPF record per domain, watch the 10-lookup limit
  • Test with MXToolbox and mail-tester.com after every change

Need professional email without the hassle?

Email on your own domain with spam filtering and personal setup help. No Microsoft 365 or Google Workspace overhead.

Explore email hosting

  1. Self-hosted email in 2026: harder than ever, more important than ever

    Gmail rejects non-compliant email at the protocol level. Microsoft does the same. Running your own mail server in 2026 means maintaining SPF, DKIM, DMARC, MTA-STS, TLS, DNSSEC, correct PTR records, and a pristine sender reputation. Here's how to decide whether it's worth it.

    1836 words
  2. Microsoft SMTP Basic Auth for Office 365 is going away: what WordPress site owners actually need to do

    If your WordPress site sends email through an Office 365 mailbox with a username and password, that setup has an expiration date. Here is what actually changed in 2026 and what to do about it.

    1780 words
  3. Why your WordPress contact form emails end up in spam (and how to fix it)

    Your contact form works fine, but submissions never reach your inbox. The problem isn't the form plugin. It's how WordPress sends email.

    2347 words

Start typing to search, or browse the knowledge base and blog.