What are the common causes of SMTP 550 errors, and are they related to spam?
Published 29 May 2026
Updated 17 Oct 2026
10 min read
Summarize with
Updated on 17 Oct 2026: We added reverse DNS checks and clearer fixes for common SMTP 550 rejections.
A 550 SMTP error means a mail server rejected the current delivery request with a permanent negative reply. The rejection can come from your outgoing SMTP service or the recipient's server. Spam filtering and sender reputation are possible causes, but mailbox and relay errors also produce 550 replies. A bare 550 does not prove spam. It is a broad rejection code.
The useful part is usually the text after it, such as 5.1.1, 5.7.1, "mailbox unavailable", "relaying denied", "sender not verified", "message rejected", or "denied by policy". Those extra words distinguish invalid addresses and relay permissions from authentication failures or spam filtering.
- 550 can be spam-related, but it also means mailbox, relay, or other policy rejection.
- Enhanced status codes and bounce wording matter more than the three-digit code.
- Group bounces by recipient domain, sending IP, SMTP stage, and exact reply text.
Key point
A later successful delivery to the same recipient domain does not establish that the earlier rejection condition has cleared. The recipient mailbox or sending IP can differ between attempts, and the message or receiving server can also change. Compare both deliveries before attributing success to a policy change or reputation recovery.
What SMTP 550 means
SMTP uses three-digit reply codes during delivery. A 5xx reply is a permanent negative completion, so the sending system should not automatically retry the same unchanged delivery request. 550 covers a mailbox that is not found, lack of access, or rejection for policy reasons. These are the broad categories in RFC 5321.
Read the enhanced status code and the human-readable explanation together. A 5.1.1 reply usually points at a bad recipient address. A 5.7.1 reply usually points at policy, security, authentication, or permission. For broader code lookup, use a structured reference for SMTP error codes and compare the full non-delivery report (NDR) wording.
|
|
|
|
|---|---|---|---|
550 | Generic permanent rejection | Unknown | Read the full reply |
5.1.1 | Invalid recipient mailbox | No | Verify; suppress confirmed invalid address |
Microsoft 550 5.1.10 | Recipient not found in directory | No | Confirm address and recipient configuration |
5.2.x | Mailbox status or quota | Usually no | Confirm mailbox status with recipient |
5.3.4 | Message too large | No | Reduce total message size |
5.7.1 | Security or access policy | Sometimes | Read the named restriction |
Gmail 550 5.7.25 | Missing or mismatched reverse DNS | Not proof | Check PTR and forward DNS |
Relaying denied | No relay permission | No | Check SMTP AUTH and route |
Blocked | Local policy or reputation | Sometimes | Read the full policy explanation |
Common SMTP rejection patterns; enhanced codes are not exclusive to 550.
Enhanced status codes are not tied to one SMTP reply number. For example, message-size failures commonly use 552 5.3.4, rather than 550. RFC 3463 defines 5.3.4 as a system message-size limit failure. Provider-specific codes also need the full explanation.
Example 550 replies and a related size-limit reply
550 5.1.1 Recipient address rejected: user unknown 552 5.3.4 Message size exceeds fixed maximum message size 550 5.7.1 Message rejected due to local policy 550 5.7.1 Relaying denied 550 5.7.26 Unauthenticated email from example.com is not accepted
Where the 550 appears changes the diagnosis
A mail server can return 550 at different points in the SMTP conversation. Record the command that immediately preceded the reply. A rejection during recipient validation points in a different direction than a rejection after the server has read the message headers and body.
|
|
|
|
|---|---|---|---|
EHLO/HELO | SMTP hostname and connection policy | Hostname or connection-policy rejection | SMTP hostname, sending IP, and DNS |
MAIL FROM | Envelope sender | Envelope sender syntax, SPF, or access policy | Envelope sender and connection IP |
RCPT TO | Recipient and relay permission | Unknown user, recipient access restriction, or relay denied | Address, domain, and connector route |
End of DATA | Headers and message body | Authentication, content, reputation, or message-size policy | Authentication results and full policy text |
Use the SMTP stage to narrow the likely cause.
Find the rejecting hop
An NDR can be generated by your sending service even when a different server issued the rejection. Keep both the generating server and the rejecting server, plus the original headers and queue or message identifiers. This prevents a local bounce generator from being mistaken for the system that blocked delivery. If the rejection occurred at submission, investigate the outgoing service before the destination domain.
When 550 is related to spam
A 550 is spam-related when the reply identifies spam filtering or poor IP or domain reputation. Words such as "policy", "blocked", or "authentication" describe broader rejection categories. Legitimate email also fails authentication checks or recipient access rules.
Spam, authentication, or access policy
- Policy wording requires checking the named restriction; access denied alone does not establish spam.
- An explicit spam verdict or poor sender reputation points to spam-related filtering.
- SPF, DKIM, or DMARC wording points to authentication checks, even when the message is legitimate.
Likely non-spam
- User unknown or recipient invalid points to an address problem; mailbox unavailable needs the full explanation.
- Relaying denied means the sending system lacks permission to use that relay path.
- A disabled or full mailbox, or a message-size limit, requires checking recipient settings or message size.
The tricky case is "denied by policy". That phrase includes spam filtering and rules unrelated to message content. A company mail server can reject external senders for a specific mailbox or require bulk senders to be on an allowlist.
Do not over-read one code
A policy rejection for a valid address still needs investigation. Confirm with authentication results, recipient-domain clustering, sending IP history, and any named blocklist (blacklist) listing. A clean public blocklist result does not rule out private filtering or poor sender reputation.
How to diagnose a 550 bounce
Preserve the full bounce first. Do not reduce it to "550" in a spreadsheet. Keep the exact SMTP reply, enhanced code, preceding SMTP command, recipient domain, sending IP, envelope sender, visible From domain, message ID, queue ID, generating server, rejecting server, campaign or message type, timestamp with timezone, and original message headers.
SMTP 550 troubleshooting flowchart covering the full bounce, enhanced status code, recipient address, policy text, authentication results, and sender reputation.
- Read the wording to separate user unknown, relay denied, sender blocked, and policy messages.
- Locate the SMTP stage: EHLO/HELO, MAIL FROM, RCPT TO, or the end of DATA.
- Group events by recipient domain, sending IP, and message type to find concentrated failures.
- Verify SPF, DKIM, and DMARC results, including the envelope sender and visible From domains.
- Check sending IP and domain reputation, starting with any blacklist named in the reply.
- Compare both failed and successful attempts before assigning a cause to a later delivery.
To send a test message and inspect authentication, use Suped's email tester. A successful test at another mailbox does not reproduce the rejecting server's private policy. Use the result alongside the original bounce.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
For authentication-related 550s, use Suped's domain health check before changing content. Check SPF authorization and the DKIM signature on an actual message. Published DNS records alone do not establish that the failed message passed authentication.
Check reverse DNS and the SMTP hostname
Missing reverse DNS is another cause of policy-related SMTP 550 errors. Gmail documents 550 5.7.25 for a missing PTR record or forward DNS that does not match the sending IP in its SMTP error reference.
- Check the actual outbound IPv4 or IPv6 address used for the failed delivery, rather than the website's IP.
- Confirm that the IP's PTR record points to a hostname and that the hostname's A or AAAA record resolves back to the sending IP.
- Configure the SMTP server to announce its fully qualified domain name (FQDN) in EHLO/HELO.
- Ask the email provider or hosting provider to correct the sending IP's PTR record, then test after DNS caches have refreshed.
Google's sender guidelines describe the required forward and reverse DNS relationship. Check the address actually used for delivery when the server has both IPv4 and IPv6.
How to fix common SMTP 550 errors
The fix depends on the failure family. Start with the most specific rejection detail. Do not rewrite a campaign before suppressing invalid recipients. Do not rotate IPs before checking authentication. Do not assume content is the problem when a provider says the sender is not authenticated.
|
|
|
|---|---|---|
Address | User unknown | Verify typos; suppress confirmed invalid recipients |
Relay | Relaying denied | Check outgoing SMTP settings, SMTP AUTH, and connector permissions |
Authentication | DMARC fail | Repair SPF or DKIM and confirm DMARC domain matching |
Mailbox | Mailbox disabled or full | Ask the recipient to restore the mailbox or free space |
Message size | Message exceeds size limit | Remove large attachments or use a secure download link |
Message headers | Missing or duplicate From header | Correct headers in the sending application and retest |
Sending quota | Daily sending limit exceeded | Pause until the stated reset or request a quota change |
Reputation | IP or domain reputation rejection | Fix the named cause before requesting removal |
Policy | Denied by policy | Ask the recipient administrator to identify the rule |
Prioritize the fix based on the rejection family.
Gmail's SMTP error reference documents 550 replies for malformed message headers and daily SMTP relay limits as well as spam filtering. Check total encoded message size when the reply names a size limit, since it includes more than the original attachment size.
For authentication errors, check SPF for the envelope sender domain and DKIM for the signing domain. DMARC needs at least one passing mechanism whose domain meets the matching requirements for the visible From domain. A receiver can still enforce separate SPF or DKIM requirements. Suped's DMARC monitoring shows reported sources and authentication outcomes; confirm which sources your organization authorizes.
For reputation errors, investigate the blocklist named in the rejection, then review complaints, sudden volume changes, old addresses, and purchased data. Fix the cause before following that list's removal process. Suped's blocklist monitoring helps track listing changes during that work. A public listing explains a bounce only if the receiving server uses it.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped is our DMARC and email authentication platform. For a policy-related 550 investigation, it brings DMARC aggregate data, SPF and DKIM results, blacklist monitoring, alerts, and record-level remediation steps into one workflow. Match those findings to SMTP logs and the rejecting server's wording. Aggregate reports do not expose every receiver policy or prove why an individual message was rejected.
Practical workflow
- Compare affected sending sources with reported SPF and DKIM failures; aggregate data is not a log of every rejected message.
- Use alerts to investigate authentication drops or listing changes alongside your bounce logs.
- Follow record-level remediation steps after confirming the failing check in the rejection.
How to handle recurring 550 patterns
Recurring 550s deserve different handling based on scale. A few isolated 550 5.1.1 replies fit normal list hygiene. A sudden rise in 550 5.7.1 replies at one mailbox provider is a deliverability incident. A single recipient domain rejecting every message can be a local gateway policy, especially in business-to-business sending.
Use your own established baseline instead of a universal bounce-rate threshold. Investigate any abrupt increase in policy, authentication, or reputation replies, especially when they concentrate at one recipient domain, sending IP, or message type. Invalid-recipient rates also need attention when they rise above the normal level for the same list source.
When the error says relaying denied, check the outgoing SMTP hostname, port, and encryption settings, then verify SMTP AUTH credentials or the connector's authorized IPs. SMTP AUTH is login to the outgoing service; SPF and DKIM are domain-authentication checks by receivers. Microsoft's relay-error guidance explains relay permission requirements. For route-specific cases, compare relaying denied errors with your connector settings.
For user unknown or recipient not found, verify the address for typos and stale autocomplete entries. Suppress confirmed invalid recipients. "Mailbox unavailable" alone also covers access restrictions; ask the recipient administrator to check mailbox status and routing when the address is valid. Microsoft's 550 5.1.10 guidance also covers recipient-directory and hybrid-routing checks. For mixed bounce messages, compare 550, 571, and 554 patterns before deciding whether to suppress, retry, or investigate reputation.
