Saturday, October 11, 2008

Make Sure Your Application's Email Gets There

Return To Sender

So many applications send email these days it's near mind boggling. Unfortunately spam continues to grow and anti-spam tools continue to get more aggressive. This often leaves developers in the middle of an email jihad, realizing that getting email to clients consistently can be a complex task.

Intranet scenarios present a little less of a challenge since you may have access to the mail administrator for the domain and you can actually figure out what kind of rules are being applied to incoming mail. Internet scenarios however require a little more attention. Not only is it awkward to QA the many different types of mail accounts (and servers) you'll be sending to, but many of them will simply ignore your mail (as opposed to sending a bounce) when your mail looks suspicious.

Developer Education

What makes the matter worse is precious few developers (myself included) get sat down at some point in their career and tutored in what a good email looks. Knowledge of SPF, PTR, MX and A records which are key to getting mail reliably to a destination, is usually compartmentalized to network, DNS and mail administrators. Either way when the mail doesn't get there, the burden often falls on the developer to figure out why email from a specific application isn't getting there.

Here are some tips, starting with what's easiest to implement to help your email reliably reach it's destination.

Use A Real Domain Name in the From Address

Don't make up domains when it comes to from addresses. A lot of email servers will check to see if the sending domain actually exists. If it doesn't then the mail will be categorized as spam and disregarded.

Odds are if you send email from it will get dropped. You can choose any value you want for someuser, just make sure the from address domain is real (that is, there's is a valid A record for that domain).

Ensure Your Domain Isn't Blacklisted

It's almost funny how often this comes up. Because mail servers often get hacked and then start spamming, blacklists are maintained by various 3rd party services to help stop the bleeding. These lists are often used by mail servers to help filter out email sent from questionable domains. It's easier than you'd think to end up on a blacklist, your domain might be blacklisted for any of the following reasons:

  • Your mail exchanger is an open relay (you can test this with 3rd party services).
  • A workstation in your domain has been infected with a virus and is sending out spam.
  • You're sending out valid email (news letters, email blasts, etc...) which has been confused as spam from multiple recipients...and they've blacklisted you.

The good news with being blacklisted is you usually get a bounce from a recipient's mail server stating why they rejected your mail and what blacklist you're on. From there you usually end up contacting the company that maintains the list and engaging with them to remove you from the blacklist.

You Have a PTR Record for Your Domain

You need to have a PTR record for your domain, and that PTR record needs to match the from address of the email message.

When mail servers get an email with a from address of, they'll often check to see if the IP address that sent the email is either:

  • An IP address to a domain that is dynamically assigned (most email coming from dynamic IP is viewed as spam and disregarded).
  • From a domain other than the one listed in the from address. IE. If your from address says the email is coming from, but the IP address that sent the email is in then this looks a little suspicious and the email may be disregarded.

It's of note that neither of the above rules can be implemented unless you have a PTR record for your domain so that the mail server on the receiving end can do a reverse lookup. If your domain doesn't have a PTR record then a reverse lookup can't be done then your emails could be ignored. Comcast for instance disregards (at time of writing) all mail from domains that don't have a valid PTR record. If you don't have one then your network admin staff can set one up.

Ensure Your SMTP Servers are Setting a FQDN in the Email Header

If you're not setting a fully qualified domain name in the email header then it may not be obvious where this mail is coming from. Half the battle in sending out email is doing as much leg work as possible so that the receiving mail server has no doubt the email is valid (or how to go about validating the email).

If you're using the IIS SMTP Server this is set under Delivery->Advanced.Setting a Fully Qualified Domain Name in SMTP Server.

Have Valid MX and SPF Records for Your Domain

Many mail servers won't accept mail from domains that don't have an MX record, ensure your domain has one (domains that receive mail will have this).

SPF records allow a domain to list the machines in the domain that are actually allowed to send mail. They are becoming increasingly important when it comes to getting your mail accepted.

Increasing Complexity

Like so many other systems developers work with today, mail is becoming increasingly complex. While it's difficult to know everything when it comes to the topic of mail and the internet, it helps to be well versed in the common problems you can run into. Unfortunately just knowing how to send email with the API often isn't enough these days.


1 comment:

digital signature said...

Congratulations, your blog is appealing and informative. Going through your Information, I found quite a few new ideas to implement.