SMTP Error Codes: A Deliverability Cheat Sheet

An SMTP error code is the three-digit number a receiving mail server sends back when it will not accept your message. This is a cheat sheet of the common SMTP error codes and what they mean, organised by what you should do next rather than by number. The single most useful fact is in the first digit: a code that starts with 4 is temporary, and a code that starts with 5 is permanent.

Right after the three-digit code you will usually see a second, dotted number like 5.1.1 or 5.7.1. That is the enhanced status code, and it names the specific reason. Read the two together — the reply code for whether to retry, the enhanced code for what to fix — and almost every bounce becomes actionable in a few seconds.

Is it a 4xx or a 5xx? That decides your next move#

The first digit of the reply code sets your whole response, so read it first. RFC 5321, the SMTP standard, defines a 4yz code as a transient negative completion reply and a 5yz code as a permanent negative completion reply. A 2yz code — which you rarely see as an error — is a positive completion, meaning the step worked (250 is the normal 'message accepted').

A 4xx is temporary. Your sending server keeps the message queued and retries on a schedule, often for up to a few days, before it gives up. You usually do nothing. A 5xx is permanent: the receiver is telling you this message will not be accepted in its current form, your server will not retry, and it returns the mail as a hard bounce. Resending the same message unchanged fails the same way.

• 4xx (transient): the server retries for you. Leave it unless it repeats for days.
• 5xx (permanent): fix the cause named by the enhanced code, then resend.
• 2xx (success): the step was accepted — 250 is a normal 'message accepted, completed'.

The enhanced status code after it#

The dotted code is defined by RFC 3463 and is written as class.subject.detail. The first number is the class: 2 is success, 4 is a persistent transient failure, and 5 is a permanent failure. The middle number is the subject (what kind of thing failed) and the last is the detail (the specific reason). So 5.7.1 reads as: permanent, security or policy, delivery not authorized.

The reply code and the enhanced code always agree on temporary versus permanent — a 550 pairs with a 5.x.x, a 421 pairs with a 4.x.x. When they seem to disagree, trust the enhanced class. Here are the ones you will actually meet, with the reply code you tend to see them alongside.

Common SMTP error codes and what to do about each#

Four classes cause most of the bounces senders actually hit: a mailbox that does not exist, a policy or authentication rejection, rate limiting, and a failed login to your own sending server. Work the table from the bounce you got — the middle column is how to confirm the cause before you change anything, because guessing wrong wastes a resend.

Fix 1: a mailbox-unknown bounce (550 5.1.1)#

5.1.1 means bad destination mailbox address: the part before the @ does not exist on that server. It is permanent, so retrying changes nothing. The only question is whether the address was mistyped or is genuinely gone.

1. 1

   Read the enhanced code

   Confirm it is 5.1.1 (mailbox) and not 5.1.2 (whole domain). A 5.1.2 or 'no such domain' points at a wrong domain or a broken MX record, which is a different fix — verify the domain still accepts mail.

2. 2

   Check for a typo

   If the local part is one character off — jon for john, a missing letter, a wrong company suffix — correct it and send once. A single successful delivery confirms the fix.

3. 3

   Remove and suppress it

   If the address is correct, the mailbox is gone. Take it off your list and add it to your suppression list so it is never sent to again. Repeatedly mailing a confirmed 5.1.1 pushes up your bounce rate, which receivers read as a reputation signal.

4. 4

   Watch your overall bounce rate

   A cluster of 5.1.1 results usually means a stale list. Clean it before your next send — a high hard-bounce rate is itself a reason receivers start issuing policy blocks.

Fix 2: a policy or authentication rejection (550 5.7.1 and 550 5.7.26)#

5.7.1 is 'delivery not authorized, message refused' — a policy block. 5.7.26 is 'multiple authentication checks failed', meaning your message failed more than one of SPF, DKIM and DMARC. Both are permanent, and both come down to whether the receiver trusts that the mail is really from you.

1. 1

   Check that SPF, DKIM and DMARC pass

   Send a test to a mailbox you control and read the Authentication-Results header, or use an authentication checker. A 5.7.26 almost always means one of the three failed or was not aligned with your From domain.

