Email Delivery Problems Explained

With an ever-growing number of spam emails flooding the Internet, more and more ISPs tighten their email filtering system to prevent spam delivered to their clients. It is virtually impossible to block even 50% of the spam arriving in a mail server, and there will always be false positives (legitimate emails filtered as spam). To reduce spam emails, the Federal Trade Commission (FTC) passed the CAN-SPAM Act of 2003, but the Internet spam traffic is still on the rise.

Internet email system is a non-confirming delivery protocol, which means that there is no guarantee that an email sent from you will be delivered to the intended recipient(s). We assume that an email will be delivered to a recipient if no "undeliverable" message is returned to you. However, this is not a safe assumption as large ISPs do filter email messages without returning "undeliverable" messages (email blackhole).

Why can't I send an email to a particular domain?

Assuming that you can send emails to other users of different domains, there may be several reasons why your email is not landing on a particular email address. This is most likely due to misconfigured or missing DNS records, or blocked IP addresses.

If your email is not delivered to a particular domain, it is more than likely due to spam filtering. Depending on how the email server is configured at the other end, you may or may not receive a bounced email message. If you do not receive a bounce message, it's really frustrating to find that your email has not been delivered to an intended recipient. Internet email is an unconfirmed delivery protocol, so there is no guarantee that your email will land in the inbox of your intended user's mailbox. This is especially true with ISPs, and Portals such as Yahoo, MSN, Google, and other providers that offer free email services. Those free email providers send and receive millions and billions of emails to and from their users, and email spam is one of the most troublesome issues to deal with. To make it tough on spammers, those email providers set up very strict filtering rules so that any suspicious email will either land in a spam folder or not be delivered at all. If so, how do we circumvent such problems as a web host?

1. Email originated from a spam blocklisted IP address. If you have a shared hosting plan, there may be a chance that your server IP address may be listed in one or more spam blocklists such as DNSBL, RBL, or SORBS. Some mail servers treat emails originating from a blocked IP address as spam emails. If you're using email clients such as Outlook or Thunderbird, it is quite possible that your home PC's IP address may be blacklisted by blocklists. The emails sent from Outlook are stamped with your home PC's IP address as the originating IP address, which may cause the email to be blocked by the receiving mail agent. To test if your home IP is the problem, you may try sending the same email from webmail. Most web hosts provide a webmail interface for managing your emails in addition to POP3 and IMAP services. You may look at the mail header, find an IP address of your mail server (or your home PC), and perform a spam blocklist check.

2. Missing Reverse DNS record for MX records. It is required by RFC 1912 that you have reverse DNS (PTR) records for all of your mail servers. If you do not have reverse DNS entries, your email may not arrive on some of the strict mail servers.

3. Mail server hostname does not match with EHLO/HELO greeting. The SMTP greeting includes a 3-digit code, followed by a space or a dash, and the mail server hostname. If your email header hostname does not match with EHLO or HELO, your email may be blocked by anti-spam software. This is a technical violation of RFC 821 Section 4.3 and RFC 2821 Section 4.3.1. The hostname given in the SMTP greeting must have an A record pointing back to the mail server.

4. Missing SPF record. Many mail servers refuse to accept emails from an IP address without an SPF record. Mail servers use SPF record to help prevent spammers from abusing their system.

Although not directly related, your mail server should be also configured to accept mail to 'postmaster' and 'abuse' email addresses. Mail servers are required by RFC 822 Section 6.3, RFC 1123 Section 5.2.7, and RFC 2821 Section 4.5.1 to accept mail to 'postmaster' account. Similarly, mail servers are required by RFC 2142 to accept mail to 'abuse' account.

Return Receipt

Some mail systems have a function that can provide a return receipt when the mail is read. The get a return receipt from the recipient mail server, you'll have to add a special mail header called return-receipt-to with a return email address where the receipt will be sent. Whether you'll get a return receipt depends on the receiving mail system. If the receiving mail system does not support receipt, the mail header is simply ignored.

Undeliverable Mail

If an email cannot be delivered, it is usually returned to you with a message indicating the problem. We usually call this a bounced email. The sample bounced message below indicates that the mail server requires SMTP-AUTH server authentication. The bounce message is from the Mailer-Daemon (mail delivery agent), and it describes the delivery problem with the original email included after the bounce message.

Your message did not reach some or all of the intended recipients.
	Subject:	Subject of the email
	Sent:	2/27/2007 8:35 AM

	The following recipient(s) could not be reached:
	'[email protected]' on 2/27/2007 8:35 AM
	550 5.7.1 ... Relaying denied. Proper authentication is required.
	

The bounce message from the SMTP server includes status codes (Enhanced Mail System Status Codes as defined in RFC 3463) with standard status messages. Each status code is comprised of three digits (i.e., 5.7.1 above). The syntax of the status codes is defined as [class] . [subject] . [detail]. The [subject] status code has three possible values as defined below:

2: Success
	4: Persistent Transient (Temporary) Failure.
	5: Permanent/Fatal Failure.

The [subject] and [detail] digits provide a more detailed status of mail delivery indication. The [subject] sub-code classifies the status, and this value applies to each of the three [class]es.

0: Other or Undefined Status
	1: Addressing Status
	2: Mailbox Status
	3: Mail System Status
	4: Network and Routing Status
	5: Mail Delivery Protocol Status
	6: Message Content or Media Status
	7: Security or Policy Status

The enumerated status codes ([subject].[detail]) describe the detailed status code of the message returned. For further information, please view RFC 3463.

Common Mail Delivery Problems

Some of the common email delivery problems are listed below.

User Unknown: The username portion of the email address (username@host) is no good. The user account may have been expired or deleted.

Host Unknown: The hostname portion of the email address (username@host) is no good. The DNS may not be able to resolve the host's IP address.

Mail Could Not Be Delivered: The message states that the email cannot be delivered for 4 hours (or some duration) means that the DNS knows about the host, but the mail server may be temporarily down. The mail server tries to resend the mail repeatedly for a 3-day period and gives up afterward.

Banned or Blocked IP Address

Increasing number of ISPs ban emails from IP addresses that are currently listed in one of the Spam Blocklist they use. A bounced email message from a blocked IP address may be indicated with the following messages:

451: IP Blocked  please visit ORDB.org/lookup/?host=10.0.0.1
451 Mail from 10.0.0.2/24 refused, see www.spamcop.net/bl.shtml?10.0.0.2

You may use our Spam Blocklists query tool to examine whether the IP in question is listed in any one of the Spam Blocklists. If you believe that you're unfairly added to any of the blocklists, you may contact them by visiting their respective websites.