How to fix '550 permanent failure for one or more recipients' and similar errors

We provide technical support for our clients' servers and infrastructure, and 550 bounces are among the most common email tickets we get. They show up with Postfix, Exim, Exchange, Microsoft 365, Gmail and pretty much any other mail system.

The good news: the bounce almost always tells you what went wrong. You just need to know where to look.

The SMTP responses in this guide were reproduced with Postfix 3.8 on Ubuntu 24.04 and swaks 20240103 in a test lab.

What a 550 error means

SMTP servers answer every command with a three-digit code. Codes starting with 5 are permanent failures. RFC 5321 defines 550 as "Requested action not taken: mailbox unavailable", and the examples it gives include both "mailbox not found" and "command rejected for policy reasons".

That's why the same 550 can mean "this address doesn't exist" or "we don't trust your server". The second number tells them apart. Most servers add an enhanced status code from RFC 3463, like 5.1.1 or 5.7.1:

• 5.1.x - a problem with the address. 5.1.1 means the mailbox doesn't exist.
• 5.2.x - a problem with the mailbox, for example it's disabled or full.
• 5.7.x - security or policy. Your server, IP or message was refused: blocklists, SPF, DKIM, DMARC, reverse DNS, relaying.

The full list lives in the IANA registry of enhanced status codes.

"Permanent failure for one or more recipients" means exactly that: at least one address in your message was refused. If you sent to several people, the others may have received it. The bounce lists the addresses that failed.

How to read the bounce message

When your server can't deliver a message, it sends you a bounce (a non-delivery report). Here's a real one from our lab, where the address jdoe@example.com doesn't exist:

shell
1<jdoe@example.com>: host mx.example.com[203.0.113.25] said: 550 5.1.1
2    <jdoe@example.com>: Recipient address rejected: User unknown in local
3    recipient table (in reply to RCPT TO command)
4
5Final-Recipient: rfc822; jdoe@example.com
6Action: failed
7Status: 5.1.1
8Remote-MTA: dns; mx.example.com
9Diagnostic-Code: smtp; 550 5.1.1 <jdoe@example.com>: Recipient address
10    rejected: User unknown in local recipient table

Look for three things:

1. Who refused the message. Remote-MTA or "host ... said" names the server. If it's the recipient's server, start with the recipient side. If the bounce was generated by your own server without talking to anyone else, the problem is on your side.
2. The code and the text. 550 5.1.1 and "User unknown" are the actual reason. Everything else is wrapping.
3. When it happened. "In reply to RCPT TO command" means the address was refused. "In reply to end of DATA command" means the server read the whole message and then refused it, which usually points to content or authentication checks.

Microsoft 365 often wraps the remote server's answer in its own code, for example 550 5.0.350 Remote server returned an error -> 550 #5.1.0 Address rejected. The 5.0.350 part only says the remote server returned an error. The part after the arrow is what the recipient's server actually said (Microsoft's guide to 5.0.350).

⚠️ Don't take the wording too literally. Postfix prefixes every refusal at the RCPT TO stage with "Recipient address rejected", even when the recipient is fine and your SPF failed. In our lab an SPF failure came back as 550 5.7.23 ... Recipient address rejected: Message rejected due to: SPF fail - not authorized. The code 5.7.23 (SPF failed) is the real reason.

Common 550 messages and which side they point to

Some of the messages you're likely to see, grouped by cause. Exact wording depends on the server software.

The address doesn't exist (recipient side, usually a typo or a deleted mailbox):

• 550 5.1.1 User unknown
• 550 5.1.1 Sorry, no mailbox here by that name
• 550 5.1.1 Is not a valid mailbox
• 550 5.1.1 The email account that you tried to reach does not exist (Gmail)
• 550 5.1.1 Recipient address rejected: User unknown in local recipient table (Postfix)
• 550 5.1.1 Recipient address rejected: User unknown in relay recipient table (Postfix as a gateway)
• 550 5.1.10 RESOLVER.ADR.RecipientNotFound (Microsoft 365)
• 550 Requested action not taken: mailbox unavailable
• 550 No such user here
• 550 No such recipient here
• 550 Invalid recipient
• 550 #5.1.0 Address rejected
• 550 #5.1.0 Unknown address error 'MAILBOX NOT FOUND'
• 554 delivery error: This user doesn't have an account
• 554 delivery error: Sorry your message cannot be delivered. This account has been disabled or discontinued

The recipient's filter blocked you (recipient's policy, often triggered by your reputation):

