SMTP Error & Bounce Code Decoder

Authentication · Gmail

Gmail requires mail to pass SPF or DKIM, aligned with the From domain, and DMARC for bulk senders. This message passed neither, or passed them for a different domain than the visible From.

• Publish an SPF record that includes the service actually sending, and sign with DKIM for your own domain.
• Make sure the SPF or DKIM domain matches the From domain (alignment) - a signature for your ESP's domain isn't enough.
• Add a DMARC record, even p=none, if you send more than a few thousand a day to Gmail.

Full guide to 550 5.7.26 → · Check the SPF record →

Authentication · Gmail

The From domain publishes p=quarantine or p=reject, and this message failed DMARC - neither SPF nor DKIM passed aligned with that domain. Gmail is enforcing the owner's instruction.

• Find which system sent it and add it to SPF, or enable DKIM signing for your domain on that system.
• If it's a forwarded or third-party stream, check alignment in the DMARC aggregate reports before touching the policy.
• Don't relax the policy as the fix - correct the sender.

Full guide to 550 5.7.1 DMARC → · Check the DMARC record →

Configuration · Gmail

The IP that connected to Gmail has no PTR record, or the PTR's hostname doesn't resolve back to that same IP. Gmail requires a matching forward and reverse pair.

• Ask whoever owns the IP (your host or ESP) to set a PTR record pointing to a hostname you control.
• Make that hostname's A record point back to the same IP, and use it as the SMTP HELO name.

Full guide to 550 5.7.25 →

Rate limit · Gmail

Gmail saw a spike in mail from this IP or domain that looks unsolicited and is deferring part of it. Gmail retries are accepted later - this is throttling, not a permanent block.

• Slow down: cut volume sharply and re-ramp gradually instead of retrying at full speed.
• Check the list - bounces and spam complaints are what trigger this; remove invalid and unengaged addresses.
• Spread sending across more mailboxes and domains rather than pushing one IP or domain harder.

Full guide to 421 4.7.28 / 4.7.0 → · Plan volume with the Warm-Up Calculator →

Reputation or blocklist · Gmail

Gmail judged this message likely unsolicited or suspicious, usually from the sending domain's or IP's reputation rather than one word in the text. It is a block on this message, and often on your next ones too.

• Test the same email with the Spam Test to see what's costing points.
• Check the domain and IP for blacklists, and your Google Postmaster Tools reputation if you have volume.
• Pause the stream, fix authentication and list quality, and resume at low volume.

Full guide to 550 5.7.1 → · Test the email with the Spam Test →

Rate limit · Gmail

That one mailbox has been sent too many messages in a short time, or the mailbox is temporarily limited. It clears by itself.

• Retry later - the usual retry schedule is enough.
• If you send the same person several messages in a row, space them out.

Full guide to 450 / 421 4.2.1 →

Rate limit · Gmail

The sending Google account has used up its daily limit of messages or recipients. It resets within about 24 hours.

• Stop sending from that mailbox until the limit resets, then resume at a lower daily volume.
• Spread volume across more mailboxes - the cap is per account.

Full guide to 550 5.4.5 → · Plan volume with the Warm-Up Calculator →

Configuration · Gmail

The account has 2-Step Verification on, so a normal password doesn't work for SMTP. The client has to log in with an app password.

• Create an app password in the Google account's security settings and use it in the SMTP login.
• On Workspace, the admin may need to allow app passwords or use OAuth instead.

Full guide to 534 5.7.9 →

Reputation or blocklist · Outlook / Microsoft

Outlook.com has blocked this sending address after detecting spam-like patterns. It's a reputation block on the IP, not a one-off.

• Contact Microsoft through the sender support form for outlook.com delivery issues, giving the IP and what you've changed.
• Clean the list and stop sending to the affected recipients until it lifts.
• If the IP is shared, ask the provider - it may be another customer's behaviour.

Full guide to 550 5.7.511 → · Check the IP and domain on the Blacklist Checker →

Reputation or blocklist · Outlook / Microsoft

