Domain Reputation Check: The Two Things That Phrase Means

Search for a domain reputation check and the first page hands you two completely different product categories side by side. Spamhaus and MXToolbox sit next to APIVoid, IPVoid and Cisco Talos, and the two groups are answering different questions. One tells you whether your email is likely to reach an inbox. The other tells a security team whether your domain looks dangerous enough to block at the firewall.

Both are called domain reputation. Running the wrong one is how a sender concludes their reputation is fine while their campaign quietly sits in spam folders, so the first job is knowing which question you are asking.

The two senses, and why the SERP mixes them

Deliverability reputation is a mailbox provider's opinion about whether mail from your domain should be accepted, filtered or rejected. It is built from your own sending behaviour: volume, complaint rates, authentication, and whether recipients engage. Google, Microsoft and the major spam filters each hold their own version, and none of them publishes a single portable score.

Threat reputation is a security vendor's opinion about whether a domain is hosting malware, running phishing, or freshly registered for something unpleasant. It is built from registration data, hosting, certificates, URL scanning and abuse reports. The output is a risk score used to block browsing and inbound traffic.

The overlap that confuses everybody is real: a domain listed on a Spamhaus blocklist appears in both worlds at once. But a clean threat score is not evidence of good deliverability. A brand new sending domain with perfect hygiene and no history will score clean at APIVoid and can still be filtered by Gmail, because Gmail is scoring something the threat tools do not measure.

Deliverability reputationWill my email reach the inbox?

• Google Postmaster Tools, Microsoft SNDS
• Built from your sending behaviour and complaints
• Held privately by each mailbox provider
• What a cold email sender needs

Threat reputationIs this domain dangerous?

• APIVoid, IPVoid, Cisco Talos, WhoisXML
• Built from registration, hosting and abuse reports
• Used to block traffic and inbound links
• Clean here says nothing about placement

BlocklistsBoth, at once

• Spamhaus DBL, SURBL, URIBL
• A listing damages delivery and threat score together
• Public lookup, published delisting process
• Check first when delivery drops suddenly

Google Postmaster Tools, and the caveat that matters for cold email

For mail to Gmail, Google Postmaster Tools is the authoritative surface, and it is free. Google publishes four reputation ratings with its own definitions: Bad means a history of sending a high volume of spam regularly, and mail is almost always marked as spam or rejected. Low means a significant volume of spam regularly. Medium means a history of legitimate email that occasionally sends spam. High means very low spam rates and compliance with Gmail's sender guidelines.

Three things about that dashboard decide whether it is useful to you.

It only sees the authenticated domain. Google's documentation states that the domain reputation dashboard only displays messages sent from the exact domain used for DKIM and SPF authentication. Reputation is scoped to that domain, so eight sending domains mean eight separate dashboards and eight separate reputations.

It goes blank at low volume. The same page notes that to protect the privacy of Gmail users, the dashboard might not include all data on days when outgoing email volume is low. Cold email programmes are built on exactly that shape, with many domains each sending modestly, so a well constructed sending pool can show almost nothing in Postmaster Tools. An empty dashboard is not a good rating. It is no rating.

It is retrospective. The data arrives after the sending, so the dashboard tells you what your reputation became rather than what it is about to be. The forward-looking numbers are your own: bounce rate, spam complaint rate, and how well the list was matched before the campaign started.

Microsoft, and the reason most senders cannot see it

Microsoft's Smart Network Data Services reports at the IP address level and gives complaint data through its Junk Email Reporting Program. Its front page states the position directly: reputation is always the responsibility of the sender.

The catch is in the unit. SNDS reports on IP addresses you control, and a company sending from Microsoft 365 or Google Workspace mailboxes does not control the sending IPs. Those belong to the provider and are shared with every other tenant. If you send from ordinary provider mailboxes, SNDS has nothing to show you, and that is a property of the arrangement rather than a fault to fix.

The practical consequence is that Outlook and Microsoft 365 delivery has to be measured from the outside, with seed addresses at those domains and by watching what bounces back rather than from a dashboard.

