Email Bounce Codes Explained: How to Read 550 5.1.1, 5.7.26, 421 4.7.0 and Other Bounce Messages

A message comes back with a subject like “Mail delivery failed: returning message to sender”, “Undeliverable:” or “Delivery Status Notification (Failure)”. Inside is a wall of text with numbers like 550 5.1.1 or 421 4.7.0. That message is a bounce, and it is the most useful piece of evidence you will ever get about an email problem, because it is the receiving server telling you, in its own words, why it said no.

This guide teaches you to read any bounce: where the important lines are, what the three-part status code means, and what to do about the codes you will actually meet. If your WordPress site is not sending at all, start with FG-42. If you are receiving bounces for mail you never sent, that is backscatter, covered in FG-46.

What is happening

When your mail server tries to deliver a message, it opens an SMTP conversation with the recipient’s server. Every command gets a three-digit reply. A 2xx reply means accepted. A 4xx reply means “not now, try later”. A 5xx reply means “no”. Most modern servers add an enhanced status code after the basic one, defined in RFC 3463, which pinpoints the reason.

If the receiver refuses, your server (or your provider’s) generates a Delivery Status Notification, or DSN, and sends it back to the envelope sender. A DSN has three parts: a human-readable explanation, a machine-readable status block, and a copy of the original message or its headers. The status block is the part that matters.

The class.subject.detail structure

An enhanced code such as 5.7.1 has three numbers:

Part	Values	Meaning
Class	2, 4, 5	2 success, 4 temporary failure, 5 permanent failure
Subject	1	Addressing (the address itself is bad)
Subject	2	Mailbox (exists, but full or disabled)
Subject	3	Mail system (the receiving system has a problem, or message too big)
Subject	4	Network and routing (DNS, connection, loops)
Subject	5	Mail delivery protocol
Subject	6	Message content or media
Subject	7	Security or policy (authentication, reputation, spam)
Detail	0 to 999	The specific reason within the subject

So 5.1.1 reads as “permanent, addressing, bad destination mailbox”: the address does not exist. 4.7.0 reads as “temporary, security or policy, other”: try later, something about you looks suspicious. Once you know the subject digit, you know which half of the problem to look at: 1 and 2 are about the recipient, 7 is almost always about you as a sender.

Before you start

You need the complete bounce, not a screenshot or a forwarded summary. In most mail apps, open the bounce and choose “Show original”, “View source” or “View message details”. If the bounce came from a WordPress site or another app, check that app’s email log or your transactional provider’s activity log, which usually stores the exact SMTP response.

For DNS checks you run dig on your own computer: built in on macOS and Linux, available through WSL on Windows (PowerShell has Resolve-DnsName as an equivalent). If you manage the sending server, you will also want SSH access to read its mail log. Nothing in this guide changes data, so no backup is needed until you start editing DNS.

Step 1: Find the lines that matter

Ignore the friendly paragraph at the top; it is generated by your own server and often vague. Scroll to the delivery status section. It looks like this:

Reporting-MTA: dns; mail.SENDER-PROVIDER.example
Final-Recipient: rfc822; RECIPIENT@example.org
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx.example.org
Diagnostic-Code: smtp; 550 5.1.1 RECIPIENT@example.org: Recipient address rejected: User unknown

This is an example of what you will see inside the bounce, not a command. Reporting-MTA is the server that wrote the bounce (yours or your provider’s). Final-Recipient is the address that failed. Action is failed for a final bounce or delayed for a “still trying” warning. Status is the enhanced code. Remote-MTA is the receiving server that refused. Diagnostic-Code is the exact text the receiver sent, and it is the most important line of all.

Two checks before you go further:

• Who refused? If Remote-MTA is missing and the diagnostic mentions your own server, the problem happened before the message left (for example, your server could not find the recipient domain). If it names the recipient’s server, the receiver refused.
• Is it a warning? Action: delayed means your server is still retrying. Do not resend yet; wait for the final result.

Exim bounces put the receiver’s response after a line like SMTP error from remote mail server after RCPT TO:. The stage named there helps: a refusal at RCPT TO is about the recipient or your reputation, a refusal after end of data means the receiver read the whole message, including authentication results, before saying no.

Step 2: Decide if it is a soft or hard bounce

A soft bounce is a 4xx response. Your server keeps the message in its queue and retries on a schedule, typically for several days (Postfix’s default limit is five days). You only see a bounce if every retry fails, though many servers send a “delayed” warning after a few hours.

A hard bounce is a 5xx response. The receiver has said no permanently and your server will not retry.

Two nuances matter. First, some receivers use 4xx codes to throttle senders with poor reputation; if the soft bounces never clear, treat it as a reputation problem, not bad luck. Second, some servers use 5xx for things that are really temporary, such as a full mailbox. Read the text, not just the first digit.

