---
title: "SMTP reply and status codes"
description: "Look up an SMTP reply such as 550 5.7.26 or 421 4.7.0: what the basic and enhanced codes mean, whether to retry, and what to fix."
url: https://www.unitpost.com/tools/smtp-codes
section: Free tools
updated: 2026-11-02
---
# SMTP reply and status codes

An SMTP reply starts with a three-digit code: 2xx means accepted, 3xx means send more, 4xx is a temporary failure the sender should retry, and 5xx is permanent. Most servers add an enhanced status code such as 5.1.1, written class.subject.detail, whose middle number says what failed: 1 the address, 2 the mailbox, 4 routing, 7 security or policy. Search a code or a phrase from a bounce to see what it means and what to do.

> Interactive tool: https://www.unitpost.com/tools/smtp-codes. The search runs in your browser over a built-in table. Nothing you type is sent to Unitpost, and there's no sign-up.

## Common SMTP errors and fixes

### 421 4.3.2 (temporary)

The receiving server is not taking messages right now, for example during maintenance or a shutdown, and closes the connection. A mail server keeps the message queued and retries.

Causes:

- Planned maintenance, a restart or heavy load on the receiving server.
- Unitpost SMTP relay: during scheduled maintenance the relay answers every connection with `421 4.3.2 Service unavailable: scheduled maintenance, retry later`.

Fixes:

