Email receiver test

Test how your domain receives mail — the way a real sending server experiences it. The domain security check reads your DNS records; this test makes an actual SMTP connection to your MX and checks delivery on the wire: is a mail exchanger reachable, does it offer STARTTLS, is the recipient accepted at RCPT, does it accept any address (catch-all), does it accept postmaster@, is greylisting active? The catch-all, postmaster and open-relay checks stop at RCPT (no message body); then one signed proof message is delivered through the full DATA stage to exactly the address you proved you control — and nowhere else — to confirm that real mail arrives end-to-end.

You prove control first. To make sure we only ever probe a domain that belongs to you, we ask you to send us one email from the domain you want to test. That email is authenticated (SPF against the real connecting IP, or an aligned DKIM signature); we then run the delivery test against exactly the address you sent from — never an address you type in. No signup, no tracking; the proof address is single-use and expires, and the report lives only in memory for a short while.

What it checks

MX reachability

Every mail exchanger is resolved and connected to on port 25 in preference order, exactly as a sending server would — including Null MX (RFC 7505) and the implicit A/AAAA fallback.

STARTTLS offered

Does each reachable MX advertise STARTTLS? A single cleartext-only exchanger drags the whole domain down, because senders fall back to the weakest MX. Full TLS/DANE grading is in the main scan.

Recipient accepted

Whether your MX accepts the recipient at the RCPT stage (250), temporarily defers it (4xx) or rejects it (5xx) — the real “does mail arrive here?” signal. This check stops at RCPT.

Catch-all

A random, non-existent recipient is probed: accepting it (250) means the domain is a catch-all — more spam exposure and no early rejection of invalid mail.

postmaster@

RFC 5321 §4.5.1 requires every mail-receiving domain to accept postmaster@. We check that it does — a small but real compliance signal.

Greylisting

A 4xx temporary deferral at RCPT is the signature of greylisting. Legitimate senders retry and get through; we surface it so a slow first contact is not a surprise.

Open-relay hint

After an external sender, a RCPT to a foreign domain should be refused (RFC 2505 / BCP 30). If it is accepted, we flag a possible open relay — no message is ever relayed.

Delivery confirmed

Finally, one signed proof message is delivered through the full SMTP DATA stage to exactly the address you proved control of — never a third party — so you learn whether real mail arrives end-to-end, not just whether RCPT is accepted. The message carries an opt-out (reply or abuse@).

Want to test the mail you send instead? Use the email sender test. New to these mechanisms? The mail server TLS & DANE guide explains the transport side.