How Unauthorized SMTP Relays Get Created and Detected

An unauthorized SMTP relay is any mail server that forwards email without explicit permission from the domain owner. The server may have been a legitimate mail sender, a web host, a container in a cluster, or a developer workstation and at some point it started forwarding unsolicited mail from unauthorized sources through itself, often without anyone noticing until the abuse reports arrive.

This is a different problem from a compromised account. A compromised account sends mail as the compromised user. An unauthorized relay accepts mail from anyone and forwards it onward, which means the relay's IP address and potentially its domain - appears in the chain of custody for spam, phishing, or sextortion campaigns.

What makes a server a relay

SMTP relaying is built into every mail server. The question is whether the relay is open or authenticated.

An authenticated relay requires the sending client to log in before submitting mail. Only approved users or systems can relay. This is the normal configuration for corporate mail servers and transactional email services.

An open relay accepts and forwards mail from any source, without authentication. In the 1990s and early 2000s this was the default. By the mid-2000s, blacklists of open relay IPs were so effective that running an open relay became a reputation death sentence. Legitimate mail operators closed their relays. The servers that remain open today are mostly compromised systems, misconfigured cloud instances, or IoT devices.

A third-party relay sits in the middle: a legitimate service (a marketing platform, a CRM, a cloud function) that sends email as your domain on your behalf. This is authorized when you configure it, but becomes unauthorized the moment it sends mail you did not approve, either because the service was compromised or because it was misconfigured.

How servers become unauthorized relays

There are three primary paths.

Misconfigured mail services

Postfix, Exim, Sendmail, and Microsoft Exchange all have relay configuration options that must be explicitly restricted. A misconfiguration typically looks like one of these patterns:

The mynetworks or relay_domains setting includes the entire internet (0.0.0.0/0)
The server accepts mail from any source and forwards it without authentication
A test or development instance was deployed without changing default relay settings

Postfix is the most common offender. Its default configuration is actually restrictive, but common tutorials and quick-start guides walk operators through adding mynetworks = 0.0.0.0/0 to get mail flowing then never remove it when the server goes to production.

Exim has a similar pattern: the acl_smtp_connect check defaults to accept in some distributions, and operators unfamiliar with Exim's ACL language leave it at that default.

Compromised credentials

SSH access to a cloud server gives an attacker a shell. From the shell, installing a lightweight SMTP daemon or repurposing an existing one takes minutes. The attacker then uses the compromised server as a relay to send spam or phishing while obscuring the true origin point.

The same logic applies to leaked API keys for cloud provider SMTP services. AWS Simple Email Service (SES), SendGrid, Mailgun, and Postmark all use API-key-based sending. If a key leaks through a public GitHub repository, a misconfigured container environment variable, or a phishing attack the attacker can send mail as your domain from anywhere in the world.

This is different from a compromised mail account because the sending infrastructure itself is not yours. The IP address the mail appears to originate from is the attacker's chosen server, not your corporate mail gateway.

Supply chain and base image backdoors

This is the least discussed but most insidious path. Cloud providers, container registries, and Linux distribution mirrors have published base images that include pre-installed and pre-configured SMTP daemons. In some cases this is intentional, a base image for email marketing platforms might include Postfix for local mail delivery. In other cases it is either accidental or malicious.

The pattern to watch: a cloud server you deployed from a standard image starts sending mail before you have installed or configured any mail software. The SMTP daemon was already running.

This has been documented in official cloud provider marketplaces and in some third-party container base images on Docker Hub and GitHub Container Registry. The backdoor is often a minimal SMTP relay that connects to an external command-and-control server, receiving instructions on what to relay and when.

How to detect unauthorized relay activity

Detection happens in three places: mail server logs, network flow data, and DNS blocklists.

Mail server logs

Every mail server logs SMTP transactions. The entries worth checking:

# Postfix grep -i "relay=" /var/log/mail.log | grep -v "from=<>"

Exchange

Get-MessageTrackingLog -EventID RELAY | Select-Object Sender, Recipient, Relay

Look for entries where the sending client IP does not match your known infrastructure. A relay entry for sender@example.com where the relay IP is 203.0.113.42 and you have no server at that address is a clear signal.

DNS blocklists

If your domain's reputation has suffered, the fastest check is to query popular DNS blocklists:

