blog.thms.uk

Using DNS records to protect your email brand

If you own a successful brand, some miscreants will eventually abuse your domain to send spam pretending to be from you.

This is because there is nothing you can do to stop others from sending emails with a From: address containing your domain. But there are a couple of things you can do to tell the email provider of the recipients of such faked emails to discard them.

The problem

The sender of any email can basically write whatever they want into the From: field of an email, and the recipient's email app will almost always just display whatever is written as From: to the reader. This has always been the case, and as a result multiple techniques have developed to counter that threat.

In this post I'll cover three of them: SPF is the oldest, and quite well understood and used by almost everyone these days. DKIM and DMARC are newer, but also widespread now, but many smaller brands still don't use them (or don't make full use of them).

SPF

The Sender Policy Framework (SPF) can be used to tell recipient email service providers, which service provider (or server) is authorised to send email on your behalf. So, if you use Microsoft 365 for your emails, and mailchimp for your newsletter, you can use SPF to indicate that any email that is not originating from either of these services and pretending to be yours, is likely Spam.

SPF involves publishing a specially crafted DNS TXT record that recipient mail servers can then inspect and evaluate.

Here is an example SPF record:

v=spf1 ip4=192.168.1.1 include:spf.protection.outlook.com -all

What does this mean?

Almost all third party email providers will give you an include: tag to add to your SPF record, and you can add (almost) as many of these as needed to your SPF record by just listing them one after another.

You definitely should provide a valid SPF record for your domain, and your email provider will provide you with the correct record to use.

Importantly, if you use multiple email providers, you should combine the SPF records you have been given into one, rather than have multiple SPF records for your domain.

DKIM

DomainKeys Identified Mail (DKIM) is a somewhat newer method, and a bit more tricky to set up and configure, which is why several providers don't enable it by default. MS365 in particular makes it extraordinarily hard to enable this.

Unlike SPF - which simply identifies servers or services allowed to send email on your behalf - DKIM includes a cryptographic signature in every email. This gives some certainty that not only is your email from an authorised server (or service), but from an authorised user account.

A DKIM record is another DNS TXT record. Your email provider will provide it to you, and give you instructions on how to use it. Unlike SPF - where each email service provider has one SPF record that is shared by all it's customers - for DKIM each customer of an email provider will need their own DKIM record.

Here is a sample DKIM record:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt4hQmrsle/3cd0vXh2uiAm6FFfUOS11ZRDnOHPb8odjjYuwSXftRr/jS+Oqc8CCXEpwGxlZ8HBh1u0TAe+y17OnsBkGS6UM/Ahr7ZvycY8rX4/qD2FlUyCKS+NqHlUbRIQlafmzDOuVfdEs+Pu67GewAVjYPo06sx8eZjXYukc1ZiqASbnbfWH42lJ4GPnZv8

Here

Unlike SPF records, DKIM records cannot be combined, so you'll need one record per email provider, and insert them unchanged.

Because DKIM can be a bit more tricky to set up, some providers don't enable it by default, which is a shame. Always enable it, and if your provider doesn't offer DKIM you should definitely move to a different provider.

DMARC

After both SPF and DKIM have been configured, you can then use Domain-based Message Authentication Reporting and Conformance (DMARC) to tell a receiving email server, what to do if either DKIM or SPF checks fail for any email. As such it's very helpful, both to test your SPF and DKIM configuration, and to specifically tell email providers to reject any offending emails.

The nice thing, is that it can also be used to get some information about the deliverability of your emails, as described in Part 2 - Testing your email setup

A DMARC record is another DNS record, and could look like this:

v=DMARC1; p=quarantine; adkim=s; aspf=s; rua=mailto:analytics@example.com;

Let's break this down again

Takeaways

To protect your email brand:

Postscript

I have since posted a follow up: Read Part 2 - Testing your email setup for details on how to test your email setup.