1. Nothing to change in your setup: a standard mail server keeps the message in its queue and retries.
2. If your app speaks SMTP directly without a queue, retry with backoff instead of treating 421 as a failed send.
3. For the Unitpost relay, check the maintenance window on the [status page](https://status.unitpost.com).

### 421 4.7.0 (temporary)

Seen as: "Try again later, closing connection."; "This message is suspicious due to the very low reputation of the sending IP address. To protect our users from spam, email sent from your IP address has been temporarily rate limited."; "This message is suspicious due to the very low reputation of the sending domain. To best protect our users from spam, the message has been blocked."; "This message is suspicious due to the nature of the content or the links within. To best protect our users from spam, the message has been blocked."; "The IP address sending this message does not have a PTR record, or the corresponding forward DNS entry does not point to the sending IP. To protect our users from spam, email sent from your IP address has been temporarily rate limited."; "TLS required for RCPT domain, closing connection."

A temporary refusal for a security or policy reason. Gmail uses it for low IP or domain reputation, suspicious content or links, a missing PTR record and recipient domains that require TLS, so the text decides the fix.

Causes:

- Low reputation of the sending IP or domain, often after a volume spike or spam complaints.
- Content or links that look suspicious, such as public URL shorteners or linked domains with a poor reputation.
- The sending IP has no PTR record, or the PTR hostname does not resolve back to the same IP.
- Yahoo documents its temporary 421 and 451 deferrals as caused by complaints, spam-like content or unusual traffic from the sending IP.

Fixes:

1. Let your server retry with backoff and hold new bulk sends until the deferrals stop. See [how to recover a damaged sender reputation](/blog/deliverability/recover-sender-reputation).
2. Drop shortened links and links to domains with a poor reputation. See [email copy that hurts deliverability](/blog/deliverability/email-copy-deliverability).
3. Give each sending IP a PTR record whose hostname has an A or AAAA record pointing back to the same IP. On an email service, the service owns this.
4. When the text says TLS is required, send over STARTTLS or implicit TLS.

### 421 4.7.26 (temporary)

Seen as: "This email has been rate limited because it is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM."

Gmail is rate limiting the message because it passed neither SPF nor DKIM. Gmail requires every sender to pass at least one of them.

Causes:

- The message has no DKIM signature, or the DKIM key in DNS is missing, truncated or on the wrong host.
- The sending IP is not in the SPF record of the return-path (envelope sender) domain.
- DNS records for a newly added domain have not propagated yet.

Fixes:

1. Check SPF with the [SPF checker](/tools/spf-checker) and your DKIM selector with the [DKIM checker](/tools/dkim-checker).
2. Publish the DKIM key exactly as your sending service gives it, at selector._domainkey on your domain. See [DKIM verification failing](/blog/troubleshooting/dkim-verification-failing).
3. Add every service that sends for the domain to a single SPF record on the return-path domain. See [SPF record not found](/blog/troubleshooting/spf-record-not-found).

### 421 4.7.28 (temporary)

Seen as: "Gmail has detected an unusual rate of email. To protect our users from spam, email has been temporarily rate limited."; "Gmail has detected an unusual rate of email originating from your IP address <ip-address>. To protect our users from spam, email sent from your IP address has been temporarily rate limited."; "Gmail has detected an unusual rate of unsolicited email originating from your DKIM domain <domain-name>. To protect our users from spam, email sent from your domain has been temporarily rate limited."; "Gmail has detected an unusual rate of unsolicited email originating from your SPF domain <domain-name>. To protect our users from spam, email sent from your domain has been temporarily rate limited."; "Gmail has detected an unusual rate of unsolicited email containing one of your URL domains. To protect our users from spam, email with the URL has been temporarily rate limited."; "Gmail has detected this sender exceeded the quota for sending messages that have the same Message-ID:. To best protect our users, the message has been temporarily rejected."

Gmail is deferring mail because the rate of mail, or of unwanted mail, from your IP, netblock, DKIM domain, SPF domain or a linked domain is unusual for your history. It is temporary; slow down rather than resend.

Causes:

- A send far above the domain's or IP's recent volume, such as a first campaign from a new domain.
- Recipients marking the mail as spam, so the same volume counts as unsolicited.
- Several campaigns close together, or retries piling on top of new sends.
- Many messages sharing one Message-ID header.

Fixes:

1. Stop sending for at least 10 minutes, resume over a single connection, then add connections one at a time, as Gmail's sender guidelines describe.
2. Spread the remaining volume over the next days, most engaged recipients first. See [how to warm up a new sending domain](/blog/deliverability/warm-up-new-sending-domain).
3. Remove old, imported and never-confirmed addresses before the next send. See [email list hygiene](/blog/deliverability/email-list-hygiene).
4. Give every message its own unique Message-ID.

### 421 4.7.32 (temporary)

Seen as: "Your email has been rate limited because the From: header (RFC5322) in this message isn't aligned with either the authenticated SPF or DKIM organizational domain."

Gmail is rate limiting the message because the From domain does not match the domain that passed SPF or DKIM, so DMARC cannot pass. Gmail's table also lists a blocking form of the same text with enhanced code 5.7.32.

Causes:

- DKIM signs with the sending service's domain instead of yours.
- The return-path uses the sending service's domain, so SPF passes for that domain and not for yours.

Fixes:

1. Sign DKIM with your own domain, so the d= domain matches the From domain.
2. Use a return-path (MAIL FROM) subdomain of your own domain. Unitpost publishes both when you verify a sending domain.
3. Paste a test message's headers into the [email header analyzer](/tools/email-header-analyzer) to see which domains SPF and DKIM passed for. See [DMARC alignment](/blog/deliverability/bulk-sender-requirements-gmail-yahoo-microsoft#alignment).

### 450 4.2.1 (temporary)

Seen as: "The user you are trying to contact is receiving email too quickly. Please resend your message at a later time. If the user is able to receive email at that time, your message will be delivered."; "The user you are trying to contact is receiving email at a rate that prevents additional messages from being delivered. Please resend your message at a later time. If the user is able to receive email at that time, your message will be delivered."

The recipient's mailbox is getting mail faster than Gmail allows, so more is deferred for now. The limit is on that recipient's incoming mail, not your overall sending.

Causes:

- Many messages to the same recipient in a short time, such as a notification loop or one email per event.
- The recipient is receiving a flood of mail from many senders at once.

Fixes:

1. Let your server retry later; the message is delivered once the recipient's rate drops.
2. Throttle or batch mail per recipient, for example a digest instead of one email per event.

### 450 4.7.1 (temporary)

A temporary refusal for a policy reason: the server will not take the message now but may later. A mail server keeps it queued and retries.

Causes:

- Greylisting: the receiver turns away a sender it has not seen before and accepts a later retry.
- Unitpost SMTP relay: the workspace subscription is inactive. The relay answers 450 4.7.1 so your server keeps the mail queued until billing is resolved.

Fixes:

1. Let your server retry on its normal schedule. Greylisting clears when the same server tries again after a delay.
2. On Unitpost, resolve billing in Settings, Billing; your server's next retry then goes through.

### 451 4.3.0 (temporary)

Seen as: "Email server has temporarily rejected this message."; "Multiple destination domains per transaction is unsupported. Please try again."

A temporary error at the receiving server while it handled the message. The sending server should retry.

Causes:

- A transient fault or overload on the receiving side.
- At Gmail, recipients at more than one domain in a single SMTP transaction.
- Unitpost SMTP relay: a temporary internal error, or the API key check could not finish. The relay answers 451 4.3.0, not 535, so your client keeps its credentials and retries.

Fixes:

1. Let your server retry with backoff; a one-off needs no change.
2. Send to one recipient domain per transaction.
3. If the Unitpost relay keeps answering 451, check the [status page](https://status.unitpost.com).

### 451 4.4.0 (temporary)

Seen as: "DNS query failed"

A temporary network or routing problem. Most often the sending server could not resolve the recipient domain's mail servers, so it keeps the message queued and retries.

Causes:

- The DNS resolver the sending server uses is down or misconfigured.
- The recipient domain's DNS servers time out or answer some lookups, such as AAAA queries, unexpectedly.
- The recipient domain's MX record is missing or names a host that does not resolve.

Fixes:

1. Check the recipient domain's MX and A records with the [domain checker](/tools/domain-checker).
2. If mail to every domain fails, fix the resolver your mail server uses.
3. If only one domain fails for days, the problem is its DNS: tell its owner. The message expires from your queue eventually.

### 451 4.7.1 (temporary)

A temporary refusal for a policy reason. Greylisting is the classic case: the receiver turns away a sender it has not seen and accepts the same message on a later retry.

Causes:

- Greylisting of a new combination of sending IP, envelope sender and recipient.
- A temporary reputation or rate policy at the receiver.

Fixes:

1. Let your server retry on a normal schedule. A sender that never retries never gets past greylisting.
2. Retry from the same sending IP where you can, since some greylisting keys on the IP.
3. If it lasts for hours, slow down and check your reputation. See [email bounce codes explained](/blog/deliverability/email-bounce-codes-explained#retry-later).

### 451 4.7.500 (temporary)

Seen as: "Access denied, please try again later"

Microsoft 365 is throttling the sending IP because its volume changed sharply from its usual pattern. Microsoft documents 4.7.500 to 4.7.699 for this and calls it graylisting.

Causes:

- A new sending IP, or a sudden jump in volume from an IP with a steady history.
- Suspicious activity that Microsoft is still evaluating.

Fixes:

1. Let your server retry. Microsoft says the restriction lifts as the IP builds a sending history over a few days.
2. Ramp volume to Microsoft 365 domains gradually. See [how to warm up a new sending domain](/blog/deliverability/warm-up-new-sending-domain).

### 452 4.2.2 (temporary)

Seen as: "The recipient's inbox is out of storage space."

The recipient's mailbox is full. It is temporary: the message can be delivered once the owner frees up space.

Causes:

- The recipient has used up their storage quota.
- A mailbox nobody reads any more is filling up.

Fixes:

1. Let your server retry over its normal queue lifetime.
2. If the same address defers send after send, treat it as abandoned and stop mailing it. Gmail reports a full and inactive mailbox as 552 5.2.2.

### 452 4.5.3 (temporary)

Seen as: "Your message has too many recipients."; "Domain policy size per transaction exceeded, please try this recipient in a separate transaction."; "Too many recipients"

The transaction lists more recipients than the receiver accepts at once. Recipients past the limit are deferred, not rejected.

Causes:

- One SMTP transaction with a long RCPT TO list. Microsoft 365 documents a limit of 200 envelope recipients from the same domain.
- A newsletter sent as one message to many recipients instead of one message each.

Fixes:

1. Split recipients across several transactions; standard mail servers do this when they get a 452.
2. Send one message per recipient, which also gives each person their own unsubscribe link and bounce handling.

### 452 4.7.0 (temporary)

A temporary refusal for a security or policy reason with no more specific code. On the Unitpost relay it means a rate limit or quota: retry later.

Causes:

- Unitpost SMTP relay: the workspace hit its sending rate limit.
- Unitpost SMTP relay: the plan's email quota for the period is used up, or the overage cap is reached.

Fixes:

1. Let your mail server retry with backoff.
2. Spread large sends over time instead of one burst.
3. If the period's quota is used up, raise it or the overage cap in Settings, Billing.

### 530 5.7.0 (permanent)

Seen as: "Authentication required."; "Must issue a STARTTLS command first."

The server requires authentication, or TLS before authentication, and the client sent mail commands without it.

Causes:

- The SMTP client has no username and password set, or never sends AUTH.
- The client tried to authenticate on port 587 before STARTTLS.
- Unitpost SMTP relay: MAIL FROM before AUTH gets `530 Error: authentication Required`, and AUTH before STARTTLS gets `538 Error: Must issue a STARTTLS command first`.

Fixes:

1. Turn on authentication in the client and set the username and password.
2. Use STARTTLS on port 587, or implicit TLS on port 465.
3. For Unitpost, the username is `unitpost` and the password is an API key with emails:send. See the [SMTP guide](/docs/smtp).

### 534 5.7.9 (permanent)

Seen as: "Application-specific password required."; "Please log in with your web browser and then try again."

The sign-in method is weaker than the server allows for this account. At Gmail it means the account password is not accepted from this app: use an app password or OAuth.

Causes:

- The Google account has 2-Step Verification, and the client sends the regular account password.
- The client only supports password sign-in, and Google requires a stronger method for this account.

Fixes:

1. Create an app password in the Google account and use it in place of the account password.
2. Or switch the client to OAuth (XOAUTH2) if it supports it.
3. For app or server mail, send through an SMTP relay or email API with its own credentials rather than a personal mailbox.

### 535 5.7.8 (permanent)

Seen as: "Username and Password not accepted."

Authentication failed: the server rejected the username, password or key. Retrying with the same credentials fails the same way.

Causes:

- A wrong username or password, or one that was changed or revoked.
- At Gmail, the account password used where an app password or OAuth is required.
- Unitpost SMTP relay: the username is not `unitpost`, the API key is wrong, revoked or missing, or the workspace is suspended. The reply text says which.

Fixes:

1. Re-enter the credentials, watching for spaces copied along with them.
2. For Gmail, use an app password or OAuth.
3. For Unitpost, set the username to `unitpost` and the password to a current API key, or create a new key in [API keys](/dashboard/api-keys).

### 550 5.1.1 (permanent)

Seen as: "The email account that you tried to reach does not exist. Please double-check the recipient's email address for typos or unnecessary spaces."

The mailbox does not exist at the destination. It is a hard bounce: the address fails every time.

Causes:

- A typo in the part before the @.
- An account that was closed or deleted, common on old lists.
- An address that was never real, such as one typed into a form without confirmation.

Fixes:

1. Remove the address. Unitpost adds hard-bounced addresses to your suppression list automatically.
2. Correct a typo only when the person confirms the address.
3. Confirm signups with double opt-in so bad addresses never reach the list. See [email list hygiene](/blog/deliverability/email-list-hygiene).

### 550 5.1.10 (permanent)

Seen as: "Recipient not found"

Microsoft 365 could not find the recipient's address in the recipient organization. It is Microsoft's unknown-recipient hard bounce.

Causes:

- A typo in the address, or an address that was removed.
- A forwarding rule at the recipient that points to an address that no longer exists.
- Spam sent with your address forged as the sender, so the bounce reaches you although you sent nothing (backscatter).

Fixes:

1. Check the address and remove it if it is wrong, as with 550 5.1.1.
2. If the address is right, ask the recipient to check their forwarding rules.
3. If you never sent the message, publish SPF, DKIM and DMARC so receivers can reject forgeries of your domain. Check them with the [DMARC checker](/tools/dmarc-checker).

### 550 5.2.1 (permanent)

Seen as: "The email account that you tried to reach is inactive."; "The user you are trying to contact is receiving email at a rate that prevents additional messages from being delivered."

The mailbox exists but is not accepting mail. At Gmail this usually means the account is inactive; Gmail also uses it when the recipient is getting mail too fast.

Causes:

- The account was disabled, or left unused long enough to become inactive.
- The recipient is receiving more mail than Gmail lets through.

Fixes:

1. For an inactive account, stop mailing the address.
2. For the rate case, mail that recipient less often before trying again.

### 550 5.4.1 (permanent)

Seen as: "Recipient address rejected: Access denied"; "Relay Access Denied"

Microsoft 365 refused the recipient at the edge of its network. Either the address does not exist in the recipient organization (Directory-Based Edge Blocking), or the server does not accept mail for that domain.

Causes:

- The address does not exist in the recipient's Microsoft 365 organization.
- The recipient domain's MX record points to Microsoft 365, but the domain is not set up there or has moved.

Fixes:

1. Check the address; if it is wrong, remove it as you would after a 5.1.1.
2. Look up the domain's MX records with the [domain checker](/tools/domain-checker). If the address is right and the MX points to Microsoft, tell the recipient's administrator.

### 550 5.4.5 (permanent)

Seen as: "Daily user sending limit exceeded."; "Daily SMTP relay limit exceeded for user."

The Gmail or Google Workspace account you send through has reached its daily sending limit. It is about your sending account, not the recipient.

Causes:

- An app or server sending through a personal Gmail or Workspace mailbox past its daily limit.
- A sudden spike from a script, or from a compromised account.

Fixes:

1. Wait for the limit to reset before sending more from that account.
2. Send app and bulk mail through an SMTP relay or email API with a verified domain instead of a personal mailbox. See the [SMTP guide](/docs/smtp).

### 550 5.7.1 (permanent)

Seen as: "The user or domain that you are sending to (or from) has a policy that prohibits the email that you sent."; "This message is likely unsolicited email. To reduce the amount of spam sent to Gmail, this message has been blocked."; "This message is likely suspicious due to the very low reputation of the sending IP address. To best protect our users from spam, the message has been blocked."; "This message is likely suspicious due to the very low reputation of the sending domain. To best protect our users from spam, the message has been blocked."; "Messages missing a valid Message-ID: header are not accepted."; "Delivery not authorized"; "Unable to relay"; "Client was not authenticated"

A permanent refusal for a security or policy reason: spam and reputation blocks, recipient or domain policies, relay denial and malformed headers all use it, so the text decides the fix. It says nothing bad about the address itself.

Causes:

- Gmail judged the message likely unsolicited, or the sending IP or domain has a very low reputation.
- A recipient or domain policy, such as a group that only accepts mail from members, or a mail flow rule.
- Relay denied: the client connected to a server that is not the recipient's and did not authenticate.
- Unitpost SMTP relay: the From domain is not verified in your workspace, the API key lacks emails:send, or the workspace is suspended. The reply text names which.

Fixes:

1. For a spam or reputation block, pause bulk sends and fix the cause: list source, complaints, volume. See [how to recover a damaged sender reputation](/blog/deliverability/recover-sender-reputation).
2. Keep the address. A policy block is about the sender or the message, not the mailbox.
3. For a relay error, authenticate to your submission server, or deliver to the recipient domain's MX host.
4. On Unitpost, verify the sending domain in [Domains](/dashboard/email/domains) and send with a key that has emails:send.

### 550 5.7.23 (permanent)

Seen as: "The message was rejected because of Sender Policy Framework violation"

SPF failed: the sending IP is not authorized by the SPF record of the envelope sender's domain, and the receiver rejects SPF failures.

Causes:

- The SPF record does not include the server or service that sent the message.
- SPF published on the From domain while the return-path uses a different domain.
- The message was forwarded by a server that is not in your SPF record.

Fixes:

1. Check the record with the [SPF checker](/tools/spf-checker) and list every service that sends for the domain in one SPF record.
2. Publish SPF on the domain in the return-path, which is the one receivers check. See [SPF record not found](/blog/troubleshooting/spf-record-not-found).
3. Sign with DKIM too, so forwarded mail can still pass DMARC.

### 550 5.7.25 (permanent)

Seen as: "This message was blocked because the sending IP address doesn't have a PTR record, or the forwarding DNS entry doesn't reference the sending IP address. Gmail requires that sending IP addresses have a PTR record."; "Access denied, the sending IPv6 address [2a01:111:f200:2004::240] must have a reverse DNS record"

The sending IP failed a reverse DNS check: it has no PTR record, or the PTR hostname does not resolve back to the same IP.

Causes:

- A server sending directly from an IP with no PTR record, common on new cloud servers and home connections.
- A PTR hostname whose A or AAAA record points to a different IP.
- Sending over IPv6 from an address without reverse DNS.

Fixes:

1. Ask whoever controls the IP to set a PTR record naming a hostname, and give that hostname an A or AAAA record pointing back to the IP.
2. Or send through an email service whose sending IPs already have matching forward and reverse DNS.

### 550 5.7.26 (permanent)

Seen as: "This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM."; "The (E)MAIL FROM domain [<domain-name>] has an SPF record with a hard fail policy (-all) but it fails to pass SPF checks with the ip: [<ip-address>]. To best protect our users from spam and phishing, the message has been blocked."; "Unauthenticated email from <domain-name> is not accepted due to domain's DMARC policy."

Gmail blocked the message because authentication failed: neither SPF nor DKIM passed, SPF hard failed under -all, or the From domain's DMARC policy refuses it.

Causes:

- No valid DKIM signature for your domain, and the sending IP is not in SPF.
- An SPF record ending in -all that does not list the server that sent this message.
- A DMARC policy on the From domain, with neither SPF nor DKIM aligned to that domain.
- Someone else sending with your domain in the From address; then the block is working as intended.

Fixes:

1. Check the domain with the [SPF checker](/tools/spf-checker), [DKIM checker](/tools/dkim-checker) and [DMARC checker](/tools/dmarc-checker).
2. Sign DKIM with your own domain and list every sending service in SPF on the return-path domain.
3. Fix authentication before resending; the same message gets the same block. See [email bounce codes explained](/blog/deliverability/email-bounce-codes-explained#fix-authentication).

### 550 5.7.27 (permanent)

Seen as: "This message was blocked because it didn't pass SPF authentication. Gmail requires bulk email senders to authenticate their email with SPF."

Gmail blocked bulk mail because SPF did not pass. IANA registers X.7.27 for a sender domain with a null MX; Gmail uses the code for SPF failures, and 421 4.7.27 is its rate-limited form.

Causes:

- The sending IP is not in the SPF record of the return-path domain.
- An SPF record that cannot be evaluated: two SPF records, or more than 10 DNS lookups.
- SPF published on the From domain while the return-path uses another domain.

Fixes:

1. Check SPF with the [SPF checker](/tools/spf-checker) and fix it on the return-path domain. See [SPF record not found](/blog/troubleshooting/spf-record-not-found).
2. Merge duplicate SPF records into one, and remove includes you no longer use to stay within 10 lookups.
3. Gmail also expects DKIM and DMARC from bulk senders. See [bulk sender requirements](/blog/deliverability/bulk-sender-requirements-gmail-yahoo-microsoft).

### 550 5.7.28 (permanent)

Seen as: "There is an unusual rate of unsolicited email originating from your IP address. To protect our users from spam, email sent from your IP address has been blocked."

Gmail is blocking mail from your IP because of an unusual rate of unwanted mail. It is the blocking form of 421 4.7.28: these messages are not retried.

Causes:

- A large send to people who did not ask for it, such as an old or imported list.
- High spam complaint rates on earlier sends.
- Volume far above the IP's sending history.

Fixes:

1. Stop bulk sends from that IP and find what changed: list source, volume or content.
2. Mail only people who opted in, and remove addresses that have not engaged in months. See [email list hygiene](/blog/deliverability/email-list-hygiene).
3. Keep the spam rate in Google Postmaster Tools under 0.3%. See [how to recover a damaged sender reputation](/blog/deliverability/recover-sender-reputation).

### 550 5.7.30 (permanent)

Seen as: "This message was blocked because it didn't pass DKIM authentication. Gmail requires bulk email senders to authenticate their email with DKIM."

Gmail blocked bulk mail because DKIM did not pass. IANA registers X.7.30 for REQUIRETLS; Gmail uses the code for DKIM failures, and 421 4.7.30 is its rate-limited form.

Causes:

- The message is not DKIM signed.
- The DKIM public key in DNS is missing, truncated or published under the wrong selector host.
- Something changed the message after it was signed, such as a gateway adding a footer.

Fixes:

1. Take the selector from the DKIM-Signature header and check it with the [DKIM checker](/tools/dkim-checker).
2. Republish the key exactly as your sending service gives it. See [DKIM verification failing](/blog/troubleshooting/dkim-verification-failing).

### 550 5.7.57 (permanent)

Seen as: "Client was not authenticated to send anonymous mail during MAIL FROM"

Microsoft 365's SMTP submission endpoint refused the message because the app or device did not authenticate before MAIL FROM.

Causes:

- The app or device has wrong or missing credentials for a mailbox in Exchange Online.
- The client cannot negotiate TLS, which Microsoft requires before authentication.

Fixes:

1. Check the username and password in the app or device settings.
2. Turn on STARTTLS on port 587.

### 550 5.7.509 (permanent)

Seen as: "Access denied, sending domain [$SenderDomain] does not pass DMARC verification and has a DMARC policy of reject."

Microsoft rejected the message because the From domain failed DMARC and that domain publishes p=reject.

Causes:

- Neither SPF nor DKIM passes in alignment with the From domain.
- A sending service that does not sign DKIM with your domain or use it in the return-path.
- A mailing list or forwarder that changed the message and broke the original authentication.
- Mail forged with your domain; then the rejection is DMARC doing its job.

Fixes:

1. Check alignment with the [DMARC checker](/tools/dmarc-checker): the DKIM d= domain or the return-path domain must match the From domain.
2. Set every service that sends as your domain to sign DKIM with it. See [DMARC alignment](/blog/deliverability/bulk-sender-requirements-gmail-yahoo-microsoft#alignment).
3. If legitimate mail is failing, move the policy to p=quarantine or p=none while you fix it, and back to p=reject once aggregate reports show it aligned.

### 550 5.7.515 (permanent)

Seen as: "Access denied, sending domain <domain> does not meet the required authentication level."

Outlook.com rejected mail from a high-volume sending domain that misses Microsoft's authentication requirements: SPF and DKIM must both pass, and DMARC must pass with at least p=none.

Causes:

- The domain sends 5,000 or more messages to Microsoft consumer addresses (Outlook.com, Hotmail, Live.com, MSN) without SPF, DKIM or a DMARC record.
- DMARC fails because neither SPF nor DKIM aligns with the From domain.
- A sending service that does not sign DKIM with your domain.

Fixes:

1. Publish SPF and DKIM for the domain and make sure both pass.
2. Publish a DMARC record at _dmarc, for example v=DMARC1; p=none. Build one with the [DMARC generator](/tools/dmarc-generator) and check it with the [DMARC checker](/tools/dmarc-checker).
3. Align the return-path or DKIM domain with the From domain. See [bulk sender requirements](/blog/deliverability/bulk-sender-requirements-gmail-yahoo-microsoft).

### 550 5.7.606 (permanent)

Seen as: "Access denied, banned sending IP [Source IP address]: To request removal from this list please visit https://sender.office.com/ and follow the directions."; "Access denied, banned sending IP [IP1.IP2.IP3.IP4]"

Microsoft 365 has put the sending IP on its blocked senders list. Microsoft uses any code from 5.7.606 to 5.7.649 for this block.

Causes:

- Spam or malicious traffic from the IP, often from a compromised account or server.
- A shared IP whose other senders damaged its reputation.

Fixes:

1. Fix the cause first: secure compromised accounts and stop unwanted sends.
2. Request removal at the [Office 365 Anti-Spam IP Delist Portal](https://sender.office.com) with the IP from the bounce. Microsoft says it can take 24 hours or more.
3. If the code is 5.7.511 instead, the portal cannot delist the IP: email delist@microsoft.com with the full bounce and the IP.

### 552 5.2.2 (permanent)

Seen as: "The recipient's inbox is out of storage space and inactive."

The recipient's mailbox is full. At Gmail this code means full and inactive, so it will not clear: treat it as a hard bounce.

Causes:

- An abandoned mailbox that has filled up.
- In a Microsoft 365 bounce, 5.2.2 can instead mean the sender passed their own sending limits (Submission quota exceeded), often a sign of a compromised account.

Fixes:

1. Stop mailing the address.
2. If Microsoft returned it for your own account, check that account for compromise before sending again.

### 552 5.3.4 (permanent)

Seen as: "Your message exceeded Google's message size limits."; "The size of your message (<size> bytes) exceeded Google's message size limits of <limit> bytes."; "Your message exceeded Google's message header size limits."

The message, or its headers, is larger than the receiver's size limit. It fails the same way on every retry.

Causes:

- Large attachments. Base64 encoding makes them about a third larger on the wire.
- Too many attachments, or very long headers such as a huge Subject.
- Unitpost SMTP relay: the raw message is over 40 MB, and the relay answers `552 5.3.4 Message exceeds the 40 MB size limit.`

Fixes:

1. Link to large files instead of attaching them.
2. Compress or resize images and attachments before sending.
3. Keep headers short.

### 553 5.1.2 (permanent)

Seen as: "We weren't able to find the recipient domain. Please check for any spelling errors and make sure you didn't enter any spaces, periods, or other punctuation after the recipient's email address."

The recipient's domain could not be found or cannot receive mail. Usually a typo in the domain.

Causes:

- A misspelled domain, such as gmial.com.
- Spaces or punctuation after the address.
- A domain that expired or publishes no MX or A record.

Fixes:

1. Fix the typo if the person confirms the address; otherwise remove it.
2. Check the domain's MX records with the [domain checker](/tools/domain-checker).
3. Catch common domain typos at signup, before they reach your list.

### 553 5.1.3 (permanent)

Seen as: "The recipient address <address> is not a valid RFC 5321 address."

The recipient address is not valid syntax, so the server will not try to deliver it.

Causes:

- Spaces, a missing @ or characters that are not allowed in the address.
- A display name or extra text passed where a bare address was expected.
- Non-ASCII characters sent to a server that does not accept internationalized addresses.

Fixes:

1. Validate address syntax before sending, and trim whitespace.
2. Pass only the address in RCPT TO, without the display name.

### 554 5.4.6 (permanent)

Seen as: "Message exceeded 50 hops, this may show a mail loop."; "Hop count exceeded - possible mail loop"

The message passed through too many servers and was stopped as a likely mail loop. Microsoft's on-premises Exchange Server reports it as 5.4.6, and Exchange Online reports the same condition as 5.4.14.

Causes:

- Two mailboxes or servers forwarding to each other.
- An MX record or connector that routes the domain back to the server that sent it.
- An auto-reply or forwarding rule that triggers another one.

Fixes:

1. Read the Received headers in the bounce to see which servers repeat.
2. Fix the forwarding rules on the mailboxes involved to break the loop.
3. Check the domain's MX records and routing so they point to the right server.

### 554 5.6.0 (permanent)

Seen as: "Email message is malformed. Not accepted."

The message content broke a rule the receiver enforces, such as malformed MIME or headers, and was refused. Resending the same message fails the same way.

Causes:

- A broken MIME structure, such as missing boundaries or bad encodings.
- Required headers missing, repeated or malformed.
- Unitpost SMTP relay: the message has no From, no recipients or no body, cannot be parsed, or fails validation, such as a template that is not published. The reply text names the problem.

Fixes:

1. Build messages with a mail library instead of by hand.
2. Make sure From, To, Date and Message-ID are each present once.
3. Fix the field the reply text names, then send again.

### 554 5.7.1 (permanent)

A permanent refusal for a security or policy reason. Servers use 554 and 550 interchangeably with 5.7.1; spam filtering, blocklists and relay denial are the usual cases.

Causes:

- The receiver's spam filter or a blocklist refused the message or the sending IP.
- Relay denied: the server does not accept mail for the recipient's domain from you.
- A recipient-side rule, such as a blocked sender or a blocked attachment type.
- Yahoo documents its permanent 553 and 554 refusals for DMARC or DKIM failures, content it will not accept, and IPs listed by Spamhaus.

Fixes:

1. Read the text for the blocklist or rule it names, and fix that cause before resending.
2. If a blocklist is named, fix the cause and then request delisting from that list.
3. For relay errors, deliver to the recipient domain's MX host, or authenticate to your own submission server.

## Reply codes

| Code | Meaning |
| --- | --- |
| 211 | A status or help reply, sent in answer to a command such as HELP. |
| 214 | Help text meant for a person reading the session, not for software. |
| 220 | The server is ready. It is the greeting when a connection opens, and also the reply to STARTTLS just before the TLS handshake (RFC 3207). |
| 221 | The server is closing the connection, usually in answer to QUIT. |
| 235 | AUTH worked and the client is signed in. Sent with enhanced code 2.7.0. |
| 250 | The command worked. After the end of the message data, it means the server has accepted the message and taken responsibility for it. |
| 251 | The recipient is not on this server, but the server will forward the message. Rare today. |
| 252 | The server will not confirm whether the address exists, but will accept a message for it and try to deliver it. |
| 334 | A step in an AUTH exchange: the server sends a base64 challenge and waits for the client's base64 answer. |
| 354 | The server is ready for the message after DATA. The client sends the message and ends it with a line holding only a dot. |
| 421 | The service is unavailable and the server is closing the connection. Receivers also use it for rate limits and deferrals, so the sender should retry later. |
| 432 | The user must switch to the selected AUTH mechanism, typically by signing in once with PLAIN. Sent with enhanced code 4.7.12. |
| 450 | The mailbox cannot take the message right now, for example because it is busy or temporarily blocked for policy reasons. The sender should retry later. |
| 451 | The server hit a local error and aborted the command. It is temporary, and receivers also use it for temporary policy refusals such as greylisting. |
| 452 | The server cannot take the message now for lack of storage. Servers also answer 452 when a transaction has more recipients than they accept, and the rest should be sent later. |
| 454 | AUTH failed because of a temporary server problem, so the client should retry later instead of asking for a new password. Sent with 4.7.0; RFC 3207 also uses 454 when TLS is temporarily unavailable. |
| 455 | The server cannot handle the parameters given with MAIL FROM or RCPT TO right now. |
| 500 | The command was not recognized or the line was too long. With enhanced code 5.5.6, it is the AUTH reply to a base64 line that is too long (RFC 4954). |
| 501 | The command was recognized, but its parameters or arguments have a syntax error. |
| 502 | The server does not implement this command. |
| 503 | Commands came in the wrong order, for example RCPT TO before MAIL FROM, or MAIL FROM before EHLO. |
| 504 | The server does not implement a parameter given with the command. |
| 521 | Sent instead of the 220 greeting: this host never accepts mail, so there is nothing to retry. |
| 530 | The server requires AUTH before this command. Sent with 5.7.0; servers that require TLS first also answer 530 with "Must issue a STARTTLS command first" (RFC 3207). |
| 534 | The chosen AUTH mechanism is weaker than the server allows for this user. Sent with 5.7.9. |
| 535 | AUTH failed because the credentials are wrong or not sufficient. Sent with 5.7.8. |
| 538 | The chosen AUTH mechanism may only be used over an encrypted connection. Sent with 5.7.11; RFC 4954 keeps it for historical reasons. |
| 550 | The action was refused and will not succeed on retry: no such mailbox, no access, or a policy rejection. The enhanced code and text say which. |
| 551 | The recipient is not on this server, and the server suggests another address to try. Rare today. |
| 552 | The message exceeds a storage limit, such as the message size limit or the mailbox quota. |
| 553 | The mailbox name is not allowed, often because the address syntax is wrong. |
| 554 | The transaction failed. As a greeting, it means the host offers no SMTP service to you; receivers also use it for policy and content rejections. |
| 555 | MAIL FROM or RCPT TO carried a parameter the server does not recognize or support. |
| 556 | A relay reports that the recipient's domain accepts no mail, usually because it publishes a null MX record (RFC 7505). Do not retry. |

## Enhanced status codes

| Code | Name | Meaning |
| --- | --- | --- |
| X.0.0 | Other undefined Status | A catch-all for when the server can only say whether the failure is temporary or permanent, not why. The text after the code usually carries the real reason. |
| X.1.0 | Other address status | Something about an address in the message caused the report, with no more specific reason given. |
| X.1.1 | Bad destination mailbox address | The mailbox does not exist at the destination: the part before the @ is wrong or was removed. Treat it as permanent and stop mailing the address. |
| X.1.2 | Bad destination system address | The domain after the @ does not exist or cannot receive mail, often because of a typo in the domain. |
| X.1.3 | Bad destination mailbox address syntax | The recipient address is not valid syntax, for example a missing @, stray spaces or characters that are not allowed. |
| X.1.4 | Destination mailbox address ambiguous | The address matches more than one mailbox at the destination, so the server cannot tell which one was meant. |
| X.1.5 | Destination address valid | A success code: the recipient address is valid. It appears in positive delivery reports. |
| X.1.6 | Destination mailbox has moved, No forwarding address | The mailbox used to exist but no longer accepts mail, and no forwarding address is known. Treat it as permanent. |
| X.1.7 | Bad sender's mailbox address syntax | The sender address is not valid syntax. |
| X.1.8 | Bad sender's system address | The sender's domain does not exist or cannot receive replies, so the receiver refuses mail from it. |
| X.1.9 | Message relayed to non-compliant mailer | The address was valid, but the message was handed on to a system that does not speak this protocol, so no further status will come back. |
| X.1.10 | Recipient address has null MX | The recipient's domain publishes a null MX record, which declares that it accepts no mail at all. |
| X.2.0 | Other or undefined mailbox status | The mailbox exists, but something about it caused the failure. |
| X.2.1 | Mailbox disabled, not accepting messages | The mailbox exists but is not accepting messages, for example because it was disabled. This can be temporary or permanent. |
| X.2.2 | Mailbox full | The mailbox is over its storage quota. The owner can free up space, so receivers usually report it as a temporary failure. |
| X.2.3 | Message length exceeds administrative limit | The message is larger than this particular mailbox allows, even though the system as a whole might accept it. |
| X.2.4 | Mailing list expansion problem | The address is a mailing list, and the list could not be expanded to its members. |
| X.3.0 | Other or undefined mail system status | The destination system normally accepts mail, but something about it caused this failure. |
| X.3.1 | Mail system full | The receiving mail system has run out of storage. This is usually temporary. |
| X.3.2 | System not accepting network messages | The receiving host is not taking messages right now, for example during maintenance, a shutdown or heavy load. |
| X.3.3 | System not capable of selected features | The destination does not support a feature the message asked for. |
| X.3.4 | Message too big for system | The message is larger than the receiving system's per-message size limit. |
| X.3.5 | System incorrectly configured | The receiving system is not configured in a way that lets it accept this message. |
| X.3.6 | Requested priority was changed | The message was accepted, but not at the priority requested. The reply text gives the priority that was used. |
| X.4.0 | Other or undefined network or routing status | A network or routing problem that does not fit a more specific code. |
| X.4.1 | No answer from host | The receiving server did not answer the connection attempt, because it was busy or unreachable. Usually temporary. |
| X.4.2 | Bad connection | The connection was opened but dropped or timed out before the message transfer finished. |
| X.4.3 | Directory server failure | A directory server, most often DNS, was unavailable, so the message could not be routed. Usually temporary. |
| X.4.4 | Unable to route | No route to the destination could be found, for example because DNS returned no mail server for the domain. |
| X.4.5 | Mail system congestion | The mail system is congested and cannot take the message now. |
| X.4.6 | Routing loop detected | The message was forwarded so many times that a routing loop is assumed, usually because of misconfigured forwarding. |
| X.4.7 | Delivery time expired | The message waited in a queue too long and expired before it could be delivered. |
| X.5.0 | Other or undefined protocol status | A protocol problem that does not fit a more specific code. |
| X.5.1 | Invalid command | An SMTP command was sent out of order or is not supported by the server. |
| X.5.2 | Syntax error | An SMTP command could not be parsed: the syntax is wrong or the command is unknown. |
| X.5.3 | Too many recipients | The message lists more recipients than the server accepts in one transaction. The sender should split the recipients across several transactions. |
| X.5.4 | Invalid command arguments | A valid command was sent with arguments that are out of range or not recognized. |
| X.5.5 | Wrong protocol version | The two mail systems could not agree on a protocol version. |
| X.5.6 | Authentication Exchange line is too long | During AUTH, the client sent a base64 line longer than the server can buffer for that mechanism. |
| X.6.0 | Other or undefined media error | Something about the message content made it undeliverable, with no more specific reason given. |
| X.6.1 | Media not supported | The message's media type is not supported on the path to the recipient. |
| X.6.2 | Conversion required and prohibited | The content needs converting before delivery, but conversion is not allowed for this message. |
| X.6.3 | Conversion required but not supported | The content needs converting to be passed on, for example from 8-bit to 7-bit, and a system on the path cannot do it. |
| X.6.4 | Conversion with loss performed | The message was delivered, but converting it lost some data. It counts as a failure only if the sender ruled out lossy conversion. |
| X.6.5 | Conversion Failed | A required content conversion was attempted and failed. |
| X.6.6 | Message content not available | The message content could not be fetched from the remote system it points to. |
| X.6.7 | Non-ASCII addresses not permitted for that sender/recipient | The server does not accept non-ASCII (internationalized) addresses for this sender or recipient. |
| X.6.8 | UTF-8 string reply is required, but not permitted by the SMTP client | Showing the mailbox name needs a UTF-8 reply, but the client did not enable that kind of reply. |
| X.6.9 | UTF-8 header message cannot be transferred to one or more recipients, so the message must be rejected | The message has UTF-8 headers that cannot be passed on to one or more recipients, so it is rejected after the message data is sent. |
| X.6.10 | Deprecated, duplicate of X.6.8 | A deprecated duplicate of X.6.8. IANA keeps the number registered, but it should not be used. |
| X.7.0 | Other or undefined security status | A security or policy problem that does not fit a more specific code, or that the server chooses not to explain. |
| X.7.1 | Delivery not authorized, message refused | The sender is not allowed to send to this recipient, because of per-host or per-recipient filtering. Receivers use it widely for spam, reputation and policy blocks. |
| X.7.2 | Mailing list expansion prohibited | The sender is not allowed to post to this mailing list. |
| X.7.3 | Security conversion required but not possible | Delivery needed a conversion between secure messaging formats that was not possible. |
| X.7.4 | Security features not supported | The message used a security feature, such as secure authentication, that the delivery path does not support. |
| X.7.5 | Cryptographic failure | A system on the path could not validate or decrypt the message because a key it needs was missing or invalid. |
| X.7.6 | Cryptographic algorithm not supported | A system on the path could not validate or decrypt the message because it does not support the algorithm used. |
| X.7.7 | Message integrity failure | Validation found that the message was corrupted or altered in transit. |
| X.7.8 | Authentication credentials invalid | AUTH failed because the credentials are wrong or not sufficient. The client should ask for new credentials. |
| X.7.9 | Authentication mechanism is too weak | The chosen AUTH mechanism is weaker than the server allows for this user. The client should retry with a stronger one. |
| X.7.10 | Encryption Needed | The requested AUTH mechanism needs an encrypted connection first, such as TLS, or a stronger mechanism. |
| X.7.11 | Encryption required for requested authentication mechanism | The chosen AUTH mechanism may only be used over an encrypted connection. The RFC keeps it for historical reasons: servers should not offer such mechanisms before TLS. |
| X.7.12 | A password transition is needed | The user must move to the selected AUTH mechanism, usually by signing in once with PLAIN. |
| X.7.13 | User Account Disabled | Authentication worked, but the account is disabled, for example for non-payment or abuse. Retrying will not help until an administrator re-enables it. |
| X.7.14 | Trust relationship required | The submission server needs a configured trust relationship with a third-party server to fetch the message content. |
| X.7.15 | Priority Level is too low | The message's priority is below the lowest the server accepts. This can be temporary, while the server only takes higher-priority mail. |
| X.7.16 | Message is too big for the specified priority | The message is too big for the priority it was sent with. |
| X.7.17 | Mailbox owner has changed | The message required the recipient mailbox to have kept the same owner since a given date, and the mailbox has changed owner since then. Sent with a permanent 5xx reply. |
| X.7.18 | Domain owner has changed | The message required the recipient's domain to have kept the same owner since a given date, and the domain has changed owner since then. Sent with a permanent 5xx reply. |
| X.7.19 | RRVS test cannot be completed | The receiver could not check the mailbox ownership date the message asked about, because it never recorded one. The sender decides whether to resend without that check. |
| X.7.20 | No passing DKIM signature found | The message carried no DKIM signature that passed verification. |
| X.7.21 | No acceptable DKIM signature found | The message has DKIM signatures that pass, but none that the receiver's policy accepts. |
| X.7.22 | No valid author-matched DKIM signature found | The message has passing DKIM signatures, but none from a domain that matches the From address. |
| X.7.23 | SPF validation failed | SPF returned fail for the sending IP, and the receiver's policy rejects such mail. |
| X.7.24 | SPF validation error | Evaluating SPF hit an error, for example a malformed record or a DNS failure. It can be temporary or permanent. |
| X.7.25 | Reverse DNS validation failed | The sending IP failed a reverse DNS check: it has no PTR record, or the PTR name does not resolve back to the same IP. |
| X.7.26 | Multiple authentication checks failed | The message failed more than one authentication check, such as SPF and DKIM. The reply does not say which ones. |
| X.7.27 | Sender address has null MX | The sender's domain publishes a null MX, so it cannot receive bounces, and the receiver refuses mail from it. |
| X.7.28 | Mail flood detected | The message looks like part of a flood of similar abusive messages. |
| X.7.29 | ARC validation failure | The message failed ARC (Authenticated Received Chain) validation. |
| X.7.30 | REQUIRETLS support required | The message requires REQUIRETLS, and none of the next servers on its path support it. |

## How to read an SMTP reply

> 

A reply has up to three parts: the basic code from RFC 5321, an enhanced status code from RFC 3463, and the server's own text.

**Reply**

```bash
452 4.2.2 The recipient's mailbox is full. Try again later.
```

| Part | Here | What it tells you |
| --- | --- | --- |
| Basic code, first digit | `4` | The class: 2 accepted, 3 send more (`354` after DATA), 4 temporary failure, 5 permanent failure. |
| Basic code, second digit | `5` | The area: 0 syntax, 1 information, 2 the connection, 5 the mail system. |
| Enhanced code, class | `4` | The same severity again: 2 success, 4 temporary, 5 permanent. |
| Enhanced code, subject | `2` | Where the problem is: 1 the address, 2 the mailbox, 3 the mail system, 4 network and routing, 5 the protocol, 6 the content, 7 security or policy. |
| Enhanced code, detail | `2` | The specific condition within the subject; 2.2 is a full mailbox. |
| Text | The rest | The server's own explanation. One code can cover several causes, so read it before acting. |

Mailbox providers reuse the same code for different problems and tell them apart in the text, often with a link to their own help page. `550 5.7.1`, for example, can mean a spam block, a policy refusal or a malformed message depending on who sent it.

## 4xx vs 5xx: which replies to retry

> 

Retry 4xx replies with a growing wait between attempts. Don't retry a 5xx for the same message and recipient: change something first, and what to change depends on the subject digit.

- 4xx, any subject: keep the message and try again. RFC 5321 suggests at least 30 minutes between attempts and giving up after four to five days. A run of `421 4.7.x` or `451 4.7.x` from one provider means send more slowly, not more often.
- 5xx on the address (`5.1.1`, `5.1.10`, `5.2.1`): the address doesn't exist, has no mail server or is disabled. Remove it; repeated sends to dead addresses hurt your reputation.
- 5xx on policy (`5.7.x`): the receiver refused you, not the recipient. Keep the address, fix authentication, reputation or content, and send later as a new message.
- 5xx on the message (`5.6.x`, `5.3.4`): the content or size was refused. Change the message, then send it again.

Unitpost retries temporary failures for you. Your webhook gets `email.delivery_delayed` while it retries, and `email.bounced` when delivery is final, with the receiver's reply in `bounce.diagnostic_code`. How each bounce class is handled is in email bounce codes explained (/blog/deliverability/email-bounce-codes-explained).

## Replies from the Unitpost SMTP relay

> 

When you send through `smtp.unitpost.com`, the relay answers with these codes, each mapped from the same check the API runs:

| Reply | Meaning | What to do |
| --- | --- | --- |
| `250 2.0.0 Queued as <id>` | Accepted and queued for delivery. | Nothing. The id is the email's id, the same one the API returns. |
| `535 5.7.8` | Authentication failed: the username isn't `unitpost`, or the API key is invalid, revoked or can't send. | Use `unitpost` as the username and a key with sending access as the password. |
| `550 5.7.1` | The From domain isn't verified for sending, or the workspace can't send. | Verify the domain, then send again. Retrying unchanged fails the same way. |
| `554 5.6.0` | The message is malformed or fails validation. | Fix the message: a From address, at least one recipient and a body. |
| `552 5.3.4` | The message is over the 40 MB limit. | Send smaller attachments, or link to large files. |
| `452 4.7.0` | A rate limit or the sending quota was reached. | Your client retries; slow down if it keeps happening. |
| `450 4.7.1` | The subscription is inactive. | Mail flows again once billing is fixed. |
| `451 4.3.0` | A temporary error on our side. | Your client retries. |

Setup for each framework and language is in the SMTP docs (/docs/smtp).

## FAQ

### What is the difference between a 4xx and a 5xx SMTP error?

A 4xx is temporary: the sending server keeps the message and tries again later. A 5xx is permanent: the same message to the same recipient will fail again until something changes.

### What does 550 mean in email?

RFC 5321 defines it as mailbox unavailable, but receivers use 550 for most permanent refusals. The enhanced code says which: `5.1.1` no such user, `5.7.1` a policy block, `5.7.26` a DMARC failure.

### Should I retry after a 421 error?

Your server does it for you: 421 means the receiver is closing the connection for now, because it is busy or limiting your rate. Repeated `421 4.7.x` replies mean you should send more slowly.

### What is an enhanced status code?

The `X.Y.Z` code after the basic reply, from RFC 3463. X repeats the severity, Y names the area (address, mailbox, routing, policy) and Z the specific condition.

### Why does the same code mean different things at different providers?

The codes are coarse and each provider writes its own text. Read the text after the code; it usually names the exact reason and often links to the provider's help page.

## Related

- [SMS character and segment calculator](https://www.unitpost.com/tools/sms-segment-calculator): Count SMS characters and segments as you type: see GSM-7 or UCS-2 encoding, which characters force UCS-2, and the cost per message by country.
- [Check your email domain's SPF, DKIM and DMARC](https://www.unitpost.com/tools/domain-checker): Check a domain's SPF, DKIM, DMARC and MX records in your browser and get a graded report that names each problem and the record that fixes it.
- [Check your SPF record](https://www.unitpost.com/tools/spf-checker): Look up a domain's SPF record, count its DNS lookups against the limit of 10, follow every include, and see what each error means and how to fix it.