SMTP 550 Error: What It Means and How to Fix It
Your transactional emails are bouncing with a blunt 550 and your users never got their password reset, receipt, or verification link. The SMTP 550 error is one of the most common — and most misdiagnosed — failures in email delivery. This guide decodes every 550 variant, gives you concrete fixes, and shows you how to reproduce and verify the fix in a safe sandbox before you ship it to production.
Why a 550 error hurts
A 550 is a permanent (hard) failure. Unlike a 4xx temporary error that the sending server retries, a 5xx tells the sender: do not try again — this message was rejected. RFC 5321 defines it as "550 Requested action not taken: mailbox unavailable." For developers shipping transactional email, that is uniquely painful.
Silent failures
Your application's send() call returns success because your code handed the message to your relay. The 550 happens downstream, between your relay and the recipient's server, so your logs look clean while real users get nothing.
Lost critical mail
Password resets, OTP codes, order confirmations, and onboarding emails are exactly the messages that must arrive. A 550 means revenue and trust evaporate quietly.
Deliverability damage
Repeated 550s — especially authentication and blacklist rejections — signal to inbox providers that your domain is poorly configured or abusive. That reputation hit can drag down all your mail.
Hard to reproduce
You can't safely fire test emails at Gmail or a customer's Exchange server to trigger a 550 on demand. You need a controlled environment that speaks real SMTP and returns real response codes.
A systematic way to diagnose and fix 550s
The key to debugging an SMTP 550 error is reading the enhanced status code (RFC 3463) that follows the basic 550. The class.subject.detail code is far more precise than 550 alone — so capture the full response, classify the failure, apply the targeted fix, then verify in a sandbox.
Capture the full response line. Don't truncate at 550 — the text after it (5.1.1, 5.7.1, 5.7.26, plus the human-readable reason) is the actual diagnosis. 5.1.1 user unknown means the recipient address doesn't exist: fix the typo, scrub invalid addresses, and validate before sending. 5.1.0 address rejected means a spoofed or invalid envelope sender: use a real, authorized MAIL FROM on a domain you control.
Fix 5.7.1 relaying denied. This is classic open-relay protection — you're asking a server to forward mail to a domain it doesn't host, without authenticating. Authenticate with SMTP AUTH against a relay authorized to send for you, or stop pointing your app at the recipient's MX and route through your own outbound provider. On internal gateways, add your app server's IP to the allowed-relay list.
Fix 5.7.1 / 5.7.26 authentication failures. Modern providers (Gmail, Microsoft 365, Yahoo) reject unauthenticated mail; 5.7.26 means the message did not pass SPF or DKIM alignment under DMARC. Publish an SPF TXT record listing every sending IP (v=spf1 include:_spf.yourprovider.com -all), enable DKIM signing with a published public key, and start DMARC at p=none before tightening to p=quarantine or p=reject. Make sure the From domain aligns.
Fix blacklist (RBL/DNSBL) and PTR blocks. A 550 blocked response means your IP or domain is on a DNSBL like Spamhaus, Barracuda, or SpamCop. Look up your IP, stop the abuse source (compromised account, spammy campaign, open relay), and submit delisting requests. Pair this with valid reverse DNS: your sending IP needs a PTR record that resolves forward to the same IP (Forward-Confirmed reverse DNS).
Key features
SMTP sandbox that speaks real SMTP
Point your app at a Maildog SMTP host instead of a production relay. Every EHLO, MAIL FROM, RCPT TO, and DATA is handled by a real server returning real response codes — so you can reproduce a 550 or confirm it's gone in a fully isolated environment.
SPF, DKIM & DMARC validation
The most common modern 550 (5.7.1 / 5.7.26) is an authentication failure. Maildog parses captured messages and reports SPF alignment, DKIM signature validity, and DMARC pass/fail — turning a cryptic rejection into a clear, fixable checklist.
Deep email inspection
View raw headers, the SMTP envelope, MIME structure, and authentication results for every message. When a server says mailbox unavailable or relaying denied, the inspector shows which envelope field or auth result triggered it.
Inbound email testing
Test the receiving side too. Confirm how your own server responds to RCPT TO for unknown users — so you understand and can tune when you return 550 5.1.1 to other senders.
Developer-friendly API & logs
Capture, query, and assert on messages programmatically. Wire 550-reproduction tests into CI so a regression in your SMTP, SPF, or relay config fails the build instead of silently bouncing customer email in production.
Reproducible, deterministic transcripts
Drive the SMTP conversation by hand with swaks or openssl s_client and capture the exact raw 550 response your code triggers — repeatable every time, never dependent on a flaky remote server's state.
Reproduce a 550 over a real SMTP conversation
The fastest way to see a real SMTP 550 error is to drive the conversation by hand, then reproduce it safely against a Maildog sandbox endpoint.
# Open a TLS SMTP session to the target server
openssl s_client -connect mail.example.com:25 -starttls smtp -crlf220 mail.example.com ESMTP Postfix
EHLO test.local
250-mail.example.com
250-PIPELINING
250-AUTH PLAIN LOGIN
250 STARTTLS
MAIL FROM:<app@yourdomain.com>
250 2.1.0 Ok
RCPT TO:<someone@gmail.com>
550 5.7.1 Relaying denied: proper authentication required# Reproduce + capture the SMTP response, no live recipients harmed
swaks \
--to user@inbox.maildog.io \
--from app@yourdomain.com \
--server mail.maildog.io \
--port 587 \
--auth LOGIN \
--auth-user "${MAILDOG_USER}" \
--auth-password "${MAILDOG_PASS}" \
--tls \
--header "Subject: 550 reproduction test"<- 220 mail.maildog.io ESMTP ready
-> EHLO yourdomain.com
<- 250-mail.maildog.io
<- 250 AUTH LOGIN
-> AUTH LOGIN
<- 235 2.7.0 Authentication successful
-> MAIL FROM:<app@yourdomain.com>
<- 250 2.1.0 Ok
-> RCPT TO:<user@inbox.maildog.io>
<- 250 2.1.5 Ok
-> DATA
<- 250 2.0.0 Ok: queued — message captured for inspectionWhy developers choose Maildog
Faster debugging
Read the enhanced status code, reproduce the exact SMTP conversation, and fix the root cause instead of guessing — cut 550 triage from hours to minutes.
Safe email testing
Trigger and verify 550 behavior against a sandbox SMTP server, never against live mailboxes or your domain's reputation.
Better deliverability
Validate SPF, DKIM, DMARC, reverse DNS, and blacklist status before you ship, so authentication-based 550s stop happening.
Improved developer workflow
Programmatic capture and assertions let you bake 550-regression checks into CI/CD, catching broken email config before customers do.
Debugging 550s in production vs a Maildog sandbox
You shouldn't debug a 550 by blasting test mail at live mailboxes. Here is how production debugging compares to an isolated Maildog sandbox.
| Capability | Maildog Sandbox | Debugging in Production |
|---|---|---|
| Risk to domain reputation | None — isolated | High — rejections hurt sender score |
| Real recipients affected | ||
| Reproducibility | Deterministic & repeatable | Flaky — depends on remote state |
| Visibility into SMTP response | Full raw conversation + codes | Often hidden behind relay logs |
| SPF / DKIM / DMARC validation | Manual, scattered tools | |
| Safe to run in CI |
Frequently asked questions
What does SMTP error 550 mean?
SMTP 550 means "Requested action not taken: mailbox unavailable." It is a permanent rejection — the receiving server refused the message and the sender should not retry. The exact cause is given by the enhanced status code that follows, such as 5.1.1 (user unknown) or 5.7.1 (relaying denied or authentication failure).
Is a 550 error permanent or temporary?
A 550 is permanent (a hard bounce). Any 5xx code tells the sending server to stop trying. Temporary failures use 4xx codes (e.g. 450), which trigger automatic retries. Because 550 is permanent, you must fix the underlying cause — the message will never deliver on its own.
How do I fix 550 5.7.1 relaying denied?
550 5.7.1 relaying denied means the server won't forward your mail to that destination. Either authenticate with SMTP AUTH against a relay authorized to send for your domain, or stop sending directly to the recipient's MX and route through your own outbound provider. On internal gateways, add your app server's IP to the allowed-relay list.
What causes 550 5.1.1 user unknown?
550 5.1.1 user unknown (or mailbox unavailable) means the recipient address doesn't exist on that server. It's usually a typo, a deleted or disabled mailbox, or the wrong domain. Correct the address, remove invalid recipients from your list, and validate addresses before sending.
What is 550 5.7.26 and how do I fix it?
550 5.7.26 means the message failed authentication under DMARC — it didn't pass SPF or DKIM alignment. Fix it by publishing a correct SPF record that includes your sending IPs, enabling DKIM signing with a published public key, and ensuring your From domain aligns with both. Start DMARC at p=none to monitor, then tighten.
Why am I getting 550 blocked or blacklisted?
A 550 blocked or blacklisted response means your sending IP or domain appears on a DNSBL/RBL such as Spamhaus or Barracuda. Look up your IP on the major blocklists, stop the abuse source (compromised account, spammy campaign, open relay), submit delisting requests, and ensure your IP has valid forward-confirmed reverse DNS (PTR).
Does a missing PTR record cause 550 errors?
Yes. Many servers reject mail from IPs without a valid reverse DNS (PTR) record, sometimes with a 550. Your sending IP should have a PTR record that resolves forward to the same IP (Forward-Confirmed reverse DNS). Set the PTR with your hosting provider so it matches your sending hostname.
How can I test and reproduce a 550 error safely?
Use a sandbox SMTP server like Maildog instead of live mailboxes. Point your app or a tool like swaks or openssl s_client at the sandbox, capture the full SMTP conversation and response codes, and validate SPF/DKIM/DMARC on the captured message — so you can reproduce a 550 and verify your fix without risking your domain reputation.
Keep exploring
Reproduce and fix your 550 the safe way
Capture the exact SMTP conversation and verify SPF, DKIM, and DMARC before you touch production.
Run the SMTP test