An email transfer path that forwards messages from one server or service to another. Organisations use relays for application mail and infrastructure messaging, but poorly secured relay points can become a path for spoofed or unauthenticated email to reach users under a trusted domain.
Expanded Definition
SMTP relay is the mail-handling mechanism that accepts a message from one host and forwards it to another, usually across organisational boundaries or between internal services. In security terms, the concern is not the relay function itself but the trust placed on it: a relay may be legitimate for application mail, yet still become a vehicle for spoofing, abuse, or unauthorised delivery if authentication, allowlisting, and message policy are too loose. Guidance varies across vendors on how much relay openness is acceptable, so practitioners should distinguish between controlled relay for business messaging and open relay exposure that permits arbitrary forwarding. The concept sits close to mail gateway policy, domain authentication, and infrastructure trust, which is why it is often discussed alongside NIST Cybersecurity Framework 2.0 and email security controls.
The most common misapplication is treating a relay as a harmless plumbing component, which occurs when administrators permit broad sender or recipient acceptance without testing how external mail sources can exploit the forwarding path.
Examples and Use Cases
Implementing SMTP relay rigorously often introduces routing and policy complexity, requiring organisations to weigh delivery reliability against tighter sender verification and monitoring.
- An internal business application sends password reset messages through a restricted relay that only accepts authenticated connections from approved hosts.
- A cloud workload uses a relay to deliver alerts and transaction notices, with domain authentication configured so recipients can verify message legitimacy.
- A security team blocks open relay behaviour at the mail gateway after discovering that unauthorised external senders can submit messages through the organisation’s infrastructure.
- An outsourced ticketing platform uses a relay relationship, but the contract requires strict source IP controls, TLS in transit, and logging for incident response.
- A phishing campaign abuses a misconfigured relay to send messages that appear to originate from a trusted domain, prompting remediation of sender policy and recipient validation.
For implementation guidance, teams often pair relay hardening with SPF, DKIM, and DMARC controls, while email administrators use logging and rate limits to spot abuse patterns. The MITRE ATT&CK knowledge base is useful when mapping how adversaries abuse trusted messaging paths, even though it does not define SMTP relay as a governance term. In practice, relay design should support the broader defensive intent reflected in CISA email security guidance.
Why It Matters for Security Teams
SMTP relay matters because it can convert a normal mail workflow into a trust shortcut if authentication, sender validation, and recipient restrictions are not enforced. That creates risk across phishing defence, brand protection, and incident containment: if a relay is too permissive, attackers may bypass user suspicion by sending messages that appear to originate from an internal or partner system. Security teams also need to consider the operational side, because application owners often depend on relay paths for alerts, transactional mail, and identity workflows such as password resets or multi-factor notifications. When relay governance is weak, those business messages become indistinguishable from hostile traffic unless the mail architecture is tightly controlled. The practical response aligns with controls around secure configuration, monitoring, and least privilege in the NIST Cybersecurity Framework 2.0 and with mail-domain protections described in CISA email security guidance.
Organisations typically encounter the real impact only after a spoofed message, abuse complaint, or deliverability incident exposes that the relay was trusted more broadly than intended, at which point SMTP relay becomes operationally unavoidable to fix.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-3 | SMTP relay depends on controlled access to trusted communication paths. |
| NIST SP 800-53 Rev 5 | SC-7 | Boundary protection governs how relays filter and route trusted traffic. |
| ISO/IEC 27001:2022 | A.8.20 | Network security controls support secure mail relay architecture and segmentation. |
Restrict relay access to approved sources and verify authentication before message forwarding.
