Blog · Deliverability
Why Gmail Shows a Phishing Warning on Your Email Even When SPF, DKIM, and DMARC All Pass
Why Gmail Shows a Phishing Warning on Your Email Even When SPF, DKIM, and DMARC All Pass
Passing authentication is not a clearance signal. SPF, DKIM, and DMARC answer one question: did your domain authorise this message. Gmail's reputation layer answers a different question: does Google still want to deliver it. Both can be true at the same time, and when a recipient sees a phishing-style warning on your legitimate mail, the second question has already been answered badly while every authentication log you own says everything is fine. The documented enforcement behind it does not produce a bounce code. It produces silence.
That silence is why this is hard to troubleshoot. You check the authentication results, they pass. You check your DMARC aggregate reports, there is nothing. You check your SMTP logs, there is no error. Nothing in your stack is broken, which is exactly why nothing in your stack can explain the warning.
What Google actually enforces when the spam rate climbs
Google publishes an enforcement table in its sender guidelines FAQ that maps each unmet requirement to its consequence. Read the two halves of that table together and the whole problem falls out of it.
| Requirement not met | What Gmail does |
|---|---|
| From: header and authentication do not align | Temporary or permanent failure codes, or spam foldering |
| Messages are not authenticated with both SPF and DKIM | Temporary or permanent failure codes, or spam foldering |
| Domain has no valid forward and reverse DNS | Temporary or permanent failure codes, or spam foldering |
| Messages are not sent with TLS | Temporary or permanent failure codes, or spam foldering |
| Messages do not follow RFC 5322 format | Temporary or permanent failure codes, or spam foldering |
| Spam rate is greater than 0.3% | Delivery support or mitigations unavailable |
| DMARC record is missing | Delivery support or mitigations unavailable |
| Marketing messages missing one-click unsubscribe | Delivery support or mitigations unavailable |
| Unsubscribe requests not honoured within 48 hours | Delivery support or mitigations unavailable |
Two numbers matter here and they are not the same number. The ceiling is 0.3%. The working target is 0.1%, which is what Google tells senders to aim for. Google also states that spam rate is calculated daily, so a single bad day is not a rounding error, it is the number that gets evaluated.
Since June 2024 the consequence has a specific shape. Bulk senders with a user-reported spam rate above 0.3% are ineligible for mitigation. They stay ineligible for as long as the rate sits above 0.3%, and they become eligible again only once the rate has stayed below 0.3% for 7 consecutive days. So the recovery clock does not start when you fix the problem. It starts after you have proved for a week that you fixed it.
The rule that catches transactional senders
The most damaging misconception here is that transactional mail is exempt. It is not. Google states plainly that high spam rates negatively affect message delivery for any message type that you send.
This is the mechanism behind the pattern that confuses senders. A company runs a marketing stream and a transactional stream on the same primary domain. The marketing team works its list hygiene, keeps the marketing subdomain clean, watches it stay under 0.1%. The transactional stream carries password resets, order confirmations, and delivery notices, and it drifts to 0.4%, then 0.6%. Recipients start seeing a warning on mail that has nothing wrong with it. The marketing dashboard looks fine. The authentication headers look fine. The password reset is the thing being flagged.
A second factor sits on top of that. One-click unsubscribe is required only for marketing and promotional messages, and transactional messages are excluded from that requirement. That exclusion is about the unsubscribe header, not about how spam rate is calculated. It is easy to read the exclusion as a broader exemption from the spam rate rules. It is not one.
Why one clean subdomain does not save a noisy sibling
Bulk sender status is calculated at the primary domain, not at the sending subdomain. Google counts all messages from the same primary domain toward the 5,000-message threshold, so a sender doing 2,500 from example.com and 2,500 from mail.example.com is a bulk sender in the eyes of the requirement.
Two consequences follow, and both surprise people:
- A subdomain with a perfect record does not offset a sibling with a bad one. The domain-level spam rate is what gets evaluated.
- Bulk sender status is permanent once assigned. Senders who meet the criteria at least once stay classified as bulk senders, and Google states that changes in sending practices do not remove that status.
You can split sending streams across subdomains for reputation hygiene. You cannot use subdomain separation to opt out of a requirement that is assessed at the domain level.
Why nothing shows up in your logs
The number that drives this whole enforcement path lives in exactly one place: Postmaster Tools. Google describes its dashboards as covering spam rate, reputation, message authentication, and delivery errors. There is no equivalent figure in your sending platform's bounce report, no field in your DMARC aggregate report, and no SMTP response that carries it.
Postmaster Tools also has a scope limit that catches people out: its data only applies to messages sent to personal Gmail accounts. The sender guidelines themselves do not apply to mail sent to Google Workspace accounts. If most of your complaints come from corporate recipients on Workspace, the enforcement table above does not explain those complaints, and you need a separate line of investigation.
Finally, an empty dashboard is not a clean record. Postmaster Tools shows no data for a domain until it is verified, and low volume on a subdomain produces sparse or missing figures. Before reading a blank chart as good news, confirm the domain is verified and confirm it carries enough volume to be measured.
That split has a practical cost. Spam rate lives in one vendor's dashboard and authentication state lives in your DMARC reports, so the two people who can fix this often do not talk to each other. Give each question one owner: Postmaster Tools owns the spam rate, and a DMARC reporting view owns the authentication estate. DMARCFlow covers that second half, showing which sending domains and subdomains you authenticate with, whether their DMARC records are correct and aligned, and which sources are drifting off policy across the estate rather than one stream at a time.
What DMARC reports will not tell you
This is worth stating directly, because it is the reflex that wastes the most time on this problem. DMARC aggregate reports record authentication outcomes. This failure has no authentication failure to record. Your DMARC reports will show you a clean week while the warning is being served.
So the instinct to open your DMARC reporting when Gmail starts flagging you is reasonable and it is pointed at the wrong layer. It is useful immediately after this problem, as a check that the authentication layer is genuinely healthy while you work on the reputation layer, and for the question that sits next door: which sending source across the estate is failing, and what does the overall DMARC state look like. DMARCFlow is built for that second question, giving one view across every domain and subdomain rather than one stream at a time. It does not report Gmail spam rate, and it does not report inbox placement, so it cannot tell you whether you are above or below 0.3%. Anyone who tells you a DMARC tool can answer that question is selling you something that does not exist.
A same-day diagnostic checklist
Run this in order. It is designed so that each step tells you whether the next one is worth doing.
- Confirm authentication really is passing. Check the Authentication-Results header on a flagged message, not a config page. If SPF, DKIM, and DMARC all pass, stop working on authentication.
- Read your Postmaster Tools spam rate for the primary domain, not for a subdomain. Note the daily figure and its trend.
- Check whether the primary domain is the one carrying the traffic that is being reported. Look at which stream the reports come from: password resets, confirmations, or campaign mail.
- Audit every list and every import in the window before the spike. New list purchases, re-engagement sends, and stale subscriptions are the usual sources of the jump.
- Fix the unsubscribe path for marketing and promotional mail. One-click unsubscribe is required for those messages, and requests have to be honoured within 48 hours. Both appear in the same enforcement table as the spam rate.
- Separate your streams by sending IP where you can. Google recommends one IP per message type, or at least a different IP for account notifications than for promotional mail.
- Note the date your rate drops back below 0.3%. Eligibility for mitigation returns only after 7 consecutive days under the threshold, so that date is the real milestone.
- Use DMARC reporting to confirm the authentication layer is still clean while you do all of this. Check every subdomain that sends mail, not just the primary domain, since a sending subdomain that has drifted is the kind of thing a single-platform view hides. That layer is the one you can verify on your own schedule rather than waiting for Google to complain.
When to accept the warning and fix the sending programme instead
At some point the diagnosis is not the answer. If the spam rate has been over the threshold for months, the problem is not a bad week, it is the list, the acquisition channels, or the mix of what you send. No DNS record and no authentication setting fixes a sender whose audience has decided the mail is unwanted.
Two honest notes on what Google documents. The enforcement path above is the documented one: mitigation unavailability and degraded inbox placement. Google does not publish a rule stating that a spam rate above 0.3% causes a phishing-warning banner, and this article is not going to claim otherwise. What senders observe in the wild is a recipient-side warning that no sender-side log reports. The useful separation is that you cannot debug the warning directly, and you can absolutely debug the spam rate that Google documents as the trigger for lost support.
And if your volume to personal Gmail accounts is low enough that Postmaster Tools shows nothing, you may not be a bulk sender at all, in which case a different part of the enforcement table is the relevant one. Confirm your bulk sender status before you start changing sending practice to fix a problem you may not have.
The practical split is simple. Postmaster Tools tells you whether Google still wants your mail. DMARCFlow, or an equivalent DMARC reporting setup, tells you whether the records the rest of your stack depends on are actually correct across every sending domain and subdomain you operate. Keep both clean: the authentication estate verified, the spam rate under 0.1%. A warning that recipients see is the most expensive email problem you will never see in a report.
Frequently asked questions
Why does Gmail flag my email as phishing if DMARC passes?
Because passing DMARC and being wanted by Gmail are different things. DMARC records whether your domain authorised the message. Gmail separately tracks a user-reported spam rate, and the enforcement it documents for a rate above 0.3% is lost delivery support and degraded inbox placement rather than a rejection. The warning is a symptom of the second layer, not the first.
What is the Gmail spam rate threshold for bulk senders?
0.3% is the ceiling. Google asks senders to keep the rate below 0.1% and to prevent it from ever reaching 0.3%. The rate is calculated daily.
Do transactional emails count toward the spam rate?
Yes. Google states that high spam rates negatively affect message delivery for any message type that you send. Transactional messages are exempt from the one-click unsubscribe requirement, which is a different rule, but not from the spam rate rules.
Why is my subdomain clean but my main domain flagged?
Bulk sender status counts all messages from the same primary domain toward the 5,000-message daily threshold, and the domain-level spam rate is what gets assessed. A clean subdomain does not offset a noisy sibling, and bulk sender status stays with you permanently once assigned.
Does a DMARC failure cause a phishing warning?
No. A DMARC failure produces an authentication failure, and Google documents that as a temporary or permanent failure code or spam foldering. A missing DMARC record is in a different group: it produces lost delivery support without an error code. Neither of those is the phishing warning described here, which arises despite authentication passing.
How long after fixing my spam rate can I ask Google for mitigation?
Seven consecutive days below 0.3%. Since June 2024, bulk senders above that threshold have been ineligible for mitigation, and eligibility returns only after the rate stays under the threshold for a full week of daily calculations.
Why does Postmaster Tools show no data for my domain?
Three usual reasons. The domain is not verified, the volume sent to personal Gmail accounts is too low to produce a reading, or you are looking at data that does not cover your case at all, since Postmaster Tools applies only to mail to personal Gmail accounts and not to Google Workspace recipients.
Sources
- Google, Email sender guidelines: https://support.google.com/a/answer/81126
- Google, Email sender guidelines FAQ: https://support.google.com/a/answer/14229414
- Google, Set up Postmaster Tools: https://support.google.com/mail/answer/9981691