Open Relay is an email server that forwards messages for unauthorised external senders. Attackers abuse it to send spam, phishing, and malware while hiding their own infrastructure. Administrators should restrict relay permissions to approved users and networks, test regularly for accidental exposure, and monitor outbound volume for abuse.
What an open relay is in email routing
An open relay is an email server that will forward messages for outside senders without proper authorisation. The core issue is not simple forwarding, but the absence of a meaningful relay boundary, which turns a mail server into an abuse platform.
Why open relays are abused
Attackers value open relays because they can send spam, phishing, and malware through infrastructure they do not own, which helps conceal origin and complicates reputation-based blocking. In practice, the relay becomes part of the attacker’s delivery chain rather than a passive transport system.
This is why outbound mail controls matter as much as inbound filtering. A relay that accepts unauthorised submission can be used to offload volume, test message delivery, and distribute malicious content at scale.
How to determine whether a mail server is exposed
Exposure is usually found by checking mail routing rules, listener configuration, and which source networks are allowed to submit or relay mail. Administrators should compare those settings against the intended user population and confirm that unauthorised external hosts cannot relay through the server.
Testing should include external relay checks, review of SMTP authentication requirements, and validation of any network-based allowlists. If the server is reachable from the internet, its relay policy should be treated as a live control, not a theoretical configuration.
Preventing and containing relay abuse
The strongest control is to permit relaying only for approved users, devices, and networks, then enforce that policy consistently across all mail paths. For broader control alignment, NIST SP 800-53 Rev 5 Security and Privacy Controls provides a useful anchor for access control, authentication, logging, and configuration management expectations.
Compensating controls include rate limiting, outbound volume monitoring, reputation alerts, and alerting on unusual SMTP patterns such as sudden spikes, repeated rejected submissions, or large volumes to unrelated recipients. Mail gateways should also log enough detail to support abuse investigation and post-incident review.
Because relay abuse is fundamentally a trust-boundary failure, NIST Cybersecurity Framework 2.0 is a practical reference for organising protection, detection, response, and recovery around email infrastructure.
Risk and Threat Considerations
Open relays create direct abuse risk because they let external actors use an organisation’s mail infrastructure to distribute spam, phishing, and malware. They also create reputational damage, delivery blacklisting, and investigation overhead when the server’s traffic profile reflects attacker activity rather than legitimate business use.
Failure mechanism: The relay accepts unauthorised outbound mail, so the attacker inherits the server’s reputation and network reach while keeping their own infrastructure hidden.
Impact: Organisations can see service abuse, domain reputation loss, increased incident response burden, and downstream compromise attempts delivered through trusted-looking mail.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Open relay exposure is an access decision about who may use the mail service to relay traffic. |
| IA-2 — Identification and Authentication (Organizational Users) | Authenticated submission is central to preventing unauthorised relay use. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Monitoring outbound volume and abuse requires reviewable mail activity records. | |
| Recommendation — Enforce relay permissions so only approved users and networks can submit outbound mail. Require authenticated mail submission for users who are allowed to relay messages. Review mail logs and outbound patterns to detect relay abuse quickly. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity and Access Management | Relay restriction depends on enforcing who can use the mail service to send mail. |
| DE.CM-01 — Networks and services are monitored to find anomalies and events | Outbound volume monitoring is a direct detection need for relay abuse. | |
| Recommendation — Restrict mail relay access to approved identities, devices, and source networks. Monitor SMTP traffic for spikes and unusual recipient patterns that suggest abuse. | ||
| MITRE ATT&CK | T1583 — Acquire Infrastructure | Attackers abuse open relays as borrowed infrastructure to hide sender origin. |
| Recommendation — Map suspicious mail-volume infrastructure patterns to attacker staging and abuse activity. | ||
Practitioner Guidance
What to watch for: Treat open relay checks as a recurring validation step, not a one-time hardening task. Mail routing rules, firewall changes, new VPN ranges, and temporary exceptions can silently reopen relay paths after an otherwise sound configuration.
Practitioner takeaway: If unauthorised external senders can relay, the mail server is already part of the attacker’s delivery infrastructure, so exposure should be treated as an immediate containment issue.