The other surfaces, and what each one can actually see

Spamhaus publishes a public domain reputation checker covering its own datasets. A listing there is serious, and it is one of the few checks where the answer is genuinely actionable: there is a documented delisting route once the underlying cause is fixed.

MXToolbox aggregates blocklist lookups plus DNS and mail configuration checks in one report, which makes it the fastest way to find a listing you did not know about. We have written up how to read its output in the MXToolbox deliverability guide.

Threat intelligence services answer the security question. They are the right tool if you want to know whether a domain your team is about to visit is safe, and the wrong tool for diagnosing placement.

Seed testing places a message in real mailboxes at each provider and reports where it landed. It is the only method that measures inbox placement directly rather than inferring it, and it has the weakness that a seed list is not your list.

Monitoring a pool, rather than checking a domain

A single check answers a question you already suspected. Running a sending pool means the question is continuous, and the shape of the work changes.

The unit of monitoring is the domain, because reputation is scoped per domain. A blended number across a pool hides the exact thing you need to catch, which is one domain going bad while the average stays comfortable. Watch bounce rate and complaint rate per domain, per week, and treat a change in the trend as the alert rather than any absolute threshold.

Blocklist status is worth checking on a schedule rather than on suspicion. Listings are usually discovered late, after delivery drops and somebody goes looking, and the delisting clock only starts when you notice. An automated check across every sending domain costs nothing and turns a week of degraded delivery into a day of it.

Google's own working target is a useful line to hold. Its sender guidelines advise keeping spam rates in Postmaster Tools below 0.10% and never reaching 0.30%, which for a domain sending a few hundred messages a week means a very small number of complaints is enough to breach it. That arithmetic is the argument for list quality over sending volume, in one line.

A weekly reputation check that takes ten minutes

• ✓Yes: Postmaster Tools open for every sending domain, not just the main one
• ✓Yes: Blocklist lookup across all sending domains, automated
• ✓Yes: Bounce rate read per domain rather than blended across the pool
• ✓Yes: Complaint rate compared against the 0.10% working target
• ✓Yes: Authentication still passing on every domain, including new ones
• ~Depends: A seed test at each major provider when a trend moves

What the composite scores are actually made of

There is no portable domain reputation score, and our glossary entry on domain reputation makes that case in full: each receiver holds its own private view, and none of them publishes a number you can carry between them. What is worth adding here, since this is the page you land on while holding a checking tool, is what the vendors selling a score out of a hundred are actually measuring, because it is not privileged access to anybody's filter.

A commercial reputation score is an aggregation of public signals: blocklist listings, DNS and authentication configuration, domain age, hosting and registration data, sometimes URL scanning. All of it is observable from outside. None of it includes the two inputs that actually decide placement, which are your complaint rate and your recipients' engagement, because only the mailbox provider can see those and none of them sell the data.

That makes a composite score useful for a specific job: assessing a domain you do not own. Checking a vendor before you route mail through them, or checking a domain a partner wants you to send from, is a legitimate use where public signals are all anybody has. For your own sending domain, you already have better information than any composite, because you can see your bounces and your complaints directly.

The tell that a score is measuring configuration rather than behaviour is how fast it moves. A score that improves the day after you publish a DMARC record is scoring your DNS. Deliverability reputation is built and repaired over weeks of actual sending, and nothing you can edit in a zone file changes it overnight.

When the check comes back bad

A poor rating is a symptom, and the causes are a short list: an unverified or stale list producing hard bounces, a poorly matched audience producing complaints, authentication that was never completed on a newer domain, or volume that climbed faster than the domain's history could support. The recovery path, and what actually moves a rating back, is in how to improve domain reputation.

What a reputation check cannot tell you is whether the list was worth sending to, and that is the input that produces most of the damage. If you would rather have the list and the sending built to that standard from the start, we will build the first campaign with you.

Provider documentation and tool behaviour verified as of August 2026. Verify current terms with the provider before relying on them.