SMTP error codes

This reference lists the SMTP error codes that mailbox providers most often send back to newsletter senders, what each one means, and the bounce class ReputeCast gives it. Each code links to a page with the receiver’s official text, the cause and the fix.

Codes

Code	Mailbox provider	What it means	ReputeCast bounce class
421 4.7.28	Gmail	Gmail saw an unusual rate of email from your IP address, domain or link domains and rate limits it for now.	spam_block
550 5.7.26	Gmail	The message failed SPF and DKIM, or the From domain’s DMARC policy, and was blocked.	policy_block
550 5.7.1	Gmail	The message was blocked as likely unsolicited, for the low reputation of the sending IP address or domain, or by policy.	spam_block, reputation or policy_block
550 5.1.1	Gmail	The email account doesn’t exist.	mailbox_unknown
452 4.2.2	Gmail	The recipient’s inbox is out of storage space.	mailbox_full
550 5.7.515	Outlook.com, Hotmail, Live.com, MSN	The From domain doesn’t meet Microsoft’s authentication requirements for high-volume senders.	policy_block
421 4.7.0 [TSS04]	Yahoo	Yahoo deferred the messages because of complaints, content, IP reputation or unusual traffic.	reputation
Account under review	None: Amazon SES is a sending provider	Not an SMTP reply. AWS found an issue with the mail your SES account sends and gives you time to fix it.	None: an account status, not a bounce

The class depends on the receiver’s text as well as the code, so one code can land in more than one class. Each page lists the variants.

Read an SMTP reply

An SMTP reply starts with a three-digit reply code (550), usually followed by an enhanced status code (5.7.26) and the receiving server’s text. A first digit of 4 means a temporary failure: the sending provider keeps the message and tries again later. A first digit of 5 means a permanent failure: the sending provider stops trying. The reply codes are defined in RFC 5321 and the enhanced status codes in RFC 3463 (checked October 2026).

Find a bounce’s original code

ReputeCast keeps each sending provider’s original event type, code and text next to the normalized event, so you can always see what the receiving server said.

In a campaign report

1. Open Campaigns and the campaign’s Report.
2. Find the bounces table. Each row is one bounce type (the ReputeCast type column). Original codes lists the sending provider, its own event type and the original code, most frequent first, for example SES Permanent/General 550 5.1.1.
3. Read Suppression to see what happens to the addresses (see bounce classes in the report).
4. Where the column shows Review, select it to read what each sending provider said. Addresses are left out of that view.

The bounces table counts hard and soft bounces only. Deferrals that were delivered on a later attempt don’t appear in it. Read campaign reports explains the other tables.

For one address or message

1. Open Sending providers › , then Events & sync.
2. In the event log, filter by Event type (for example Deferred, Hard bounce or Soft bounce), or search for the recipient or the message id.
3. Read the Original code · diagnostic column: the code and the receiving server’s text.

The event log keeps events for 90 days. Its CSV export adds the original_code, diagnostic and bounce_class columns; recipients are masked unless you have subscribers:export, and every export is recorded in the audit log. Delivery events and suppression sync explains how events arrive.

Addresses on the suppression list keep their code too: Audience › , then Suppression list, column Reason · original code.

Bounce classes in the report

Every adapter maps its sending provider’s bounce to one of eight classes. The campaign report groups them into rows:

Bounce class	Row in the report	Suppression column
mailbox_unknown	Hard · unknown user	Auto-suppressed
domain_invalid	Hard · domain not found	Auto-suppressed
mailbox_full	Soft · mailbox full	Retry next send
temporary	Soft · deferral expired	Retry next send
policy_block, spam_block, reputation	Blocked · policy or reputation	A button to add the addresses, or a badge once they are on the list
other	Other	Review

• The two hard rows show the addresses as suppressed. If some aren’t on the list yet, the column offers to add them.
• The soft rows can’t be suppressed from the report: those addresses get mail again on the next send. You can still add one by hand on the suppression list.
• The blocked row is about the sender, not the address. Adding those addresses needs subscribers:edit and stops mail to people who may be fine; fix the cause first.

When ReputeCast suppresses an address

ReputeCast puts an address on the shared suppression list, for every stream and every sending provider, when the sending provider reports a hard bounce, a complaint or an unsubscribe. A soft bounce or a deferral never suppresses an address on its own. Transactional mail adds one rule: when a Transactional message soft-bounces and the address has soft-bounced 3 times within 7 days, the address is suppressed.

An address that doesn’t exist (mailbox_unknown, domain_invalid) is a hard bounce with every sending provider. A permanent block about the sender (policy_block, spam_block, reputation) is recorded like this:

Sending provider	A permanent block about the sender is recorded as
Amazon SES, Resend	A hard bounce when the sending provider reports the bounce type Permanent, otherwise a soft bounce
Postal	A hard bounce when Postal reports HardFail with a 5xx reply, otherwise a soft bounce
SMTP (bounce mailbox)	A hard bounce when the bounce report’s status is 5.x.x
Postmark	A soft bounce, unless Postmark types it HardBounce, BadEmailAddress or ManuallyDeactivated
SendGrid	A soft bounce when SendGrid marks it blocked or classifies it as Content, Reputation or Frequency/Volume, otherwise a hard bounce
Mailjet	A soft bounce when Mailjet relates the error to spam, content, its system or Mailjet itself, otherwise Mailjet’s own hard or soft flag
SparkPost	A soft bounce: only SparkPost’s bounce classes 10 and 30 (invalid recipients) are hard
Mailgun, Brevo, Azure Communication Services, generic HTTP adapter	A soft bounce
Community adapters	Whatever the adapter reports

If blocked addresses were suppressed as hard bounces and you have fixed the cause, you can remove them from the suppression list with a reason. A contact removed after a hard bounce goes back to pending consent and needs a new opt-in before it gets mail again.

How ReputeCast picks a bounce class

ReputeCast reads the sending provider’s event and the receiver’s text in this order. The first match wins.

1. The sending provider’s own bounce type, where it has a precise one (for example Amazon SES’s NoEmail and MailboxFull subtypes, Postmark’s InboxFull and DnsError, SparkPost’s bounce classes).

2. Words in the text, such as reputation, TSS04 or rate limited due to for reputation, and spam, blocklist, Spamhaus, virus or phish for spam_block.

3. The enhanced status code:

   Enhanced status code	Bounce class
   5.1.0, 5.1.1, 5.1.6, 5.2.1	mailbox_unknown
   4.2.2, 5.2.2	mailbox_full
   4.1.2, 5.1.2, 5.1.10, 4.4.4, 5.4.4	domain_invalid
   5.4.1, 5.7.0, 5.7.1, 5.7.23 to 5.7.27, 5.7.509, 5.7.606	policy_block

4. More words, such as user unknown or does not exist for mailbox_unknown, mailbox full or over quota for mailbox_full, domain not found or no mx for domain_invalid, and dmarc, spf, dkim, access denied or policy for policy_block.

5. Any other 4xx reply is temporary; everything else is other.

Because the text is read before the code, Gmail’s 421 4.7.28 is spam_block: its text says “To protect our users from spam”. When a sending provider passes only the code without the text, the class can differ. 421 4.7.28 alone is temporary and 550 5.7.515 alone is other.

Related

• Bounces, complaints and provider limits
• The suppression list
• Monitor a send and auto-pause