• 550 permanent failure for one or more recipients (address:blocked)
• 550 5.7.1 Message rejected as spam
• 550 5.7.1 Service unavailable; Client host blocked using a DNSBL

Your server or domain failed a check (sender side):

• 550 5.7.23 SPF fail - not authorized
• 550 5.7.25 The sending IP address doesn't have a PTR record (Gmail)
• 550 5.7.26 Unauthenticated email is not accepted due to domain's DMARC policy (Gmail)
• 550 5.7.515 Access denied, sending domain does not meet the required authentication level (Outlook and Hotmail)
• 550 5.7.1 Relaying denied, or 554 5.7.1 Relay access denied
• 550 5.1.0 Sender rejected

The #5.1.0 Address rejected message is generic. Most of the time it means the recipient address is wrong, but some gateways use it when they don't like the sender. If the address is definitely correct, go through the sender-side checks below.

Recipient server issues

The address is wrong or no longer exists

Most 550 bounces come down to the address. A typo, an old address of someone who left the company, a mailbox that was deleted after a migration.

Check the address character by character against a recent message from that person. If it's correct, contact the recipient some other way (phone, messenger, a colleague) and ask whether the address still works.

Ideally, forward them the full bounce from a working account. Their mail admin will need the exact error text and the time it happened.

The recipient domain's MX records are wrong

Mail for a domain goes to the servers listed in its MX records, not to the website's address. If the MX records point to an old or wrong server, that server refuses the message because it doesn't know the mailbox, or because it doesn't accept mail for that domain at all.

Check the MX records:

shell
1dig +short MX example.com

You should see one or more mail servers with a priority number:

shell
110 mx1.example.com.
220 mx2.example.com.

