Open Relay Tester
A real open-relay test requires an SMTP probe — which browsers cannot perform. This tool runs the DNS-side posture check (MX, A/AAAA, PTR, FCrDNS, ISP-host heuristics) and renders the exact telnet sequence you run yourself to complete the SMTP-level verification.
What an open relay actually is
RFC 5321 §3.6 defines a mail relay as a server that accepts a message and forwards it onward. A closed (legitimate) relay only forwards mail for its own users or authenticated senders. An open relay accepts any MAIL FROM and RCPT TO from any client without authentication — and was the primary spam delivery vector through the early 2000s.
Modern mail server defaults block this behaviour, but misconfiguration still happens — leftover test sites, one-off admin scripts, mail-gateway appliances with permissive ACLs, devices reachable from the public internet with default credentials. A single open relay on your network can land your entire IP range on the Spamhaus Policy Block List in under an hour.
Why this tool can't actually test SMTP
The honest answer is browser limitations. The web platform gives a page exactly two ways to make a network request: HTTP/HTTPS (via fetch, XHR) and WebSocket. Neither can open a raw TCP connection to port 25 of an arbitrary host. So the MAIL FROM:<outside@example> / RCPT TO:<another-outside@example> sequence that proves a server is or isn't an open relay has to come from your terminal, not our browser.
What we can do over Cloudflare DoH: resolve every MX record for the domain, look up A/AAAA, reverse-resolve PTR, check FCrDNS (forward-confirmed reverse DNS), and flag MX hosts that look like generic ISP or residential infrastructure (a common smoking-gun pattern for misconfigured or compromised relays). That is the posture check above. The actual SMTP probe is the telnet recipe under each MX card.
How to read the SMTP response
Run the telnet sequence against each MX. Watch the response to the second RCPT TO (the external recipient):
| SMTP code | What it means | Verdict |
|---|---|---|
250 OK / 250 2.1.5 | Recipient accepted | Open relay confirmed — the server is accepting mail to a domain it does not own. |
550 5.7.1 relay not permitted | Recipient refused | Closed relay (expected behaviour). |
553 5.7.1 sender address rejected | Server rejected the sender first | Strong SPF / sender-domain policy. Closed relay; try again with a sender from the server's own domain. |
454 4.7.1 client was not authenticated | Server requires AUTH | Closed relay. Authentication is the gate; relay is only available to credentialled clients. |
What the DNS posture flags mean
- Missing PTR — the IP has no reverse DNS record. Gmail, Outlook, and most large receivers reject mail from PTR-less IPs outright. Cannot be open relay if nothing sends to it, but the misconfiguration is its own problem.
- FCrDNS mismatch — the PTR resolves to a hostname that, when forward-resolved, does not return the original IP. Treated as 'identity unverifiable' by most receivers and downgrades sender reputation.
- Generic ISP / residential hostname — patterns like
1-2-3-4.dynamic.cox.netorpool-72-x.dsl.example.netindicate the IP is consumer infrastructure, not dedicated mail hosting. Legitimate mail rarely originates here — and when it does, it is most often a compromised home device being used as a relay by malware.
If you find an open relay
- Identify the responsible MTA — postfix, exim, sendmail, an appliance, a mail gateway product.
- Lock down the relay configuration. Postfix:
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination. Exim: review theacl_smtp_rcptACL. - Check the IP against Spamhaus Blacklist Check — if you were an open relay for any length of time, you are likely already listed.
- Submit delisting requests to every blocklist the IP is on (Spamhaus SBL, CBL, Barracuda, SORBS, etc.). Most require evidence of the fix.
What this tool will become
We have a roadmap entry to expose the SMTP probe behind a backend endpoint so the full MAIL FROM / RCPT TO check runs server-side. Until that ships, the telnet recipe is the honest path — and it has the bonus of letting you run the probe from your own egress IP rather than ours (which can matter for ACLs that gate by client IP).
Get the full picture with DMARCguard
Continuous monitoring, aggregate report parsing, and actionable insights for all your email authentication protocols.
Start Free