SMTP reply and status codes

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.

• 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.

To fix

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.

Temporary 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.

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.

• 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.

To fix

1. Let your server retry with backoff and hold new bulk sends until the deferrals stop. See how to recover a damaged sender reputation.
2. Drop shortened links and links to domains with a poor reputation. See email copy that hurts 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.

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

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

• 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.

To fix

1. Check SPF with the SPF checker and your DKIM selector with the DKIM checker.
2. Publish the DKIM key exactly as your sending service gives it, at selector._domainkey on your domain. See 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.

Temporary 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.

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.

• 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.

To fix

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.
3. Remove old, imported and never-confirmed addresses before the next send. See email list hygiene.
4. Give every message its own unique Message-ID.

Temporary 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.

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.

• 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.

To fix

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 to see which domains SPF and DKIM passed for. See DMARC alignment.

Temporary 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.

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.

• 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.

To fix

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.

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.

• 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.

To fix

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.

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

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

• 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.

To fix

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.

Temporary 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.

Seen as: DNS query failed

• 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.

To fix

1. Check the recipient domain's MX and A records with the 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.

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.

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

To fix

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.

Temporary 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.

Seen as: Access denied, please try again later

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

To fix

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.

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

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

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

To fix

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.

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

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

• 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.

To fix

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.

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.

• 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.

To fix

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.

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

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

• 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.

To fix

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.

Permanent 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.

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

• 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.

To fix

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.

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

Seen as: Username and Password not accepted.

• 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.

To fix

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.

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

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.

• 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.

To fix

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.

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

Seen as: Recipient not found

• 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).

To fix

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.

Permanent 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.

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 account was disabled, or left unused long enough to become inactive.
• The recipient is receiving more mail than Gmail lets through.

To fix

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

Permanent 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.

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

• 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.

To fix

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. If the address is right and the MX points to Microsoft, tell the recipient's administrator.

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

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

• 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.

To fix

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.

Permanent 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.

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

• 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.

To fix

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.
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 and send with a key that has emails:send.

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

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

• 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.

To fix

1. Check the record with the 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.
3. Sign with DKIM too, so forwarded mail can still pass DMARC.

Permanent 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.

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

• 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.

To fix

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.

Permanent 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.

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.

• 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.

To fix

1. Check the domain with the SPF checker, DKIM checker and 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.

Permanent 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.

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

• 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.

To fix

1. Check SPF with the SPF checker and fix it on the return-path domain. See 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.

Permanent 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.

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.

• 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.

To fix

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.
3. Keep the spam rate in Google Postmaster Tools under 0.3%. See how to recover a damaged sender reputation.

Permanent 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.

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

• 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.

To fix

1. Take the selector from the DKIM-Signature header and check it with the DKIM checker.
2. Republish the key exactly as your sending service gives it. See DKIM verification failing.

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

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

• 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.

To fix

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

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

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

• 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.

To fix

1. Check alignment with the 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.
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.

Permanent 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.

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

• 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.

To fix

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 and check it with the DMARC checker.
3. Align the return-path or DKIM domain with the From domain. See bulk sender requirements.

Permanent 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.

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]

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

To fix

1. Fix the cause first: secure compromised accounts and stop unwanted sends.
2. Request removal at the Office 365 Anti-Spam IP Delist Portal 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.

Permanent 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.

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

• 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.

To fix

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

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

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.

• 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.

To fix

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

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

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.

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

To fix

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

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

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

• 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.

To fix

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

Permanent 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.

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

• 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.

To fix

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.

Permanent 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.

Seen as: Email message is malformed. Not accepted.

• 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.

To fix

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.

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.

• 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.

To fix

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.