Microsoft's filtering has banned this IP address, usually after spam or compromised-account activity from it or from its range.

• Check the IP on the Blacklist Checker, then request delisting through Microsoft's sender support (sender.office.com).
• Find and stop whatever sent the bad mail before requesting removal - a request made while the cause persists is declined.

Full guide to 550 5.7.606 → · Check the IP and domain on the Blacklist Checker →

Reputation or blocklist · Outlook / Microsoft

Microsoft 365 rejects traffic from this IP because of its reputation, often on shared or newly-allocated IPs and ranges.

• Request mitigation via Microsoft's delist portal for the IP.
• If you're on a shared IP, move to a dedicated one or a different provider.

Full guide to 550 5.7.708 → · Check the IP and domain on the Blacklist Checker →

Reputation or blocklist · Outlook / Microsoft

Microsoft is throttling this IP because of its reputation. Mail is deferred, not refused, and is accepted again as reputation recovers.

• Reduce volume and let the queue retry slowly.
• Review bounce and complaint rates and clean the list; check the IP for listings.

Full guide to 451 4.7.650 → · Check the IP and domain on the Blacklist Checker →

Rate limit · Outlook / Microsoft

Outlook.com is throttling mail from this IP (codes in the 4.7.500 - 4.7.699 range). It usually appears when volume jumps or a new IP starts sending.

• Let the mail queue retry; don't resend manually on top of it.
• Lower the sending rate per connection and ramp up more gradually.

Full guide to 451 4.7.500 / 4.7.xxx → · Plan volume with the Warm-Up Calculator →

Authentication · Outlook / Microsoft

The sending domain has a DMARC policy of reject, and this message failed DMARC, so Outlook.com refused it.

• Make SPF or DKIM pass and align with the From domain for whatever sent this message.
• Check the DMARC record and aggregate reports to find the unauthorised or misconfigured sender.

Full guide to 550 5.7.509 → · Check the DMARC record →

Authentication · Outlook / Microsoft

Outlook.com requires SPF, DKIM and DMARC for senders above its high-volume threshold. This sender didn't meet that level.

• Publish SPF and DKIM for the sending domain and a DMARC record with at least p=none.
• Ensure SPF or DKIM aligns with the visible From domain.

Full guide to 550 5.7.515 → · Check the DMARC record →

Reputation or blocklist · Outlook / Microsoft

Part of the network the sending IP belongs to is on Outlook.com's block list (S3150) or a public one such as Spamhaus.

• Check the IP on the Blacklist Checker to see which list it is.
• Ask your ISP or host to resolve it - the listing is on the range they own.

Full guide to S3150 / Spamhaus → · Check the IP and domain on the Blacklist Checker →

Bad address · Exchange Online

The recipient domain uses Microsoft 365 with directory-based edge blocking, and no mailbox matches this address. In practice it's a bad address.

• Remove or correct the address; it will never deliver.
• Verify addresses before sending - frequent hits like this raise your bounce rate.

Full guide to 550 5.4.1 →

Bad address · Exchange Online

RESOLVER.ADR.RecipientNotFound - Microsoft 365 couldn't find a mailbox, group or contact for this address.

• Check the spelling and the domain, or remove the address.
• If it should exist, the recipient's admin has to create or restore it.

Full guide to 550 5.1.10 →

Reputation or blocklist · Yahoo / AOL

Yahoo is deferring mail from this IP because of unexpected volume or user complaints. It's a temporary reputation throttle, not a refusal.

• Cut the volume and spread the send over more hours; keep retrying through the normal queue.
• Reduce complaints: remove unengaged recipients, make the unsubscribe easy, and match the content to what people signed up for.

Full guide to 421 4.7.0 [TSS04] → · Plan volume with the Warm-Up Calculator →

Policy · Yahoo / AOL

Yahoo refused the message on policy grounds - most often a failed DMARC policy or content that matched its spam filters.

• Check SPF, DKIM and DMARC alignment for the From domain.
• Run the same email through the Spam Test and remove spam-trigger content and link shorteners.

Full guide to 554 5.7.9 → · Test the email with the Spam Test →

