Sender reputation is how receiving systems assess the trustworthiness of your email, including its sending domain and IP address. Check the relevant identity in the affected provider’s diagnostics, then use external scores and blocklist lookups as supporting evidence. A healthy score, passing authentication or an empty dashboard alone does not establish inbox placement.
For permission-based marketing email, start with: which domain or IP, according to which system, for which recipients? Those details turn a vague delivery concern into a check you can repeat.
Domain reputation and IP reputation measure different identities
Domain reputation concerns a sending domain; IP reputation concerns the address used to send messages. Your brand’s website address is not enough to identify everything being assessed. Establish the authentication domain and sending IP used by the campaign you are investigating.
Google’s sending guidelines explain a particular risk of shared IPs: other senders’ activity affects the reputation of the shared address. That makes an IP warning relevant to your provider as well as your own email programme. It does not establish which customer caused the problem.
Authentication and reputation also answer different questions. Setting up SPF, DKIM and DMARC is not a reputation report. Keep the authentication results beside the reputation check rather than treating a successful configuration check as the answer.
What shapes reputation? Validity’s explanation includes complaints, unknown recipients, blocklists, infrastructure and sending-volume fluctuations. These are useful investigation areas, not a disclosed formula for every receiving system. Avoid assigning your own weights or declaring that one metric settles the result. For the broader filtering question, see how AI spam filters decide what reaches the inbox.
If the question is whether to separate different mail streams, the sending-subdomain guide handles that architecture decision.
Choose a check that matches the question
Use provider diagnostics for the recipients you are investigating, with external checks supplying additional context.
| Question | Relevant check | Boundary to retain |
|---|---|---|
| What does Gmail report about this sending identity? | Postmaster Tools compliance, spam, authentication and delivery-error diagnostics; legacy reputation views where available | Personal Gmail data only. The newer interface excludes domain/IP reputation views. |
| What can we inspect for our sending IP at Outlook.com? | Microsoft’s Smart Network Data Services, or SNDS | Individual-IP data requires authorized access. |
| What does an external scoring service report? | Sender Score | A third-party assessment, not a replacement for the affected provider’s evidence. |
| Is this resource on a particular blocklist? | The blocklist operator’s lookup | A result for that checked system, not a universal delivery verdict. |
Microsoft’s current SNDS portal provides individual-IP data for Outlook.com and includes its Junk Email Reporting Program. Access requires a Microsoft Account and authorization for IPs for which you are responsible. Owning the sending domain alone does not grant that access. For a provider-managed shared IP, ask the email provider to investigate the implicated address and relevant diagnostics.
Validity describes Sender Score as a 0–100 measure of email-program and IP reputation calculated using its data network. Retain the identity checked and the date beside the number.
Spamhaus explains that its Reputation Checker checks resources against its DNS blocklists and supplies listing explanations and remediation guidance. A clean lookup means no listing was found in the checked system at that time.
Check Gmail diagnostics in the interface you have
The newer Postmaster Tools interface does not include Domain and IP Reputation dashboards. Google’s migration notice says those views will be retired. As of 6 November 2026, Google had postponed retiring the legacy interface and supplied no retirement date. Record which interface you checked rather than assuming a missing view means missing traffic.
Use the available Compliance status, Spam rate, Authentication and Delivery errors views as diagnostic evidence. They are not substitutes for a domain/IP reputation grade. To inspect the right sending domain, establish and verify it first.
Start with an actual campaign message rather than guessing from the address on your website. In desktop Gmail, open the message and select More beside Reply → Show original to view its full header. Google documents that path here.
Then follow Google’s Postmaster Tools setup:
- Identify the DKIM
d=domain or SPF Return-Path domain used for the outgoing mail. Ask your email provider to identify it if necessary. - In Postmaster Tools, choose Manage Domains → Add new domain, enter that authentication domain, then Create.
- Choose the domain’s More options → Verify domain, copy the supplied TXT or CNAME records, add them through your DNS provider, and return to Verify. Data is not displayed before verification.
- Add a sending subdomain separately if you need its dashboards independently. Google says a verified primary domain removes the need for separate subdomain verification.
Choose the verified domain, an available dashboard and reporting period. Where legacy reputation views are available, Google documents Bad, Low, Medium and High categories. Read those assessments alongside the other diagnostics.
For those legacy reputation views, Google says data comes from DKIM-authenticated messages, falling back to SPF-authenticated messages when DKIM is not used. Match the exact authentication domain being assessed.
Keep the reporting limitations attached: the data covers personal Gmail, uses UTC, and is not real time. Google says updates typically occur within 24 hours, sometimes longer; low-volume days may have incomplete data. Missing data is an information gap, not a favourable rating.
Interpret disagreement before changing your sending setup
Consider an invented example: an external lookup gives your sending IP a healthy score, while an available legacy Gmail reputation view reports poor reputation for the campaign’s authentication domain. The results concern different identities and datasets. Averaging them would produce a number with no useful meaning.
Instead, preserve both observations and investigate the stream experiencing the problem. Use this table to choose a next check; its rows are investigation prompts, not proof of a cause.
| Observation | Check next | Useful next action |
|---|---|---|
| A Gmail reputation view is missing | Whether you are using the newer interface, which excludes it | Use the available diagnostics and record the interface. |
| An available dashboard has no data | Domain selection, verification, authentication domain, reporting period and data availability | Resolve setup or coverage before interpreting silence. |
| A provider reports poor domain reputation | The affected stream’s audience, complaints and sending changes | Choose a specific behaviour or configuration issue to investigate. |
| A shared sending IP has an adverse assessment | The implicated address, campaign time and provider evidence | Give the email provider a concrete support case. |
| A named blocklist reports a listing | The operator’s explanation for that exact resource | Follow the documented remediation process. |
| External results look healthy but delivery trouble continues | Evidence from the affected provider and campaign | Continue the delivery investigation rather than treating the score as clearance. |
A low complaint rate needs context too. Google gives two possible explanations when user-reported spam is low but reputation is poor: its filtering may already route substantial mail to spam, or the domain or IP may still be recovering from poor reputation. Read those observations together before concluding that placement has recovered.
Save a check record someone else can use
Keep a compact record with the campaign or mail stream. A screenshot without the checked identity and reporting period leaves the next person guessing.
| Field | What to save |
|---|---|
| Sending identity | Exact domain or IP checked and the campaign it served |
| Recipient scope | Provider or receiving service being investigated |
| Observation | Diagnostic source, result, observation date and reporting period |
| Delivery evidence | Relevant error text, original message or authentication result |
| Follow-up | Specific next check, responsible person and result after the change |
For improvement, Google’s guidance calls for wanted messages, easy unsubscribe and consistent sending, with volume reduced in response to bounces or deferrals. Use the deliverability repair workflow for the full investigation.
Repeat the relevant check after the change and preserve its scope. A better external number can be useful supporting evidence; recovery still needs evidence about the delivery problem you set out to fix.
Is sender reputation the same as Sender Score?
No. Sender reputation is the broader assessment of sending trustworthiness. Validity’s Sender Score is a particular third-party measure on a 0–100 scale describing email-program and IP reputation. It is not a universal grade issued by every mailbox provider or an inbox-placement percentage.
Does a clean blocklist check mean your emails will reach the inbox?
No. It establishes only that the checked resource was not found on the checked blocklist at that time. It does not establish a receiving provider’s own reputation assessment or where that provider will place an individual message.
Sources
- Google, Email sender guidelines
- Validity, Get your Sender Score
- Microsoft, Outlook.com Smart Network Data Services · 22 Sept 2026
- Spamhaus, Reputation Checker: Troubleshoot your listing · 17 Dec 2025
- Google, Learn about the deprecation of the old Postmaster Tools interface
- Google, Trace an email with its full header
- Google, Set up Postmaster Tools
- Google, Postmaster Tools dashboards