If you send newsletters or marketing mail, remove hard-bounced addresses from your list immediately. Repeatedly mailing addresses that do not exist is one of the clearest signals of a poorly maintained list, and receivers notice.

Step 3: Recipient-side codes (subjects 1 and 2)

550 5.1.1 User unknown

The mailbox does not exist. Check for typos (gmial.com, a missing letter), ask the recipient for their current address, or confirm the person has left the organization. Microsoft 365 phrases this as 550 5.1.10 RESOLVER.ADR.RecipientNotFound (the standard meaning of 5.1.10 is a null MX, but Microsoft uses it for unknown recipients). Nothing on your side needs fixing.

5.1.2 or “Host or domain name not found”

Your server could not find a mail server for the recipient’s domain. Confirm it on your computer:

dig +short MX example.org

Replace example.org with the recipient’s domain (the part after @). +short prints only the answer. Good output is one or more lines like 10 mx1.example.org.. Empty output means the domain has no MX record; mail is then attempted to the domain’s A record, which often fails. 0 . is a “null MX” (RFC 7505), meaning the domain explicitly accepts no mail. If the domain is misspelled, fix the address. If it is correct and has no MX, the recipient’s domain is broken and only they can fix it.

552 5.2.2 Mailbox full

The recipient’s mailbox is over quota. This is usually temporary from the recipient’s point of view, even though it arrives as a 5xx. Let them know through another channel, or retry in a few days. If you see it repeatedly for one address, the mailbox is probably abandoned.

5.2.1 Mailbox disabled and 5.3.4 Message too big

5.2.1 means the account exists but is suspended or disabled. 552 5.3.4 means your message exceeds the receiver’s size limit; send large files as a download link instead of an attachment.

Step 4: Sender-side codes (subject 7 and friends)

These are the bounces that mean you have something to fix.

550 5.7.1 Delivery not authorized

5.7.1 is a catch-all for “policy says no”, so the text decides everything. Common variants:

• Listed on a blocklist. Text mentions Spamhaus, Barracuda, SpamCop or “blocked using”. See FG-44.
• Content flagged as spam. Gmail’s text says it has detected the message is likely unsolicited mail. Look at the content, links and your domain’s reputation.
• Recipient policy. Phrases such as “This message violates example.org email policy” or “Sender not allowed” mean the recipient’s admin blocks you specifically. Only they can lift it.
• Microsoft IP block. Outlook.com text says part of your provider’s network is on its block list, with a code such as S3150 in brackets. See FG-45.

550 5.7.26 Authentication failed

RFC 7372 defines 5.7.26 as “multiple authentication checks failed”. Gmail uses it for unauthenticated mail; its text says the message is unauthenticated and the sender must authenticate with at least one of SPF or DKIM. A variant says the mail is not accepted because of the sending domain’s DMARC policy. Either way, the message failed SPF and DKIM for your domain (or failed alignment), and your DMARC record told the receiver to reject. Related codes from the same RFC: 5.7.23 SPF validation failed, 5.7.25 reverse DNS validation failed, and Microsoft’s 5.7.509 for a DMARC reject failure and 5.7.515 for high-volume senders missing required authentication.

Fix: identify which service sent the bounced message (your website, a CRM, a billing tool) and make sure it is in your SPF record and signs with DKIM for your domain. FG-06 covers the records; FG-46 covers finding forgotten senders.

553 Mailbox name not allowed

A 553 during MAIL FROM usually comes from your own outgoing server: you authenticated as one account but tried to send as an address you do not own. Postfix phrases it Sender address rejected: not owned by user. Send as the authenticated address or add a “send as” permission. A 553 at RCPT TO usually means a malformed recipient address.

554 5.7.1 Relay access denied

You tried to send to an outside domain through a server that does not know you. The usual cause is a mail app or plugin connecting without authentication, or authenticating on the wrong port. Turn on SMTP authentication in the client and use port 587 or 465.

421 4.7.0 Try again later

A temporary policy refusal. Gmail uses 421 4.7.0 for, among other things, very low sender reputation and connections without TLS. Microsoft and others use it for too many connections at once. If it clears within hours, ignore it. If it persists, it is a reputation problem: check blocklists (FG-44) and the major provider requirements (FG-45).

451 4.7.1 Greylisting

Greylisting servers deliberately reject the first attempt from an unknown sender with a temporary error, often 451 4.7.1 and text such as “Greylisted, please try again later”. A real mail server retries a few minutes later and gets through; many spam tools never retry. A single greylisting delay is normal. It only becomes a problem if your sending system does not retry, which is the case for some badly written scripts that talk SMTP directly. Proper MTAs and transactional providers always retry.

Step 5: Gmail and Microsoft specific texts

The two largest receivers write descriptive bounce text and include a help link. These are the patterns you will see most:

