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 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).
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?
v=spf1means that this is an SPF record. Every SPF record must start with this string.
ip4=192.168.1.1means that the server with IP address
192.168.1.1is allowed to send email on your behalf.
include:spf.protection.outlook.commeans that this 3rd party email provider (in this case Microsoft 365) is also allowed to send email on your behalf.
-allmeans that no-one else is authorised to send email on your behalf. (Other options are
~allmeaning essentially that those not listed are probably not authorised, or
?allwhich basically means that anyone else may or may not also be authorised - I'm not sure why you'd use the latter.)
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.
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
v=DKIM1means that this is a DKIM record. Every DKIM record must start with this string
k=rsameans that this DKIM record uses an RSA key.
p=...is the public key used to verify your DKIM signature.
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.
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:firstname.lastname@example.org;
Let's break this down again
v=DMARC1means that it's a DMARC record
p=quarantinemeans that any email that fails SPF or DKIM checks, should be 'quarantined' (usually sent to spam.) Other options are
p=reject, which means that any offensive email should be rejected completely, and
p=none, which is useful for testing.
dkim=smeans that DKIM checks are "strict." This can also be set to "relaxed" by changing the
aspf=smeans that SPF checks are "strict." This can also be set to "relaxed" by changing the
rua=mailto:email@example.com that the email server should send a notification about emails that fail DKIM or SPF checks to the given address. Not all providers honour this, but it can be useful to monitor email, and particularly together with
p=none, can be used when first configuring SPF, DKIM, and DMARC to just monitor your setup, and ensure no actually valid email is accidentally failing checks.
To protect your email brand:
- Make sure you set the correct SPF records for all your domains. Always end your SPF records with
-allto signify that only servers / providers you have specifically listed are authorised to send emails on your behalf.
- Ensure you configure and test DKIM correctly. If your current mail provider doesn't support DKIM consider switching email providers.
- Having configured both SPF and DKIM, ensure you also configure DMARC for your domain. Make sure you set
p=reject- otherwise email that fails SPF or DKIM may just be 'waved through' by receiving email providers
I have since posted a follow up: Read Part 2 - Testing your email setup for details on how to test your email setup.