What the check actually does
An MXToolbox blacklist check is a batch of DNS queries. Its own page states the scope plainly: the tool “will test a mail server IP address against over 100 DNS based email blacklists”. Each of those hundred lookups follows the same convention, set out in RFC 5782: a listed address answers with an A record in the 127.0.0.0/8 range, an unlisted one answers with nothing, and an optional TXT record carries the reason.
So the result is a read. It reports what a set of publishers said about your address at the moment you asked. It does not tell you what any receiving server will do with that, it grants nothing, and it changes nothing about your next send.
That distinction is the whole reason this page exists rather than repeating the lookup instructions. Almost everybody runs this check after delivery has already fallen over, which means the check is being used to explain an effect that has already happened. The natural next thought is to run it more often. A system that sends continuously could run the same lookup every minute and be no better off, because frequency was never the missing piece. The missing piece is a decision that exists before the answer arrives.
A read is not an authority
We hit this exact problem from the other side, building the endpoint that reports how much sending capacity an account has. It returns a read-only delivery projection, and our own API documentation is deliberately blunt about what it is not: the endpoint never authorizes or reserves a send, the actual send still passes through the single delivery authority, and clients must not calculate headroom from a plan name.
We wrote it that way because agents do the thing a person would never bother to do. A human checks a status and acts on it within seconds. An agent reads a status, holds it, and acts on it later at machine speed, possibly across thousands of messages. A read that gets treated as permission is wrong for the entire window between the read and the act, and at agent volume that window contains a lot of email. So the read admits it is a read, and the decision stays in the send path where it can be made against current state.
A blacklist lookup has exactly the same shape and almost never gets the same treatment. Wire an agent to “check the blacklists before sending” and you have built a gate out of something that was never an authority. No receiver consulted it on your behalf, it authorizes nothing, and it goes stale on a schedule you do not control. The lookup belongs in the same category as the capacity projection: useful to read, dangerous to obey.
What a listing changes now, and what it only predicts
Google's Email Sender Guidelines address blocklists directly, in the section on shared IPs: “Make sure the shared IP address isn't on any internet blocklist. Messages sent from IP addresses on a blocklist are more likely to be marked as spam.” More likely. That is a shift in probability, not a rejection.
Spamhaus, the operator most people mean when they say blacklist, describes the same thing from the publishing side. Once an address is queried against one of their DNS blocklists, the administrator running the mail server “can then choose to either: a. Reject the email in real-time, with an appropriate delivery code, or b. Accept the message and tag it for additional filtering.” The list publishes evidence. Somebody else decides what it is worth.
RFC 5782 records both habits in the field: servers that check “each list in turn until it finds one with a DNSBL entry, in which case it rejects the connection”, and servers where “DNSxL entries are used as inputs to a weighting function that computes an overall score for each message”. Same listing, two completely different outcomes, and the lookup cannot tell you which one you are getting.
What you can read, on your own side, is the outcome. A hard rejection comes back as a bounce carrying the receiver's own diagnostic text, and that is the measurement that settles the question. It is why our suppression records keep the bounded provider diagnostic text retained from the source feedback event rather than only the fact of the failure, and why the suppression list is filterable by reason and by source provider. The bounce tells you what a listing did to you. The lookup only tells you it exists.
The same Google guidance is worth reading for what it does put a number on. The requirements say to keep spam rates reported in Postmaster Tools below 0.30%, and the monitoring section is stricter again: “Keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher.” Complaint rate is a signal you own, you can watch continuously, and you can act on long before any list has formed an opinion about you.
Which lists matter, and why a combined view hides it
Coverage is what makes MXToolbox useful and it is also what makes the result hard to act on. Over a hundred publishers arrive as one column of red and green, which flattens lists that mean entirely different things into a single verdict.
Spamhaus alone publishes six datasets with distinct purposes, and their own guidance is that the datasets are not interchangeable and are not even consulted at the same moment. SBL, PBL and XBL belong at the initial connection. DBL belongs at the content filtering stage. A single row reading “listed” erases a distinction the publisher drew on purpose.
RFC 5782 then puts the choice where it actually sits: “Mail servers typically check a list of DNSxLs on every incoming SMTP connection, with the names of the DNSxLs set in the server's configuration.” The set that matters is the set your receivers configured, not the set your checker happened to query.
Which gives a usable rule. A listing on a list that nobody you send to consults is a data point. A listing on a list your largest receiver consults at connection time is an outage. Neither the tool nor this page can tell you which one you are looking at for your own senders, because that information lives in other people's configuration. What a system can do is stop treating the two as equivalent, and that means deciding in advance, list by list, what an entry is allowed to change.
What happens between the check and the delisting
This is the part almost nobody writes about, and it is where the avoidable damage happens.
Delisting is a publisher-side event. Propagation is not. RFC 5782 leaves the timing entirely to the list's own policy: “The Time to Live (TTL) and refresh times SHOULD be chosen to reflect the expected rate of change of the DNSxL.” It gives the range too, from slow-moving lists where “the TTL might be several days” to lists of addresses observed sending spam that “might change every few minutes”. Receivers are then allowed to hold what they already fetched: long-running mail servers “MAY cache DNSxL data internally, but MUST respect the TTL values and discard expired records”.
So the sequence after a successful removal is not one event. The publisher drops the record, your checker turns green, and some receivers keep answering from their own cache until their copy expires. Your lookup and their answer disagree, legitimately, for a period governed by a policy neither of you wrote.
A person handling this by hand simply waits and re-checks tomorrow, and the gap never becomes visible. An agent sending continuously through that window needs an actual instruction for it, and “the checker says green” is not one. The instruction that works is about volume and evidence rather than about the lookup: keep sending small to receivers you can measure, read the bounce diagnostics coming back, and treat a clean bounce stream as the clearance signal. That is the same principle as the capacity endpoint. Trust the thing that is measured at the moment of the send, not the thing that was reported beforehand.
Deciding before you look
Everything above argues for one conclusion. The check is cheap and the decision is expensive, so the decision has to exist before the check runs. For anyone putting this in front of an agent, four things need settling in writing first.
- Which lists you will act on, named individually, and what each one triggers.
- What acting means in each case: hold the campaign, cut the volume, change nothing and log it.
- What evidence closes the incident. Our answer is the bounce stream, not the lookup.
- Who is allowed to resume, and whether that is a person or the agent.
We built the surfaces so those four answers are expressible rather than aspirational. The suppression list returns hard bounces, soft-bounce suppressions, complaints and manual suppressions together, with the provider diagnostic text attached and filters on reason and source provider, so the evidence is queryable rather than something you scroll. Segments filter on deliverability fields directly, including suppressed, bounced, complained, soft-bounce count and suppression reason, which turns “hold this group” into a definition instead of a note in a runbook. And delivery control is a tool the agent can call to approve, pause or schedule a campaign, so pausing is an action with a gate on it rather than a person remembering to log in.
What we deliberately did not build is an agent that sends on its own read of a status. Sending capacity moves with sender standing, Probation, Standard or Trusted, and the documentation is explicit that history is not copied between domains, so there is no cached fact about an account that stays true across a change of sending context. Generic prompts receive generic results, and a blacklist lookup wired to no decision is a generic prompt in a different medium. The answer comes back, nothing downstream knows what to do with it, and the tab gets closed.
FAQ
What is an MXToolbox blacklist check?
A batch of DNS lookups. MXToolbox states that it tests a mail server IP address against over 100 DNS based email blacklists, and reports which of them hold a record for your address at that moment. It is a read of what publishers say, not a statement about what any receiver will do.
Does a blacklist listing block my email?
Not by itself. Google says messages from an IP on a blocklist are more likely to be marked as spam, and Spamhaus says the receiving administrator chooses between rejecting in real time and accepting the message for extra filtering. The bounce you get back, with its diagnostic text, tells you what actually happened.
Which blacklists actually matter?
The ones your receivers have configured. RFC 5782 notes that the list of DNSBLs a mail server queries is set in that server's own configuration, so the set that affects you is not the set a checker queries. Within a single operator the datasets differ too: Spamhaus applies SBL, PBL and XBL at the connection and DBL at content filtering.
How long after delisting does delivery recover?
Longer than the checker suggests. RFC 5782 leaves TTL and refresh intervals to each list's policy, ranging from several days to a few minutes, and receiving servers may cache the data they already fetched until it expires. Expect a window where your lookup reads clean and some receivers are still answering from cache.
Is continuous blacklist monitoring better than spot-checking?
Only if something downstream is wired to the answer. Checking more often with no pre-agreed response changes nothing except how early you feel anxious. Decide per list what an entry triggers, then the frequency starts to matter.
Go deeper
The lookup was never the hard part
Running a blacklist check is a browser tab and ten seconds. Deciding what a given list is allowed to change about a send in flight, and having that decision execute the same way every time without somebody being awake, is the part that has never had a good answer. We built Nitrosend so the decision lives in the send path rather than in a habit: the evidence is queryable, the audience rule is a segment definition, delivery control is a tool an agent can call from Claude, ChatGPT, Codex or Cursor, and the send itself is authorized at the moment it happens rather than from a status somebody read earlier. Keep the MXToolbox sweep for diagnosis. Do not let it become the gate.