# Check if your mail server IP is listed (substitute your IP) host -t A mail.yourdomain.com | awk '{print $4}' | xargs -I{} dig +short {}.bl.spamcop.net

If the query returns a blocklist server address, your IP is listed. If it returns nothing, you are likely clear. Run this against your known sending infrastructure, not just your corporate gateway, an unauthorized relay may be using a different IP you do not recognize.

Outbound mail volume monitoring

Set a baseline. If your mail gateway normally sends 200–400 transactional messages per day and suddenly logs show 12,000 messages in an hour, something changed. This is not subtle.

The challenge is that most organizations monitor inbound mail, not outbound. If you do not have outbound monitoring in place, the first signal is usually an abuse report from a recipient or a blocklist notification.

What DMARC reports reveal about relay patterns

DMARC aggregate reports are one of the most underused tools for detecting unauthorized relaying. Here is why.

When a mail server accepts a message that claims to be from yourdomain.com, it performs SPF, DKIM, and DMARC checks. If the message fails those checks, the receiving server may generate a report, an XML document and send it to the rua address you specified in your DMARC record. That report contains the sending mail server's IP address.

If your DMARC aggregate report shows an IP address sending mail as your domain and that IP is not in your sender inventory, you have found an unauthorized relay. It might be:

A third-party marketing platform you authorized and then forgot about
A compromised API key for a transactional email service
A server that has been turned into a relay without your knowledge

DMARCFlow surfaces these anomalies automatically. When a new, unrecognized IP appears in your aggregate reports, DMARCFlow flags it and alerts you, before the relay's activity damages your domain's reputation. This is faster than waiting for blocklist notifications or recipient complaints.

Without DMARC aggregate report monitoring, you are relying on external parties to tell you something is wrong. With it, you find out when the first message is relayed, not when the hundredth complaint arrives.

Hardening checklist

If you are auditing your own SMTP exposure, work through this list:

1. Audit your mail servers - Identify every host that can send mail as your domain. Include cloud instances, container workloads, and legacy systems. 2. Close open relays - In Postfix: mynetworks = 127.0.0.0/8 only, or use smtpd_relay_restrictions = permit_mynetworks, reject. In Exim: restrict acl_smtp_connect to known networks. 3. Rotate API keys - Any SMTP API key that has been committed to a repository, exposed in a container image, or shared with a third party should be rotated immediately. 4. Monitor aggregate reports - Route your DMARC rua reports to a service that can parse and alert on them. Review new sending IPs regularly. 5. Add unexpected senders to your sender inventory - If a DMARC report shows a legitimate third-party relay you use, add it to your documentation and your monitoring scope. 6. Check base images before deployment - Audit cloud instances and containers for pre-installed SMTP daemons before they go to production. If Postfix or Sendmail is running and you did not install it, investigate.

FAQ

Can DMARC tell me if my domain is being relayed?

Yes, if the relay is sending mail as your domain and the receiving server participates in DMARC reporting. The aggregate report will show the relay's IP as a sending source. You will not see content, only the envelope metadata: sending IP, sender address, and result (pass or fail).

My server only relays mail internally. Does that matter?

Yes, if it accepts mail from external sources and forwards it onward. A server that relays internal mail to the internet is an unauthorized relay if it does not authenticate the sender.

I use a third-party email service. How do I know if they are the relay source?

Check your DMARC aggregate reports. Any legitimate transactional email service will appear as a regular sending source. If you see a new IP you do not recognize in reports and you have not added a new vendor, that is a signal worth investigating.

Is an open relay the same as an unauthorized relay?

Not exactly. An open relay is a configuration, it accepts mail from anyone. An unauthorized relay is a designation, it is sending mail it was not authorized to send. A server can be an open relay without being unauthorized if it only relays mail from authorized sources. In practice, open relays almost always become unauthorized relays because attackers find and exploit them within hours of going online.

Bottom line

Unauthorized SMTP relays are not a theoretical risk. They are running infrastructure somewhere in your address space right now, or they were until someone caught them. The detection window is narrow: the relay appears in your domain's sending history in DMARC reports, then your domain appears on blocklists, then you start getting abuse reports. DMARC aggregate monitoring collapses that window by giving you the first signal a new, unrecognized sending IP - before the downstream damage accumulates.

Start by checking your DMARC reports for any IP address you do not recognize. If you do not know who is sending mail as your domain, that is the problem to solve first.