Gmail DMARC requirements in 2026, explained

What Google requires — and who counts as a bulk sender

Google's email sender guidelines have been in force since February 1, 2024. They set a baseline for everyone and a stricter tier for bulk senders — any domain that sends 5,000 or more messages a day to personal Gmail accounts. The count covers everything sent from your primary domain, subdomains included, and the status is sticky: Google says bulk-sender classification has no expiration date, so crossing the threshold once puts you in the stricter tier for good.

Every sender, at any volume, must authenticate with SPF or DKIM, publish valid forward and reverse DNS (PTR) records, send over TLS, format messages to RFC 5322, and keep the spam-complaint rate in Postmaster Tools below 0.3%. Bulk senders must go further:

• Set up both SPF and DKIM — either alone is no longer enough.
• Publish a DMARC record for the sending domain, with a policy of at least p=none.
• Make sure the visible From: domain aligns with the domain SPF or DKIM validated.
• Support RFC 8058 one-click unsubscribe on marketing and subscribed mail, keep a visible unsubscribe link in the body, and honor requests within two days.

Enforcement started gently — temporary errors on a slice of non-compliant traffic — but Google announced that from November 2025 it would ramp up to temporary and permanent rejections. As of mid-2026, a missing DMARC record on a bulk-sending domain is not a deliverability nice-to-have; it is a reason Gmail bounces your mail.

DMARC in plain English

SPF and DKIM each prove something narrow. SPF lists which servers may send mail for a domain. DKIM cryptographically signs the message so receivers can verify it wasn't altered and see which domain signed it. What neither checks is the From: address your reader actually sees — the exact thing phishing forges.

DMARC closes that gap. It is a single DNS TXT record that tells receiving servers: “if a message claims to be from my domain but neither SPF nor DKIM validates that same domain, here is what to do with it” — deliver it anyway, quarantine it, or reject it. The record can also ask receivers to email you aggregate reports showing who is sending as your domain and whether those messages pass, which is how you find every legitimate sending service before you tighten the policy.

The exact DNS record to add

DMARC lives at the _dmarc host of the domain in your From: address. The minimal record that satisfies Gmail's requirement looks like this:

Host:   _dmarc.yourdomain.com
Type:   TXT
Value:  "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

• v=DMARC1 — the version tag. It must come first, exactly like this.
• p=none — the policy: what receivers should do when a message fails. none means “deliver normally, just tell me” — and it is Google's stated minimum.
• rua= — where daily aggregate reports go. Technically optional, but without it you are flying blind; use a real mailbox or a DMARC reporting service address.

Publish exactly one DMARC record — two records at the same host make both invalid. Once DNS propagates, confirm it resolves:

dig +short TXT _dmarc.yourdomain.com

Policy levels: none → quarantine → reject

The p= tag has three settings, and they form a natural rollout path:

• p=none — monitor only. Failing mail is delivered as usual; you collect reports. This satisfies Gmail's bulk-sender rule but offers zero spoofing protection.
• p=quarantine — failing mail goes to spam. You can phase it in with pct=, e.g. p=quarantine; pct=25 applies the policy to a quarter of failing traffic.
• p=reject — failing mail is refused outright. This is the end state that actually stops spoofing of your domain.

A sane rollout: publish p=none with a rua= address and watch reports for four to six weeks. Fix every legitimate source that fails — usually a third-party service that isn't signing with your domain. When reports show your real mail passing, step up to p=quarantine (optionally ramping pct=), and once nothing legitimate lands in spam, finish at p=reject. Rushing straight to reject is how invoices and password resets silently vanish.

Alignment: the part everyone misses

DMARC doesn't just ask “did SPF or DKIM pass?” — it asks whether the domain that passed matches the domain in your visible From: header. That match is called alignment, and Google calls it out explicitly: for direct mail, the From: domain must align with the SPF domain or the DKIM domain.

This is where senders who “pass everything” still fail. Say you send through an email service provider: From: news@yourdomain.com, but the envelope sender is bounce.espmail.com and the DKIM signature is d=espmail.com. SPF passes and DKIM passes — for the ESP's domain. Nothing aligns with yourdomain.com, so DMARC fails. The fix is configuring custom domain authentication at your ESP: a DKIM key that signs as d=yourdomain.com (usually a couple of CNAME records) and, ideally, a custom return-path subdomain for SPF.

By default alignment is relaxed: a subdomain counts, so a DKIM signature for mail.yourdomain.com aligns with From: yourdomain.com. Strict mode (adkim=s / aspf=s) requires an exact match — leave it relaxed unless you have a specific reason.

Common ways DMARC breaks

• Forwarding. When a message is forwarded, it arrives from the forwarder's server, so SPF fails; DKIM usually survives because the signature travels with the message. This is why DKIM alignment matters more than SPF alignment — and why Google doesn't require alignment on forwarded or mailing-list (“indirect”) messages.
• Third-party senders. The CRM, help desk, billing system, or survey tool sending “as you” without signing with your domain. Your aggregate reports will surface every one of them — fix or retire each before moving past p=none.
• Subdomains. Your organizational policy covers subdomains by default, so news.yourdomain.com inherits the apex record unless it publishes its own (or you set the sp= tag). Senders forget the mail streams running on subdomains and break them when the apex moves to reject.
• Record mistakes. Two DMARC records at the same host (both become invalid), the record published at the wrong name, or syntax typos in the tag list. When in doubt, dig it and read what's actually there.

Frequently asked questions

Is DMARC required if I send fewer than 5,000 emails a day?

Not strictly. Google's DMARC mandate applies to bulk senders — domains that send 5,000 or more messages a day to personal Gmail accounts. Smaller senders only need SPF or DKIM. But the count covers your whole primary domain, bulk-sender status is permanent once you cross the line, and every major mailbox provider is moving the same way — so publishing at least p=none now is cheap insurance.

Is p=none enough to satisfy Gmail?

Yes. Google's minimum is a valid DMARC record with a policy of at least p=none, which satisfies the requirement while telling receivers to deliver your mail normally and send you reports. Treat it as a starting point, though: p=none does nothing to stop spoofing, so plan to move to quarantine and then reject once your reports show legitimate mail passing.

Does bulk-sender status expire if my volume drops?

No. Google says bulk-sender classification has no expiration date — once a domain sends 5,000 or more messages to Gmail in a single day, it is treated as a bulk sender permanently, even if daily volume later falls below the threshold.

Do I need both SPF and DKIM, or is one enough?

Bulk senders need both. Senders below 5,000 messages a day can pass with either SPF or DKIM, but DMARC still needs at least one of them to align with your From: domain — and because SPF routinely breaks when mail is forwarded, DKIM alignment is what keeps DMARC passing in practice.

Do Yahoo and Microsoft require DMARC too?

Yes. Yahoo rolled out its requirements together with Google in February 2024, and Microsoft brought a matching rule to Outlook, Hotmail and Live addresses in May 2025 — senders of 5,000+ messages a day need SPF, DKIM, and a DMARC record of at least p=none. One correct DMARC record satisfies all three providers.

Check your DMARC in seconds

The fastest way to know where you stand is to test a real message. Upload the raw .eml and the checker reads your SPF, DKIM, and DMARC results, checks alignment against your From: domain, and inspects your one-click unsubscribe headers — then tells you in plain English what Gmail would do with it.