InboxRatio
Check your domain

DMARC for Gmail: what Google requires, and what Gmail does with your policy

DMARC and Gmail meet in two directions, and most confusion comes from blurring them. In one direction, Gmail is the receiver of your mail and has rules about what your domain must publish before it will accept that mail at volume. In the other, Gmail is an enforcer of your policy: when someone else sends mail claiming to be your domain, your DMARC record tells Gmail what to do with it. A domain can satisfy the first and get almost no benefit from the second. This guide covers both, plus the setup path for domains that run on Google Workspace, and it stays deliberately independent of any single year's announcement: the requirements below are the ones in Google's current sender documentation, checked in September 2026.

If DMARC itself is new, start with what DMARC is and come back.

What Gmail requires, by sender tier

Google's Email sender guidelines split senders into two groups, counted by the mail they send to personal Gmail accounts.

All senders must authenticate with SPF or DKIM. DMARC is not mandatory at this tier.

Bulk senders, which Google's FAQ defines as senders of close to 5,000 messages or more to personal Gmail accounts within 24 hours, must authenticate with both SPF and DKIM and publish a DMARC record for the sending domain. The count covers everything sent from the same primary domain, whichever platform sends it, and per the FAQ the classification never expires. How the threshold relates to the per-account caps that also get called limits is untangled in Gmail sending limits.

The policy bar is low on purpose. The guidelines say the DMARC enforcement policy can be set to none, and Google's Postmaster Tools FAQ goes further, describing p=none applied to 0% of messages (pct=0) as acceptable minimal enforcement. A record like this satisfies the requirement:

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

What the low bar does not relax is alignment.

Alignment is the requirement domains actually fail

Google's wording is that the organizational domain in the From header must be aligned with either the SPF organizational domain or the DKIM organizational domain. Passing SPF or DKIM is not enough; the domain that passes has to be yours.

The classic failure looks healthy on a dashboard. You send through a marketing platform that signs with its own DKIM domain and uses its own bounce domain as the envelope sender. SPF passes, for the platform's domain. DKIM passes, for the platform's domain. Neither matches the example.com in your From address, so DMARC fails, and a bulk sender with no aligned pass is out of compliance with a perfectly valid record published. The fix is configuration at the platform: a custom DKIM signature with your domain (see DKIM alignment) or a custom return path on your domain for SPF alignment. One aligned pass is enough, and DKIM is the one that survives forwarding.

Google's DMARC setup documentation also notes that relaxed alignment, the default, typically provides sufficient spoofing protection. Strict alignment (adkim=s, aspf=s) requires exact domain matches, so mail authenticated on a subdomain such as a bounce domain fails it, and it adds nothing to Gmail compliance.

The error codes that name DMARC

Gmail tells you when DMARC is the problem, and its SMTP errors reference distinguishes a temporary nudge from a block.

| Code | What Google's reference says it means | |---|---| | 421 4.7.40 | Rate limited: the sending domain has no DMARC record, or the record doesn't specify a policy | | 550 5.7.40 | Blocked for the same reason | | 421 4.7.32 | Rate limited: the From header isn't aligned with the authenticated SPF or DKIM organizational domain | | 550 5.7.32 | Blocked for the same alignment failure | | 550 5.7.26 | Unauthenticated mail not accepted due to the From domain's DMARC policy |

The 4.7.x codes are a deferral your sending server will retry; the 5.7.x codes are a refusal that comes back as a bounce-back. A sender seeing the temporary form and changing nothing should expect the permanent form. The full register of Gmail's sender-guideline codes lives on our Gmail sender requirements page.

550 5.7.26 is different in kind. It is Gmail applying a DMARC policy, usually p=reject, that the From domain published. If that domain is yours, some legitimate source of your mail is failing authentication, and DMARC fail is the debugging guide.

What Gmail does with your policy

The second direction. Google's DMARC documentation describes the three policy values in receiver terms. With none, take no action and deliver the message. With quarantine, mark the message as spam and send it to the recipient's spam folder. With reject, reject it, and the receiving server usually sends a bounce to the sender.

Read those from the spoofer's side. At p=none, a forged message claiming your domain is evaluated, fails, and is left to Gmail's ordinary filtering. At quarantine, the forgery goes to the spam folder. At reject, it never arrives. Compliance with the bulk-sender rule needs only the first; protection for your customers starts at the second.

The same logic applies to your own unfinished setup. A policy of reject published while a billing system still sends unauthenticated mail means Gmail refuses those invoices with 5.7.26. That is why enforcement is staged, not flipped.

Setting it up for a Google Workspace domain

