Tutorial Troubleshooting "550 Please turn on SMTP Authentication in your mail client"

If you use ConfigServer Security & Firewall (CSF), there is a potential conflict between CSF and the "Restrict outgoing SMTP to root, exim, and mailman (FKA SMTP Tweak)" Tweak Setting.

The "FKA SMTP Tweak" works by adding iptables rules that redirect any normal user connections attempts to make an outbound SMTP connection get redirected back to localhost. The rules do not apply to the mail transport agent (MTA), Mailman mailing list software, and the root user.

Here is an example of the firewall rules added by the Tweak Setting, from the output of "iptables-save":

In rare cases, during server start up, both CSF and cPanel may attempt to make changes to the firewall rules at the same time, and the full set of rules may not be properly configured, which can result in all outbound SMTP connections being redirected to localhost -- including exim. This causes authentication failures because exim is unknowingly is sending outbound emails to itself.

It does not necessarily happen every time the server boots up, so no issues may occur after several reboots. However, all of a sudden one day everyone trying to send mail through your server gets the 550 error, even though they have proper SMTP authentication.

If you ever run both the Tweak Setting and CSF, CSF will provide the following warning:

*WARNING* The option "WHM > Tweak Settings > Restrict outgoing SMTP to root, exim, and mailman (FKA SMTP Tweak)" is incompatible with this firewall. The option must be disabled in WHM and the SMTP_BLOCK alternative in csf used instead

Click to expand...

That is the solution -- disable "FKA SMTP Tweak" via the Tweak Settings interface, and (optionally) enable SMTP_BLOCK in CSF. If you ran into this problem, you should also reload your CSF rules after you make these changes, to ensure they are correct. It is best to ensure that you have console access before changing the firewall rules, because it is possible to accidentally lock yourself out of the server.

Sometimes, you may send an email from another email provider to your server, and get the 550 error message, even though you are not using an email client.

The cause of the error is usually that the MX record for the recipient domain name points to the server, but the Email Routing is set to Remote Mail Exchanger rather than Local Mail Exchanger.

The easiest way to check this from the command line is to check for the domain in the /etc/remotedomains and /etc/localdomains file:

In this instance, "problemdomain.tld" is set to use a remote mail exchanger -- however, the MX record for it points to the server.
When someone tries to send an email to any "@problemdomain.tld" email address, they get a bounceback error like this:

The solution for this is to correct the mail routing for the domain in cPanel » "Email Routing". If email for the domain should be hosted on your server, ensure it is using "Local Mail Exchanger". If emails are supposed to be external (such as users of G-Suite or Office365), use "Remote Mail Exchanger".

This setting is important to get right -- and while you are looking at it, you should also verify that the MX record points where you intend as well. Check both the DNS record on the server, and the public DNS record. Keep in mind that if a domain users external nameservers, the actual MX record others see may not match what cPanel thinks is configured.

I prefer to use the command line tool "dig" to check MX records -- it can be used as follows:

In this example, emails to any @problemdomain.tld email address goes to the servers with IP addresses 1.2.3.4 and 5.6.7.8.

If you have recently made changes to the DNS, you can use "+trace" instead of "+short" to do a full recursive query and bypass propagation delays.

Often times, your mail client may be configured to send a password when logging in to check your emails, but not when sending them.

For some servers, this will work -- but others will reject them.

In WHM » Tweak Settings, there is an option "Allow users to relay mail if they use an IP address through which someone has validated an IMAP or POP3 login within the last hour (Pop-before-SMTP)".

Sometimes, people may migrate from a server where that setting was ON to a server where it is OFF (which is the default). In such cases, they might not have ever actually configured their email clients for authentication for outbound messages. Suddenly after migration to the new server, they start receiving the 550 error.

There are two solutions for this:

1. Reconfigure your mail client to ensure it is using outgoing authentication. Each mail client should have a setting for this.
2. Enable the Tweak Setting, so that it doesn't matter so long as you are able to authenticate over POP/IMAP.

The SMTP Restriction Tweak Setting mentioned earlier prevents code running under a website from sending direct outbound mail and bypassing the local exim.

This is important for preventing a website from being able to send a large amount of spam without the server administrator being able to detect it.
For example, if a PHP script makes a direct outbound connection via port 25 (or any SMTP submission port) to external mail servers, it will not be logged anywhere in your exim logs, because it does not go through exim.

Because the setting works by redirecting the connection to the local mail server, generally scripts that are coded to use direct SMTP on servers with the SMTP restriction enabled will run into authentication errors.

The options to work around this are:

1. Create a local email account for the script to log into and send mail from.
2. Use sendmail instead.
3. Disable the Tweak Setting. Note that this is server wide. If you want to have the Tweak Setting enabled on a per-user basis, you would need to set up your own firewall rules, similar to the ones I noted above in the CSF section -- but allowing more UID/GIDs through.