2. 2

   Fix the failing record in DNS

   SPF must list every server that sends as your domain; DKIM must sign with a key published at your selector; DMARC must be aligned. Correct the record that failed, then re-test before you resend.

3. 3

   Check sender reputation for a bare 5.7.1

   A 5.7.1 with authentication passing usually points at content or reputation: you may be on a block list, or recent spam complaints are high. Use the receiver's postmaster tools, cut complaints, and warm up gradually.

4. 4

   Resend only after the cause is fixed

   Because the rejection is permanent, re-sending the same message repeats it. Change the underlying cause first, confirm the test passes, then send again.

Fix 3: a rate-limit or connection block (421)#

421 is a special reply code. RFC 5321 defines it as 'service not available, closing transmission channel' — the receiver is dropping this connection. It is a 4xx, so it is temporary, but it is telling you to back off. Providers commonly phrase it as 'too many concurrent connections', 'unusual rate of mail', or 'sending quota exceeded', and Google's own SMTP reference lists 421 as 'Service isn't available, try again later.'

1. 1

   Read whether it is connections or volume

   'Too many concurrent connections' means you opened too many parallel SMTP sessions to one provider. 'Unusual rate' or 'quota exceeded' means too much volume too fast. The wording tells you which lever to pull.

2. 2

   Reduce concurrency

   Lower the number of simultaneous connections your sending tool opens to a single receiving provider. Many throttles clear the moment you stop hammering the connection limit.

3. 3

   Slow the send rate and spread it out

   Add a delay between messages and pace a large list over time rather than firing it in one burst. New domains and IPs need a gradual warm-up before they can send at volume.

4. 4

   Let the queue retry — do not hand-resend in a loop

   Because 421 is transient, your server retries on a backoff on its own. Manually re-sending in a tight loop makes the throttle worse and can escalate a temporary slowdown into a lasting block.

How to tell which cause you have#

When you are not sure, work from the code outward. Read the first digit, then the enhanced code, then the free-text line the server appended — that human-readable text is where Gmail, Outlook and others name the real reason, and it is the single best clue in any support ticket.

• First digit 4 → transient; usually rate limiting, greylisting or congestion. Wait and watch before acting.
• First digit 5 → permanent; the enhanced code names what to fix.
• 5.1.x → an address problem (unknown mailbox or a non-existent domain).
• 5.2.x → the mailbox is full or disabled.
• 5.7.x → security or policy: authentication, reputation, or a deliberate block.
• 535 5.7.8 vs 550 5.7.26 → 535 is your own outbound login failing; 550 5.7.26 is the receiver rejecting mail that was not authenticated. Different problem, different fix.

Preventing it#

Most SMTP errors are reputation and authentication problems wearing different numbers, so prevention comes down to one short list. Get these right and the 5.7.1, 5.7.26 and 421 rejections mostly stop appearing.

• Authenticate every domain you send from — SPF, DKIM and DMARC, all aligned. This alone clears most 5.7.1 and 5.7.26 rejections.
• Keep your list clean: remove every 5.1.1 immediately and suppress hard bounces so your bounce rate stays low.
• Keep complaints low. Google asks bulk senders to stay under a 0.1% spam rate and never reach 0.3%; high complaints turn into policy blocks.
• Send at a steady rate. Bursts trigger 421 throttling; warm up new domains and IPs gradually.
• Offer one-click unsubscribe on marketing mail. Google, Yahoo and Apple require it (RFC 8058); Microsoft recommends it.

Where a mail client fits — and where it doesn't#

Everything above is about mail you send, and the fix lives in your DNS and your sending platform. AI Emaily is a mail client, not an ESP, a DMARC monitor or a deliverability tester — it will not send your campaigns or score your sending reputation, and for those jobs you want your sending platform and a dedicated DMARC tool.

Where it works is the mirror image, on the receiving side. The same SPF, DKIM and DMARC results that make a server reject an unauthenticated message with 550 5.7.26 are what AI Emaily reads on the mail arriving in your inbox, so its spam and phishing protection can flag a spoofed sender that failed authentication instead of trusting it. We build AI Emaily. It connects to Gmail, Outlook and IMAP, keeps you in control with approve-before-send, undo and an audit trail, and comes with a 7-day free trial on the Pro and Autopilot plans.