Emails Boring Are Not

Email reputation and DNS records

Published in

buildo blog

4 min readJul 6, 2018

So you’d like to send some emails through code. Boring, that's easy. SMTP (Stupid Mail Transfer Protocol) is dead simple... here you go:

echo “very spoofy” | mail -s “much boring” recipient@domain.tld

It seems even designed for spoofing. We’re done, right?

Wrong.

The universe is a constant struggle between good and evil, and emails are no exception. To get emails delivered, and to make your customers happy, you need to prove you're not sending junk. You need to prove it's not spam [1, 2].

Reputation

The goodness of your emails is measured considering your reputation. If you're known to be a Nigerian Prince who sends gold to European Housewives it's very likely your emails are going to be blocked by an ISP (Internet Service Provider).

Yes, ISPs do block your emails. They use different tools for that, such as spam filters and IP blacklists. To avoid such problems, you need to uphold your reputation [4].

It takes time to build a good reputation. Quoting Mailgun:

The way to think about your email reputation is much like your credit score. When you haven’t sent any email, you don’t have a bad reputation but you don’t have a good one, either […] There needs to be a history of performance for you to create a reputation.

As you send emails you build up your reputation. Your ESP (Email Service Provider) gets convinced that you’re a good guy, and you’re progressively allowed to send more and more emails. Some ESPs help you in the process, queuing your emails and sending them at appropriate rates with respect to your level of reputation.

Both ISPs and ESPs limit the number of emails you can send. They don’t want to be blamed for your spam. Your reputation is measured considering both your IP and domain name.

Let’s get deeper into what you can do to protect your domain name.

Domain Name and DNS Records

Your reputation depends on your domain name, and that's why some people suggest you to use different subdomains for different emails tasks. For instance, you might want to have a separate subdomain for marketing emails. It might help you protect against potential damage.

Something else you can do to improve your email rejection rate is to set up some DNS records: SPF and DKIM.

Sender Policy Framework (SPF) is a simple validation system. It allows the email recipient to check whether an email from a domain comes from an authorized host. It’s a TXT record, and its content looks like this:

v=spf1 include:youresp.org ~all

Domain Keys Identified Mail (DKIM) is an email authentication method designed to detect email spoofing. You can use it to add your public key in the form of a TXT record to your domain. The record looks like:

k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC1lcwm2uUhkv/rd8towMNgXCxx       sN/DRnX70yWOdADk44Z9pwyKC8+GhzFhe8q1g2PCMBfZoloCoitr7bBDNaw3WNYP    2qextiq8rLqtdz5vNGdAhafBZG+PEACfT9Y0ZT9x9mH5+DK6tE86AcizGuWVw8glgMBH/fe13a+HPNDpdwIDAQAB;

You can then sign your emails with your private key, and the recipient (the ESP for instance) can check you were really the sender

Getting practical

Let’s see how to do that in practice. At buildo we use Mailgun to do that, the most developer-friendly email service we found so far.

Here is what you see when you add a domain to Mailgun:

This is quite self-explanatory. You just need to add those records to your domain and your done. Beware it might take up to 48 hours for the records to propagate.

We also wrote Mailo, our own Scala library to send emails: it still needs some improvement, but it already integrates with Mailgun and supports HTML email templates and MIME.

Conclusions

At buildo we have to deal with emails in many of our projects. Sending emails is not rocket science, but is not very straightforward either.

We initially wanted to write this post for internal use, but we later considered that it could be useful for others as well and we decided to make it public.

Hope you find this post useful 💌.