I do not like green eggs and SPAM!

November 15th, 2023

One of the things we do for our customers is send email. A lot of it. And it is important for their customers (and so for the business) that this email arrives quickly and reliably. This is easier said than done.

Building on the ruins of the past

Email is a very old medium in computing terms, it's protocol is one of the oldest. The original protocol dealt with the technical delivery of a message over a network. It did not factor in any security. Because who would ever try to send an email pretending to be someone else, right?? Unfortunately, almost half of all emails sent are spam (down from 80% in 2011 - yikes!). Since the beginning, a lot of extra protocols have been added in email for the receiving side to confirm:

1. Are you allowed to send me this email? (SPF)
2. Is the content the same since you sent it? (DKIM)
3. If I get email that does not pass 1 and/or 2, what should I do with it? (DMARC)

If you are building applications that send email, you should be familiar with these terms. If you are paying someone to build an application that sends email, you should be aware that these things exist.

Do not build what you can buy

We did not build an email sending platform for any of our customers. None of them has "sending email" as a core business, it does not make sense to build what you can buy. In this case, we use a SaaS email sending platform so we can fire-and-forget from the application's side.

But you still need to configure your sending domains. And while most email sending services will help you with the correct configuration, what we learned over the years is:

"All services are equal (they can all send email) - but some are more equal than others!"

This is not an article meant to compare these services. But some differences are potentially risky so you need to be aware of them to decide if the risks are acceptable to you.

Configure , configure, configure

The first thing an email service should ask you to confirm is domain ownership. This is not used directly in a check by an email recipient, but it protects the email sending service from becoming a spammer themselves. It is important to confirm that the service blocks email from unverified domains. If you can send email from any domain through your account then other customers can do the same with your domains*.

The services can check domain ownership by asking you to add a DNS record for your domain.

*This risk is even larger when combined with a shared DKIM key (below)

SPF

The easiest configuration to cover is SPF. This answers question 1 for the recipient of an email: are you (the sending server) allowed to send me this email?

This checks if the sending domain (something@yourdomain.name) has an SPF entry in DNS. The entry should contain the IP address of the mail server that sent the email. Confirming that the sender at least trusts the mail server (as opposed to some other party sending an email in your name). Since this check is IP based, our advice is to pay for a dedicated IP address right from the start. This way, you only trust "yourself" to send email. In any case, you'll want to keep this list as short as possible.

Once you send a lot of email, you always need to keep in mind that any IP that sends a lot of email needs to be "trusted". Building trust takes time - a process called IP warming. If you only have one service for sending email and only a single warmed IP, this poses a vendor-lock-in risk that you might want to avoid. It depends on your needs, but be aware of the risk at least. Migrating from one service to another is not a trivial task and can take weeks (if not months) to complete.

DKIM

The second thing to configure is a DKIM key. This one allows the recipient to answer question 2: Is the content the same since you sent it?

This checks if the sending domain has a DKIM key in their DNS, which is used to confirm the contents of the email. Like a physical letter, an email can have a few stops between sending and delivery. The check confirms that none of the stops has changed the message along the way.

It's important to realise that your email sending service is adding this DKIM signature for you on each email. What you do is provide the key that can confirm the message. In our opinion, each of the email service's customers (you!) should get a unique key. Otherwise, other customers of the same email service can potentially send valid DKIM signed email from your (domain) name*.

*This is a big risk if the email sending service allows sending email for non-validated domains, see domain ownership above.

If the key is not unique, at least the DKIM selector should be unique. The "selector" is going to be added to each email as a header. It tells the recipient in which DNS record the public key will be found. If the selector does not look very unique (something like "mail") then it's a good idea to ask your email service how they are mitigating the risk of email from other customers being sent in your name.

DMARC

The final thing to configure is DMARC. This is the most important one, since it answers the third question: If I get email that does not pass SPF and/or DKIM, what should I do with it?

Email for a domain that does not have SPF or DKIM configured could still be valid, but email clients will (and should) be more weary of delivering these emails.

The configuration can be quite extensive. It has rules that tell the receiving mailserver that it's okay to dump an email in the trash without delivery if the SPF or DKIM check does not pass. In case of external spammers mis-using your domain there is not much more you can do. A domain with all settings in order that instructs 100% of invalid email to be dropped will be much less interesting for spammers to use. Because none of their email would get through.

But DMARC also includes a way to configure a report back to you as a sender, if any email was not properly configured. It's configured by adding an additional part to the DMARC DNS record and contains an email address to send the report to. rua=mailto:reporting@yourdomain.com. Since you will receive a lot of these reports, it's highly advisable to configure a service that can process these reports for you.

This reporting can really help if you, or even your email service screws up. We're all human and mistakes happen. But getting a bad reputation as an email sender can have bad consequences for a long time. So keeping an eye on the number of invalid emails can help with early detection of problems.

Final thoughts

The term "web developer" is sometimes synonymous with "programmer", and I'm not sure if I could define the roles with clear boundaries. But I do know that when developing for the web some aspects of the job have very little to do with writing code... in Dutch we have a saying "door schade en schande wordt men wijs" - roughly meaning that you learn best from your mistakes. Some of the work that we do comes from being in this business for 17 years.

This post outlines some of the challenges involved in sending email from applications we build for our clients. I hope it helps you if you're also building applications, or if you're deciding to hire a party to do that for you, or even if you're picking a service to send email for you.

Good luck (and don't send spam!).

Other resources:

• History of email
• Spam statistics
• SPF
• DKIM
• DMARC

Ramon de la Fuente

Pointy haired boss