Workspace domains follow the same steps as any other, with Google-specific prerequisites spelled out in its Admin documentation:

  1. Finish SPF and DKIM first. Google states you must turn on SPF and/or DKIM before using DMARC. SPF means adding the include Google documents for Workspace to your record; DKIM means generating a key in the Admin console, publishing it in DNS, and turning signing on so mail carries your domain's signature.
  2. Wait. Google recommends allowing 48 hours after setting up SPF or DKIM before setting up DMARC.
  3. Publish at _dmarc, starting with p=none. Google's own rollout advice is to start with none. Build the record with the DMARC generator; the step-by-step version is how to set up DMARC.
  4. Send reports somewhere you will read. Google recommends against using a personal address for rua and suggests a dedicated mailbox, a group, or a third-party service, and notes that the number of reports you receive depends on how much mail your domain sends.

Every other service that sends as the domain needs the same treatment. DMARC aggregate reports are how you find them; the DMARC report analyzer turns the XML into a source list.

Checking compliance from Google's side

Outside-in checks confirm what the world sees: the DMARC checker validates the record and policy, and pasting a delivered message into the email header analyzer shows Gmail's own dmarc= verdict in Authentication-Results.

Google also grades you directly. Postmaster Tools has a Compliance status dashboard that, for bulk senders, reports on DMARC authentication alongside one-click unsubscribe, with each requirement shown as Compliant, Needs work, or No data found, plus an Authentication dashboard showing the share of traffic passing SPF, DKIM and DMARC. Verify your domain there before you need it, not in the middle of an incident.

Past p=none: reasons Gmail itself gives you

Monitoring mode is compliant, but Google attaches real benefits to enforcement. The clearest is BIMI: Google's BIMI documentation says the DMARC policy must be quarantine or reject, that BIMI doesn't support p=none, and that pct must be 100, with a Verified Mark Certificate or Common Mark Certificate required on top. The BIMI checker shows whether a domain meets the record side.

One standards note for anyone following Google's rollout docs literally. Google's DMARC documentation still describes the pct tag for gradual rollout. RFC 9989, published in May 2026, obsoleted RFC 7489 and removed pct in favor of a t=y testing flag; receivers adopt new standards gradually, which is why a transition-era record can carry both. The staged migration, with both tags and a rollback plan, is laid out in DMARC enforcement: from p=none to p=reject.

Related guides

About this guide

Written by InboxRatio Editorial. Sender tiers, the bulk-sender definition, the p=none allowance and alignment wording follow Google's Email sender guidelines, its FAQ and the Postmaster Tools FAQ; error codes follow Google's Gmail SMTP errors reference; policy handling, prerequisites and reporting advice follow Google's Workspace DMARC and BIMI setup documentation; the Compliance status dashboard follows Google's Postmaster Tools help; the pct/t change follows RFC 9989. All were checked in September 2026, and the current documents govern if they change. No vendor sponsorship influences it.

Methodology

InboxRatio's benchmark sends real campaigns through the platforms we review to a controlled seed list and records where each message lands. This guide draws on Google's documentation and the DMARC specification rather than our measurements; the protocol is in how we test and our source rules in sources.

Last updated

13 October 2026. Google's sender documentation and RFC references reviewed quarterly.

Frequently asked questions

Does Gmail require DMARC? For bulk senders, yes: domains sending close to 5,000 or more messages a day to personal Gmail accounts must publish a DMARC record and pass it with SPF or DKIM alignment. Other senders need SPF or DKIM; DMARC is optional for them but still protects the domain from spoofing.

Is p=none enough for Gmail? For compliance, yes. Google's guidelines allow a policy of none, and its Postmaster Tools FAQ describes p=none with pct=0 as minimal enforcement. It is not enough for BIMI, which requires quarantine or reject, and it gives no protection against spoofing.

What does Gmail do with emails that fail DMARC? It applies the From domain's published policy. Google's documentation describes none as delivering the message, quarantine as marking it spam and sending it to the spam folder, and reject as refusing it, with a bounce usually returned to the sender.

What is error 550 5.7.26 in Gmail? Gmail refused the message because it failed authentication and the From domain's DMARC policy asks receivers to reject such mail. If the domain is yours, a legitimate source isn't authenticating with aligned SPF or DKIM; find it in your aggregate reports.

Why does Gmail say my From header isn't aligned when SPF and DKIM pass? Because they pass for someone else's domain, typically your sending platform's. Configure custom DKIM signing with your domain at the platform, or a custom return path on your domain, so at least one pass matches your From address.

Do the Gmail DMARC requirements apply to mail sent to Google Workspace addresses? Google's FAQ says the sender guidelines don't apply to messages sent to Google Workspace accounts. Workspace recipients are still protected by filtering their administrators control, so the same authentication is the sensible baseline.

Gmail's DMARC rule is cheap to meet and easy to fail on alignment. Publish the record, prove one aligned pass for every source, and then let the DMARC checker confirm each step as you move the policy toward reject.