Why is Google Postmaster Tools flagging my root domain for compliance?
Updated on 12 Oct 2026: We updated this guide with signed unsubscribe checks and the authentication identities behind root-domain compliance warnings.
Google Postmaster Tools is flagging your root domain because the Compliance Status Dashboard reports status for the primary domain. If you send from mail.example.com, Google uses that traffic to evaluate example.com and still shows the compliance verdict for example.com. The flag does not prove Gmail found mail using user@example.com as the visible From address.
Treat the root row as an aggregate view of the domain family. Check every mail stream under the primary domain, including marketing, transactional, support, website forms, CRM sends, billing notifications, and employee mail. Then test a real message with an email tester and compare that result with DMARC aggregate reports and Google Postmaster Tools. Postmaster data covers mail sent to personal Gmail accounts, not mail delivered to Google Workspace accounts.
Common causes include a subdomain stream failing a sender requirement, a forgotten system sending under the domain family, a bulk marketing stream missing working one-click unsubscribe, or a rolling compliance calculation that has not incorporated a recent fix.
Why Google shows the root domain
Google separates its normal diagnostic dashboards from the Compliance Status Dashboard. Authentication, spam rate, encryption, and delivery errors can provide data for a separately added subdomain when volume is sufficient. Compliance Status is different: it uses primary-domain and subdomain traffic to calculate one status for the primary domain. Google documents this primary-domain scope in Postmaster Tools dashboards.
For example, adding mail.example.com does not produce a separate compliance verdict for that subdomain. Google shows the verdict for example.com. If you need diagnostic data for mail.example.com, add the subdomain to Postmaster Tools and use dashboards other than Compliance Status. For more detail on the primary-domain rule and sender volume, see volume thresholds.
- Primary domain: Google groups example.com, mail.example.com, and news.example.com under the same primary domain for compliance.
- Subdomain data: Subdomain mail can make the primary-domain status show Needs work even when the root domain sends no campaigns.
- Bulk status: Messages across the same primary domain count toward about 5,000 messages to personal Gmail accounts in 24 hours. Crossing that threshold once establishes permanent bulk-sender status; reducing volume or switching subdomains does not reset it.
- Dashboard delay: Data usually updates within 24 hours, but a corrected Needs work status can take up to seven days because Google uses a rolling average.
Google Postmaster Tools Compliance Status dashboard for example.com and mail.example.com.
What the root-domain flag means
A Needs work result means qualifying mail associated with the primary domain has not met a sender requirement. All senders need SPF or DKIM; bulk senders need both, plus DMARC. DNS records, encryption, message formatting and user-reported spam checks apply to all senders. One-click unsubscribe and honor-unsubscribe checks apply to bulk senders. These distinctions are set out in Google's sender guidelines.
|
|
|
|---|---|---|
Needs work | A requirement failed | Status detail |
SPF and DKIM | Authentication is incomplete | Received headers |
DMARC | Record or alignment failed | DMARC data |
One-click | One-click implementation is incomplete | Signed headers and HTTPS endpoint |
Honor unsubscribe | Requests exceed 48 hours | Endpoint and suppressions |
No data found | Too little qualifying traffic | Volume and date range |
Common root-domain compliance signals and what to check first.
Postmaster Tools is not a live DNS checker. Its verdict is based on mail Google received, and configuration checks reflect what Google observed when those messages arrived. A correct DNS record today does not prove that historical messages used the same setup. Old sends, one-off systems, and partial vendor migrations can keep a primary-domain row red after the visible configuration looks clean.
Do not fix only the root DNS record and stop. If mail.example.com is the real sender, the primary-domain compliance verdict still depends on how that subdomain authenticates, includes unsubscribe headers where required, honors opt-outs, and avoids user spam reports.
- Check scope: Review every sender and subdomain grouped under the primary domain.
- Check history: Wait up to seven days after a confirmed fix before treating the dashboard state as unresolved.
- Check evidence: Use received headers and DMARC aggregate reports instead of relying on the intended setup.
Why one-click unsubscribe can flag the root domain
When the compliance problem is one-click unsubscribe or honor unsubscribe, Google is not only checking whether the footer link works. For bulk senders, marketing and subscribed messages must include RFC 8058 one-click unsubscribe headers. Transactional messages, such as password resets and purchase confirmations, are excluded from this requirement. Keep promotional content out of transactional messages instead of relying on the sending platform's category label.
Minimum one-click unsubscribe headerstext
List-Unsubscribe: <https://example.com/unsubscribe/abc123> List-Unsubscribe-Post: List-Unsubscribe=One-Click
Both unsubscribe headers must be covered by a valid DKIM signature and included in its h= list, as required by RFC 8058. A published DKIM key or unsigned unsubscribe headers are insufficient.
A preference center is still useful, and bulk marketing or subscribed messages also need a clearly visible unsubscribe link in the body. That body link alone does not satisfy one-click unsubscribe. The HTTPS endpoint must accept Gmail's POST without a login, cookies, a redirect, or a confirmation step. Remove the recipient from the relevant mailing list within 48 hours.
Looks compliant
- Footer link: The email has a visible unsubscribe link in the message body.
- Preference page: The website lets subscribers change mailing lists after loading a page.
- Platform setting: The sending platform says unsubscribe handling is enabled.
Actually compliant
- Headers present: Each bulk promotional stream has List-Unsubscribe and List-Unsubscribe-Post covered by a valid DKIM signature.
- POST accepted: The HTTPS endpoint records the unsubscribe without extra user steps or a security challenge.
- Suppression works: Future sends to the associated mailing list exclude the recipient within 48 hours.
This is why a primary-domain flag can appear even when the website unsubscribe service works in a browser. Google judges what Gmail users receive and what happens after Gmail submits the one-click POST. Test the exact headers from a real Gmail-delivered message, the endpoint response, and the final suppression record. Check security logs for blocked POST requests and give each mailing list a unique List-ID or From address. Gmail's visible Unsubscribe button depends on its eligibility checks; its absence alone does not prove a header failure. See Google's unsubscribe guidance.
How to identify the failing mail stream
Start with source discovery because the main marketing platform is often not the failing stream. The source can be a forgotten sender that uses the same primary domain, a default website mailer, an old automation, or employee mail with promotional content.
- DMARC reports: Group by visible From domain, source IP, DKIM domain and SPF domain. DMARC reports do not show unsubscribe handling or Gmail inbox placement.
- Postmaster views: Compare Compliance Status with authentication, spam rate, feedback loop and delivery errors. Use Feedback-ID to group complaints by campaign; Gmail provides aggregate data rather than individual complainant identities.
- Gmail samples: Open Show original for real messages and inspect SPF, DKIM, DMARC, and unsubscribe headers.
- Suppression logs: Search for Gmail unsubscribe requests and verify the recipient was removed from the correct list within 48 hours.
For a broad DNS snapshot, run the primary domain and each active subdomain through Suped's domain health checker. It checks published records, but DNS alone cannot prove that outgoing messages are DKIM-signed. Verify the active selector and signature in received messages, then compare them with DMARC reports and Postmaster Tools.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
If the checker is clean but the primary-domain row still says Needs work, keep investigating. Postmaster Tools can be using historical mail, a different qualifying dataset, or a mail stream that the DNS-only check did not exercise.
Use deliverability analysis before changing DNS
Open Deliverability analysis under the Compliance Status Dashboard before changing records. Google uses this diagnostic to provide a recommendation about the primary domain's status with Gmail. It can distinguish insufficient data from delivery failures, excessive user-reported spam, low recipient engagement, and a sender-guideline failure.
- Read the recommendation: Separate a technical compliance failure from low volume or poor recipient response.
- Match the date: Compare the affected period with campaign launches, sender migrations, and authentication changes.
- Confirm with evidence: Use raw messages, SMTP logs, DMARC data, and unsubscribe logs to identify the responsible stream.
- Change one cause: Fix the named requirement, then allow up to seven days for the rolling status to change.
A No data found status is not a pass or failure. Google can withhold data when message volume is too low or privacy filters remove too much of the qualifying traffic. Do not respond to that state by publishing speculative DNS changes.
Which domain does each authentication check use?
Read Gmail's Authentication-Results alongside the visible From and Return-Path. Primary-domain reporting does not mean every authentication check looks up DNS at example.com.
|
|
|
|---|---|---|
SPF | SMTP MAIL FROM domain, shown in Return-Path; HELO domain when MAIL FROM is empty | SPF TXT record at that exact domain and Gmail's SPF result |
DKIM | Signing domain in the DKIM-Signature d= tag | The s= selector, its key at selector._domainkey.signing-domain and Gmail's DKIM result |
DMARC | Visible From domain | Applicable DMARC policy and alignment with a passing SPF or DKIM identity |
Compliance Status | Primary domain | Qualifying traffic across the primary domain and its subdomains |
Authentication identities and primary-domain reporting have different scopes.
SPF does not automatically inherit a parent domain's record. DKIM looks up the selector under the signature's d= domain. These lookup rules are defined in the SPF specification and DKIM specification.
A DMARC pass through DKIM does not prove that SPF passed. Bulk senders still need both SPF and DKIM, with DMARC alignment through at least one, as explained in Google's authentication FAQ.
DNS records to verify
For a domain family that sends from subdomains, verify each stream's actual sending identities. The root's DMARC record can apply even when it sends no campaigns, but check the sending subdomain's direct record and any inherited policy. The policy-discovery rules are defined in RFC 9989.
Root DMARC record with reportingtext
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
For bulk senders, Google requires a DMARC record with at least p=none. The default relaxed alignment is sufficient for this requirement. Add adkim=s or aspf=s only when your policy requires exact-domain alignment and every legitimate sender supports it.
Root SPF record when the root sends no mailtext
example.com. 3600 IN TXT "v=spf1 -all"
Use the no-send SPF record only when no legitimate system uses the root domain in SMTP MAIL FROM or HELO. It is optional, not a prerequisite for fixing subdomain compliance. It does not stop inbound mail, but authorizes no sending IP for the root's SPF identity. Do not publish a null MX record unless the domain should receive no email at all.
For a DNS records warning, check the actual sending IP: its PTR must resolve to a hostname whose A or AAAA record resolves back to that IP. The sending provider normally manages the PTR record. For encryption warnings, confirm TLS on the SMTP delivery connection. These infrastructure checks are described in Google's sender guidelines.
Suped is our DMARC reporting and email authentication platform. Its sender-discovery workflow shows sources appearing in DMARC reports so teams can identify systems using the primary domain or subdomains and investigate authentication failures.
- Source map: Find verified and unverified senders across the domain family.
- Fix steps: Turn authentication failures into specific DNS or sender actions.
- Alerts: Track new sources and recurring authentication failures after remediation.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
For teams that manage several domains or clients, Suped's DMARC monitoring workflow turns aggregate reports into a sender inventory and keeps monitoring for changes after the first fix.
What to fix first
Do the fixes in an order that matches the evidence. Start with source discovery, then fix the failing requirement in that stream. Changing every DNS record at once makes it harder to prove what worked.
Gmail spam complaint thresholds
Use these bands as operational triggers while investigating a primary-domain compliance flag.
Target
Under 0.1%
Keep the user-reported rate below Google's recommended target.
Watch
0.1% to below 0.3%
Investigate recipient consent and the campaigns generating complaints.
Risk
0.3% or higher
Stop the affected sends and correct the source of complaints.
A low or zero reported spam rate does not prove inbox placement. Gmail measures user reports on inbox-delivered mail; messages automatically sent to spam can make that rate look low. Compare the rate with delivery errors and real recipient samples, as described in Google's spam-rate documentation.
- Inventory senders: List every system that sends to personal Gmail accounts using the primary domain or a subdomain.
- Inspect samples: Send one real message from each stream and save the raw Gmail headers.
- Fix authentication: For bulk senders, make SPF and DKIM pass. Confirm that at least one passing identity meets DMARC alignment with the visible From domain under the applicable relaxed or strict mode.
- Fix unsubscribe: Add one-click headers to bulk promotional streams and verify the endpoint suppresses the right list within 48 hours.
- Wait and measure: Recheck Postmaster Tools after seven days while monitoring live delivery errors and fresh DMARC data throughout.
For the distinction between compliance and domain reputation, keep the dashboard version in mind. Google's interface migration guidance says v2 excludes the legacy Domain and IP Reputation dashboards. A compliant status still does not guarantee inbox placement.
Does a compliance flag affect Gmail deliverability?
Yes, a compliance failure can affect Gmail deliverability, especially for bulk traffic. Needs work does not itself mean every message is blocked. Google increased enforcement of noncompliant traffic starting in November 2025, including temporary and permanent rejections, as stated in its sender requirements FAQ.
The risk depends on the failed requirement. Missing authentication, invalid forward or reverse DNS, missing TLS, bad message format and failed From-domain alignment can lead to 4xx or 5xx errors. Unsubscribe failures also affect eligibility for delivery support or mitigation; Google does not automatically reject a message solely because one-click unsubscribe is missing. Identify the failed requirement and match it to the messages and SMTP responses.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
If the test message passes but Postmaster Tools stays red, do not assume Google is wrong. The sample can be cleaner than the mail stream that triggered the verdict. Test each stream, including old automations and lower-volume sends.
Views from the trenches
Best practices
Check the primary domain and every active subdomain before changing DNS records at scale.
Keep one-click unsubscribe logs so you can prove requests are honored within 48 hours.
Use Gmail Feedback-ID campaign data to locate complaint patterns across sending streams.
Common pitfalls
Treating the root flag as a root-only send can hide subdomain traffic that caused it.
Fixing current DNS only and ignoring Google's rolling compliance average delays diagnosis.
Assuming a body unsubscribe link satisfies one-click unsubscribe creates repeat failures.
Expert tips
Send a seed message from each stream and inspect the exact headers Gmail received today.
Use DMARC aggregate data to find forgotten systems before changing the Gmail setup.
Separate transactional and promotional sends so unsubscribe rules match the message type.
Marketer view
Marketer from Email Geeks says the root-domain row usually means Google is evaluating the primary domain, even when the visible sending domain is a subdomain.
2025-03-13 - Email Geeks
Marketer view
Marketer from Email Geeks says fixes can take days to appear because the compliance dashboard uses aggregated data rather than a live DNS lookup.
2025-05-08 - Email Geeks
How to verify the compliance fix
The primary-domain row will still show example.com after you fix mail.example.com. Success means the affected requirement changes to Compliant. Keep dated Gmail samples and logs that show the correction, then recheck after seven days of normal sending. No data found is not confirmation that the fix worked; Google needs enough qualifying traffic to evaluate it.
Suped's product supports this workflow after the immediate incident. It monitors DMARC, SPF, DKIM, and sender changes across domains, then turns authentication issues into concrete remediation steps.
