Emails are being rejected by some email providers

Question

I have this asp.net application that sends out emails. The SMTP server is iis6. The emails are being sent on behalf of our application users and they have different domain names. Most of the email providers, like gmail and yahoo, would accept the emails but some of them not e.g. AOL.

This is the message that users receive from our SMTP server after a few minutes:

Subject: Delivery Status Notification (Failure) This is an automatically generated Delivery Status Notification. Unable to deliver message to the following recipients, due to being unable to connect successfully to the destination mail server.

Answer 1

The message you posted is a failure to connect which doesn't necessarily mean they refused your email, it seems more likely a dns issue or some other connection issue. Some things to check/think about are:

Can you check your application server to make sure it is properly resolving the dns and MX records for the domain you are trying to email.

Can you telnet from this server to those domains, if so what response do you get?

Do the domain names you are sending from have spf records and if so, is the ip you are sending from included in the spf record?

Are reverse DNS records setup properly for the IP you are sending from for the domains you are sending as?

Ideally, before anyone can really give you a definitive answer on the problem you need to have a telnet or something and get a server response telling you why you cannot connect in the first place.

Answer 2

One possible option is that these servers are flagging your email as Spam. Even if it is not really spam, many email providers block messages that are not exactly correct, or that are going out to a large number of people.

We ran into this at one point and had to contact a bunch of providers to get white listed. Once we contacted them and explained our email coupon program (opt in, fully compliant with CAN-SPAM) and gave them the details, they added us to white lists.

There are a lot of things that can get you flagged as a spammer. Here are a couple to check:

1. Number of emails going out.
2. HTTP headers on the email not matching the domain you're sending from. (Example: using a from address of @microsoft.com when the email is coming from your own domain.) This can happen by accident if you're using a domain like @yourcompanyname.com, but the SMTP server is registered under a different domain or is not registered under your domain.

Here are a few links you may find useful

http://searchwarp.com/swa209211.htm

http://www.wilsonweb.com/05/020529b.htm

http://searchdomino.techtarget.com/news/article/0,289142,sid4_gci1192720,00.html (not really Domino specific, ins spite of the url)

Answer 3

The message you posted is a failure to connect which doesn't necessarily mean they refused your email, it seems more likely a dns issue or some other connection issue. Some things to check/think about are:

1. Can you check your application server to make sure it is properly resolving the dns and MX records for the domain you are trying to email.

2. Can you telnet from this server to those domains, if so what response do you get?

3. Do the domain names you are sending from have spf records and if so, is the ip you are sending from included in the spf record?

4. Are reverse DNS records setup properly for the IP you are sending from for the domains you are sending as?

Ideally, before anyone can really give you a definitive answer on the problem you need to have a telnet or something and get a server response telling you why you cannot connect in the first place.

Answer 4

Where is the NDR coming from, presumably your IIS SMTP server, although I don't work with IIS SMTP very often so I'm not sure if the IIS SMTP server is capable of generating NDR's.

In any event make sure to enable logging in the properties of the IIS SMTP server and then check the logs after you receive an NDR. If there are no entries in the log file that correspond to the email that generated the NDR then I would suspect a problem with the IIS server's dns client being able to resolve the MX record for the recipient's domain. If there are entries in the log file that correspond to the email that generated the NDR, then the SMTP status codes in the log file should clue you in to what's happening.

Answer 5

Make sure you are specifying Sender and Return-Path in the email header. Read this one: http://serverfault.com/questions/40215/send-email-on-behalf-of-clients

Answer 6

You should first check that you can actually connect to the destination SMTP mail server from your internal server. You can do that by telnet <destination server> 25 and see if you get the greeting. Sometimes, some places filter out port 25 connections as a spam prevention policy.

Another potential problem with mail is the reverse dns setting. Sometimes, the destination servers check who you claim to be by checking your source ip against the domain that you claim to represent. You may need to set this up with your DNS provider.

Answer 7

Some mailservers will limit your connections until you establish that IP address as a safe sender. This takes several things - you have to adhere to best practives for settings up:

1. Reverse DNS Entry
2. SenderID / SPF
3. Domain Keys

You'll also be better off if you submit the IP(s) to the various whitelist / bulk sender lists, such as AOL and yahoo.

The number of users that report you as spam and the number of bad email addresses you send to will also affect your ability to send.

Habeas and Returnpath can also give you some extra "points" to make your spam score better.

Finally, if you are sending emails from users that aren't on your domain, you're likely to always have some issues. You might try sending from a specific email address, and just changing the from name and "reply-to" address in the email.

Answer 8

Who are you hosting your application with? I've had problems with shared hosts having all sites hosted on their servers blacklisted into the spam hole.

Just because your application isn't sending spam doesn't mean that another app on the shared host isnt. Since it's a shared host, all smtp traffic comes from the same source, which can end up being blocked.