Cold Email Infrastructure

    Blacklist Domain Name Checks: Which of Your Domains Got Listed, and Why

    Four of your domains are tested during one delivery, at three separate moments. A clean sending domain is not a clean bill of health when the body carries a link.

    Editorial illustration for Blacklist Domain Name Checks
    August 17, 2026Updated August 16, 20267 min read
    Share:
    The short answer

    A domain blocklist lists names rather than addresses, and receiving servers test several of yours in one delivery: the reverse DNS name, the HELO hostname, the envelope sender domain, and every domain appearing in the body. A listing frequently belongs to a link shortener or tracking domain rather than to the sender.

    Key takeaways

    • Spamhaus publishes three checkpoints for its Domain Blocklist: the reverse DNS name at connection, the HELO string and Mail From domain in the pre-data phase, and every domain in the headers and body during content inspection.
    • SURBL's Multi dataset filters on links in the message body regardless of the sending IP address, which is why a clean sending domain does not settle the question.
    • RFC 5782 notes there is no agreed wildcard convention for name-based lists, so a clean sending subdomain says nothing definitive about the root domain.
    • A domain listing survives every change of sending infrastructure, which makes prevention through separate sending domains and one purpose per domain cheaper than any remedy.

    Reviewed and updated August 16, 2026

    Blacklist Domain Name Checks: Which of Your Domains Got Listed, and Why

    A sending domain checks clean on every list a free tool queries. The sending address behind it is clean too. Mail still gets refused at a large share of recipients, and the reason turns out to be a link shortener in the message body that somebody else abused two months ago. Nothing that belongs to the sender was ever listed, and the campaign was blocked anyway.

    Domain blocklists work differently from the address-based lists most checkers lead with, and the difference is not cosmetic. They test a different identifier, at different moments in the conversation, for different reasons. A domain blacklist check that does not specify which domain it is checking is answering an incomplete question.

    Domain lists are a distinct mechanism, not a variant

    RFC 5782 describes both kinds. Address-based lists encode an IP by reversing its octets and appending the list's zone. Domain-name lists, which the specification says are sometimes called right-hand-side blacklists, put the domain name itself in front of the zone: if the list is doms.example.net and the domain to be listed is invalid.edu, the entry is named invalid.edu.doms.example.net, carrying an A record and a TXT record read the same way as in an address-based list.

    The RFC adds two observations that shape how these behave in practice. Name-based lists are far less common than address-based ones, and there is no agreed convention for wildcards among them. The absence of a wildcard convention is the reason a subdomain and its parent are not interchangeable in a lookup, and it is why checking a sending subdomain clean tells you nothing definitive about the root.

    Four of your domains are tested in one delivery, at three different moments

    This is the part that reorganises the whole diagnosis. Spamhaus publishes, on its own Domain Blocklist page, the points in the filtering process at which the DBL should be consulted:

    • At the initial connection, against the domain associated with the connecting IP via reverse DNS.
    • Through the pre-data phase of the SMTP transaction, against the HELO string and the Mail From domain.
    • After the message data has been accepted, during content inspection, by looking up domains appearing in the mail headers and body, including URLs and contact email addresses.

    Read that as a list of your assets rather than a list of checkpoints. The reverse DNS name of your sending host, the name your server announces in HELO, the envelope sender's domain, and every domain that appears in your body copy are four separate identifiers, frequently under four different owners, any one of which can be the listed one. Only the second and third are usually what a sender thinks of as "my domain".

    1. Step 1Connection

      The domain resolved from the connecting IP by reverse DNS

    2. Step 2HELO

      The hostname your sending server announces itself with

    3. Step 3Mail From

      The envelope sender domain, which is where bounces are returned

    4. Step 4Content inspection

      Every domain in the headers and body, including link and tracking domains

    The points at which a receiving server can test a domain against a blocklist, per Spamhaus's published guidance for its Domain Blocklist.

    What the major domain lists actually list

    Section illustration: What the major domain lists actually list

    Spamhaus's published policy statement for the DBL describes it as a list of domain names with poor reputation, published in a domain DNSBL format, with reputation calculated from a range of observed domain behaviours. The list, it says, includes domains used in unsolicited bulk email including phishing, fraud and malware distribution, and those with poor reputation on a broad set of heuristics. Spamhaus's stated argument for running it alongside the address-based lists is that senders willing to invest in evading address-based detection are caught by domain-based detection instead.

    SURBL approaches the same territory from the content side. Its publicly provided Multi dataset, in SURBL's own description, lists domains of malicious or abused web sites, and can be used to filter or tag unsolicited messages based on links in the message body regardless of sender IP addresses. That last clause is the whole reason a clean sending address is not a clean bill of health.

    The practical difference between the two families is durability. An address is a lease. Move to different infrastructure and the listed address stops being yours, which is a real if expensive remedy. A domain is an identity you chose and printed on everything, and its standing follows it across every infrastructure change. Our glossary entry on domain reputation works through the same stickiness on the private-score side, and the two behave alike: easy to damage, slow to rebuild.

    Address-based listingThe connecting IP
    • Tested at connection, before any content exists
    • Frequently an address your provider owns, not you
    • Remedy can include moving infrastructure
    • Delisting routes are published per list operator
    Domain-based listingA name in the transaction or the body
    • Tested at HELO, at Mail From, and again during content inspection
    • Can be a domain you do not control, such as a shortener
    • Survives every change of sending infrastructure
    • Remedy starts with removing or replacing the named domain
    Address listings and domain listings differ in what is tested, when, and what a remedy costs.

    The three domains that get senders listed by proxy

    Link shorteners. SURBL publishes a shortener domain list covering, in its description, major services from bit.ly and t.co through to minor hobbyist shorteners, plus a separate list of specific abused shortener URIs. A shortened link puts a shared, heavily abused domain into your message body in place of your own. The reputation you inherit is the aggregate of everyone else using that service, and you have no route to influence it.

    Tracking and redirect domains. An open-tracking or click-tracking domain appears in the body of every message, which makes it the single highest-frequency domain in your sending, and on shared tracking infrastructure it is shared with every other customer of the same platform. It is worth knowing whether yours is dedicated before a campaign, not after.

    Newly delegated domains. SURBL's Fresh dataset lists domains recently added to top-level domain zone file delegations, and SURBL's own framing of why is worth quoting for what it concedes: younger domains are more likely to be abusive, so delegation age can be used as one of multiple factors indicating domain reputation, and while not all new domains are bad, many bad domains are young. Cold outbound runs on domains bought for the purpose, which places every new sending domain on the wrong side of that correlation for a while. The answer is not to avoid new domains. It is to accept that a new domain has no accumulated evidence in its favour and to spend the first weeks producing some, through gradual volume and clean sending, rather than proving the heuristic right.

    When the listed domain is not yours

    Section illustration: When the listed domain is not yours

    A domain listing you did not cause is the common case in outbound, and it changes the order of operations. There is no delisting request to file, because the request would have to come from whoever owns the listed name, and a shortener operator has no reason to prioritise one customer's campaign.

    The fix is removal rather than appeal. Take the named domain out of the message and resend to the unattempted portion of the audience. A shortener is replaced by a full link on a domain you control. An abused partner or client site referenced in the copy is replaced with a different reference, or with no link at all, which is frequently better copy anyway. Shared tracking infrastructure is replaced by a dedicated tracking domain, and that is a platform configuration rather than a campaign change.

    Worth ruling out first: content inspection is the last of the four checkpoints, so a listing found there refuses messages that already passed connection and envelope checks. If the refusals arrive at the connection stage instead, the subject is the connecting address rather than any domain, and the diagnosis belongs with the address-based lists.

    Checking a domain, and staying off

    The mechanical check is the easy half. Query the domain at the operator's own lookup rather than an aggregator, and repeat it for the sending domain, the root domain, the HELO hostname, and every domain that appears in your body copy including the tracking domain and any link destination.

    The preventive half is where the leverage is, and Spamhaus's own best-practice list for maintaining domain reputation is short and specific. It names registrar security services such as registry lock and DNS change monitoring, monitoring DMARC reports for attempts to spoof your domain, restricting outbound SMTP so that port 25 traffic can only originate from your mail server, and ensuring your hostname and HELO match. The DMARC item is the one most cold-email programmes skip, and it doubles as an early-warning channel: reports arrive whether or not anything is wrong, which is what makes an unusual pattern visible. Which DMARC policy to run while sending cold email covers the choice that sits underneath it, and SPF, DKIM and DMARC for cold email covers getting the three aligned in the first place.

    Check every one of these, not just the sending domain
    • Yes: The reverse DNS name of the connecting host
    • Yes: The HELO hostname your platform announces
    • Yes: The envelope Mail From domain, which is often a subdomain you did not choose
    • Yes: Your root domain as well as the sending subdomain, because wildcard behaviour is not standardised
    • Yes: Every link destination in the body, including shorteners and partner sites
    • Yes: The click and open tracking domain, and whether it is dedicated or shared
    The domains to check when a domain blocklist listing is suspected, in the order they get tested during delivery.

    What a listing does and does not tell you

    Section illustration: What a listing does and does not tell you

    A confirmed domain listing is a specific, published statement with a specific remedy, and the delisting path per operator, along with the diagnosis that should precede any removal request, is covered in email blacklist check and recovery.

    The more common outcome of a careful check is that nothing is listed and delivery is still poor. That is a reputation problem rather than a blocklist problem, it is a private score no operator publishes, and it responds to sending behaviour over weeks instead of to a form. Email domain reputation and the architecture that holds at volume is the relevant read, and how to improve domain reputation step by step covers the recovery.

    The structural answer, which is cheaper than either remedy, is to arrange things so a listing can never reach the domain that matters. Sending domains stay separate from the corporate domain, one purpose per domain so that outbound cannot contaminate transactional mail, and spare warmed capacity so a single bad domain is replaced rather than rescued.

    If you would rather start with infrastructure built that way, we plan the first campaign for free.

    Standards and vendor documentation references verified as of August 2026. Verify current terms with the vendor before relying on them.

    Questions

    Frequently asked questions.

    Frequently asked questions
    How do I check if my domain is blacklisted?
    Query it at the list operator's own lookup rather than an aggregator, and repeat the check for each identifier separately: the sending domain, the root domain, the hostname announced in HELO, and every domain that appears in your body copy including the tracking domain and any link destination. Any one of them can be the listed name.
    Why is my domain blacklisted when my IP address is clean?
    Because they are different lists testing different things at different moments. Address lists are consulted when a server connects, before any content exists. Domain lists are consulted again during content inspection, against the names inside the message. A link shortener or a shared tracking domain in the body can trigger a refusal with nothing of yours listed at all.
    Does a link shortener affect deliverability?
    It can, because it substitutes a heavily used shared domain for one you control. SURBL publishes both a list of shortener domains, from major services to minor ones, and a separate list of specific abused shortener URIs. Your message inherits whatever reputation that shared domain has accumulated, and you have no route to influence it.
    Are new sending domains more likely to be blocked?
    Newly delegated domains carry a documented correlation with abuse. SURBL publishes a dataset of recently delegated domains for exactly that reason, while noting that not all new domains are bad even though many bad domains are young. A new domain simply has no accumulated evidence in its favour, which is what gradual volume in the first weeks produces.
    DeliverabilityEmail InfrastructureBlocklistsDomain ReputationCold Email
    Byline

    About the author.

    Tim Carden

    Tim Carden is CMO / CTO at RevenueFlow, which builds and operates outbound revenue engines for B2B companies. Studied at McGill University.

    Tim Carden · CMO / CTO

    Connect on LinkedIn →
    Your next move

    Ready to scale your outreach?

    We build GTM engines that book real meetings. See the receipts.

    Further reading

    Related articles.

    Cold Email Infrastructure

    Blacklist IP Search: What the Lookup Returns, and Whose IP You Are Checking

    The address your browser reports is almost never the one a receiving server refused. What a blocklist lookup queries, and which IP to run it against.

    8 min readRead →
    Cold Email Infrastructure

    Email Bounce Message Examples: Eight Refusals, and Who Owns Each One

    Eight rejections a B2B sender actually meets, each quoted as Google or Microsoft publishes it, sorted by who owns the problem rather than by what the code means.

    7 min readRead →
    Cold Email Infrastructure

    Email Bouncer: What Bouncer Costs, and the Product Split That Trips Up Buyers

    Bouncer sells verification as credits and deliverability testing as a subscription. Here is the full credit ladder, and the product split that catches buyers out.

    7 min readRead →
    Cold Email Infrastructure

    SMTP Ports: What 25, 465, 587 and 2525 Are Actually Registered For

    Three of the four ports in circulation are registered to mail and one is not. What the IANA registry and the RFCs say, and why none of it moves placement.

    8 min readRead →
    Cold Email Infrastructure

    Email Validation APIs: The Five Decisions the Vendor Docs Leave to You

    Wiring an email validation API takes an afternoon. Deciding what a catch-all verdict authorises, and what happens when the endpoint is down, takes longer.

    7 min readRead →
    Cold Email Infrastructure

    Fake Email Bounce Messages: Bounces for Mail You Never Sent

    Non-delivery reports arriving for messages nobody wrote look like a breach and usually are not. The ten-minute test that separates the two, and what actually helps.

    7 min readRead →