Email Delivery Problems

With ever growing number of spam emails flooding the Internet, more and more ISPs tighten their email filtering system to prevent spams delivered to their clients. It is virtually impossible to block even 50% of the spams arriving in a mail server, and there will always be false positives (legitimate emails filtered as spams). In an effort to reduce spam emails, the Federal Trade Commision (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 a 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” message (email blackhole).

Why can’t I send email to a particular domain?

Assuming that you can send emails to other users of different domains, there may be a number of 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 address.

If your email is not delivered to a particular domain, it is more than likely due to a spam filtering. Depending on how email server is configured at the other end, you may or may not receive a bounce email message. If you do not receive a bounce message, it’s really frustrating to find that your email is not delivered to an intended receipient. Internet email is uncomfirmed delivery protocol, so there is no guarantee that your email will land in mailbox of your intended user. 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 emails to and from their users, and email spams are one of the most troublesome issues to deal with. To make it tough on spammers, those email providers setup a very strict filtering rules so that any suspicious email will either land in a spam folder or not delivered at all. If so, how do we circumbent 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 block list 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 block lists. The emails sent from Outlook is 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 a webmail. Most web hosts provide webmail interface for managing your emails in addition to POP3 and IMAP services. You may look at the mail header, and find an IP address of your mail server (or your home PC) and perform a spam blocklist check at topwebhosts.org.

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 some of the strict mail servers.

3. Mail server hostname does not match with EHLO/HELO greeting. The SMTP greeting include 3-digit code, followed by a space or a dash, and the mail server host name. 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 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 recipient mail server, you’ll have to add special mail header called return-receipt-to with return email address where receipt will be sent. Whether you’ll get a return receipt depends on the receiving mail system. If receiving mail system does not support receipt, the mail header is simply ignored.

Undeliverable Mail

If email cannot be delivered, it is usually returned to you with a message indicating the problem. We usually called this 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:
	'test@iplocation.net' on 2/27/2007 8:35 AM
	550 5.7.1 <test@email.firm.in>... Relaying denied. Proper authentication required.
	</test@email.firm.in>

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 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]) describes 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 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 repeately for 3-day period, and gives up afterwards.

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 Blocklist. If you believe that you’re unfairly added to any of the blocklist, you may contact them by visiting respective websites.