Fix SPF and DMARC for the Gmail and Yahoo Sender Requirements

Google and Yahoo now reject unauthenticated mail instead of spam-foldering it. Here are the exact DNS records to publish, in the right order.

Do this now

Two TXT records get you most of the way. Replace the include with your actual mail provider's and the report address with a mailbox you own:

# TXT record at yourdomain.com — one SPF record, ending in ~all
v=spf1 include:_spf.google.com ~all

# TXT record at _dmarc.yourdomain.com — monitoring-mode DMARC with reporting
v=DMARC1; p=none; rua=mailto:[email protected]

Then enable DKIM in your mail provider's admin console — the signing key is generated per domain, so it can't be pasted from a guide. When all three are in DNS, confirm them with our SPF & DMARC checker — it reads the live records and flags the exact problems Gmail and Yahoo would see.

What Gmail and Yahoo actually require

Since February 2024, Google and Yahoo enforce a shared baseline for anyone sending to their users. For every sender: authenticate with SPF or DKIM, keep valid forward and reverse DNS on your sending IPs, and keep your spam-complaint rate low — Google's published ceiling is 0.3%, and they recommend staying under 0.1%.

If you send around 5,000 or more messages a day to Gmail addresses, you're a bulk sender and the bar rises: SPF and DKIM (both, not either), a DMARC record at minimum p=none, a From: domain that aligns with your SPF or DKIM domain, and one-click unsubscribe (RFC 8058 list headers) on marketing mail. Miss the bar and mail is deferred or rejected at the door — you'll see it in bounce messages, not in a dashboard you happen to check.

The fix order matters: SPF and DKIM first, because DMARC is evaluated on top of them.

Step 1 — SPF: one record, restrictive ending

SPF is a TXT record at your domain listing which servers may send mail claiming to be you. The two rules that break most setups:

Exactly one record. Two v=spf1 TXT records is a permanent error — receivers treat it as no SPF at all. If you add a second sender (say, a newsletter service), merge its include: into the existing record.
Stay under 10 DNS lookups. Every include:, a, mx and redirect= costs lookups, and includes nest. Over 10 is a permerror — again, effectively no SPF.

End the record with ~all (softfail) or -all (hardfail). Never +all — that authorizes the entire internet to spoof you. ~all is the sane default while DMARC does the actual enforcement.

Step 2 — DKIM: turn it on at the provider

DKIM cryptographically signs each message; receivers fetch your public key from DNS at <selector>._domainkey.<yourdomain> to verify it. You don't write this record by hand — your provider generates the key pair and tells you what to publish (Google Workspace uses the selector google; most others use s1/s2 or similar). Prefer 2048-bit keys where offered. If you know your selector, our checker will confirm the public key resolves.

Step 3 — DMARC: start at p=none, with reporting

DMARC is a TXT record at _dmarc.<yourdomain> that tells receivers what to do when a message fails authentication — and, crucially, to send you aggregate reports about who's sending as your domain. Start in monitoring mode:

v=DMARC1; p=none; rua=mailto:[email protected]

p=none blocks nothing — spoofed mail still lands. Its job is the rua= reports: a few weeks of them shows you every service legitimately sending as your domain (the CRM and the billing system someone forgot about) before you turn enforcement on and break them.

The part everyone misses: alignment

DMARC doesn't just require SPF or DKIM to pass — the domain that passed must match the domain in the visible From: header. A newsletter service can pass SPF using its own bounce domain and still fail DMARC for you, because that domain isn't yours. The fix is almost always custom-domain DKIM: have the service sign with a key published under your domain. Any reputable sender supports this; it's usually called "custom DKIM" or "domain authentication" in their settings.

Tighten when the reports are clean

Once a few weeks of aggregate reports show only legitimate senders passing, escalate: p=quarantine (failures go to spam), then p=reject (failures are refused). You can move gradually with pct= — e.g. p=quarantine; pct=25 applies the policy to a quarter of failing mail. p=reject is the destination: it's what actually stops other people spoofing your domain, and it's the strongest deliverability signal you can send.

Verify, then re-verify

DNS edits are easy to typo and slow to propagate. After each change, run your domain through the SPF & DMARC checker — it evaluates the live records against the RFCs, counts your SPF lookups, and explains each finding in plain English. Checking takes ten seconds; a silently broken SPF record can cost you weeks of deliverability.

If you're setting up email on a fresh domain and would rather not assemble this by hand, hosted providers with security pedigree do it well — Proton Mail, for instance, walks you through publishing correct SPF, DKIM and DMARC records as part of adding a custom domain.