SMTP error 541 isn't a standard code - here's what you actually got

SMTP error 541 is not a standard SMTP reply code. RFC 5321 defines a specific, closed set of

three-digit reply codes, and 541 is not among them - valid 5xx codes in standard use are 500

through 504 and 550 through 555. If you are seeing "541" reported by a tool, a log parser,

or a bounce-handling dashboard, the real server reply was something else, and a layer in your own

pipeline relabelled or misparsed it.

What to do instead of researching "541": find the real reply. The most common underlying

reply for a "message content rejected" condition - which is what most "541" write-ups describe -

is `551 5.7.1`, "delivery not authorized, message refused," or one of its siblings in the

550-554 range covered elsewhere in this series.

Why "541" shows up anyway

• A bounce-handling library truncates or re-encodes the reply code incorrectly when parsing a

non-delivery report, producing a number that was never actually sent on the wire.

• **A proprietary or legacy appliance (older content-filtering gateways, some mainframe-adjacent

mail systems) uses non-standard reply codes internally** and a monitoring tool surfaces that

internal number instead of translating it to a standard one.

• Manual transcription error. "541" is one keystroke away from several real codes (551,

554, 500), and it propagates through documentation once someone writes it down wrong.

The transcript (what the sender actually received)

$ swaks --to test@mailpilots.in --server mx.example.net
-> DATA
<- 354 Start mail input; end with <CRLF>.<CRLF>
-> [... message content ...]
-> .
<- 551 5.7.1 Message content rejected by policy

This is the real, standard reply that content-rejection scenarios like the one "541" write-ups

describe actually produce. 551 is a defined code ("user not local; please try a different

path"), reused here by some systems for policy-based content rejection, and 5.7.1 confirms it

is a delivery-authorization refusal.

How the big three word it (for a genuine content rejection)

Diagnose it

$ grep -i "reject\|541\|551" /var/log/mail.log | tail -5
Oct 14 10:02:03 mx1 postfix/cleanup[8891]: ABC123: milter-reject: END-OF-MESSAGE from
    client.example.com: 5.7.1 Message content rejected by policy; from=<sender@yourdomain.com>
    to=<test@mailpilots.in> proto=ESMTP

The raw mail log on either side of the transaction always shows the real reply code - if your

monitoring dashboard says "541" and your mail log says 551, trust the log, not the dashboard.

The fix, in order

1. Go to the raw mail log or SMTP transcript, not the summarised dashboard view, and find the

literal three-digit code and enhanced status that was actually sent.

1. Treat whatever real code you find using its own documented meaning - most likely `550

5.7.1, 551 5.7.1, or 554 5.7.1`, each covered with its own specific fix elsewhere in this

series.

1. Report the mislabelling to whoever built the tool showing "541" if it is yours or a

vendor's, since it will mislead the next person who hits this exact condition.

1. Check your own content and authentication once you have the real code - content rejections

in the 550-554 range are almost always about message content, reputation, or missing

SPF/DKIM/DMARC alignment, not about a mysterious undocumented code.

1. Do not search further for "541" as if it were authoritative. No RFC, no major provider's

public documentation, and no IANA registry defines it.

What not to do

• Do not apply a fix written for "541" without first confirming your real reply code. A fix

written around a misread code may target the wrong cause entirely.

• Do not assume your mail system is unusually broken for using a non-standard number. It is

far more likely a parsing or transcription issue downstream of the actual server reply.

• Do not build bounce-handling logic that matches on "541". It will never match a real

server reply and will silently fail to catch the condition it was meant to catch.

• Do not conflate this with `540` or `542`, which are themselves also non-standard; none of

the 540s series appears in RFC 5321.

MailPilot records the exact, literal SMTP reply string for every send attempt rather than a

normalised or re-coded summary, specifically so a report never shows a code that was never

actually sent by the receiving server.