Reputation or blocklist · Yahoo / AOL

Yahoo refused the connection because the sending IP is listed in a DNS blocklist it uses.

• Check the IP on the Blacklist Checker and follow the listing's removal steps.
• Find out why it was listed before requesting removal.

Full guide to 553 5.7.1 [BL21] → · Check the IP and domain on the Blacklist Checker →

Reputation or blocklist · Spamhaus

The PBL (Policy Block List) lists IP ranges that shouldn't deliver mail straight to other servers - typically home, office or dynamic addresses. It's not a spam judgement on you, it's a policy.

• Send through your provider's authenticated SMTP relay or an email service instead of directly from this IP.
• If the IP is a static business address you control, the owner can ask Spamhaus to remove it.

Full guide to Spamhaus PBL → · Check the IP and domain on the Blacklist Checker →

Reputation or blocklist · Spamhaus

A domain used in the message - the sender, a link or the return path - is on Spamhaus's Domain Block List. The block follows the domain, not the sending IP.

• Check every domain used in the email on the Blacklist Checker, including tracking and link domains.
• Request delisting only after the cause is fixed; replace a listed link or tracking domain.

Full guide to Spamhaus DBL → · Check the IP and domain on the Blacklist Checker →

Reputation or blocklist · Spamhaus

The sending IP is listed by Spamhaus - SBL for spam sources, XBL for exploited or infected machines, or the ZEN combination of all of them.

• Look up the IP at Spamhaus or on the Blacklist Checker to see which list and the reason.
• XBL usually means a compromised account or machine: clean it up first, then request removal.
• On a shared IP, move providers or ask them to resolve it.

Full guide to Spamhaus ZEN / SBL / XBL → · Check the IP and domain on the Blacklist Checker →

Reputation or blocklist · Barracuda

Barracuda Reputation Block List lists this IP, and Barracuda-protected recipients refuse mail from it.

• Check the IP on the Blacklist Checker and use Barracuda's free removal request.
• Fix the cause - high volume to bad addresses, a compromised account or an open relay - or it will be relisted.

Full guide to Barracuda BRBL → · Check the IP and domain on the Blacklist Checker →

Reputation or blocklist · SpamCop

SpamCop lists IPs after users report mail from them as spam. Listings expire on their own after a day or two if the reports stop.

• Wait for it to expire once the reports stop, or request removal.
• Reduce complaints at the source - the reports come from recipients.

Full guide to SpamCop → · Check the IP and domain on the Blacklist Checker →

Reputation or blocklist · Proofpoint

The recipient uses Proofpoint, which blocked the message on IP reputation or content. The bounce usually includes a Proofpoint lookup link for the IP.

• Open the lookup link in the bounce to see the reason, and submit the IP there for review.
• Check blacklists and content, since Proofpoint draws on many reputation sources.

Full guide to Proofpoint block → · Check the IP and domain on the Blacklist Checker →

Reputation or blocklist · Mimecast

The recipient's gateway is Mimecast and it refused the message - for IP reputation, failed authentication, a policy set by that company, or content.

• Read the exact text after 'Mimecast' in the bounce - it names the policy.
• Check SPF/DKIM/DMARC, blacklists and content; if all clean, ask the recipient's IT to allow-list you.

Full guide to Mimecast rejection → · Run the Domain Health Check →

Authentication

The receiving server checked SPF and the sending IP isn't authorised in the domain's SPF record (or the record is broken), so it refused the message.

• Add the sending service or IP to the SPF record, keeping the total under 10 DNS lookups.
• Make sure there is only one SPF record on the domain.

Full guide to 550 5.7.23 → · Check the SPF record →

Authentication

The receiver needed a valid DKIM signature and either found none or couldn't verify the one on the message.

• Enable DKIM signing at your sending service and publish the public key it gives you at the selector it names.
• Check that nothing alters the message after signing (footers, link rewriting by a gateway).

Full guide to DKIM failure → · Check the DKIM record →

Configuration

The receiver looked up the sending IP's PTR record and found none, or found a hostname that doesn't resolve back to that IP.

