Skip to main content
SMTP

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 codeWhat it meansVerdict
250 OK / 250 2.1.5Recipient acceptedOpen relay confirmed — the server is accepting mail to a domain it does not own.
550 5.7.1 relay not permittedRecipient refusedClosed relay (expected behaviour).
553 5.7.1 sender address rejectedServer rejected the sender firstStrong SPF / sender-domain policy. Closed relay; try again with a sender from the server's own domain.
454 4.7.1 client was not authenticatedServer requires AUTHClosed 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.net or pool-72-x.dsl.example.net indicate 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

  1. Identify the responsible MTA — postfix, exim, sendmail, an appliance, a mail gateway product.
  2. Lock down the relay configuration. Postfix: smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination. Exim: review the acl_smtp_rcpt ACL.
  3. Check the IP against Spamhaus Blacklist Check — if you were an open relay for any length of time, you are likely already listed.
  4. 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