Free Email Diagnostic Tools, Grouped by What They Inspect
Twelve free single-purpose diagnostics for addresses, mail domains, authentication records and sender reputation. Each is grouped by what it actually inspects, so you can pick one from the symptom you are seeing rather than the cause you already suspect.
The twelve tools on this page each answer one narrow question, which is exactly what you want when something has gone wrong and you do not yet know why. They divide into two jobs. Some inspect infrastructure you control — your DNS records, your mail server, your sending IP — and are the ones to reach for when your own mail is bouncing or landing in spam. The rest inspect an address or a domain that somebody else gave you: a signup, a purchased lead, a form submission you are not sure is genuine. Working out which side of that line you are on immediately narrows twelve tools down to three or four.
It helps to picture a delivery as five stacked layers: the format of the address, the DNS records published for its domain, the mail server those records point to, the authentication that proves the message is genuinely from you, and the reputation of the IP it was sent from. A failure at any one of them looks identical from the outside — the message does not arrive — but the fix is completely different at each layer. These tools are arranged in the same order a full verification runs: cheap local checks first, DNS second, a live SMTP conversation last. Running an email syntax check before a DNS lookup costs nothing and rules out the single most common cause, which is a typo.
Mapping symptoms to tools is the fastest way through the list. Mail landing in spam is an authentication and reputation question: start with the DMARC record checker to see whether you publish a policy at all, then the SPF record checker for the 10-DNS-lookup limit that quietly invalidates records as you add sending services, then the DKIM record checker for the selector actually signing your mail. Is this one address real? runs in the other direction — syntax, then the MX record checker for the domain, then the catch-all detector to find out whether a definitive answer is even possible. Senders reporting that mail to your domain bounces is almost always missing MX records or a closed port, which the MX checker and the SMTP connection tester settle between them.
Two limits shape what any of this can settle. The first is that a live SMTP conversation returns evidence rather than proof: a server that accepts every recipient it is offered, including a random address that cannot exist, has told you nothing about the mailbox you actually asked about. Recognising that wall is the whole job of the catch-all detector, and it is why the risk scorer sits beside it, weighing domain age, disposable status, catch-all behavior, blacklist entries and the shape of the local part into a single 0-to-100 score you can set a threshold against when a clean yes or no is not on offer. The second limit is that every answer here is a point-in-time reading — DNS records drift as sending services are added, blocklist entries appear and clear, and a domain that checked out last quarter proves nothing today — so a check that has to run continuously, on every signup at the moment it happens, belongs in the verification API rather than a browser tab.
Working with the address itself
These four need nothing but the address string and what is already known about its domain, so they return an answer without waiting on a mail server. Use them as the first pass on a signup, a lead, or a block of raw text you need addresses out of.
- Email Syntax Checker Validate email format.
- Email Extractor Extract emails from text.
- Disposable Email Detector Detect temporary emails.
- Email Risk Scorer Score email risk level.
The domain and its mail servers
Once an address looks well formed, the next questions are whether its domain can receive mail at all, whether the server is reachable on the usual ports, and whether it will answer honestly about individual mailboxes. These three inspect the receiving side of the connection.
- MX Record Checker Lookup mail server records.
- SMTP Connection Tester Test SMTP connections.
- Catch-All Detector Detect catch-all domains.
Your authentication records
The three DNS records a receiving server consults to decide whether a message genuinely comes from the domain it claims, and whose verdicts that server then writes into the Authentication-Results header of the delivered message. A broken record here is one of the most common reasons legitimate mail gets quietly filtered rather than bounced outright — the message is accepted, just not into the inbox.
- SPF Record Checker Validate SPF records.
- DKIM Record Checker Verify DKIM records.
- DMARC Record Checker Check DMARC policy.
Diagnosing mail that already failed
When a specific message was filtered or a whole IP stopped delivering, these two work backwards from evidence rather than from configuration: the headers each server wrote as the message passed through, and the public blocklists a receiver consults before accepting anything.
- Email Header Analyzer Parse email headers.
- Blacklist Checker Check IP/domain blacklists.
Each tool here answers one question about one target, so when you need syntax, MX, SMTP, disposable and catch-all checks applied to every row at once, upload the file to the bulk email verifier instead.
Clean a full listTools FAQ
Read the headers of a message that really was delivered, rather than re-reading your own configuration. The record checkers tell you what your domain publishes; the header analyzer tells you what the receiver did with it, because the Authentication-Results header carries the SPF, DKIM and DMARC outcomes exactly as that server evaluated them — which is where a technically valid record that does not actually cover the service you send from finally shows up as a failure. In Gmail you open the message, choose Show original and copy the whole block; the Received headers stack bottom-to-top into the route the message took with a timestamp at every hop, and many filters add their own X-headers carrying the score behind the decision. The earliest Received header also gives you the originating IP, which is the value to paste into the blacklist checker when authentication comes back clean and the filtering still needs explaining.
The email verifier returns one combined verdict per address; these tools expose a single layer in isolation, which is what you need when you are debugging rather than cleaning a list. Several of them have no verification equivalent at all — the header analyzer, the SMTP connection tester and the blacklist checker inspect messages, servers and IP reputation rather than mailboxes. The trade-off is that each one handles a single target per run, so any list of real size belongs in the bulk verifier instead.
Most of them, yes, because they read data that is public by design. SPF, DMARC and MX records are published in DNS for any server to query, and blacklist listings are deliberately open so that senders can find and appeal them, which is why checking a prospect's or a supplier's domain works normally. There are two exceptions. The DKIM checker needs a selector name, which cannot be discovered from DNS alone and usually has to come from a message the domain has sent or from its provider's setup documentation; the header analyzer likewise needs the full headers of a message you actually received.