Domain reputation is a mailbox provider's evolving assessment of email associated with a sending domain. It can influence filtering, throttling, and inbox placement, but there is no single domain-reputation score shared by Gmail, Yahoo, Outlook, and every other receiver.
Domain reputation- What is domain reputation? A provider-specific history, not one universal score
- The better mental model
- What usually changes domain reputation
- Recipient complaints
- Sending to people who did not ask for the mail
- Authentication consistency
- Volume shape
- Traffic mix
- Domain reputation is not complaint rate
- Domain reputation is not deliverability either
- Worked example
- What Domain reputation requires
- A practical Domain reputation rollout
- Common mistakes
- Questions we get asked
- OnVoard's take
What is domain reputation? A provider-specific history, not one universal score
The difficult part is identifying which domain a provider is evaluating. A message can contain a visible From domain, a DKIM signing domain, an SPF / return-path domain, link domains, and other hostnames. Provider tools do not necessarily attribute reputation to all of them in the same way.
The better mental model: provider × domain × stream × time
Treat domain reputation as a set of provider-specific histories rather than a property stamped permanently on example.com. For any investigation, ask 4 questions:
The same domain, different providers, different history
Reputation is evidence scoped to a provider, a domain identity, a stream, and a time window, not one number.
| Stream | Gmail | Yahoo | Outlook |
|---|---|---|---|
| Promotional newsletter | Degraded this month | Healthy | Unknown, no recent evidence |
| Transactional receipts (separate identity) | Healthy | Healthy | Healthy |
Promotional newsletter
- Gmail
- Degraded this month
- Yahoo
- Healthy
- Outlook
- Unknown, no recent evidence
Transactional receipts (separate identity)
- Gmail
- Healthy
- Yahoo
- Healthy
- Outlook
- Healthy
That model explains why 2 apparently contradictory observations can both be true. Gmail may show poor outcomes for a domain while Yahoo remains healthy. A promotional subdomain can deteriorate while a separately authenticated transactional stream remains stable. Reputation can also recover after behavior changes, but not necessarily immediately.
What usually changes domain reputation
Mailbox providers do not publish complete scoring formulas, and their systems can change. Public guidance nevertheless exposes recurring inputs.
Recipient complaints
When people repeatedly mark a stream as spam, that is direct evidence that recipients do not want the mail. High complaint rates can damage filtering outcomes even when authentication is perfect.
Yahoo's current guidance explicitly tells senders to keep spam complaint rates below its published threshold and enroll DKIM domains in its Complaint Feedback Loop. Gmail exposes user-reported spam data in Postmaster Tools.
Sending to people who did not ask for the mail
Permission and list quality affect complaints, inactivity, and invalid-recipient behavior. Both Gmail and Yahoo emphasize opt-in and easy unsubscribe in sender guidance.
Authentication consistency
A stable authenticated domain gives receivers a durable identity to evaluate. Broken DKIM, SPF, or DMARC does not merely fail a compliance checklist; it can make it harder to attribute legitimate history consistently and can create rejection or filtering problems.
Volume shape
A new or quiet domain that suddenly sends a large burst has less established history than a mature domain with predictable volume. Gmail advises senders to increase volume gradually rather than producing sudden spikes.
Traffic mix
If newsletters, lead-generation campaigns, receipts, and password resets all share the same authentication identity, poor behavior in one stream can make diagnosis harder. Separating traffic where operationally appropriate gives you cleaner accountability and reduces the chance that one risky program dominates the same identity history.
Domain reputation is not complaint rate
Complaint rate is one input, not the reputation itself. Gmail's documentation gives a particularly useful counterexample: its displayed spam rate can appear low when Gmail is already placing a significant amount of your mail in spam. Fewer messages arrive in the inbox where recipients can manually mark them as spam, so the measured complaint rate can fall while reputation remains poor. That means this inference is unsafe: > "Spam complaints are low, therefore domain reputation is healthy." The correct question is whether provider-specific evidence, delivery errors, complaint trends, authentication health, and recipient behavior tell a coherent story.
Domain reputation is not deliverability either
A healthy domain identity improves your odds, but it is one input among many. Providers can still filter a particular message because of IP behavior, content, URLs, recipient-level preferences, authentication failures, rate patterns, or other anti-abuse signals.
Yahoo's sender FAQ is explicit that reputation is multifactorial and that good reputation does not guarantee inbox placement. That is the right conceptual boundary: reputation is an assessment input, while deliverability is the observed outcome of the whole sending system.
Worked example
A retailer sends:
From: [email protected]DKIM: d=email.store.exampleReturn-Path: [email protected]
- A campaign to an old list causes a complaint spike at Gmail
- The team checks a generic "store.example reputation" tool and sees nothing alarming. That does not clear the sender. Gmail's evidence is about Gmail recipients and the authenticated identities it observes. The operator should inspect the exact
email.store.exampleauthentication path, campaign complaint data, delivery errors, and the acquisition source for the old list
If the same store sends receipts through d=txn.store.example, the transactional stream may have a different history even though both identities sit under the same organizational brand domain.
The lesson is not that subdomains magically isolate reputation. It is that identity scope and traffic scope must be explicit before a reputation diagnosis means anything.
What Domain reputation requires
Do not assume the visible From: domain and the domain shown in a reputation tool are identical. Google's Postmaster documentation historically states that its Domain Reputation dashboard displays messages sent from the exact domain used for DKIM and SPF authentication. Google also explains that Postmaster data can be viewed in different authentication contexts, and the visible From domain is important for DMARC alignment.
At the same time, Google is transitioning Postmaster Tools to v2. Its current deprecation notice says the legacy Domain and IP Reputation dashboards will be retired and replaced by more actionable tools. That means a glossary page should teach the concept and the identity model rather than promising that a particular reputation chart will exist forever. For operators, the safe habit is to capture the exact values from a real message:
- ```text
From: offers@shop.example Return-Path: bounce@mail.shop.example DKIM-Signature: ... d=mail.shop.example; ... `` Then ask which of shop.example or mail.shop.example` the receiving provider's evidence actually refers to. The fact that the domains are related does not make every dashboard or model collapse them into one number.
A practical Domain reputation rollout
Six steps, in order.
- 01Prove the scopeDo not start with "our domain reputation is bad." Start with: - affected provider; - exact From domain; - exact DKIM
d=domain; - exact SPF / return-path domain; - affected stream; - date the behavior changed. - 02Check authentication before blaming reputationA broken DKIM key, misaligned DMARC path, missing DNS record, or provider configuration error can resemble a reputation problem. Fix deterministic failures first.
- 03Read provider-native evidenceFor Gmail, use current Postmaster compliance, spam, authentication, delivery-error, and feedback-loop signals. Do not build a permanent process around the legacy reputation dashboard because Google has announced its retirement in Postmaster v2. For Yahoo, use Sender Hub guidance and Complaint Feedback Loop data. For Outlook.com, IP-specific evidence is available through Microsoft SNDS, but that is not a domain-reputation oracle.
- 04Compare behavior before and after the dropLook for changes in: - send volume and cadence; - acquisition source; - inactive-recipient targeting; - complaint rate; - bounce and rejection mix; - authentication identity; - URL or domain infrastructure; - campaign type.
- 05Stop the damaging inputIf one list import, campaign source, or stream produced the change, reduce or stop it. Reputation recovery is a result of sustained better behavior, not a DNS incantation.
- 06Rebuild with wanted mailSend to recipients most likely to expect and engage with the mail. Keep volume stable. Make unsubscribe easy. Remove invalid recipients. Monitor provider-specific response rather than assuming recovery follows a fixed number of days.
Common mistakes
- Looking for one universal domain-reputation score
- Assuming the visible From domain is always the domain a provider's reputation view is reporting
- Treating low complaint rate as proof that reputation is healthy
- Treating domain reputation and IP reputation as interchangeable
- Moving to a new subdomain to escape bad practices instead of fixing the behavior that created them
- Assuming perfect SPF/DKIM/DMARC creates positive reputation by itself
- Depending on a provider dashboard without noticing that its interface or metric is being deprecated
Questions we get asked
Is domain reputation shared across Gmail, Yahoo, and Outlook?
No. Each mailbox provider observes its own traffic and applies its own models and policies. A sender can have different outcomes across providers.
Does a new subdomain start with a completely clean reputation?
Do not assume complete isolation. A subdomain creates a more specific identity and can help separate streams, but providers can evaluate related domains, infrastructure, authentication, URLs, and broader behavior. Use segmentation for operational clarity, not as a reputation-reset trick.
Can I see my Gmail domain reputation score in Postmaster Tools?
Google historically exposed Domain Reputation ratings, but its current Postmaster Tools v2 transition says the legacy Domain and IP Reputation dashboards will be retired. Use the current compliance, spam, authentication, feedback, and delivery-error evidence Google exposes rather than treating one old rating as permanent product behavior.
Is domain reputation more important than IP reputation?
Neither is universally "more important." They are different identifiers. A receiver can use both, plus recipient behavior and other signals. Diagnose the identifier that matches the failing traffic.
How long does domain reputation take to recover?
There is no universal recovery timer. It depends on the provider, severity, volume, and subsequent sending behavior. Stop the harmful input, send wanted mail consistently, and measure provider-specific outcomes over time.
OnVoard's take
The phrase "domain reputation" is useful only after you name the provider and the exact domain identity. Without that scope, it becomes a vague explanation for every deliverability problem.
For operations, keep a sender identity map beside your campaign data: visible From domain, DKIM domain, SPF / return-path domain, IP or pool, stream, and provider. That makes reputation a diagnosable history instead of a superstition.
Every app on every plan. Connect your store and switch on the flows in an evening.