Remediation Guides

How to Fix an Open Mail Relay (MTA Open Mail Relaying Allowed, Nessus 10262)

26 September 2026 8 min read

An open mail relay is an SMTP server that accepts mail from anyone and forwards it to any outside domain, which lets spammers send through your server and your IP reputation. Scanners report it as “MTA Open Mail Relaying Allowed”. Fix it by allowing relay only for trusted IP ranges and authenticated users, then retest from outside.

What the scanner is actually detecting

An open relay test is simple in principle. From the scanner’s address, the check opens an SMTP session and tries to address a message from a domain your server does not handle to a recipient in another domain it does not handle. If the server accepts that recipient instead of refusing it, the finding fires.

  • Nessus plugin 10262, “MTA Open Mail Relaying Allowed” (family: SMTP problems). Tenable rates it High (CVSS v3 base 7.5, CVSS v2 base 10.0). The synopsis is simply that an open SMTP relay is running on the remote host, and the plugin references CVE-1999-0512, CVE-2002-1278 and CVE-2003-0285.
  • Greenbone (OpenVAS) runs an equivalent check titled “Mail relaying”. The underlying condition and the fix are the same.

The result is relative to where the scanner sits. A relay that is meant to accept mail from an application subnet will correctly “fail” this test when the scanner is inside that subnet.

Real-world risk, stated honestly

This is not a code execution bug, and nobody reads your mailboxes through it. Tenable’s CVSS v3 vector scores confidentiality and integrity impact as none and availability as high, which matches what actually happens: someone else uses your server.

  • Spam and phishing through your IP. Microsoft’s Exchange documentation notes that an open relay masks the original source of messages and that open relays are eagerly sought out by spammers.
  • Blocklisting. Tenable lists bandwidth consumption and the risk of your server being blacklisted. Once your outbound IP is listed, legitimate mail from the whole organization can start bouncing.
  • More convincing forgeries. If the relay’s IP is in your domain’s SPF record, forged mail using your domain as the envelope sender will pass SPF checks at the receiver.

An Internet-facing open relay should be fixed immediately. An internal-only one is lower priority, but it still lets any compromised workstation send mail as anyone. Knowing which SMTP listeners are really reachable from outside is part of scoping your external attack surface.

How to confirm it on the host

Test from a network that should not be allowed to relay, such as a cloud VM. Use a sender and recipient in domains the server does not handle. With swaks, stop after the recipient so no message is actually sent:

swaks --server mail.example.com --from probe@example.org --to probe@example.net --quit-after RCPT

The same test by hand with telnet or nc on port 25:

EHLO test.example.org
MAIL FROM:<probe@example.org>
RCPT TO:<probe@example.net>
QUIT

A 250 reply to RCPT TO means the server will relay for you. A refusal means it will not: Exchange answers 550 5.7.1 Unable to relay, and Postfix answers with a 554 when reject_unauth_destination is in use or a temporary 4xx code with its default defer_unauth_destination. Nmap’s smtp-open-relay script tries a hardcoded set of sender and recipient combinations:

nmap -p 25,465,587 --script smtp-open-relay mail.example.com

Then inspect the server configuration.

Postfix: show the relay settings and any per-service overrides in master.cf (postconf -P needs Postfix 2.11 or later):

postconf smtpd_relay_restrictions smtpd_recipient_restrictions mynetworks mynetworks_style relay_domains
postconf -P | grep -E "relay_restrictions|recipient_restrictions|mynetworks"

Exchange Server (Exchange Management Shell): list the Receive connectors, then find any that grant anonymous users the right to send to any recipient:

Get-ReceiveConnector | Format-List Identity,TransportRole,Bindings,RemoteIPRanges,PermissionGroups,AuthMechanism

Get-ReceiveConnector | Get-ADPermission -User "NT AUTHORITYANONYMOUS LOGON" |
  Where-Object { ($_.Deny -eq $false) -and ($_.ExtendedRights -like "*Accept-Any-Recipient*") } |
  Format-Table Identity,User,ExtendedRights

A hit on a connector whose RemoteIPRanges includes 0.0.0.0-255.255.255.255 is an open relay. So is a connector using the ExternalAuthoritative mechanism with a wide RemoteIPRanges.

How to fix it

Postfix: smtpd_relay_restrictions and a tight mynetworks

Since Postfix 2.10, relay policy lives in smtpd_relay_restrictions, separate from spam rules. Set it explicitly and limit mynetworks to hosts that genuinely need to relay without logging in:

cp /etc/postfix/main.cf /etc/postfix/main.cf.bak
postconf -e "smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination"
postconf -e "mynetworks = 127.0.0.0/8 [::1]/128 10.20.30.0/24"
postfix check
postfix reload

Then look for the usual causes of a relay leak:

  • mynetworks too wide: 0.0.0.0/0, a whole provider range, or mynetworks_style = class, which the Postfix manual warns may trust your entire provider’s network. IPv6 entries go inside square brackets.
  • Proxies and NAT. If a load balancer or port forward rewrites the source address, every Internet client arrives from an internal IP that matches mynetworks. Fix the network path or take that address out of mynetworks.
  • Empty smtpd_relay_restrictions (the backward-compatibility mode) combined with a permit rule placed before reject_unauth_destination in smtpd_recipient_restrictions. The Postfix documentation describes the old combined approach as error-prone.
  • master.cf overrides such as -o mynetworks= or -o smtpd_relay_restrictions= on the port 25 service. A submission service should permit relay only for SASL-authenticated clients.
  • relay_domains listing domains you do not actually handle. Its default is empty since Postfix 3.0.

