Mail server not reachable on port 25

Port 25 is not the port your mail client uses

This trips people up constantly, so it is worth separating clearly before anything else.

Port 25 - server-to-server relay. When Gmail delivers a message to your domain, it looks up your MX records and connects to those hosts on port 25. This connection is not authenticated. Any mail server on the internet can open it, because that is how mail works. It is the port this check tests, and the only one that matters for receiving mail.

Port 587 - submission (RFC 6409). For a mail client authenticating to its own provider to send outbound mail. Requires authentication and normally upgrades to TLS via STARTTLS.

Port 465 - submission over implicit TLS. The connection is encrypted from the first byte rather than upgraded mid-session.

The practical consequence: "my email works fine, I can send and receive in Outlook" tells you nothing about this finding. Your client talks to your provider on 587 or 465. Inbound mail from the rest of the world arrives on 25. Those are different paths through different firewall rules. The common cloud advice to "use 587 instead" does not apply here - that advice is about sending mail out, not receiving it.

What the check actually does

DNSAudit resolves your MX records, opens a TCP connection to each MX host on port 25, and waits for the SMTP greeting - a 220 banner. A host counts as reachable only when that banner arrives. A socket that opens and then stays silent does not count.

That distinction is deliberate. A TCP connect succeeding tells you something is listening, not that it is a mail server. Tarpits, misconfigured load balancers, and services that happen to occupy port 25 all accept a connection and then do nothing useful. Requiring the banner is the difference between "the port is open" and "a mail server answered."

Two honest limitations. This is one connection from one vantage point at one moment. A pass means the host answered at that time - not a guarantee of deliverability from every network. A fail can occasionally be transient: re-run the scan before treating a single failure as conclusive, particularly if only one host in a multi-MX set failed.

How this finding is rated

The severity depends on what the probe could establish, and the confidence it can reach:

• Primary MX answers, backup does not → Informational. Mail is flowing. The concern is a stale backup record, but the check cannot prove takeover risk on its own.
• No MX answers, egress confirmed working, stable across a retry → Warning with an explicit from-our-vantage-point caveat. This is the honest ceiling for a single external probe.
• Egress self-test failed → check reported as unavailable. This finding is never raised because the scanner could not get out.

Reading a partial failure

If your domain has several MX records and only some answered, that is usually more informative than a total failure. MX records carry priorities, and senders try the lowest number first:

• Lowest-priority host answers, higher-numbered backup does not - mail still flows and nobody notices. That backup is the classic stale record: it was a real server once, the service moved, and the DNS entry stayed.
• Primary does not answer but a backup does - mail is flowing through your fallback path right now, and the primary has probably been down longer than anyone realised.
• Hosts from one provider answer, hosts from a previous provider do not - you are looking at an incomplete migration.

When a dead MX becomes a security finding

A stale MX record pointing at a host that no longer serves mail is a delivery problem first. Whether it is also a security problem depends entirely on what happened to the hostname.

If the hostname still resolves and simply is not listening, the exposure is limited. If the hostname stopped resolving because the underlying domain lapsed or the cloud resource was released, then whoever picks it up next inherits a position in your mail path. Every sender that falls through to that MX will hand them mail addressed to your users. That is the same class of problem as a dangling CNAME pointing at a deprovisioned service - applied to mail rather than web.

This is why the check sits alongside the authentication checks rather than under plain availability. SPF, DKIM, and DMARC control who can send as you. A reclaimable MX is about who can receive as you.

Diagnosing it yourself

Test from a network that permits outbound port 25 - this rules out most cloud instances (see the next section). Start by listing what senders actually see:

dig +short MX example.com

Then connect to one of those hosts. swaks is the cleanest tool for this:

swaks --server mx1.example.com --port 25 --quit-after CONNECT

openssl shows the banner and whether STARTTLS is offered:

openssl s_client -connect mx1.example.com:25 -starttls smtp

Plain telnet is enough if you only need to know whether the port opens:

telnet mx1.example.com 25

Check IPv6 separately if the host has AAAA records - a host reachable over IPv4 and broken over IPv6 is a real and reasonably common failure, and senders with working IPv6 will try it first:

dig AAAA mx1.example.com
# Then test the IPv6 address directly

Connection refused immediately - nothing is listening, service is down or bound to the wrong interface. Connection hangs until timeout - a firewall is dropping packets silently. Connection opens but no banner - something occupying the port that is not a mail server, or a deliberate tarpit. Your test succeeds but DNSAudit reports unreachable - re-scan first, then consider whether something is treating scanner traffic differently (rate limiter, reputation-based block).

Outbound port 25 is blocked on most cloud platforms

This is the single most common reason a port 25 test gives a misleading answer, and it affects your own diagnosis as much as any scanner.

Cloud providers block outbound port 25 by default because a compromised instance with unrestricted 25 is an ideal spam relay. The details differ by provider and change over time, but broadly: Google Cloud blocks connections to external port 25 from VMs. AWS blocks outbound 25 on EC2 instances and Lambda by default. Azure blocks outbound 25 for most subscription types.

Ports 587 and 465 usually stay open on these platforms, which is exactly why the "just use 587" advice is so widespread and why it confuses this particular diagnosis.

The practical consequence: if you test from a cloud VM and every MX on the internet appears unreachable, the problem is your test environment, not the internet. Confirm before drawing conclusions by connecting to a mail host you know is healthy. DNSAudit applies the same logic to itself: before probing your MX hosts, the scanner verifies its own outbound port 25 works by connecting to a known-good control host. If that fails, the check reports as unavailable rather than marking your mail servers as failing.

Fixing it

1. MX points at a host that should no longer receive mail - remove or correct the record. While you are in there, check whether anything else still references that hostname, particularly SPF includes and MTA-STS policy mx: lines.
2. Host should be live - work outward: confirm the mail service is running and bound to the right interface and address family, confirm the host firewall allows inbound 25, confirm the network firewall or security group does the same.
3. Provider blocks inbound 25 by policy - that is a conversation with them. If they will not lift it, that host cannot serve as an MX.
4. Domain does not receive mail at all - publish a null MX (RFC 7505) rather than leaving stale MX records in place. A single MX record with priority 0 and a target of . states explicitly that the domain accepts no mail.