A form of abuse where an attacker uses a legitimate service workflow to send unwanted messages through a trusted sender. The service is not compromised in the usual sense, but its normal communication path is exploited to bypass filtering and make the message look more credible.
What Relay Spam Is in Practice
Relay spam is abuse of a trusted service workflow, not a classic service compromise. The attacker exploits an ordinary sending path so unwanted messages inherit the sender’s legitimacy and are more likely to pass filters or evade scrutiny.
That distinction matters because the security problem is often the workflow itself: a system can behave exactly as designed and still become a delivery channel for abuse when trust, forwarding, or automation is too permissive.
How Relay Spam Works as a Trust-Boundary Abuse
Relay spam usually depends on a legitimate sender, approved integration, or normal business process that is repurposed to deliver content the recipient never intended to receive. The message may originate from a service, application, ticketing system, notification platform, or other trusted workflow, which gives it a better chance of reaching inboxes or downstream users.
The abuse is effective because defenders often tune controls around obvious spoofing and direct sender impersonation. When the message comes through an allowed path, filtering logic, allowlists, reputation systems, or user trust can all be turned into part of the delivery chain.
This is why relay spam sits closer to trust-boundary abuse than simple bulk emailing. The underlying issue is not just volume, but the misuse of a permitted communications path to launder legitimacy into the message.
Operational Controls That Matter
Defending against relay spam requires thinking about how a trusted workflow can be misused, not just whether the service is “secure.” Controls that constrain who can trigger outbound messages, what content can be sent, and how much volume any single workflow can emit are central to reducing abuse.
Message origin, sender reputation, approval paths, and rate limits all become important because they reduce the chance that a legitimate channel can be turned into a spam relay. Strong monitoring also helps distinguish normal service traffic from unusual bursts, abnormal recipients, or content that does not match the service’s intended purpose.
When a service is integrated with other systems, the security posture of the whole chain matters. A legitimate relay can be abused through weak approvals, overbroad permissions, exposed automation, or misconfigured delivery rules even when the mail or messaging platform itself is behaving correctly. For related identity and control patterns, see EmeraldWhale Git config credential theft, which shows how trusted cloud material can be turned into abuse at scale.
Why Relay Spam Is Hard to Spot
Relay spam is difficult because it often looks like normal service output. Security teams may see an approved sender, valid authentication, and a message path that appears operationally legitimate, even though the business use case is being exploited.
That creates a detection problem: the signal is rarely “unauthenticated spam,” but instead an anomaly in volume, recipient pattern, message intent, or workflow behaviour. In practice, the best detection programs compare message activity against expected business purpose, not just technical sender validity.
Reviewing the broader control plane also helps. Service workflows, automated notifications, and delegated sending paths can all be legitimate, but if they are not bounded tightly enough they become a convenient abuse channel.
Risk and Threat Considerations
Relay spam creates a trust abuse risk because recipients, filters, and even internal governance processes may treat the message as more credible than it deserves. That can increase delivery success, reduce user skepticism, and create a foothold for phishing, fraud, or malware-adjacent social engineering when the relayed message is used as a trusted carrier.
Failure mechanism: A permitted communication workflow is repurposed to send content outside its intended business context, so the sender’s legitimacy substitutes for message trustworthiness.
Impact: Organisations can see reduced filter effectiveness, damaged sender reputation, user confusion, and higher exposure to downstream abuse through a trusted channel.
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 CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Relay spam exploits a trusted delivery boundary to reach recipients. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Abuse of a legitimate relay is best detected through anomalous workflow and message activity. | |
| AC-6 — Least Privilege | Relay abuse often follows from overbroad permissions to send or trigger messages. | |
| Recommendation — Constrain outbound message paths and segment trusted senders from broad relay capability. Review logs for unusual sender, recipient, and volume patterns that indicate relay abuse. Limit who and what can initiate trusted outbound messages to the minimum required. | ||
| CIS Controls v8 | CIS-5 — Account Management | Controlling who can use service workflows helps prevent trusted sender abuse. |
| Recommendation — Restrict and review accounts or services that can send on behalf of trusted systems. | ||
| MITRE ATT&CK | T1657 — Acquire Infrastructure: Botnet | Trusted relays can be abused to distribute unwanted or malicious messaging at scale. |
| Recommendation — Correlate relay abuse with infrastructure used to scale delivery and investigate the originating workflow. | ||
Practitioner Guidance
Why practitioners should care: Relay spam is a workflow-control problem as much as a messaging problem. If a service can send on behalf of a trusted sender, the security question is whether that capability is bounded to a narrow, auditable purpose.
What to watch for: Pay attention to unusual recipient expansion, message bursts, or content that is technically valid but inconsistent with the service’s normal business function. Those patterns often signal that a legitimate relay path is being abused rather than broken.
Practitioner takeaway: The strongest defence is not just blocking spam at the perimeter, but tightening the trust relationship that makes the relay believable in the first place.
Related resources from NHI Mgmt Group
- Why do permissive outbound email relay settings create such a high spam abuse risk?
- What are the signs that outbound email relay is being abused for spam campaigns?
- What happens when outbound relay settings are too permissive and spam actors find a working path?
- How should security teams reduce NTLM relay risk in Active Directory?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 13, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org