Getting your email delivered

These days, almost every website sends email. Whether it’s from a contact form, e-commerce purchase or new post notification, email is usually the best option for communicating with visitors after they’ve left your site. So it’s a problem when those emails are treated as spam, or worse, not delivered at all.

We can thank a certain Nigerian prince for the sorry state of email delivery. In the early 2000s, the email spam problem became epidemic and to a large extent, it still is. Over the years, ISPs have gotten very good at preventing obvious spam from reaching our collective inboxes. They do this using protocols (agreed upon methods of communication) designed to validate the authenticity of each email that is passed through. Understanding what they’re looking for is the key to getting your website’s email through this protective maze.

Who is an authorized sender?

Mail systems don’t generally look at the individual sender, they look at the sender’s domain. For example. when I send mail as greg@webdancers.com, the recipient’s mail server wants to know, is this email coming from somewhere that mail from webdancers.com is supposed to come from? Now here’s the tricky part: Mail from my website comes from a completely different place than mail that I send from my own computer, yet both are “from” webdancers.com. How do I tell the world that both are ok?

Warning, acronyms ahead

These authentication protocols work using the DNS (Domain Name Service) records of your domain registration. You may need to ask for help in working with DNS but anyone can understand the principles involved.

The most basic authentication protocol, and the one that has been around the longest, is SPF (Sender Policy Framework). It works by adding a list of the authorized places that mail can come from to the DNS records of the domain. Recipient mail servers then query DNS for the SPF record and reconcile the list of approved senders against the path the message actually took. The SPF record can also tell the recipient server what action to take in the event of a non-match. In that case, the message can either be thrown away completely or just marked as suspicious. What happens after that is up to the receiving mail service.

A newer, more comprehensive protocol is DKIM (Domain Keys Identified Mail). DKIM uses cryptography to digitally sign every email sent and it must be supported by the sending mail service. Mail sent from your website probably won’t be using DKIM, while mail sent from your email application likely will. DKIM can guarantee that the mail came from a particular domain in ways that SPF cannot (public and private keys, blah blah blah). For that reason, if it’s available it should be added to your domain’s DNS. Your ISP or mail hosting company will be able to provide instructions and assistance.

Use fewer mail servers

You can reduce a lot of this complexity by using the same mail server for both your website and email sent from your computer. For example, I use Google as my mail service. If I configure my website to send mail using Google’s servers, the same SPF and DKIM records will apply to email sent from either place. Note that this is not the way most web hosting companies send mail from websites. They will use their own mailer service to send mail for all of the websites on the server. WordPress users can install a plugin such as WP Mail SMTP to make a connection to their own domain’s primary mail server.

Summing up

You should have SPF and, if available, DKIM set up for every mail server that sends mail using your domain name. It’s the first thing that your recipient’s mail server will check. While there are certainly other things that can prevent your mail from getting through (lots of attachments, images and links, spammy subject lines), these protocols are table stakes, so don’t ignore them.