Self-Hosted Mail Servers Email Verification

A self-hosted domain publishes MX records that point at hostnames the organization controls, typically something like mail.example.com, mx.example.com, or a pair of numbered hosts on the company's own network. There is no shared vendor fingerprint to match against, which is the first thing that distinguishes this category from a hosted platform. Mailthentic identifies a self-hosted domain by the absence of a known provider signature in the MX chain, then falls back to reading the SMTP banner and the responses themselves.

What the SMTP conversation looks like

Verification opens a normal SMTP session, greets the server, declares a null sender, and issues RCPT TO for the address being checked. It then stops. The session is closed before DATA, so no message body is ever transmitted and nothing arrives in anyone's inbox.

What comes back depends on how the mail transfer agent was built and configured:

• Postfix with a local recipient table or an LDAP lookup will usually answer an unknown address with 550 5.1.1 User unknown. That is a definitive negative, and Mailthentic treats it as one.
• Exim installations often perform recipient callouts or verify against a local user database, and typically produce a similar 550 for an address that does not exist.
• Zimbra generally validates recipients at the edge and rejects unknown mailboxes during the SMTP transaction.
• Microsoft Exchange on-premises depends heavily on whether recipient filtering is enabled. With it enabled, unknown addresses are rejected during RCPT TO. With it disabled, Exchange accepts the address and generates a non-delivery report later, which is invisible to a probe.

Greylisting is the norm here, not the exception

Of every category Mailthentic verifies, self-hosted servers are the most likely to greylist. A greylisting policy answers an unfamiliar sender with a temporary deferral and asks it to come back later, on the theory that spam software will not bother. The relevant codes are 421, 450, and 451. None of them is a failure and none of them says anything about whether the mailbox exists. They are a request to retry. Mailthentic retries with a backoff instead of writing the address off, and only makes a decision once the server gives a real answer or the retry budget is exhausted.

Rate limiting shows up in the same numeric range. A small server may accept a handful of connections and then start deferring, which is the same request to slow down. Backing off and retrying is the correct response, and treating those deferrals as bounces is how clean lists get destroyed.

Catch-all and what a result really means

Some administrators configure a catch-all so that mail to any local address is delivered somewhere rather than rejected. Mailthentic detects this by probing the domain with a random address that could not plausibly exist. If the server accepts it, the domain is catch-all, and from that moment no individual mailbox on that domain can be confirmed by SMTP, because the server will say yes to everything. That verdict is reported as accept-all, not as valid.

So a result on a self-hosted domain carries exactly the weight of the evidence behind it. A 550 means the mailbox does not exist. A clean acceptance on a domain that rejected the random control address is a genuine signal that the mailbox is real. An acceptance on a catch-all domain is a statement about the server's policy and nothing more.

Self-hosted domains reward patience and punish aggression. The server on the other side is often a single machine run by one administrator who watches its logs, and it will defend itself long before a hosted platform would.

Verify at a pace the server can absorb

• Keep concurrency per destination low. One connection at a time to a given host is plenty, and it is the difference between getting answers and getting throttled.
• Expect deferrals and let the retry logic run. A 421, 450, or 451 is a temporary condition, so an address that produced one has not been judged yet. Re-check it rather than treating it as bad.
• Do not re-probe the same domain repeatedly after a deferral in the hope of a different answer. Greylisting is timed, and hammering it looks exactly like the behavior it was designed to stop.

Reading the verdicts

Invalid. A 550 on a non catch-all self-hosted domain is about as reliable as verification gets. Suppress the address and remove it from the list.

Accept-all. The domain answered yes to a random control address, so it will answer yes to anything. This is a statement about the configuration, not about the person. The address may well be fine, but SMTP cannot tell you. Judge it on other evidence: where it came from, whether it is a role account such as info@ or sales@, whether it has ever engaged, and how old it is. Send to accept-all addresses in small, isolated batches with close bounce monitoring rather than folding them into a large campaign.

Unknown. The server never gave a usable answer, usually because it kept deferring or refused to talk within the retry window. This is not a verdict. Queue the address for a later re-check before you make any decision about it, and keep it out of a send that a fresh bounce would damage.

Protecting deliverability when you mail these domains

• Warm up gradually. A small in-house server that suddenly receives a large volume from a sender it has never seen is likely to defer or reject the whole run.
• Honor deferrals in your sending stack the same way you do in verification. Retrying too fast is a classic path onto a local blocklist.
• Keep your authentication in order. SPF, DKIM, and DMARC alignment carry real weight with administrators who tune their own filters, and many of them reject outright on failure.
• Process bounces promptly. On a catch-all domain, the bounce is the only place the truth ever appears, so feed it straight back into suppression.