At Brixly, Technical Analysts will get asked this question many times. Unfortunately, the question is a little vague since there are really hundreds of reasons why an email may not get delivered.
These can be:
- Authentication issues (the most common).
- DNS related issues (is your rDNS set up correctly?).
- SPF, DKIM and/or DMARC settings (misconfigured or missing completely).
- Firewall issues (or proxying of port 25 by the NOC, Datacenter, Host or customers ISP) or other networking issues.
- Blocked IP addresses (Customers IP address may be blacklisted).
- SpamAssassin settings too strict.
- Spammer (or more likely a compromised email account) has filled up your exim mail queue with spam messages and legit messages are now waiting to be sent.
- Exim misconfiguration.
- Sender Verify and even Greylisting or other temporary soft-errors.
- An incorrect setting within your /etc/resolv.conf file.
- A misconfigured filter.
- Mailbox is over quota (5.2.2. error).
- Virus was attached to message and virus scanner redirected your email to /dev/null.
What are bounce messages?
A bounce error is also called a Non-Delivery Report/Receipt (NDR), a (failed) Delivery Status Notification (DSN) message, a Non-Delivery Notification (NDN) and is an automated electronic mail message from the mail server informing the sender about a delivery problem. There are two types of errors. Temporary errors (which start with a 4.x.x) are known as soft-bounce errors, and permanent delivery errors (which start with 5.x.x) and are known as hard-bounce errors. Temporary errors will usually be re-delivered, while permanent errors will be returned or bounced.
That being said, the most common cause is usually user error in setting up the email on their mail client (Outlook, Thunderbird, Eudora, etc...) So the first thing that should be checked is the configuration settings. In cPanel all user names for both POP (Post Office Protocol) and IMAP (Internet Mail Access Protocol) are the full email address.
The mail server in most cases is mail.DOMAINNAME.TLD (where DOMAINNAME.TLD is the domain name in question). Verifying authentication issues for sending email is fairly trivial and not part of this post.
Below, I've outlined some of the things that should be checked when trying to troubleshoot email delivery. These are just some of the more common error messages we (as technical analysts) have seen.
Take a look at the following error...
firstname.lastname@example.org <email@example.com> R=dkim_lookuphost T=dkim_remote_smtp: SMTP error from remote mail server after initial connection: host somedomain.com [xx.xxx.xx.xxx]: 550 Your host is not allowed to connect to this server. Frozen (delivery error message)
See the "550" Your host is not allowed to connect to this server message? That means point blank that the host you are trying to send to, has blocked your server. This could be do to spam complaints or other abuse issues, or even because that server is misconfigured. You would need to contact the host in question to ask why they have decided to block your server. You should also check to see if your server has been blacklisted. A good site to use to check that is:
Another error that might creep up from time to time is this one:
SMTP error from remote mail server after end of data: host someserver.mx.domain.com [xx.xx.xxx.xxx]: 521 5.2.1 : http://postmaster.someserver.com/errors/521.html
This one actually contains a link (obscured for security) to a site that will explain why the message failed, and usually why it failed.
I mentioned earlier about soft-errors vs hard-errors, take a look at the following error message:
2013-12-29 23:41:45 1VxPzN-3420m0-1p SMTP error from remote mail server after initial connection: host mx.somedomain.com [xxx.xxx.xxx.xxx]: 421 mx.someserver.com Service unavailable - try a gain later
The temporary error could very well be Greylisting. Greylisting is a method of defending e-mail users against spam. A mail transfer agent (MTA) using greylisting will temporarily reject" any email from a sender it does not recognize. If the mail is legitimate the originating server will, after a delay, try again and, if sufficient time has elapsed, the email will be accepted.
It might be some other temporary issue however so you would need to contact the mail service provider of the host in question to find out what that temporary reason is (or just wait to see if it goes through later).
We've also seen a few issues with the big mail servers (Gmail, Yahoo, Hotmail/Outlook.com) rejecting mail connections. The majority of them have been firewall related (either your server's firewall or one upstream from your server).
To test if it's a firewall issue, you can try a simple telnet command to port 25 from your server. First you have to obtain the correct MX record, which can be done via a dig (Domain Information Groper) query.
root@server [~]# dig gmail.com MX +short 5 gmail-smtp-in.l.google.com. 30 alt3.gmail-smtp-in.l.google.com. 40 alt4.gmail-smtp-in.l.google.com. 10 alt1.gmail-smtp-in.l.google.com. 20 alt2.gmail-smtp-in.l.google.com.
Now armed with the MX records, you can try to telnet to port 25 on one or more of them.
root@server [~]# telnet alt3.gmail-smtp-in.l.google.com 25 Trying 22.214.171.124... Trying 2a00:1450:4008:c01::1b... telnet: Unable to connect to remote host: Network is unreachable root@server [~]# telnet mta6.am0.yahoodns.net 25 Trying 126.96.36.199... Trying 188.8.131.52... Trying 184.108.40.206... Trying 220.127.116.11... Trying 18.104.22.168... Trying 22.214.171.124... Trying 126.96.36.199... Trying 188.8.131.52... telnet: Unable to connect to remote host: Connection timed out root@server [~]# telnet mx4.hotmail.com 25 Trying 184.108.40.206... Trying 220.127.116.11... Trying 18.104.22.168... Trying 22.214.171.124... Trying 126.96.36.199... Trying 188.8.131.52... Trying 184.108.40.206... Trying 220.127.116.11... Trying 18.104.22.168... Trying 22.214.171.124... Trying 126.96.36.199... Trying 188.8.131.52... telnet: Unable to connect to remote host: Connection timed out
As you can see from the above, all of them sit there simply Trying to connect. That's a big indication that a firewall (either yours or one upstream from you is blocking the connection). To test this thoroughly, you should also try to telnet to each one of the above to port 25 from another location that is not your server and not using your servers internet connection. If it works from the other location, then chances are it is your server or your data center, NOC or hosting provider that is blocking (also known as proxying) port 25.
Here's another one where a server administrator added a DROP rule for port 25 to his server and wondered by email was not being delivered...
First the rule:
12 14 NNN DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25
Here's the resulting log file entries:
2013-12-24 17:19:25 1VvSpO-0006ga-QZ SMTP error from remote mail server after initial connection: host mx.aol.com [xx.xx.xx.xxx]: 421 mx.aol.com Service unavailable - try again later
Let's talk a little about SPF (Sender Policy Framework). Lots of information can be found at www.openspf.org.
A message in the /var/log/exim_mainlog file might look like this:
SMTP error from remote mail server after HELO server.someserver.com: host backup.anotherserver.net [xxx.xxx.xx.xx]: 550-SPF HELO check failed (Fail): 550 See http://www.openspf.org/why.html?sender=postmaster%40server.someserver.com&ip=xxx.xxx.xxx.xx&receiver=backup.anotherserver.net
This message indicates that the message was rejected by the mail server because it didn't have a valid SPF record. To check the SPF record of the domain in question we would again use the dig command:
root@server [~]# dig anotherserver.net TXT +short
If you get nothing back, then you need to have the customer add an SPF record to their DNS. Documentation on how to set up SPF and DKIM records can be found here.
Additional note: There is another form of email authentication that Google/Gmail is using called dmarc.
If you have email that is either being rejected or is landing in the Spam folder at Gmail, look at the full headers (Show Original) and look for "dmarc=fail If you don't yet have a dmarc record, you can learn how to set one up here.
If you do get something back, then using the information at openSPF.org should help you decipher what the record is doing (or not doing). Then armed with that information you can go to the link in the error message (if one is provided) and find out why they are blocking the message.
Not permitted to relay errors
Another common message we see is this one:
Please turn on SMTP Authentication in your mail client. mx.someserver.net (mx.someserver.net) [xxx.xxx.xxx.xx]:4471 is not permitted to relay through this server without authentication.
This is pretty self explanatory, and usually means that the MUA (Mail User Agent) which is usually Outlook doesn't have the "My SMTP server requires authentication" option checked.
However, it can also mean that you have a script or program/application that is not authenticating properly before attempting to send email.
UNKNOWN email address
Here's a log entry showing a rejection due to an invalid email address:
2013-12-12 12:44:55 1Vr5dP-0004RG-6a SMTP connection outbound 1386852295 1Vr5dP-0004RG-6a someserver.com firstname.lastname@example.org 2013-12-12 12:44:56 1Vr5dP-0004RG-6a ** email@example.com R=dkim_lookuphost T=dkim_remote_smtp: SMTP error from remote mail server after RCPT TO:<firstname.lastname@example.org>: host mail.someserver.com [xx.xxx.xxx.x]: 553 sorry, unknown email address;
In this case, the person obviously tried sending to an email address that doesn't exist.
No such user here (but with a slight twist)
This one had us scratching our heads at first. See if you can figure out what is going on here:
2013-12-14 02:01:57 1VrkAf-0007F8-30 <= email@example.com H=localhost (onthisserver.com) [127.0.0.1]:53861 P=esmtpa A=dovecot_login:someuser S=853 firstname.lastname@example.org T="test from cPanel - please ignore" for email@example.com 2013-12-14 02:01:57 1VrkAf-0007F8-30 ** firstname.lastname@example.org R=virtual_aliases: No Such User Here 2013-12-14 02:01:58 1VrkAf-0007F8-30 Completed
See the R=virtual_aliases line? That means it is routing to a virtual alias on this server, and that user doesn't exist. But wait, it's going to a @yahoo.com account??? The problem here was that the server administrator added the following line to the /etc/userdomains file:
# grep yahoo /etc/userdomains yahoo.com: yahoo
Obviously this server is not answering for Yahoo Simply removing that line from /etc/userdomains fixed that issue.
Custom SpamAssassin Rules
Let's look at SpamAssassin and a message that was marked as spam and bounced back to the recipient even though it really isn't spam at all. In the exim_mainlog file, you may see something like this:
X-Spam-Status: No, score=0.8
X-Ham-Report: Spam detection software, running on the system "server.somedomain.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email.
This particular message got a score of 0.8 (less than 1) so it wasn't really flagged as spam, but as ham. Now, you may be asking your self, what the heck is ham?? "Ham" is email that is not Spam. In other words, "non-spam", or "good mail".
So why was this message returned? It's not considered spam so shouldn't it have been delivered? Once again, looking at the exim_mainlog file, we see the following:
spamd: config: score: requires a symbolic rule name and 1 or 4 scores spamd: config: SpamAssassin failed to parse line, no value provided for "score", skipping: score 2
Hmmm. Looks like a SpamAssassin configuration problem. Looking at:
SpamAssassin Configuration Documentation, the correct syntax for using the score option, is "score SYMBOLIC_TEST_NAME n.nn" So a configuration of "score 2" is syntactically incorrect.
Spam detected - Message bounced
So here's one where spam was actually detected and the message was bounced. I've included this just so you can see what it looks like in your /var/log/exim_mainlog file.
2014-01-15 11:39:48 1W3TVL-003z0J-Lq H=(server.domain.com) [xx.xx.xxx.xxx]:44151 Warning: "SpamAssassin as server detected message as spam (26.2)" 2014-01-15 11:39:48 1W3TVL-003z0J-Lq <= A_SPAMMER@somespamdomain.net H=(server.domain.com) [xx.xx.xxx.xxx]:44151 P=esmtp S=11026 email@example.com T="Update Your Biography" for firstname.lastname@example.org 2014-01-15 11:39:48 1W3TVL-003z0J-Lq => /dev/null <email@example.com> R=central_filter T=**bypassed** 2014-01-15 11:39:48 1W3TVL-003z0J-Lq Completed
Here, you can tell that it was NOT delivered because of the "central_filter" and "bypassed" line.
Filters... Friend or foe?
What exactly is a filter? A filter is a way of processing and email message but with certain criteria. Common uses for mail filters include organizing incoming email and removal of spam or viruses.
2014-01-02 10:19:53 1Vykza-0005s5-La <= firstname.lastname@example.org U=root P=local-esmtp S=449 T="This is a test message with filters" for email@example.com 2014-01-02 10:19:53 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1Vykza-0005s5-La 2014-01-02 10:19:53 1Vykza-0005s5-La => /dev/null <firstname.lastname@example.org> R=virtual_user_filter T=**bypassed** 2014-01-02 10:19:53 1Vykza-0005s5-La Completed
If you see this: (R=virtual_user_filter and T=**bypassed**), that means that a filter has been set up to discard or delete the message. You can also see that it was redirected to /dev/null. Let's see if we are correct by going to:
# cd /home/cptest/etc/cptest.net/newuser # ls -al filter* -rw-r--r-- 1 cptest cptest 339 Jan 2 10:13 filter -rw-r--r-- 1 cptest cptest 232 Jan 2 10:13 filter.cache -rw-r--r-- 1 cptest cptest 253 Jan 2 10:13 filter.yaml # cat filter # Exim filter # Auto Generated by cPanel.Do not manually edit this file as your changes will be overwritten. If you must edit this filter, edit the corresponding .yaml file as well. if not first_delivery and error_message then finish endif #Fubar Rule if $header_from: is "email@example.com" then save "/dev/null" 660 endif
So, any message sent from firstname.lastname@example.org is automatically deleted by saving it into /dev/null
Those by the way are user level filters. For Account Level Filters, you would look in the /etc/vfilters directory.
Blacklisted IP Address
How about if your servers IP address is blacklisted? First of all, you can check to see if your IP address is blacklisted or that of the customers ISP. It's more common that your customer's IP address is blocked.
SMTP error from remote mail server after initial connection: host mx.ayahooserver.net [xx.xxx.xxx.xx]: 421 4.7.1 [TS03] All messages from xx.xxx.xxx.xxx will be permanently deferred; Retrying will NOT succeed. See http://postmaster.yahoo.com/421-ts03.html: retry timeout exceeded
This particular message means that Yahoo's server has blacklisted you (or your customers IP address). You should check with them (using the link they provided) as to why. Notice that Yahoo is using a soft-error code (421)? They *should* be allowing retries and not state that Retrying will NOT success. It's technically against RFC.
Here's a similar one from Google:
SMTP error from remote mail server after end of data: host ASPMX.L.GOOGLE.COM [184.108.40.206]: 550-5.7.1 [xxx.xxx.xx.xxx 1] Our system has detected an unusual rate of 550-5.7.1 unsolicited mail originating from your IP address. To protect our 550-5.7.1 users from spam, mail sent from your IP address has been blocked. 550-5.7.1 Please visit http://www.google.com/mail/help/bulk_mail.html to review 550 5.7.1 our Bulk Email Senders Guidelines. xa2si10793227pab.345 - gsmtp
Remember that you can use MX Toolbox to check an IP address to see if it is blocked on any other lists. No matter how you get on a blacklist, your first priority is to contact the blacklist and find out how to get removed. some lists, you don’t need to do anything; for others, you may need to make changes and prove that you have made those changes. The procedures are as varied as the lists themselves.
Invalid PTR/rDNS (reverse) record
rDNS (Reverse or PTR). Another common problem with email being returned is if the IP address that you are using to send email from does not have a PTR (or rDNS/reverse DNS) record set up. Let's use cPanel's MX IP address to test this:
# dig -x 220.127.116.11 +short mx1.cpanel.net.
That happens to be correct, so we know that mx1.cpanel.net points to 18.104.22.168 and the reverse of that IP address points back to mx1.cpanel.net. If you get back nothing at all, or something other than what you expected, then that can be a problem as some mail servers will reject email if the PTR does not match or is missing. To set up an rDNS properly, your ISP/Hosting provider, NOC or Datacenter must have delegated the IP address to you. The following documentation will show you the steps you need to set up your own rDNS.
If they have NOT delegated the IP address to you, then they will need to set up the proper rDNS entries for you.
Invalid entry in /etc/resolv.conf
An invalid /etc/resolv.conf file can also hinder delivery messages. In that case the log file may look something like this:
2014-01-02 12:45:59 1VynH0-0006D0-Oc <= email@example.com U=root P=local-smtp S=417 T="Test2" for firstname.lastname@example.org 2014-01-02 12:45:59 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1VynH0-0006D0-Oc 2014-01-02 12:46:00 1VynH0-0006D0-Oc == email@example.com R=dkim_lookuphost defer (-1): host lookup did not complete
So if your /etc/resolv.conf file contains an IP address that can not resolve gmail.com then this is a problem. Once fixed the same message can be seen as having been successfully sent.
2014-01-02 12:48:52 1VynJq-0006DL-OO <= firstname.lastname@example.org U=root P=local-smtp S=425 for email@example.com 2014-01-02 12:48:52 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1VynJq-0006DL-OO 2014-01-02 12:48:57 1VynJq-0006DL-OO => firstname.lastname@example.org R=dkim_lookuphost T=dkim_remote_smtp H=gmail-smtp-in.l.google.com [22.214.171.124] X=UNKNOWN:ECDHE-RSA-AES128-GCM-SHA256:128 C="250 2.0.0 OK 1388688538 jb8si45146276obb.27 - gsmtp" 2014-01-02 12:48:57 1VynJq-0006DL-OO Completed
Sender verify failures
Here's one where the server shows Sender verify failed...
SMTP error from remote mail server after RCPT TO:email@example.com: host someserver.com [xxx.xxx.xxx.xxx]: 550-Verification failed for firstname.lastname@example.org 550-The mail server could not deliver mail to email@example.com. The account or domain may not exist, they may be blacklisted, or missing the proper dns entries. 550 Sender verify failed
In this particular case, the problem was that there was no A record for the host.someserver.net account. The error message was pretty much right on the money with the account or domain may not exist.
Once the customer was advised to add an A record, the problems went away.
Here's another interesting error...
2013-12-24 13:08:21 H=mail.someserver.com [xx.xxx.xxx.xx]:56035 F=<bounce-452_HTMLfirstname.lastname@example.org> temporarily rejected RCPT <USER.NAME@DOMAIN.COM>: remote host address is the local host
This was caused because the host name was not a Fully Qualified Domain Name (FQDN). To fix this, make sure your hostname for the server is always a FQDN.
As you can see there are dozens of reasons why an email message may not be delivered. Log files don't lie, and they will always be able to tell you why the message could not be delivered. It just takes a little research on your part. I hope that the above information is helpful to you and if you have anything to add to this please let me know.
As an additional note, if you haven't read it yet, I recommend reading the SPAM Primer by Randy Cassingham. This truly explains in laymans terms what spam is, who sends it, and how they got your email address in the first place.