• Have the IP's owner set a PTR record to a hostname you control, and point that hostname's A record back at the IP.
• Use the same hostname in the SMTP HELO/EHLO greeting.

Full guide to Reverse DNS / PTR →

Configuration

The server announced itself with a hostname the receiver won't accept - not a fully-qualified domain name, an IP literal or one that doesn't resolve.

• Configure the mail server to greet with a real, resolvable hostname (mail.yourdomain.com), not 'localhost' or the bare IP.
• Make that hostname match the IP's reverse DNS.

Full guide to HELO rejected →

Configuration

The receiver couldn't find DNS for the domain in the envelope or From address - it doesn't exist, has expired or its DNS is broken.

• Check the sending domain's registration and nameservers - it may have expired.
• Confirm it has A or MX records, then retry.

Full guide to 4.1.8 / sender domain not found → · Look up the MX records →

Configuration

The server you connected to isn't willing to relay this message: either you didn't authenticate to it, or the recipient's domain isn't one it handles.

• If you sent through your own provider: turn on SMTP authentication in the sending app.
• If you're sending to a recipient's server directly, check the recipient domain's MX - you may be sending to the wrong host.

Full guide to 550 5.7.1 Relay denied → · Look up the MX records →

Rate limit

The server deliberately defers first-time senders and expects a legitimate mail system to retry. Real mail servers retry automatically and the message goes through a few minutes later.

• Do nothing - the sending server retries by itself.
• If your sending tool doesn't retry deferrals, switch to one that does.

Full guide to Greylisting →

Configuration

The server only accepts mail over an encrypted connection and you didn't upgrade the session with STARTTLS before sending.

• Enable TLS/STARTTLS in the SMTP client settings (port 587 with STARTTLS, or 465 with SSL).
• Make sure the sending server supports modern TLS versions.

Full guide to 530 5.7.0 →

Configuration

The mail server rejected the credentials used to log in. Nothing about the recipient or content is involved - the message never left your side.

• Re-enter the username (usually the full email address) and password; check for a trailing space.
• For Gmail and Microsoft accounts with 2-step verification, use an app password.
• If it worked before, the password may have been changed or the account locked.

Full guide to 535 5.7.8 →

Rate limit · Gmail

The mail server is temporarily refusing logins after too many attempts, often from several tools connecting at once or a wrong password retried repeatedly.

• Stop all tools using that mailbox for 15-30 minutes, then reconnect once.
• Check that the credentials are right so retries don't keep failing.

Full guide to 454 4.7.0 →

Recipient mailbox

The recipient's mailbox is over its storage quota and can't take new mail. Some servers treat it as temporary, others reject it outright.

• It's the recipient's problem - retry later, or reach them another way.
• Don't keep resending: repeated attempts add to your bounce count for nothing.

Full guide to 552 5.2.2 →

Content

The message, with attachments and encoding overhead, is bigger than the recipient's server accepts.

• Remove or shrink attachments; for cold email, send a link instead of a file.
• Remember that attachments grow about a third when encoded.

Full guide to 552 5.3.4 / 5.2.3 →

Content

The receiving filter scored the message as spam based on its content - wording, links, images or HTML - or flagged a URL in it.

• Run the exact email through the Spam Test and the Spam Word Checker.
• Remove link shorteners, tracking-domain redirects, all-caps and image-only layouts, and add a plain-text part.
• If a specific URL is named, check that domain on a blacklist.

Full guide to Rejected as spam / content → · Test the email with the Spam Test →

Bad address

The domain exists, but there is no mailbox with that name. The most common hard bounce and the most damaging one to your sender reputation if you keep sending to it.

• Remove the address from your list now - it will never deliver.
• Check for a typo, then verify addresses in bulk before the next campaign.
• A bounce rate over about 2% is a warning sign; a list full of these needs cleaning.

Full guide to 5.1.1 →

Bad address

The part after the @ can't be found in DNS - a typo, an expired domain or one that has no mail records.

• Correct the domain or remove the address.
• Look up the domain's MX records to see if it can receive mail at all.

