A rejected message tells you exactly why

by Francis Rozange | Sep 8, 2026 | Email Marketing

Abstract 3D render: beams of light returning down a dark corridor, sorted into coloured channels

A rejected message answers you. It tells you why, with a precision you will find in no dashboard, and it tells you for free.

Almost nobody reads it. People look at a bounce rate, watch it climb, and go looking for the cause elsewhere. It is written out in full in the sending log.

Learning to read three numbers is enough.

The first digit: retry or give up

The basic code comes from RFC 5321, the SMTP standard of October 2008. It defines two families of failure, and the definitions deserve to be read exactly.

“4yz Transient Negative Completion reply. The command was not accepted, and the requested action did not occur. However, the error condition is temporary, and the action may be requested again.”

“5yz Permanent Negative Completion reply. The command was not accepted and the requested action did not occur. The SMTP client SHOULD NOT repeat the exact request (in the same sequence).”

The standard gives a test to tell them apart, and it is smarter than the usual shorthand:

“A rule of thumb to determine whether a reply fits into the 4yz or the 5yz category is that replies are 4yz if they can be successful if repeated without any change in command form or in properties of the sender or receiver.”

A 4xx may succeed if you repeat it identically. A 5xx will only succeed if something changes. The standard even adds: “Even some ‘permanent’ error conditions can be corrected.”

A 5xx is therefore not a life sentence. It is a ban on trying again without fixing anything.

The three numbers: the real information

The enhanced code comes from RFC 3463, of January 2003. Its structure is simple:

“status-code = class ‘.’ subject ‘.’ detail”

The class repeats the severity. The second number identifies the nature of the problem: 1 for the recipient address, 2 for the mailbox, 4 for the network, 5 for the protocol, 7 for security and operator policy.

That second number is what orients you. A 5.1.1 is an address that does not exist, so a database problem. A 5.7.x is a policy refusal, so a reputation or authentication problem. The two are fixed in different departments of your company.

The third number narrows things down, and that is where the ground gets uneven.

The registry, and what it reveals

The detailed codes are not all in RFC 3463. It stops at X.7.7. Everything after that has been added over the years to a registry maintained by IANA, created in 2008 and last updated on 6 December 2024.

Two entries in that registry are worth the detour, because they explain much of the confusion in the field.

X.7.26, the authentication failure code Gmail returns most often, comes from RFC 7372, not RFC 3463. The registry describes it thus: “This status code is returned when a message failed more than one message authentication check, contrary to local policy requirements.”

X.7.28, the one every volume sender eventually meets, is more surprising. Its description is “The message appears to be part of a mail flood of similar abusive messages”, its “Associated basic status code” column is empty, and its reference is an expired, archived IETF working document.

The 421 4.7.28 that Gmail returns is therefore not a standardised combination. It is an operator-imposed usage, on a code whose specification never completed. That is a fair summary of this trade.

Three operators, three conventions

Here is the point that costs technical teams the most time: the major operators do not map the same codes onto the same causes.

Gmail documents a dense list, with an identification convention of its own: “Gmail appends one or both of these identifiers to all error messages: gsmtp (Google SMTP) is added to all errors. gcdp (Google Custom Domain Policies) is added to errors resulting from customized rules created by a Google Workspace administrator.”

That detail is worth its weight in diagnostic time. A rejection marked gcdp does not come from reputation: it comes from a rule written by an administrator, in the recipient domain’s admin console. You can stop looking at your DNS records.

Gmail also documents the same causes at both severity levels, which is information in itself: 421 4.7.30 for a temporary DKIM failure, 550 5.7.30 for the same failure gone permanent. The shift from one to the other measures how much patience you have left.

Yahoo publishes no enhanced code table at all. Its page reasons in basic codes, and gives a clear operational instruction: “You should not retry sending an email that comes back with a 5xx error. List managers should have a policy for removing email addresses that generate 5xx errors/bounces.”

Microsoft, finally, uses 5.7.23 for an SPF failure, where Gmail uses 5.7.27. Same cause, two codes. Any tool claiming to classify your rejections by enhanced code without distinguishing the operator produces a false statistic.

The four codes behind most rejections

Without claiming to be exhaustive, four families cover most of what you will see.

5.1.1 and 5.1.10, recipient does not exist. This is not a deliverability problem, it is a list hygiene problem. An address returning this code should leave the database on the first rejection, something Sestaro’s verification establishes before the send rather than after, and continuing to write to those addresses is exactly what takes you somewhere worse.

5.7.26 and 5.7.27, authentication. Gmail then writes: “This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM.” The message contains the IP address tested and the domain evaluated. Everything you need to fix it is there.

5.7.25, no reverse DNS record on the sending IP. This is an explicit requirement of the sender guidelines, and it is settled with one request to your host.

421 4.7.28, rate limiting. Google gives here the only quantified instruction in all of its documentation on the subject: “Do not send email for at least 10 minutes.” Retrying immediately makes it worse.

What to do tomorrow morning

Open your server’s sending log or your provider’s rejection export, and classify one full day by enhanced code, operator by operator. Not by rate: by code, in absolute numbers.

You will almost always get a very lopsided distribution, dominated by two or three causes. Those two or three causes are your work plan, in order.

Then separate what belongs to the list from what belongs to the infrastructure. The 5.1.x codes are fixed by deleting addresses. The 5.7.x codes are fixed by correcting DNS records or slowing down. Mixing them means explaining an authentication problem with list quality, or the reverse.

And keep the full rejection text, not just the code. Operators write in the domain evaluated, the IP address tested, and sometimes a link to the rule you broke. It is the most precise documentation you will ever have about your own traffic, and it is addressed to you personally.

Sources

LaFactory works email on the evidence: headers, DNS records, rejection logs. No open rate promises, ever. Get in touch for a deliverability audit.