If there are no MX records, the hosts point to a provider the company no longer uses, or the answer is 0 . (a "null MX" that says the domain doesn't accept mail), the problem is on the recipient's side. Tell them, since only the domain owner can fix it.

The recipient's spam filter or firewall blocks you

Many companies put a filtering gateway in front of their mailboxes. When it blocks you, the bounce often says "permanent failure for one or more recipients" with ":blocked" after the address, or a 5.7.1 code with a short reason.

The block can be on the recipient's side only (a local block list, a strict policy) or caused by your reputation. Here's how to tell:

• Only one company bounces your mail. It's probably their policy. Ask their admin to check the gateway logs and allow your domain or IP. Send them the error text and the time.
• Several unrelated companies bounce your mail. It's probably your IP or domain reputation. Go to the sender-side checks below.

Sender server issues

Your IP is on a blocklist (DNSBL)

Most mail servers check the connecting IP against DNS blocklists (DNSBLs) before accepting a message. If your server's IP is listed, you get something like this. This one is from our lab, where the test IP was listed:

shell
1554 5.7.1 Service unavailable; Client host [203.0.113.66] blocked using bl.example.net; Listed in bl.example.net lab blocklist

Postfix uses 554 for DNSBL rejections by default, other servers use 550. The meaning is the same.

To check a single list by hand, reverse the IP's octets and look it up in the list's zone:

shell
1IP=203.0.113.66
2REV=$(echo "$IP" | awk -F. '{print $4"."$3"."$2"."$1}')
3dig +short "$REV.zen.spamhaus.org"
4dig +short TXT "$REV.zen.spamhaus.org"

An answer like 127.0.0.2 means the IP is listed, and the TXT record usually explains why. An empty answer means it isn't.

⚠️ Spamhaus refuses queries that come through public DNS resolvers like 8.8.8.8 or 1.1.1.1 and answers with 127.255.255.254 instead of real data (Spamhaus on return codes). Run the check from a server that uses its own resolver, or use a web checker like MxToolbox to check dozens of lists at once.

If you're listed, find and fix the cause first: a hacked account, an infected website sending mail, an open relay. Only then request delisting. Most lists will relist you quickly if the spam continues.

Missing or mismatched reverse DNS (PTR)

The PTR record maps your server's IP back to a hostname. Gmail requires every sender to have valid forward and reverse DNS, and many other servers check it too. Without it, Gmail answers with 550 5.7.25.

Check that the IP resolves to a name and that the name resolves back to the same IP:

shell
1host 203.0.113.10
2host mail.example.com

The first command should return something like 10.113.0.203.in-addr.arpa domain name pointer mail.example.com., and the second should return the same IP. A "not found" answer means there is no PTR record.

In our lab, Postfix with a reverse DNS check refused a client without a PTR record like this:

shell
1450 4.7.1 Client host rejected: cannot find your reverse hostname, [203.0.113.66]

That's a temporary 450 by default. Admins can switch it to a permanent 550, and Gmail returns 550 straight away.

The PTR record is set by whoever owns the IP: your hosting or cloud provider. You can't set it in your domain's DNS zone. Look for "reverse DNS" in your provider's panel or ask their support. Use the same hostname your mail server announces in EHLO.

SPF, DKIM or DMARC fail

Since February 2024, Gmail and Yahoo require senders to authenticate their mail. Microsoft added similar rules for Outlook and Hotmail in May 2025. If your domain isn't set up, your messages go to spam or bounce.

Google's sender guidelines require:

• All senders: SPF or DKIM, valid forward and reverse DNS, TLS, and a spam rate below 0.3% in Postmaster Tools.
• Senders of more than 5,000 messages a day to Gmail: SPF and DKIM, a DMARC record (the policy can be p=none), a From domain aligned with the SPF or DKIM domain, and one-click unsubscribe for marketing mail.

Yahoo's requirements are close to Google's. Microsoft's policy asks domains sending more than 5,000 messages a day to Outlook and Hotmail addresses for SPF, DKIM and DMARC, and non-compliant mail can be rejected with 550 5.7.515.

Check your records:

shell
1dig +short TXT example.com | grep spf1
2dig +short TXT selector._domainkey.example.com
3dig +short TXT _dmarc.example.com

Replace selector with your DKIM selector. You'll find it in the s= tag of the DKIM-Signature header in any message you've sent, or in your email provider's settings.

What a good result looks like:

• SPF: one record starting with v=spf1 that includes every service sending mail as your domain (your mail server, your email provider, your CRM or newsletter tool). Two separate SPF records is an error.
• DKIM: a record starting with v=DKIM1 with a public key.
• DMARC: a record starting with v=DMARC1. Start with p=none and a rua address for reports, then tighten it once the reports look clean.

When SPF fails, the bounce usually names it. Here's the Postfix SPF policy service from our lab, refusing a message sent from an IP that isn't in the SPF record:

shell
1550 5.7.23 <alice@example.com>: Recipient address rejected: Message rejected due to: SPF fail - not authorized.

Gmail uses its own codes: 5.7.26 for DMARC or general authentication failures, 5.7.27 for SPF and 5.7.30 for DKIM (Gmail SMTP error reference). Some of them don't match the meaning in the IANA registry, so trust the text next to the code.

Your server refuses to relay

If your own server refuses to pass the message on, you'll see "Relay access denied" or "Relaying denied". With default settings, Postfix answers 454 4.7.1 Relay access denied. With the stricter reject_unauth_destination setting it's 554 5.7.1, and other servers use 550 5.7.1.

Usually your mail client isn't logging in to the outgoing server, or it's using the wrong port. We cover all the cases in our guide on how to fix the Relay Access Denied error. If your server answers 530 and asks you to authenticate, see how to fix 530 login authentication failed.

The sender address is rejected

"550 5.1.0 Sender rejected" and similar messages are about the From address you send with (the envelope sender), not the recipient. Common reasons:

• The sender domain doesn't exist in DNS or has no mail records. In our lab, Postfix answered 450 4.1.8 Sender address rejected: Domain not found for a domain that didn't resolve.
• The recipient's server blocks your address or domain.
• A script or app on your server sends mail with a made-up From address, like root@localhost or a domain you don't own.

Make sure the app sends from a real address on a domain you control, and that the domain has SPF and DKIM set up.

Your email account is hacked

If you see bounces for messages you never sent, someone may be sending spam through your account or server. That also gets your IP blocklisted, which then bounces your legitimate mail.

Do this right away:

1. Change the password and turn on multi-factor authentication.
2. Sign out all sessions and revoke app passwords and SMTP credentials you don't use.
3. Check forwarding and inbox rules. Attackers often add a rule that forwards or deletes mail.
4. On your own server, check the mail queue for spam and look for scripts that send mail, like an infected website or a compromised form.

On Postfix, this shows the queue:

shell
1postqueue -p

A queue with hundreds of messages to random recipients is a clear sign. Find the source before you clear the queue, or it will fill up again.

Your server treats the recipient's domain as local

This one looks weird, but we see it regularly. If the recipient's domain is listed as a local domain on your server, your server tries to deliver the message to its own mailbox for that address, doesn't find one and bounces it with 5.1.1. The message never leaves your server.

It typically happens after a migration: the domain moved to Microsoft 365 or Google Workspace, but the old server still thinks it hosts it. The bounce doesn't name a remote server, because the error comes from your own server.

On Postfix, check mydestination, virtual_mailbox_domains and virtual_alias_domains:

shell
1postconf mydestination virtual_mailbox_domains virtual_alias_domains

On Exchange, check the accepted domains. Remove the domain from the list once its mail is hosted elsewhere.

Test the SMTP conversation yourself

You can talk to the recipient's mail server directly and see exactly where it refuses your message. Run these tests from your mail server, not from your laptop. Many internet providers and cloud platforms block outbound port 25, and the recipient's server judges your mail server's IP, not your laptop's. AWS, for example, restricts port 25 on EC2 by default.

First, find the server to connect to. It's the host from the MX record, not the domain itself. The domain's own address usually points to the website, which doesn't accept mail:

shell
1dig +short MX example.com

Check that port 25 on that host is reachable:

shell
1nc -vz mx1.example.com 25

"Succeeded" means the port is open. A timeout means something in between blocks port 25, often your own provider.

The easiest way to test the conversation itself is swaks. On Ubuntu or Debian, install it with sudo apt install swaks. This command goes through the SMTP conversation and stops after the recipient check, so no message is actually sent:

shell
1swaks --to jdoe@example.com --from you@yourdomain.com --server mx1.example.com --quit-after RCPT

The <** line shows the refusal:

shell
1 -> MAIL FROM:<you@yourdomain.com>
2<-  250 2.1.0 Ok
3 -> RCPT TO:<jdoe@example.com>
4<** 550 5.1.1 <jdoe@example.com>: Recipient address rejected: User unknown in local recipient table

If the server accepts the recipient (250 2.1.5 Ok) but your real messages still bounce, the problem is with the message itself or with SPF, DKIM or DMARC, which servers check after DATA.

To test with TLS, add --tls. To see the server's certificate and TLS setup, use OpenSSL:

shell
1openssl s_client -starttls smtp -connect mx1.example.com:25 -crlf

You'll see the certificate chain and then a 250 line. From there you can type SMTP commands like EHLO yourdomain.com and QUIT. The -crlf flag makes OpenSSL send the line endings SMTP expects.

telnet mx1.example.com 25 works too if telnet is installed, but it can't do TLS. Keep these tests to a handful of connections. Repeated test sessions from the same IP can look like address harvesting to the recipient.

Check your own mail logs

Your server's logs show every refusal with the remote server's full answer.

On Postfix, find bounced messages:

shell
1grep "status=bounced" /var/log/mail.log

On systems without /var/log/mail.log, use the journal:

shell
1journalctl -t postfix/smtp | grep "status=bounced"

Each line includes the recipient, the remote server and its answer, for example status=bounced (host mx.example.com[203.0.113.25] said: 550 5.1.1 ...).

On Microsoft 365, run a message trace in the Exchange admin center. It shows whether the message left your tenant and what the remote server answered.

Still getting 550 errors?

Most 550 bounces are fixed in minutes once you read the code: check the address, check the recipient's MX, then check your own IP, PTR, SPF, DKIM and DMARC.

If your mail keeps bouncing or your server keeps landing on blocklists, ITsyndicate can help. We set up and support mail servers and the infrastructure around them, so your messages reach the inbox.