Full guide to 5.1.2 → · Look up the MX records →

Bad address

The recipient address is malformed - a missing @, spaces, double dots or illegal characters.

• Fix the address format or drop it from the list.
• Validate syntax when you import a list.

Full guide to 5.1.3 →

Recipient mailbox

The mailbox exists but is deactivated, suspended or set not to accept messages - often a former employee's address.

• Treat it as undeliverable and remove it.
• If it should work, the recipient's admin has to re-enable it.

Full guide to 5.2.1 →

Configuration

DNS or routing failed for the recipient's domain - no usable MX, or the mail server isn't reachable.

• Check the recipient domain's MX records.
• If the domain is yours, fix its DNS; if not, retry later and remove if it persists.

Full guide to 5.4.4 → · Look up the MX records →

Policy

The most common policy rejection. 5.7.1 says only that the receiver refused the message for a policy reason - reputation, blocklist, authentication or content. The text after the code tells you which.

• Read the full line after 5.7.1: look for a blocklist name, 'SPF', 'DMARC', 'IP reputation' or a URL.
• Check the sending IP and domain on blacklists and test authentication.
• If the text is only 'refused', run the email through the Spam Test.

Full guide to 5.7.1 → · Check the IP and domain on the Blacklist Checker →

Policy

A general security/policy rejection. The server didn't give a specific reason in the code itself.

• Look at the text after the code for the actual reason.
• Check authentication and blacklists as for 5.7.1.

Full guide to 5.7.0 → · Run the Domain Health Check →

Rate limit

The receiver is temporarily refusing, usually to slow you down: volume, reputation or load. Deferral means 'not now', and your server should retry.

• Let the queue retry - don't resend manually in parallel.
• If it happens repeatedly to one provider, lower the sending rate to it.

Full guide to 4.7.0 → · Plan volume with the Warm-Up Calculator →

Rate limit

The server is closing the connection for now: overloaded, rate limiting you or deferring on reputation. Temporary.

• Retry later and reduce sending speed to that provider.
• If it persists for days, treat it as a reputation problem and check blacklists.

Full guide to 421 → · Plan volume with the Warm-Up Calculator →

Recipient mailbox

The mailbox can't take the message right now - busy, greylisting, or a temporary policy. The sending server will retry.

• Wait; delivery usually succeeds on retry.
• If it keeps coming back as 450, treat the address as risky.

Full guide to 450 →

Rate limit

The receiving server hit a temporary problem or is deliberately delaying mail (greylisting, throttling). Temporary.

• Retry later.
• If it repeats, check what the text after the code says - reputation throttles are phrased as 451.

Full guide to 451 →

Rate limit

The server is out of space, or the message has more recipients than it accepts in one go.

• Send to fewer recipients per message.
• If the cause is storage on the recipient's side, retry later.

Full guide to 452 →

Policy

The generic permanent rejection. It can mean a bad mailbox, a blocklist, failed authentication or spam filtering - the enhanced code and text next to it say which.

• Find the x.y.z status code (like 5.1.1 or 5.7.1) in the same message and decode it.
• Don't retry the same message; fix the cause first.

Full guide to 550 → · Run the Domain Health Check →

Bad address

The server doesn't host this user and either won't forward or can't. Rare in modern mail.

• Check the address and the domain's MX records.

Full guide to 551 → · Look up the MX records →

Recipient mailbox

Either the recipient's mailbox is full or the message is larger than the server allows.

• Shrink or remove attachments; if the mailbox is full, retry later.

Full guide to 552 →

Bad address

The address is rejected for its form, or the sender address is not allowed to be used from this server.

• Check the recipient's syntax; if it is the sender that is rejected, make sure the From address is one you're allowed to send as.

Full guide to 553 →

Policy

The generic fatal error: the receiver refused the message, typically for spam, blocklist or policy. Read the text after it.

• Find the enhanced status (5.x.x) and the explanation text next to it.
• Check blacklists, authentication and content.

Full guide to 554 → · Check the IP and domain on the Blacklist Checker →