Undelivered Mail Returned to Sender: where the reason is in a Postfix bounce

Undelivered Mail Returned to Sender is the subject line Postfix puts on a bounce, and every Postfix server in the world sends the same one. The reason is further down, on the line that starts with said:, quoted from the server that refused the message. This page shows where that line is and what each reply means.

Is this a scam? No, if it quotes a message you sent. Real Postfix bounces come from MAILER-DAEMON at your own server. A bounce for a message you never sent is backscatter, covered at the end.

Anatomy of the bounce

The top of the body is the template. Every word of it is fixed, so nothing here is about your message:

The hostname on the first line is the server that gave up. It's the server your mail client or application handed the message to, not the one that refused it.

Under that comes one paragraph per failed recipient. This is the part to read:

Four pieces. The address in angle brackets is the recipient that failed. The host and IP are the server that refused. Everything after said: is that server's reply, quoted word for word. The bracketed note at the end says which step of the conversation the refusal came at.

RCPT TO or end of DATA: which step refused

That final bracket is the most useful thing in the notice, and almost nobody reads it.

(in reply to RCPT TO command) means the receiver refused when your server named the recipient. At that point it hadn't seen the message. It had seen your server's IP, the sender address in the envelope, and the recipient. So the refusal is about one of those three: the address doesn't exist, your IP is on a blocklist, or SPF failed for the envelope sender.

(in reply to end of DATA command) means the receiver took the whole message and then refused it. That's where DKIM is verified, where DMARC is evaluated against the From header, and where spam and content filters run. A DMARC rejection is always here, because DMARC needs the From header and the header arrives with the data.

(in reply to MAIL FROM command) is rarer and means the receiver refused the sender address itself, usually because its domain has no DNS.

The attached delivery report

The same information is attached in machine-readable form as a message/delivery-status part. Mail clients show it as an attachment or a second section. It looks like this:

Status is the code to match against. Diagnostic-Code is the same reply as the said: line. X-Postfix-Queue-ID is the handle for the next section, if you have a shell on the server.

With shell access: follow the queue ID

Take the queue ID from the report and search the log. On Debian and Ubuntu that's /var/log/mail.log, on Red Hat systems /var/log/maillog, or the journal.

Every attempt is there, with the reply the receiver gave each time. For a message that was retried, the log has the original 4xx reply that started the delays, which the bounce doesn't quote. For a message that's still queued, postqueue -p lists it and postcat -q with the ID prints it.

Match the reply to the fix

• 5.1.1, User unknown, does not exist. The address. Check it against what the person gave you. 550 5.1.1 has the Postfix, Exchange and Gmail wordings.
• 5.7.26, unauthenticated, SPF or DKIM did not pass. A Gmail recipient found no authentication for your From domain. 550-5.7.26.
• 5.7.1 with DMARC in the text. The receiver enforced your own DMARC policy. Rejected per DMARC policy.
• 5.7.1, 554, blocked using, Spamhaus, Barracuda. The connecting IP is on a blocklist, or the receiver's filter refused the message. 554 5.7.1.
• SPF permerror, too many DNS lookups. Your SPF record is over the limit and fails for every sender. The permerror page.
• Host or domain name not found, Name service error, type=MX. The recipient's domain has no mail server in DNS. Usually a typo in the domain.
• Connection timed out, Connection refused. The receiving server is down, or a firewall is in the way. Postfix retried for the queue lifetime first.
• mail for example.com loops back to myself. Your own server. The domain's MX points at this host but the host isn't configured to accept its mail.

Anything starting 5.7 that names SPF, DKIM or DMARC is a DNS problem at your sending domain, and it's failing for every message from that system, not only this one. Check the domain in your From address with the SPF checker and the DMARC checker. Hard bounce vs soft bounce sorts the whole code space by who owns the fix.

Delayed Mail: the notice before this one

For a temporary refusal Postfix keeps the message and retries. If the admin set delay_warning_time, you get an earlier notice with the subject Delayed Mail (still being retried). By default that setting is off, so the first thing you hear is this bounce, five days after the message left. Read the said: line the same way. The reply it quotes is the last one Postfix got, and the log has the rest.

Bounces for mail you never sent

Postfix addresses a bounce to the envelope sender of the failed message. If someone forges your address into the envelope of their spam and a receiver refuses it, the refusal comes to you. The attached original is the spam, not anything you wrote. Your server wasn't involved, and the notice is backscatter.

You can't stop other servers doing that. You can make forging your domain less useful with a DMARC record at p=reject, which asks receivers to refuse mail that puts your domain in the visible From without passing authentication. The bounces that stop are the ones from receivers that check.

After the fix

One recipient's server sent this bounce. Most receivers don't bounce a failing message at all. They accept it and file it in spam, and the only record of that is the DMARC aggregate reports they send to the address in your DMARC record. Our weekly digest reads those reports and lists every server that sent as your domain and whether it passed. On a paid plan we email you the day an unfamiliar sender first fails. Your first domain is free.