550 5.1.1 Error: Detailed Instructions for Fixing It

An SMTP session consists of back-and-forth communication between the client and the server. The client uses text commands and the server replies in numerical codes attached with messages. We discussed this communication in our blog post on SMTP Commands and Response Codes. Error codes can have different meanings on different servers, so you have several potential options for resolving the issue. Today we’ll discuss one of them, 550 5.1.1 error, and explain how to fix it.

What does 550 5.1.1 error mean?

The client typically receives a 550 5.1.1 code as a reply to RCPT TO command. It is an error code that usually stands for some issue with the recipient server. The most frequent error message is “User unknown”. In most cases, this is because the recipient address does not exist. But there are other possible reasons and other possible error messages. 

550 5.5.1 error messages you can encounter

550 5.1.1 : User unknown

550 5.1.1 : Recipient rejected

550 5.1.1 : Recipient address rejected

550 5.1.1 : Recipient address rejected: User unknown in virtual alias table

550 5.1.1 <user@domain.com>: Recipient address rejected: User unknown in relay recipient table

550 5.1.1 : The email account that you tried to reach does not exist

550 5.1.1 : Mailbox not found

550 5.1.1 : Invalid mailbox

550 5.1.1 : Mailbox unavailable

550 5.1.1 : Unrouteable address

550 5.1.1 : Mailbox temporarily disabled

550 5.1.1 : No such user here

Bonus:

550 5.1.1 : Protocol error

You may see this error message if the outgoing email was rejected. In this case, it is identifying an issue with a sending server that has used SMTP protocol instead of ESMTP. So, does this mean that 550 5.1.1 error code can be caused by issues with both the recipient and sending server? Let’s find out.

Reasons for 550 5.1.1 and solutions 

The basic reason for SMTP error RCPT TO 550 5.1.1 is a typo in the recipient’s email address, such as a missed or duplicated character, resulting in an invalid address. So, email validation should be the first thing to verify. If the email address is valid, you will need to dig deeper.

Issues related to the receiving server

Issues related to the sending server

What might be wrong on the receiving end

Email address does not exist

The recipient server can’t find the email account to which you’ve sent an email. Therefore, the email will bounce back to the sender because it cannot be delivered.

How to solve this?

All you can do is recheck the email address for spelling errors. 

MX record resolving to the wrong server

A Mail Exchange (MX) record is a DNS record used by mail servers to determine where to deliver an email. The sender mail server looks for the MX record in order to communicate with the recipient mail server. The MX record points to the A record which, in turn, points to the mail server’s IP address. For example, the MX record of the domain example.com points to the A record of mail.example.com, which points to 192.168.123.4. If the MX record for the recipient domain resolves to some other server, you can get 550 5.1.1 error. The email delivery fails because the receiving mail server cannot identify the email account in it. 

How to solve this?

First, you need to check the routing and DNS resolution using the dig tool with the +trace parameter. For example:

dig +trace example.com

The domain should resolve to the correct server on your end. After that, confirm the MX records for the domain using:

dig example.com MX

If you find any issues, contact the recipient server administrator to edit the DNS records and set up the correct MX records. The MX won’t resolve correctly if the DNS settings for the recipient’s domain are incorrect.

Custom security settings

It’s unlikely that a recipient server has no security mechanisms to protect from spam. If you get a 550 address rejected error message, your email might have been rejected by spam filters. It does not mean that you’re a spammer or your email is spammy. Usually, strict security rules are in the way.

How to solve this?

Use telnet to connect to the receiving SMTP server (or its IP address) to check whether the firewall is blocking the sending server. We blogged about this in How to Test SMTP Server. Run the following:

telnet example.com 25

or 

telnet 192.168.123.4 25

If telnet says that you can’t connect, it means the recipient server has blocked your emails. So, the reason for the 550 5.1.1 error is much closer to home – on the sending server.

What might be wrong on the sending end

Above we learned that the email sent from your server hit spam filters on the receiving end. There are a few reasons for that. 

Blacklisted IP

Here is how it looks. Some companies monitor servers and blacklist them if they are identified as spam senders. The majority of mail servers refer to these blacklists and reject emails coming from them. If you get 550 5.1.1 error code, your server is likely on such a blacklist. Keep in mind that the use of a shared IP address increases the probability of being blacklisted. If you use a dedicated IP and are blacklisted anyway, your server was likely hacked.

How to solve this?

The first thing to be done is to check whether your IP is blacklisted. You can use such tools as IP Reputation Monitor by GlockApps, Blacklist Check by MXToolbox, or any other you like. After that, you need to follow the blacklist-removal process. Usually, it is based on the requirements of a particular blacklisting database.

