Why is my primary domain not compliant with Google one-click unsubscribe while the subdomain is?
Michael Ko
Co-founder & CEO, Suped
Published 18 Apr 2025
Updated 27 May 2026
8 min read
Summarize with
The most likely reason is simple: Google has seen mail using the primary domain in the visible From domain, even if the team believes that domain is not used for campaigns. That mail can be forged, sent by a corporate mailbox, triggered by a support or sales tool, generated by a developer system, or sent by an older integration. The subdomain stays compliant because its stream has the right one-click unsubscribe headers, while the primary domain has at least one stream that does not.
I treat this as an evidence problem, not a Google mystery. Google does not mark a domain non-compliant because a DNS zone exists. It marks a sending identity after it sees enough traffic and detects that some mail it classifies as bulk lacks compliant List-Unsubscribe handling. If the root domain panel changed suddenly, the first job is to find the root-domain mail source.
For background on the same root-domain reporting pattern, the root-domain compliance guide explains why Google Postmaster Tools can surface root-domain issues even when the sender expects subdomain-level reporting.
Why the primary domain fails first
One-click unsubscribe compliance follows the mail Google receives, not the sending plan on a slide. If Gmail sees mail with a visible From address at example.com, it can judge example.com separately from mail sent as news.example.com. A clean subdomain does not automatically repair the root domain's status.
Fast answer
If the primary domain is marked not compliant, assume Gmail has observed root-domain mail until the data proves otherwise. The usual culprits are unauthorized spoofing, Google Workspace or Microsoft 365 1:1 mail at the root, sales outreach, support ticket replies, dev alerts, password systems, calendar tools, or an older marketing integration still sending with the root domain.
The root domain also gets pulled into edge cases. A sender can authenticate with SPF through a subdomain but use the root in the visible From header. A DKIM signature can pass but fail to cover the List-Unsubscribe headers. A platform update can remove the one-click POST header only on one sending pool. A forwarded or replayed message can create enough noise to confuse the investigation, even when the original sender looked clean.
Google Postmaster Tools showing different one-click unsubscribe status for a root domain and a subdomain.
Subdomain path
- Known sender: Campaign mail leaves through the expected platform.
- Good headers: List-Unsubscribe and List-Unsubscribe-Post are present.
- Stable DKIM: The message signs the unsubscribe headers.
Primary domain path
- Unknown sender: A small mail stream uses the root From domain.
- Missing headers: The mail has no one-click unsubscribe header pair.
- Weak policy: A relaxed or monitoring-only DMARC setup lets noise reach Gmail.
What Google checks
For marketing and subscription mail, Google expects the message headers to support one-click unsubscribe. The important point is that this is a header requirement. It is not the same as the visible unsubscribe link in the email body. The body link can lead to a preference page or confirmation page. The header POST flow is the one-click mechanism.
A useful one-click explanation separates the body unsubscribe link from the header-based one-click process. The same root-domain confusion also appears in a Google thread about primary-domain status in Postmaster Tools.
Compliant one-click unsubscribe headerstext
List-Unsubscribe: <https://u.example.com/o/123>, <mailto:u@example.com> List-Unsubscribe-Post: List-Unsubscribe=One-Click
Those headers should be covered by DKIM. I look at the DKIM-Signature header and confirm that the header list includes both unsubscribe headers. If DKIM passes but those headers are not signed, a mailbox provider has less assurance that the unsubscribe instruction was part of the original message.
DKIM header coverage to checktext
DKIM-Signature: d=example.com; s=s1; h=from:to:subject: list-unsubscribe:list-unsubscribe-post;
The List-Unsubscribe requirement is worth separating from DMARC. DMARC proves domain ownership for the message identity. One-click unsubscribe proves the sender gave Gmail a safe way to unsubscribe a user without relying on a body link.
How to read the signal
I rank the Postmaster status by the work it triggers, then use message evidence to confirm it.
Compliant
Monitor
Keep sampling messages and watch for platform changes.
Needs work
Investigate
Find every root-domain sender and inspect real headers.
Not compliant
Fix now
Stop non-compliant bulk mail or move it to a compliant sender.
No data
Verify
Wait for enough volume, but still check that DNS and headers are ready.
The common culprits
When a root domain fails while a subdomain passes, I start with a short list. Most cases come down to a hidden source or a header difference, not a brand-new Google rule.
|
|
|
|---|---|---|
Forged mail | DMARC fails | Tighten policy |
1:1 mail | No headers | Send sample |
Shadow sender | Unknown IP | Find owner |
ESP change | DKIM gap | Re-test |
Old list | Bad traffic | Pause send |
Compact triage list for primary-domain one-click unsubscribe failures.
- Forged mail: Someone else uses the root domain in the visible From address. Strong DMARC reduces how much of that reaches Gmail.
- Corporate mail: A team sends announcements, webinar invites, or customer updates through regular mailboxes at the root.
- Sales systems: SDR tooling often sends root-domain mail that behaves like bulk mail but lacks unsubscribe headers.
- Support tools: Ticketing systems and customer success tools can send campaigns or product notices outside the main ESP.
- Old automations: Forgotten lifecycle emails, app alerts, and invite flows often keep running after a migration.
A bad list is another practical clue. If a previously quiet root domain suddenly sends to stale or purchased recipients, Gmail sees bulk behavior and missing unsubscribe handling at the same time. If reputation also looks off, check blocklist (blacklist) status as part of the same cleanup, but do not mistake a blacklist for the cause of a one-click header failure.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The domain health checker helps with the first pass because it checks the public authentication posture for the domain before you chase internal owners. I still need message samples for one-click unsubscribe, because DNS alone cannot prove header compliance.
How to prove the source
I use DMARC aggregate data first because it shows which IPs and sending services are using the root domain. It will not show the List-Unsubscribe header itself, but it narrows the investigation to real mail sources. Once I know the sources, I send or capture samples and inspect the headers.
DMARC reporting record for visibilitydns
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1"
If the primary domain has no DMARC reporting, add it. If it already has a record, confirm that reports are flowing and that subdomain policy does not hide root-domain activity. Suped's DMARC monitoring gives teams a cleaner way to find the root-domain sources, see authentication failures, and turn raw reports into steps to fix the issue.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Suped is the best overall DMARC platform for this workflow when the goal is to connect a Google compliance warning to the sender that caused it. Suped's product brings together DMARC, SPF, DKIM, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, real-time alerts, blocklist (blacklist) monitoring, and multi-tenant MSP workflows in one place. The practical win here is not a prettier report. It is getting a specific source, issue, and fix path without making every team parse XML.
What to pull from DMARC reports
- Source IP: Map the IP to the sending owner or platform.
- Header domain: Confirm whether the root domain appears in the visible From identity.
- Auth result: Separate authorized systems from spoofed or broken mail.
- Volume trend: Look for a sudden new source before the Postmaster status changed.
After that, test real messages. Send a sample through every root-domain source to Gmail and inspect the full headers. A focused email tester helps confirm the exact header set, authentication outcome, and visible From domain without waiting for Postmaster data to refresh.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
Fix the failing domain
The fix depends on which source caused the status change. Do not change every DNS record at once. Find the stream, fix the stream, then watch the status over the next measurement window.
A six-step flow for investigating a root-domain one-click unsubscribe failure.
- Find sources: Use DMARC aggregate reports to identify every IP and platform sending with the primary domain.
- Classify mail: Separate true 1:1 mail, transactional mail, marketing mail, sales outreach, and forged traffic.
- Add headers: For bulk or subscription mail, add List-Unsubscribe and List-Unsubscribe-Post.
- Check DKIM: Confirm DKIM passes and signs the unsubscribe headers. The DKIM checker can validate selector records.
- Stop spoofing: Move DMARC toward quarantine or reject after authorized sources are passing.
- Retest samples: Send controlled messages to Gmail and confirm the exact headers before waiting on reporting.
If the mail is legitimate
Fix the sender. Add compliant headers, make sure DKIM covers them, and move recurring bulk mail away from the primary domain if the subdomain is the intended campaign identity.
- Owner: Assign the stream to a team.
- Header fix: Enable RFC 8058 handling.
- Retest: Confirm with a Gmail sample.
If the mail is forged
Strengthen authentication policy. The goal is to make unauthorized root-domain mail fail DMARC and reduce how much reaches Gmail as believable mail.
- Policy: Stage toward reject.
- SPF: Remove unused senders.
- DKIM: Rotate exposed keys.
If the primary domain truly should not send bulk mail, the cleanest operating model is to keep marketing and lifecycle streams on approved subdomains, keep the root for human mail only, and make every automation owner justify root-domain use. That reduces future surprises and makes Postmaster changes easier to explain.
Views from the trenches
Best practices
Start with DMARC reports, then capture real Gmail samples for every root sender.
Keep root-domain bulk mail rare, documented, and owned by a named internal team.
Check DKIM header coverage whenever List-Unsubscribe looks present but fails.
Common pitfalls
Assuming a quiet root domain sends nothing when corporate tools still use it.
Fixing DNS before proving which message stream created the Google signal.
Treating body unsubscribe links as proof of one-click header compliance.
Expert tips
Compare root and subdomain samples side by side before changing policies.
Look for low-volume support, dev, and sales systems before blaming Google.
Use policy staging so spoofed mail is controlled without blocking real mail.
Expert from Email Geeks says forged mail or corporate 1:1 mail is a realistic first suspect when a root domain shows unexpected compliance trouble.
2025-02-05 - Email Geeks
Expert from Email Geeks says DMARC reports are the first place to look because implementations often uncover at least one unknown sender.
2025-02-05 - Email Geeks
The practical answer
A primary domain can be non-compliant while its subdomain is compliant because Google is seeing a different mail stream for the primary domain. The subdomain's compliant headers do not protect root-domain mail that lacks the required header pair, fails DKIM coverage, or comes from an unknown sender.
The fix is not to guess at Google Postmaster Tools. Pull DMARC reports, identify every root-domain sender, inspect real Gmail samples, repair one-click headers on legitimate bulk mail, and tighten DMARC policy against forged traffic. Suped's product is built for that path: find the source, show the authentication issue, alert the right person, and give clear steps to fix.