Exchange Server 2016, 2019 and Subscription Edition

Microsoft’s guidance is to never add relay rights to the default Receive connectors, and to use a dedicated Frontend Transport connector scoped to specific IP addresses instead. An open relay finding usually means one of two things went wrong.

Anonymous relay was granted on an Internet-facing connector. Remove the right (use your own connector identity):

Get-ReceiveConnector "EX01Default Frontend EX01" |
  Remove-ADPermission -User "NT AUTHORITYANONYMOUS LOGON" -ExtendedRights ms-Exch-SMTP-Accept-Any-Recipient

A relay connector is scoped too widely. The new connector wizard starts with 0.0.0.0-255.255.255.255 under Remote network settings, and that entry must be removed. Record the current value, then restrict the connector to the hosts that need it (single IPs, ranges and CIDR are accepted; the new value replaces the whole list):

Get-ReceiveConnector "EX01Anonymous Relay" | Format-List RemoteIPRanges
Set-ReceiveConnector "EX01Anonymous Relay" -RemoteIPRanges 192.168.5.10,192.168.5.11,10.20.30.0/24

Apply the same scrutiny to connectors set up as Externally secured (ExchangeServers permission group with ExternalAuthoritative). Microsoft notes that those hosts are treated as completely trustworthy and bypass antispam checks, so their ranges must be tight.

IIS 6 SMTP service on Windows Server

The legacy SMTP Server feature, managed from IIS 6.0 Manager, is a common source of this finding on application and SharePoint servers. In IIS 6.0 Manager, right-click the SMTP virtual server, choose Properties, open the Access tab and click Relay under Relay restrictions. Select Only the list below and add the specific IP addresses or subnets that must relay. “All except the list below” with an empty list relays for everyone. Microsoft removed the SMTP Server feature from Windows Server 2025, so treat this as a stopgap and plan a move to a supported MTA.

Exim

The default Exim configuration only relays for hosts in relay_from_hosts and for authenticated clients, and its RCPT ACL rejects any other domain that is not in +local_domains : +relay_to_domains. Keep the host list narrow and make sure that require statement has not been removed or preceded by a broad accept:

hostlist   relay_from_hosts = 127.0.0.1 : 10.20.30.0/24

You can test the policy without sending mail: exim -bh 203.0.113.10 runs a fake SMTP session as if from that address.

How to verify the fix and rescan

  1. Repeat the external swaks or telnet test. RCPT TO for an outside recipient must now be refused.
  2. From an allowed host, such as the application or printer subnet, confirm that relay still works.
  3. Confirm that authenticated submission still works for users and applications that log in.
  4. If the server listens on IPv6 or on other ports (465, 587), test those as well.
  5. Rescan from the same scanner position that raised the finding.

What can break and how to roll back

Tightening relay mostly affects devices that send mail without authenticating: multifunction printers with scan-to-email, monitoring systems, backup software, line-of-business applications and web forms. Before the change, review the SMTP logs (the Postfix mail log, Exchange protocol logs) for clients that send to external recipients, and add the legitimate ones to mynetworks or to the relay connector. After the change, watch the logs for relay rejections from hosts you missed.

Rollback is quick:

# Postfix
cp /etc/postfix/main.cf.bak /etc/postfix/main.cf
postfix reload

# Exchange: restore the recorded ranges on the dedicated relay connector
Set-ReceiveConnector "EX01Anonymous Relay" -RemoteIPRanges <previous values>
# Exchange: re-grant anonymous relay (dedicated relay connector only)
Get-ReceiveConnector "EX01Anonymous Relay" | Add-ADPermission -User "NT AUTHORITYANONYMOUS LOGON" -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient"

Never roll back by re-granting relay on a default Internet-facing connector; move the affected device to the dedicated connector instead.

Common false positive reasons

  • The scanner is inside the trusted range. An internal scanner in mynetworks or in a relay connector’s RemoteIPRanges will see relaying that is intended. Record it as expected, or scan from outside the range.
  • Accept now, reject later. Some filtering gateways accept every recipient during the SMTP conversation and discard or bounce later. A check that judges only by the server’s reply cannot see that, so confirm by checking whether the test message was actually delivered.
  • The IP is not your mail server. Email security appliances, firewall SMTP proxies and load balancers often answer on port 25. The finding belongs to that device’s configuration.

FAQ

What is the difference between an open relay and anonymous relay?

Anonymous relay lets specific internal hosts send to outside domains without logging in, which Microsoft describes as a common business requirement. An open relay extends that to everyone.

Does a default Postfix install allow open relay?

No. Since 2.10 the default smtpd_relay_restrictions ends with defer_unauth_destination, and since 3.0 mynetworks_style defaults to host. Open relays usually come from later edits.

Do SPF, DKIM or DMARC fix an open relay?

No. They help receivers judge mail that claims your domain. They do not stop your server from accepting mail for other domains.

Why does the finding persist after the fix?

Usually the scanner sits inside an allowed range, or another listener (a second IP, IPv6, or another port) still relays.

Tracking this finding across many hosts

Plugin 10262 tends to appear on forgotten application servers as well as the main mail gateway, so a single list helps. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners (Nessus results come in by uploading the exported .nessus file), merges duplicates per scanner and can retest individual Nessus findings to confirm closure after the change.

Sources

SITEY closes the loop, not just the report.Discover, validate, fix and verify in your own infrastructure.

See pricing
← All articles