Holders of dedicated IPs should examine their email logs for spamming activity. You also need to check the server for malicious scripts. After that, block the suspicious email account and strengthen your password policy. And don’t forget to change the password, of course.

Configuration issues

Another spam trigger refers to improper verification of the sending server. This refers to the verification of TXT DNS records (SPF, DKIM, and DMARC) and the reverse DNS record (rDNS). If you get a 550 5.1.1 rejection, the DNS settings might be misconfigured.

How to solve this?

• Perform a rDNS lookup manually with a command line using the command-line tool dig (in OSX and Linux) with the added -x flag lie as follows:

dig -x 192.168.123.4

The full rDNS record will be shown in the “ANSWER SECTION” of the outcome. The record must be set up and valid. You can also make use of online tools to verify rDNS:

Reverse DNS Lookup by WhatIsMyIP.com

Reverse DNS Lookup by iplocation.net

Reverse Lookup by MXToolbox

• Check the TXT records for your domain. This can be done manually using dig as follows:

dig example.com NS

and then 

dig google._domainkey.example.com TXT @ns1.example.com

ns1.example.com is your name server, which you can find in the “ANSWER SECTION” of the outcome to dig example.com NS

• Also, you can use nslookup as follows:

nslookup -type=txt example.com

You’ll then need to find the SPF record that starts with v=spf1. For example:

v=spf1 include:_spf.example.com ~all

• Update it according to your requirements. If the SPF record does not exist, make sure to create one. For more on this, read SPF Explained. 
• Look for the DKIM record of your emails that starts with v=DKIM1. You can validate the DKIM signature using an online tool like DKIM Record Check. For more on this, read DKIM Explained. 
• Also, you need to look for the DMARC record that starts with v=DMARC1. The receiving server always looks for it. If it is missing or is modified in any way, the whole verification will fail. For more on this, read DMARC Explained. 

All DNS records should be set up in a way to show that an IP address indeed belongs to the domain it claims. Otherwise, the recipient server may think that it is using someone else’s domain to send spam emails. You can read more about this in Why Emails Going to Spam and How to Prevent It. 

How to fix 550 5.1.1 user unknown in Exchange, Exim, Postfix and Qmail servers

For Microsoft Exchange Servers

Security parameters are the main reason for error ‘550 5.1.1 User unknown’ in Exchange Servers 2010 and later. They authenticate the sender to prevent spamming and restrict email sending by default. All emails sent beyond local email addresses get bounced back with the 550 5.1.1 error. Remove the restriction as follows:

• Go to the Exchange admin center and navigate to Recipients > Mailboxes
• Click the mailbox for which you want to set up mail forwarding
• Click Mailbox Features on the mailbox properties page
• Under Message Delivery Restrictions, select View details to view or change the delivery restrictions 
• Clear the checkbox Require that all senders are authenticated. Click OK and then Save.

For Exim servers

For Exim mail servers, 550 5.1.1 User unknown is not a common issue. But if it happens, the route likely needs to be identified. First, make sure that the mail server settings are correct. Then, verify filters and custom rules added to the server. This will help you identify and fix the 550 address rejected.

For Postfix and Qmail servers

Start with the verification of the recipient domain resolution. It must resolve to the correct server. If the email service for the domain is hosted elsewhere, turn it off. Verify filters and custom rules added to the server. They must not mess up the mail delivery.

Can I avoid 550 5.1.1 when sending bulk emails?

550 5.1.1 is a nightmare for any marketer who deals with bulk emails. Why? Just imagine that your email campaign has thousands of recipients. If you failed to verify all of them, it’s most likely that a large number of email addresses are invalid. This entails multiple bounces with 550 5.1.1 User unknown. Will this have some sort of effect on email hosting providers? What do you think? Of course, it will, and your client will most likely be identified as a spammer sending emails to unverified addresses. 

You might have guessed that there is only one way to avoid this failure – keep your mailing lists clean. For this, you need to make sure that email address validation is a high-priority task. You can easily automate the process using bulk email verifiers available on the market. Some of them we’ve already introduced in the Email Testing Checklist. 

To wrap up

As you can see, 550 5.1.1 User unknown is not an unsolvable issue.

Be attentive to your server settings and do not neglect email address verification. By following these steps, you won’t jeopardize your email campaign. Additionally, it’s highly advisable to test your emails for spam. One way of doing that is using a safe testing environment like Mailtrap Email Sandbox. The Sandbox prevents test emails from reaching recipients and allows developers to troubleshoot and debug any issues. Thanks to an integrated Apache Spamassassin filter, the content of any email can get a detailed spam analysis that helps you understand what needs to be improved for a better score. 

For more on what else Emails Sandbox offers, read our Getting Started Guide.

Try Mailtrap for Free