Email Authentication Guide

A plain-English guide to SPF, DKIM, and DMARC for site owners who want their emails to actually arrive.

Why your emails go to spam

You hit send. The email leaves your site. And then... nothing. Your customer never gets the order confirmation, the password reset link expires unseen in their spam folder, and you have no idea any of it is happening.

The problem isn't your email provider or a bug in your site, it's how your domain's DNS is configured.

Since February 2024, Gmail, Yahoo, and Microsoft require proper email authentication for all senders. If your domain doesn't have the right DNS records in place, your emails look indistinguishable from spam to these providers. They don't bounce, they just quietly disappear into the junk folder.

Google alone blocks roughly 15 billion spam emails every day. Their filters don't judge your writing style or subject line. They check whether your domain is actually set up to prove it sent that email, and without authentication records, it can't.

The good news: this is fixable, usually in under an hour, and it's free. You just need to know what to set up. If you want to understand why your Gmail works fine while your website emails don't, read how email routing actually works.

What is email authentication?

Email authentication is a set of DNS records that prove your emails are legitimate. Think of it like sending a physical letter:

• SPF is the return address. It says which post offices (mail servers) are allowed to send letters on your behalf.
• DKIM is a wax seal. It proves the letter hasn't been opened or changed since you sent it.
• DMARC is the postal regulation. It tells the recipient what to do if the return address doesn't match or the seal is broken.

All three are DNS records, text entries you add to your domain's DNS settings. They don't cost anything. Most domain registrars and hosting providers have a DNS management panel where you can add them.

SPF: Who can send email as you?

SPF (Sender Policy Framework) is a DNS record that lists every server authorized to send email from your domain. When Gmail receives an email claiming to be from you@yourdomain.com, it checks your SPF record to see if the sending server is on the list.

Here's what an SPF record looks like:

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

Breaking that down:

• v=spf1 - this is an SPF record (always starts with this)
• include:_spf.google.com - Google Workspace servers are allowed to send
• include:sendgrid.net - SendGrid is also allowed (maybe you use it for transactional emails)
• ~all - emails from any other server should be treated as suspicious

Common SPF mistakes

• Too many DNS lookups. SPF has a hard limit of 10 DNS lookups. Each include: counts as one (and can trigger more). If you exceed 10, your entire SPF record breaks and providers ignore it. This is common when you use multiple services (Google + Mailchimp + your hosting + a CRM).
• Using +all instead of ~all or -all. The +all setting means "allow anyone to send as my domain." This defeats the entire purpose of SPF.
• Forgetting to add your email provider. If you send email through Google Workspace but your SPF record only lists your web host, emails sent from Gmail won't pass SPF.

DKIM: Proving your emails haven't been tampered with

DKIM (DomainKeys Identified Mail) adds a digital signature to every email you send. The receiving server checks this signature against a public key stored in your DNS. If the signature matches, the email hasn't been altered in transit.

Think of it like a wax seal on a letter. If the seal is intact, you know nobody opened and re-sealed it.

DKIM uses a "selector" to find the right key. The DNS record lives at:

selector._domainkey.yourdomain.com

Common selectors include google (for Google Workspace), selector1 and selector2 (for Microsoft 365), default, and k1 (for Mailchimp).

Common DKIM mistakes

• Not enabling it. Many email providers support DKIM but require you to manually add the DNS record. If you never set it up, your emails go out unsigned.
• Weak keys. Older DKIM setups may use 512-bit or 1024-bit keys. Modern best practice is 2048-bit. Short keys can be cracked, letting attackers forge your email signatures.
• Multiple services, missing signatures. If you send email through Google Workspace AND a transactional service like SendGrid, both need their own DKIM records. Missing one means those emails go out unsigned.

DMARC: What happens when someone fakes your email

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy layer. It tells receiving servers what to do when an email claims to be from your domain but fails SPF or DKIM checks.

DMARC has three policy levels:

The recommended path: start with p=none to see who's sending email as your domain (you might be surprised). Once you're confident your legitimate email passes SPF and DKIM, move to p=quarantine, then p=reject.

Common DMARC mistakes

• Staying on p=none forever. Many people set up DMARC in monitoring mode and never progress. With p=none, you're collecting data but not protecting anything. Anyone can still send fake emails as your domain.
• No reporting address. DMARC can send you reports about who's using your domain to send email. Without a rua= address, you're flying blind.
• Jumping straight to p=reject. If your SPF or DKIM isn't fully set up for all your sending services, a reject policy will block your own legitimate emails.

How SPF + DKIM + DMARC work together

Here's what happens when Gmail receives an email from your domain:

If all three pass, your email lands in the inbox. If any fail, it depends on your DMARC policy: p=none delivers anyway (just logs it), p=quarantine sends it to spam, p=reject blocks it entirely.

You need all three. SPF alone was enough before 2024. Now Gmail and Yahoo explicitly require both SPF and DKIM to pass, and strongly recommend DMARC. Without all three in place, you can't count on your emails being delivered consistently.

Common problems and how to fix them

Contact form emails go to spam

Your website sends emails through your hosting provider's mail server (usually PHP mail). But if your SPF record only lists Google Workspace or Microsoft 365, emails from your web host aren't authorized. Fix: add your hosting provider's mail servers to your SPF record, or route contact form emails through an SMTP service like Brevo, SendGrid, or Amazon SES.

WooCommerce or Shopify order emails not arriving

Same root cause. Your e-commerce platform sends transactional emails (order confirmations, shipping updates) from a server that isn't listed in your SPF record. For WordPress/WooCommerce, install an SMTP plugin (like WP Mail SMTP) and route emails through an authenticated service. For Shopify, ensure your custom domain's SPF and DKIM records include Shopify's sending servers.

SPF record has too many DNS lookups

SPF records are limited to 10 DNS lookups. Each include: directive counts as at least one. If you use Google Workspace + Mailchimp + SendGrid + your hosting provider + a CRM, you can easily exceed this limit. When you do, your entire SPF record becomes invalid. Fix: consolidate includes where possible, use IP addresses (ip4:) instead of includes for simple setups, or use an SPF flattening service.

Yahoo or Gmail says "authentication failed"

Since early 2024, both Yahoo and Gmail enforce stricter authentication requirements. If you see "authentication failed" warnings, it usually means one of: your SPF record is missing or invalid, DKIM is not set up for your sending service, or your DMARC record is missing entirely. Run a scan to find out exactly which check is failing.

DMARC is set to "none" - is that okay?

No. p=none means "let everything through, even fakes." It's fine as a starting point while you monitor who's sending as your domain, but you should move to p=quarantine or p=reject within a few weeks. Staying on p=none indefinitely means anyone can spoof your email address and your domain's reputation takes the hit.

Everything passes but emails still land in spam

If SPF, DKIM, and DMARC all pass but your emails still go to spam, the issue is likely content or reputation rather than authentication. Possible causes: your domain or IP is on a blocklist, your email content triggers spam filters (too many links, spammy words, large images with little text), or your sending volume spiked suddenly. Authentication is necessary but not the whole picture, because blocklists, content quality, and sending patterns also matter.

Check your domain now

Enter your domain below and we'll check your SPF, DKIM, DMARC, and mail server configuration in about 30 seconds. No signup required. No data stored.

For an even deeper analysis, use the "Deep Check" option on the results page. It sends a real test email and verifies that your authentication actually works in practice, not just in DNS.

Need help fixing what we find? Email valentin@doesmyemail.work with your results and I'll tell you exactly what to change.