Email list hygiene without SMTP mailbox probing

List hygiene means keeping only addresses that work and belong to people who want your mail. The tempting shortcut — asking each receiving server whether a mailbox exists — does neither reliably, and it can damage the reputation you are trying to protect. This guide explains why, and what works instead.

How mailbox probing works

Probing-based “email verification” opens an SMTP connection to the domain’s mail server, goes as far as naming the recipient, and disconnects without sending anything:

S: 220 mx.example.net ESMTP
C: EHLO probe.example.com
S: 250 mx.example.net
C: MAIL FROM:<check@example.com>
S: 250 OK
C: RCPT TO:<alice@example.net>
S: 250 OK                      ← read as "mailbox exists"
C: QUIT

A 250 reply is taken to mean the mailbox exists, a 550 5.1.1 that it doesn’t. The VRFY command was designed for this question, but RFC 5321 lets sites disable it for security reasons, in which case the server answers 252 — “cannot verify, but will accept the message” — which tells you nothing.

Why the answer is unreliable

• Catch-all domains accept every recipient during the SMTP conversation and sort things out later, so every address looks valid.
• Deferred checks. RFC 5321 itself notes that when a server decides whether an address is valid only after the message data arrives, the RCPT reply may carry no information at all. Such a server accepts the message and sends a bounce afterwards.
• Greylisting and rate limits answer unknown clients with temporary 4xx replies (RFC 6647). The probe gets “try again later”, not an answer.
• Defences against harvesting. Because RCPT replies can be used to collect valid addresses, some operators make them deliberately uninformative for unknown clients.
• Existence is not consent. A mailbox that exists may be abandoned, belong to someone who never signed up, or be a spam trap. Traps are real addresses that accept mail, so probing reports them as valid.
• Answers expire. A mailbox that exists today may be closed next month.

Why it can hurt you

Connections that name many recipients and never deliver a message look like a directory harvest — the kind of address collection RFC 5321 discusses when it explains why sites restrict VRFY and EXPN. Receiving systems may slow down, reject or block the IP that does it, and it can end up on blocklists. If that IP or domain is the one you send from, you pay with your deliverability.

Third-party verification services run probes from their own infrastructure, so the risk is theirs, but the answers have the same limits. That is also why correct.email’s tools check syntax and DNS, never whether a mailbox exists.

What to do instead

1. Validate syntax at the point of entry

Reject what can’t be an address, and flag likely typos while the person is still on the form. Check against the SMTP mailbox syntax — RFC 5321, extended to UTF-8 by RFC 6531: one @ before the domain, a local part of at most 64 octets, a whole address of at most 254 octets, and a domain made of valid labels. Avoid strict regular expressions that reject real addresses; how to validate email addresses covers the details.

The email syntax validator runs these checks on a single address or a pasted list, handles internationalized domains, flags role addresses and suggests fixes for common domain typos.

2. Check that the domain can receive mail

A well-formed address at a domain that accepts no mail is still dead. Look up the domain’s MX records with the MX lookup:

• MX records present — the domain accepts mail.
• No MX, but A or AAAA records — under RFC 5321 the host itself acts as an implicit MX. Delivery is possible but less certain.
• Null MX — a single MX 0 . record (RFC 7505, see null MX) says the domain accepts no mail. Reject.
• The domain doesn’t exist — reject; it is usually a typo.

example.net.     3600  IN  MX  10 mx1.example.net.
parked.example.  3600  IN  MX  0 .

A DNS timeout or server failure is not a verdict. Accept the address and let the confirmation step decide. More on reading MX results: troubleshooting MX records.

3. Confirm with double opt-in

The only reliable proof that an address works and belongs to the person who typed it is that they act on a message sent to it. Send a confirmation email with a link or code, and add the address to your mailing list only after it is used. Google’s sender guidelines ask senders to confirm each recipient’s address before subscribing them, and Yahoo recommends double (confirmed) opt-in to reduce invalid recipients.

Double opt-in also keeps out typos, bots and people signing up someone else’s address. Expire sign-ups that are never confirmed instead of mailing them again and again.

4. Handle bounces automatically

A bounce is the receiving server’s answer to a real delivery attempt — the information probing tries to obtain without sending anything.

	Hard bounce	Soft bounce
SMTP reply	5xx (permanent failure)	4xx (temporary failure)
Typical enhanced codes	5.1.1 mailbox doesn’t exist, 5.1.2 bad destination domain, 5.1.10 null MX	4.2.2 mailbox full, 4.7.x policy or rate deferrals
What to do	suppress the address immediately	let your server retry; suppress after repeated failures

Three details matter in practice:

• Not every 5xx is about the address. Codes in the 5.7.x range (RFC 3463: security or policy) usually mean the receiver rejected you — authentication, reputation or content. Fix the cause instead of deleting the recipient.
• Mailbox full is defined as a transient condition, but some servers report it as 5.2.2. An address that is full for weeks is probably abandoned.
• Bounces also arrive later, as delivery status notifications sent to your envelope sender (Return-Path). Process those, not only the replies during the SMTP session.

The providers are explicit: Google recommends automatically unsubscribing recipients who have multiple bounced messages, and Microsoft’s Outlook.com policies say that after a permanent failure the sender must not retry, and after multiple non-delivery responses must stop sending to that recipient. What individual codes mean: email bounce codes.

5. Remove complainers and honour unsubscribes

Feedback loops such as Yahoo’s Complaint Feedback Loop and Microsoft’s Junk Email Reporting Program tell you who marked your mail as spam. Suppress those recipients immediately, and process unsubscribe requests promptly — ideally with one-click unsubscribe. Someone who can’t leave easily will press “Report spam” instead.

6. Sunset unengaged recipients

Addresses that show no activity for a long time are a risk: they may be abandoned, and abandoned addresses can be turned into spam traps. Set a sunset policy:

1. Define inactivity in terms of your sending frequency — a daily newsletter can decide sooner than a quarterly one.
2. Send a re-permission message (“Do you still want these emails?”). Google suggests periodically confirming that recipients want to stay subscribed, and Yahoo suggests reconfirming inactive subscribers.
3. Remove those who don’t respond.

Opens are a weak signal. Apple’s Mail Privacy Protection, which the Mail app offers to switch on when it is first opened, downloads remote content in the background regardless of whether the person engages with the message, so an “open” may not be a read, and image blocking hides real reads. Prefer clicks, replies, purchases and logins.

7. Treat role addresses with care

Addresses such as info@, sales@ or support@ (RFC 2142 lists conventional role mailbox names) usually reach a shared inbox, a group or a ticketing system rather than one person who subscribed. For transactional mail they are fine — invoices to billing@ are normal. For marketing, ask for a personal address or require confirmation. The syntax validator flags role addresses.

8. Suggest typo fixes, don’t apply them silently

At entry, offer a correction (“Did you mean gmail.com?” for gmial.com) and let the person accept it. Don’t rewrite addresses in your database automatically: a domain one letter away from a large provider may be a real domain.

9. Never buy, rent or scrape lists

Google’s guidelines tell senders not to purchase addresses. Such lists are where dead addresses, spam traps and complaints concentrate, and no cleaning step turns them into consent.

A routine that keeps a list clean

• At sign-up: syntax check with typo suggestions, domain check, confirmation email.
• On every send: process bounces, complaints and unsubscribes automatically; keep suppressed addresses suppressed.
• Periodically: review engagement, send re-permission messages, remove those who stay silent.
• Before mailing an old list: don’t send to all of it at once — treat it like a warm-up, starting with the most recently active addresses.