Code	Receiver	What the text is about	Fix
550 5.7.26	Gmail	Unauthenticated, or failed the sender’s DMARC policy	Pass SPF or DKIM, aligned with the From domain
421 4.7.26	Gmail	Temporary version of the above, rate limited	Same as above, before it becomes permanent
550 5.7.25	Gmail	Sending IP has no PTR, or the PTR name does not resolve back to the IP	Set forward-confirmed reverse DNS (FG-45)
421 4.7.28	Gmail	Unusual rate of mail from your IP or domain, temporarily rate limited	Slow down, check for compromise or a sudden campaign
550 5.7.1	Gmail	Likely unsolicited mail, blocked	Reputation and content; see FG-45
550 5.7.1 (S3150)	Outlook.com	Sending IP or its network is on Microsoft’s block list	Request mitigation through Microsoft’s sender support
550 5.7.509	Outlook.com	Fails DMARC and the domain publishes p=reject	Fix SPF or DKIM alignment for that sender
550 5.7.515	Outlook.com	High-volume sender does not meet the required authentication level	SPF, DKIM and DMARC all in place and passing
550 5.7.606	Microsoft 365	Banned sending IP	Use Microsoft’s delist portal for Microsoft 365

Exact wording changes over time, so always paste the full bounce text into your notes rather than relying on the code alone. Both providers link to a help page from the bounce; follow the link in your own bounce, as it reflects the current guidance.

Step 6: The full code reference

Code	Meaning	Hard or soft	Usual fix
550 5.1.1	Mailbox does not exist	Hard	Correct or remove the address
5.1.2	Recipient domain not found or cannot receive mail	Hard	Check spelling; recipient must fix their DNS
5.2.1	Mailbox disabled	Hard	Contact the recipient another way
552 5.2.2	Mailbox full	Treat as soft	Retry later, tell the recipient
552 5.3.4	Message too large	Hard for that message	Use a download link instead of attachments
4.4.1 / 4.4.2	No answer or connection dropped	Soft	Usually clears; persistent means receiver outage or firewall
421 4.7.0	Temporary policy refusal or too many connections	Soft	Wait; if persistent, check reputation
451 4.7.1	Greylisting or temporary policy	Soft	Make sure your sender retries
550 5.7.1	Policy refusal (blocklist, spam, recipient rule)	Hard	Read the text; fix reputation or ask the recipient
5.7.23	SPF failed	Hard	Add the sending service to SPF
5.7.25	Reverse DNS check failed	Hard	Set a matching PTR record
550 5.7.26	Multiple authentication checks failed (often DMARC)	Hard	Aligned SPF or DKIM for the From domain
553 5.7.1	Not allowed to send as that address	Hard	Send as the authenticated account
554 5.7.1	Relay access denied, or rejected for policy	Hard	Authenticate to your outgoing server

Advanced: tracing a bounce through your own server logs

If you run the sending server, the log shows the full conversation and every retry. Bounces carry the original Message-ID in the returned headers; use it to find the message. On the server, over SSH:

grep -F "MESSAGE_ID" /var/log/mail.log
grep -F "QUEUE_ID" /var/log/mail.log

MESSAGE_ID is the value of the Message-ID: header from the original message quoted in the bounce, without the angle brackets. The first search returns a line with Postfix’s queue ID, a short hexadecimal string before a colon, which is your QUEUE_ID. The second search returns every log line for that message. -F treats the text literally so dots and symbols are not read as patterns. Use /var/log/maillog on RHEL-family systems. Good output shows a final status=sent. Bad output shows status=deferred lines (soft failures with the reason in brackets) and finally status=bounced with the receiver’s exact response.

On Exim servers, use the Exim message ID (a string like three blocks separated by hyphens) with exigrep:

exigrep "EXIM_MESSAGE_ID" /var/log/exim_mainlog

EXIM_MESSAGE_ID appears in the bounce’s headers and in Exim log lines. exigrep gathers all lines for that message into one block. Lines with <= show the message arriving, => a delivery, == a deferral and ** a permanent failure. The text after ** is the receiver’s answer.

Patterns worth spotting in the log: deferrals to one receiver only (reputation with that receiver), deferrals to everyone (your server’s network or DNS), and many bounces to addresses you do not recognize (your server may be sending spam: see FG-44 and FG-05).

When to contact your host

Open a ticket if the bounce shows your own outgoing server refusing (relay denied, 553 on your own domain, authentication errors you cannot explain), if soft bounces from many different receivers never clear, or if the bounce mentions a blocklist entry for your server’s IP. Send:

• The complete bounce message, including headers, as an attachment or pasted raw source.
• The UTC time the original message was sent and the sender and recipient addresses.
• The Message-ID of the original message.
• Which app sent it: a mail client, a WordPress site, a CRM.
• Whether all mail to that domain fails, or only some recipients.
• Anything that changed recently, such as DNS edits, a new sending service or a server move.

The diagnostic tools page lists DNS and header checkers that help with the steps above. If mail to customers is failing right now, go to the Emergency Room.