- June 2022
- Engineering Memo · External Release
Gmail Postmaster Tools provides two distinct reputation signals: IP reputation (how Gmail views each registered sending IP address) and domain reputation (how Gmail views the sending domain). These signals measure different things, update at different rates, and should drive different operational responses when they decline. Operators who treat them as interchangeable — or who focus on one while ignoring the other — miss the diagnostic specificity that makes Postmaster Tools the most useful free deliverability monitoring tool available.
This note explains what each reputation signal measures, how they interact, what causes each to change, and what the correct operational response is to changes in each.
IP Reputation: What It Measures
IP reputation in Postmaster Tools reflects Gmail's assessment of a specific IP address's sending behaviour — based on the complaint rates, engagement signals, and sending patterns observed from messages delivered from that IP to Gmail addresses. It is assigned a tier (High, Medium, Low, Bad) based on these observed signals.
IP reputation is IP-specific: if a pool has 5 sending IPs, each IP has its own reputation tier that may differ from the others. IP-01 may be High reputation while IP-05 (recently warmed) is Medium reputation. The reputation tiers reflect each IP's specific history with Gmail — the engagement signals from messages delivered from that IP, the complaint rates from those deliveries, and the consistency of the sending pattern from that IP.
IP reputation changes in response to IP-level events: a blacklisting on the IP (typically causes an immediate reputation drop), a period of elevated complaint rate specifically from sends through that IP, a sudden change in sending volume from the IP (a spike that exceeds the IP's established rate), or a period of low or zero sending that causes reputation signals to decay. IP reputation can change quickly — a single high-complaint campaign sent through a specific IP can move that IP from High to Medium within days.
Figure 1 — IP vs Domain Reputation: What Each Signal Measures
Both signals determine inbox placement — but they move at different speeds and respond to different inputs. Diagnosis requires checking both.
Domain Reputation: What It Measures
Domain reputation in Postmaster Tools reflects Gmail's assessment of the sending domain — the domain in the From: header that recipients see. It aggregates engagement signals, complaint rates, and sending history across all IP addresses that have sent authenticated mail from that domain to Gmail addresses. Domain reputation is the most influential single reputation signal for inbox placement at Gmail.
Domain reputation changes slowly relative to IP reputation. It is built over months of consistent clean sending and is resistant to rapid decline from a single event. A single high-complaint campaign that sends a Medium-reputation IP to Low reputation may produce only a modest domain reputation impact if the programme's overall sending history is strong. Conversely, domain reputation that has been eroded by sustained poor sending practices over 3–6 months may take 3–6 months of clean sending to recover.
Domain reputation is domain-bound, not IP-bound. When sending IPs are changed — migrating to new infrastructure, replacing a blacklisted IP, adding new IPs during peak season warmup — the domain reputation carries over. New IPs sending from an established High-reputation domain benefit from that domain's reputation history. This is why domain reputation is considered a more durable and more valuable deliverability asset than IP reputation: IPs can be replaced; domain reputation must be rebuilt if the domain changes.
When They Diverge: Diagnostic Scenarios
The most operationally useful information from Postmaster Tools often comes from the divergence between IP and domain reputation, not from reading either in isolation. The divergence patterns reveal different underlying causes:
Scenario 1: Domain reputation High, specific IP reputation Medium or Low. This pattern indicates an IP-specific problem. The domain's overall sending history is strong, but a specific IP has accumulated worse signals than the pool average — possibly because it was used for higher-complaint list segments, experienced a temporary blacklisting, or had a volume spike relative to its established rate. The remediation: rotate the problematic IP out of production, replace with a warm reserve IP, investigate what made this IP's signals worse than the pool average. Domain reputation is unaffected, so inbox placement for the overall programme is not severely impacted.
Scenario 2: Domain reputation declining, IP reputations stable. This pattern indicates a programme-level problem that spans all IPs. All IPs are sending with similarly problematic signals — the complaint rate, bounce rate, or engagement rate is poor across the entire programme, not concentrated in one IP. The remediation requires programme-level changes: list hygiene, complaint rate reduction, engagement-based segmentation. No IP-level change will resolve a domain reputation decline that has all-IP causes.
Scenario 3: IP reputation Good, domain reputation Medium or Low. This pattern can indicate: the programme recently migrated to new IPs (which are High reputation) but the domain accumulated poor signals during the previous infrastructure period; or a brand new domain where the IP reputation is inheriting the shared infrastructure's established reputation but the domain itself has no history. In the first case, the domain reputation will recover as the new IPs' clean sending history accumulates. In the second case, the domain reputation needs time to build from the clean signals the new infrastructure produces.
Scenario 4: Both domain and IP reputation declining simultaneously. This pattern indicates a sustained programme-wide problem. The complaint rate or engagement rate has been below acceptable levels across all sends for long enough to affect both the aggregate domain signals and the per-IP signals. Both require intervention, but the priority is the domain reputation because it is the primary inbox placement driver. IP-level remediation (replacing IPs) will not help if domain reputation is the constraint.
Table 1 — Postmaster Tools diagnostic scenarios and remediation paths
| Domain rep | IP rep(s) | Likely cause | Primary remediation |
|---|---|---|---|
| High | One IP Medium/Low | IP-specific campaign or event | Rotate out problematic IP; investigate its unique sends |
| Declining | All IPs stable | Programme-level complaint or engagement issue | List hygiene; complaint rate reduction; engagement segmentation |
| Medium | All IPs High | Recent infrastructure migration; new domain | Continue clean sending; domain rep builds over time |
| Both declining | Both declining | Sustained programme-wide poor signals | Immediate list hygiene + complaint rate intervention; domain rep recovery takes weeks |
The Spam Rate Signal: What It Adds to the Picture
In addition to IP and domain reputation tiers, Postmaster Tools shows a domain spam rate — the percentage of Gmail-delivered messages that Gmail users marked as spam. This is the most actionable individual data point in Postmaster Tools because it is a direct measurement of recipient dissatisfaction that feeds directly into the domain reputation model.
The spam rate is reported as a rolling average across recent sends, with some smoothing applied. A single high-complaint campaign will show up as a spike in the spam rate graph, followed by return to the programme's baseline level. A sustained elevated spam rate — consistently above 0.08% for several weeks — indicates that the complaint issue is not campaign-specific but programme-level, requiring list hygiene intervention rather than campaign-level content changes.
Cross-referencing the spam rate graph with the campaign calendar reveals which specific campaigns generated elevated complaints. A spam rate spike that correlates with a specific campaign date points to that campaign's list segment as the complaint source — the specific acquisition source, engagement cohort, or content type that produced the elevated response. This campaign-level complaint attribution is not possible from the spam rate alone (it is an aggregate signal) but becomes possible when the spam rate time series is overlaid with the campaign send calendar.
Minimum Volume Thresholds and the "Not Enough Data" State
Postmaster Tools requires a minimum sending volume to display reputation data — specifically, a minimum number of authenticated messages delivered to Gmail addresses per day. The threshold is not published precisely, but is generally around 1,000 messages per day for domain reputation to display and slightly higher for per-IP data. Programmes sending fewer messages than this threshold will see "Not enough data" in the reputation sections.
"Not enough data" is not a negative signal — it simply means Gmail hasn't accumulated enough signal volume to display a reliable reputation tier. A domain that sees "Not enough data" is not being penalised; it has no reputation history in Gmail's displayed model. If the volume threshold is crossed consistently, a reputation tier will appear based on the accumulated signals. The reputation tier that appears may be surprising if the low-volume sends have been to low-quality list segments — the first reputation display may show Medium or Low based on the engagement signals from whatever volume has been processed.
For newly warmed IPs, the "Not enough data" state is normal for the first 3–5 weeks of warmup, depending on the volume ramp. As volume increases through the warmup schedule and the IP begins delivering meaningful volume to Gmail, IP reputation data will appear. The progression from "Not enough data" to a displayed reputation tier is a warmup milestone that operators should track — it confirms that the IP has reached the minimum threshold where Gmail is evaluating its signals, which is a prerequisite for building the High reputation that produces the best inbox placement outcomes.
Reading the Authentication Section: DMARC Pass Rate
Postmaster Tools includes an authentication section that shows the percentage of messages from the domain that passed DMARC, DKIM, and SPF authentication. This section is less prominent than the reputation sections but provides critical context for diagnosing reputation problems. A domain with declining reputation that also shows declining DMARC pass rate has an authentication dimension to its problem that must be resolved alongside the reputation dimension.
The DMARC pass rate in Postmaster Tools is computed differently from the DMARC aggregate report pass rate. Postmaster Tools computes it over the messages Gmail has received from the domain, while DMARC aggregate reports compute it over the messages Gmail has seen from all sources sending with the domain in the From: header. Significant differences between the two may indicate that Gmail is seeing traffic from sources that are not reporting to the DMARC aggregate. This discrepancy is worth investigating to identify unauthenticated sending sources that DMARC aggregate reports may be missing.
The authentication section serves as a quick sanity check: if DKIM pass rate drops below 99% in Postmaster Tools while domain reputation is stable, there may be an authentication configuration drift affecting some messages without yet impacting reputation. Catching this early — through the authentication section monitoring — allows remediation before the authentication failures accumulate into a reputation impact.
How to Use Postmaster Tools for Weekly Monitoring
The operational cadence for Postmaster Tools monitoring: weekly review of domain reputation tier (has it changed from the previous week?), weekly review of spam rate trend (is it higher or lower than the previous week's average?), weekly check of DMARC pass rate (is it above 99%?), and biweekly check of IP reputation for each registered IP (are all IPs at the expected tier?). Monthly review of the authentication section for any DKIM or SPF pass rate changes.
The weekly review takes approximately 15 minutes for a single sending domain with 3–8 IPs. The most valuable practice is comparing each week's values to the previous week and recording the comparison — maintaining a simple spreadsheet with domain reputation tier, spam rate (weekly average), DMARC pass rate, and any IP reputation changes allows trend identification that a single point-in-time view cannot provide. A spam rate that has been 0.04% for eight consecutive weeks and moves to 0.06% in week nine is a trend signal that weekly point-in-time checking without comparison would miss.
The action protocols that should be documented and ready before a Postmaster Tools signal appears: what to do when domain reputation moves from High to Medium (investigate spam rate trend, FBL complaint data, and recent campaign performance data for the past 30 days to identify the cause), what to do when a specific IP moves from High to Medium (investigate what unique campaigns or list segments were sent from that IP), what to do when DMARC pass rate drops below 97% (DMARC aggregate report analysis to identify which source is failing alignment). Having these protocols documented in advance means the response to a reputation signal is executed within hours of detection rather than after the investigation of what to do first.
Domain Reputation Recovery: Realistic Timelines
Domain reputation recovery is one of the most frequently underestimated timelines in deliverability management. Operators who address a domain reputation problem (implementing list hygiene, reducing complaint rates, improving engagement) often expect to see domain reputation recover within 2–4 weeks. The actual recovery timeline is typically 6–12 weeks for a domain that has declined from High to Medium, and 12–24 weeks for a domain that has declined from Medium to Low or Bad.
The slow recovery is a feature, not a bug, of the reputation model. If reputation could be rapidly improved, it could also be rapidly gamed — spam operations would make short-term reputation improvements to deliver a burst of spam before reputation declines again. The slow recovery timeline rewards sustained legitimate sending over time rather than temporary improvements that don't reflect genuine programme quality changes.
During the recovery period, inbox placement remains constrained by the current reputation tier. A domain recovering from Medium to High will see inbox placement improve gradually as the domain approaches the High tier boundary, but the full High-tier inbox placement advantage is not available until the recovery is complete. This makes early detection and early intervention the most commercially valuable deliverability practice — catching a domain reputation that is softening at Medium and preventing it from declining to Low avoids the 12–24 week recovery timeline that a Low-to-Medium recovery would require. Postmaster Tools weekly monitoring with trend tracking is the mechanism that catches these early softening signals.
Understanding the distinction between IP reputation and domain reputation — and using both signals for their specific diagnostic value rather than treating them interchangeably — is the operational practice that makes Postmaster Tools maximally useful as a deliverability management tool. Both signals are real, both are influential, and both require specific remediation approaches that differ based on which signal is degrading and what the divergence between them reveals about the root cause of the degradation.
The Postmaster Tools API: Programmatic Access to Reputation Data
Gmail Postmaster Tools provides an API that enables programmatic access to the same data available in the web interface — domain reputation, spam rate, IP reputation, and authentication metrics. The API uses OAuth 2.0 authentication and returns data in JSON format suitable for ingestion into monitoring dashboards and alerting systems. Organisations with multiple sending domains can query all domains through a single API integration rather than manually checking each domain's web interface weekly.
The API is the correct integration approach for any monitoring system that consolidates deliverability data from multiple sources — Postmaster Tools, SNDS, FBL complaint rates, and accounting log metrics — into a single dashboard. With the Postmaster Tools API, domain reputation and spam rate can be retrieved daily and compared against previous values, with automated alerting when any metric crosses a configured threshold. This automates the weekly review process described above and ensures that reputation changes are detected within 24 hours rather than at the next manual review.
The API data includes the same fields as the web interface — domain reputation tier, spam rate (daily and weekly aggregates), IP reputation tiers for registered IPs, and authentication pass rates. One important nuance: the API returns reputation data only for dates with sufficient volume, and the data lag is typically 1–3 days from the actual sending date. Monitoring systems that query the API must account for this lag and not interpret the absence of data for the most recent days as a data collection failure — it is the expected delay in Gmail's reputation data pipeline.
For the purposes of operational monitoring, the API integration produces monitoring that is superior to manual web interface review in every dimension: it checks daily rather than weekly, it produces automated alerts rather than depending on human observation, it maintains historical data in a format that enables trend analysis, and it scales to any number of domains without proportionally increasing monitoring effort. The initial API integration investment — typically 1–2 days of engineering time — pays returns in the form of earlier signal detection across every week of the programme's operation thereafter.
Postmaster Tools in the Broader Monitoring Context
Postmaster Tools provides Gmail-specific reputation signals — it says nothing about Yahoo, Microsoft, or other ISP relationships. A domain with High Gmail reputation may have Yellow SNDS status at Microsoft or elevated complaint rates at Yahoo. Using Postmaster Tools without also monitoring SNDS and FBL data provides an incomplete picture of programme health that can miss significant ISP-specific problems that are not visible in Gmail signals.
The complete monitoring stack uses Postmaster Tools for Gmail reputation and spam rate (daily via API), SNDS for Microsoft IP status (twice weekly via web export), and FBL complaint data for Yahoo and Microsoft JMRP (processed in real-time by the FBL daemon). Each source covers a different ISP and provides different signal types that together produce the full picture of the sending programme's reputation across the ISPs that constitute the bulk of consumer email volume.
Postmaster Tools is the most sophisticated and most directly interpretable of these signals for the Gmail audience, which makes it the anchor of the monitoring stack. When Postmaster Tools shows stable High domain reputation, the programme is performing well for Gmail. When it shows declining domain reputation, the programme has a problem that will affect inbox placement at Gmail regardless of what the other ISP signals show. The specificity and directness of the Postmaster Tools signal — particularly domain reputation tier and spam rate — make it the single most important monitoring data source available to email operators, and the correct starting point for any deliverability investigation or ongoing monitoring practice.
Infrastructure Assessment
Our managed infrastructure includes Postmaster Tools registration and daily monitoring for all client sending domains and IPs, with weekly trend analysis that identifies divergence between IP and domain reputation signals and triggers specific investigation protocols based on the divergence pattern. Request assessment →