It’s 2022, and even with all our technological advancements it’s still quite hard to properly configure sending emails from a domain. Whilst some services handle everything for you, many companies will have to manage some part of their email setup themselves. This typically means DNS records for SPF, DKIM and DMARC.

Whilst this only means three simple text entries with your domain registrar, it’s still quite easy to make a mistake. And doing so could affect whether people receive your emails, and how your cyber security is rated. This blog covers all three protocols, and provides tips and advice on how to set them up.

Introduction

The three elements of email security configuration are, in (arguable) order of descending importance:

1. SPF, which tells recipients what legitimate sources of email you have.
2. DKIM, which allows recipients to verify that some or all of the email hasn’t be modified in transit.
3. DMARC, which tells recipients what to do if there’s a possible issue with an email from your domain.

In a future blog we’ll show some stats for adoption of the three elements, but it’s fair to say most organisations have SPF implemented, many have DKIM, and some have DMARC.

Not having them implemented, or having them improperly implemented, will typically affect how reliably people receive emails from your domain, but it doesn’t affect you getting emails from anyone else outside your organisation.

Basic Email Protections

Sender Policy Framework (SPF)

SPF is a published DNS record that allows you to define what sources should be sending emails from your domain. Email recipients, when they get an email that purports to be from your domain, can compare the actual sender to what’s listed in your SPF record. A mismatch allows them to drop or flag the email as suspicious.

Your SPF record should list all the legitimate sources of email from your domain, which typically includes your email service, maybe a private mail server, and any other tools that automatically send emails, such as sales and account management services.

Here’s a simplified example of how it is used, when someone receives an email from your domain:

Why is SPF important?

Not implementing SPF for your domain, or implementing it incorrectly, could affect how reliably emails sent from your domain are received. So it could mean customers, suppliers, or any other recipient regularly do not receive emails sent by you.

SPF is arguably the most important thing to get right with email configuration. We’ve worked with cyber insurers who won’t take on customers that don’t have an SPF record, on the grounds that it makes them more susceptible for phishing. This is because your SPF record is also used to check emails you receive from your own domain.

SPF Record Format

SPF records are a single line of text, published as a DNS TXT record. They start with the fixed version string, v=spf1, with following fields separated by spaces. Some fields stand alone, others have a value or modifier.

A good explanation of the syntax can be found on this page; all we’ll cover here are the commonly used fields.

Common SPF Fields

Ignoring the version string that has to come first, there are some other common fields:

1. include:mydomain.com - the most common way to list an approved sender of emails from your domain is with the include: mechanism to specify a domain. This will add the SPF record of the specified domain to your domain. This is commonly used when 3rd party email services are used (e.g. Google Workspace or Microsoft 365)
2. ip4:1.2.3.4 or ip6:1080::8:800:0000:0000 - as you might guess, you can also specify IP addresses as legitimate email senders. For example, the fixed IP of a hosted mail server. Both of these can take ranges too, in CIDR notation.
3. a - accept email from any sources named in the DNS Address record for your domain.
4. mx - accept email from any sources named in the MX record for your domain.
5. The last field in a record should be the all mechanism, which tells the recipient what to do for any other source not explicitly named. It can be one of:
   1. +all - Pass all (i.e. accept emails from your domain, wherever they come from). NOT RECOMMENDED, EVER, AT ALL.
   2. ~all - Soft fail all (i.e. accept emails from your domain, wherever they come from, but mark them for the recipient). <- THIS IS THE BEST OPTION FOR EVERYONE.
   3. ?all - Neutral on all. POINTLESS. NOT RECOMMENDED.
   4. –all - Hard fail all (i.e. don’t accept emails from your domain unless it comes from a source named in the SPF record). THE MOST RESTRICTIVE, BUT CAN CAUSE DELIVERY FAILURES.

Example

We can look at our own SPF record with a simple dig command (non command line folks can use an online tool):

dig TXT +short hexiosec.com
...
"v=spf1 include:spf.protection.outlook.com include:6865538.spf02.hubspotemail.net -all"
...

It’s identifiable by the starting version string. Our record has three other fields:

1. v=spf1 - the version string.
2. include:spf.protection.outlook.com - an included sender domain, in this case Microsoft 365, which is our main email platform. The SPF record for spf.protection.outlook.com will be included in our domain’s SPF record.
3. include:6865538.spf02.hubspotemail.net - another included sender domain, in this case HubSpot CRM, which can send marketing emails for us.
4. -all - the final instruction to recipients to ignore any source other than those listed in the record.

That’s it, and most small or medium companies will likely have a similarly simple record.

Domain Keys Identified Mail (DKIM)

DKIM helps prevent anyone spoofing emails from your domain by digitally signing all your emails. This means that the recipient of an email from your domain can check the email header, and sometimes the contents and attachments, to verify that the received email has not been modified in transit.

This works with fairly standard cryptography, based on a private key held by the mail server, and a corresponding public key published as a DNS record. When the email is sent, the mail server creates some hashes (fingerprints) of the email, signs them with the private key and attaches them to the email. The recipient can look up the public key and use it to verify the signature and hashes (and therefore the email) are unchanged. The technical details are covered in more detail here.

Here’s a basic example:

Why is DKIM important?

The absence of a DKIM signature shouldn’t result in an incoming email being rejected for that reason alone, but its inclusion offers the recipient a means to verify the email has not be modified in transit.

This helps with the reliable delivery of legitimate email, and the detection of forged emails, spam and phishing. As detailed here, DKIM provides additional protection on top of SPF, as:

The addition of DKIM in this scenario reduces false positive spam reporting

Use DKIM to validate outbound email sent from your custom domain, Microsoft

Example

DKIM records have a selector and a value. The selector forms part of the hostname, is fixed for each email provider, and can be quite complicated. For example, at Hexiosec we’re on Microsoft 365, and our primary DKIM key is held at selector1-redmaple-tech._domainkey.redmapletech.onmicrosoft.com. This is a concatenation of the selector name (selector1), our domain name (redmaple-tech), the common identifier (_domainkey), and the fully-qualified Microsoft 365 name (redmapletech.onmicrosoft.com).

Different email providers have their own format, and thankfully the sensible ones will generate the record for you.

To fetch the value, given that we know the selector, we can again use dig:

dig +short selector1-redmaple-tech._domainkey.redmapletech.onmicrosoft.com txt
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC80cgtHksbUoPPyP4BLdzA6eo/V/DNkNPW9a4nhPJZEwg7LCeRaZ/v3DIPJoVtXtd6CYS8ABfmLydCyGizHMP6QvS3IYXx5qAVq6R+ugGpQ0lVM90ocJDdnfn7c/ebNdNK+qbWAEhHqRG/iLNi/fbg8NaNGcmRbh7XxxIrBQVziwIDAQAB;"

It’s normally a DNS TXT or CNAME record. Like SPF it starts with a version string and has space-separated fields. As it’s a cryptographic key, unsurprisingly the public key (the p= value) forms the bulk of the record. More details on the format and signing process can be found on the DKIM Wikipedia page.

Domain-based Message Authentication, Reporting and Conformance (DMARC)

Finally, the snappily named DMARC ties together both SPF and DKIM to provide a mechanism to instruct anyone who receives email from your domain what to do in the case of, for example, invalid SPF and DKIM. It can help with the application of SPF and DKIM, and provides a reporting path for failed emails.

Why is DMARC important?

As well as providing additional controls around SPF and DKIM, the primary advantage of DMARC is that it moves decisions that would be made by the receiving email server or client into your control. For example, if you’re confident that SPF and DKIM are setup correctly, adding a DMARC policy of reject and a reporting policy means you know spoofed emails purporting to be from your domain will be rejected by any recipient, and reported to you.

It can also be of use when applying SPF and DKIM, as it allows you to scale the application of those protocols up to 100%, and receive reports on progress.

DMARC Record Format

DMARC is also a DNS TXT record, published with the subdomain prefix _dmarc, which starts with a fixed version string. The fields are space and semi-colon separated. Full details can be found here, below we’ll cover the common fields.

Common DMARC Fields

1. The fixed version string, v=DMARC1;, should be the first field.
2. The first proper field, and the most important, should be the policy or p mechanism. This tells recipients what to do in the event of an email failing the DMARC checks. It applies to the principal domain as well as any subdomains, unless they are explicitly set with sp. It can be one of:
   1. none - Do nothing. ONLY USEFUL WHEN SETTING UP DMARC, OTHERWISE SHOULD NOT BE USED.
   2. quarantine - Tells the recipient to quarantine the email. THIS IS THE BEST OPTION FOR MOST PEOPLE.
   3. reject - Tells the recipient to reject the email immediately.
3. fo - Allows you to specify what failure conditions are reported back. The recommended setting is fo=1, which reports if either SPF or DKIM fail.
4. pct - the percentage of messages to which DMARC is applied. ONLY USEFUL WHEN SETTING UP DMARC, OTHERWISE SHOULD NOT BE USED.
5. ruf/rua - the URIs to which recipient servers can send forensic and aggregate reports, respectively.
6. sp - The explicit policy for subdomains of the organisation.
7. adkim - Alignment mode for DKIM, either strict (adkim=s) or relaxed (adkim=r). Strict Mode requires exact matching between the SPF domain and an email’s header-From domain, relaxed mode will also match any subdomain of the main domain.
8. aspf - Alignment mode for SPF, as above.

Example

For the last time, let’s use dig to grab our own DMARC record:

dig +short TXT _dmarc.redmaple.tech
"v=DMARC1; p=quarantine; rua=mailto:[email protected]; aspf=s; adkim=r"

Aside from the version string, we have four values set:

1. v=DMARC1; - DMARC version.
2. p=quarantine; - The policy setting. In this case, email failing the DMARC authentication and alignment checks should be treated as suspicious by mail receivers. This can mean receivers place the email in the spam/junk folder, flag as it suspicious or scrutinize this mail with extra intensity.
3. rua=mailto:[email protected] - The list of URIs to which receivers should send XML feedback. Like many people, we use the free Report URI service, which keeps records for 30 days.
4. aspf=s - Strict alignment mode for SPF.
5. adkim=r - Relaxed alignment mode for DKIM.

Setting It Up Yourself

If you’re starting from scratch and want to set up SPF, DKIM and DMARC, you’ll need:

1. To figure out what your SPF and DMARC records should be:
   1. Your SPF records needs to cover every legitimate email sender you have, so include your main provider (Microsoft 365/Google Workspace/some email server), other CRM and marketing tools (MailChimp, HubSpot, SalesForce), plus any email security tools (Mimecast). Many tools have instruction pages that tell you what to do.
   2. For DMARC, you’ll want a reporting location. Report URI is a free tool for aggregating DMARC reports. The policy should not be none, and you’ll need to think about subdomains for the aspf and adkim values. If you’re testing things out make use of pct, otherwise don’t use it.
2. Administrator access to the email provider, which will need to check and accept the records. Most services will generate the DKIM record for you, as it needs to correspond to a key they hold. You’ll then need to publish the record.
3. Access to the domain registrar account, with permission to change the CNAME and TXT records.

Microsoft 365

SPF

For SPF, to include just Microsoft 365 as the only legitimate sender, and to instruct recipients to reject email from anywhere else, you’ll need to post the following SPF record:

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

This record has three fields:

1. The standard SPF version, v=spf1.
2. Microsoft 365 (include:spf.protection.outlook.com) as the only included sender.
3. The instruction to reject email from any other source other than Microsoft 365 (-all).

DKIM

For DKIM, you need to go to this admin panel, and for all sending domains make sure DKIM is turned on:

When you first try to turn it on it will generate records for you to post, which include a CNAME redirect. This needs to posted online with your domain registrar. After the records are live, you should be able to back to the panel and enable DKIM.

For more information, see the Microsoft instructions for SPF and DKIM.

Google Workspace

SPF

For SPF, to include just Google Workspace as the only legitimate sender, and to instruct recipients to reject email from anywhere else, you’ll need to post the following SPF record:

v=spf1 include:_spf.google.com -all

DKIM

For DKIM, go to this admin panel, which can generate a DKIM record for you to post.

For more information, see the Google instructions for DKIM and SPF.

Testing SPF, DKIM and DMARC

There are loads of testing websites out there that’ll take your domain name and test your configuration. One of the more useful is this one, which has you send an example email so it can properly test SPF, DKIM and DMARC. Get it right and you should have passes across the board:

We have our own testing tool that we use for consultancy work, which is now integrated into FractalScan Surface, so if you use FractalScan you’ll get the same analysis.

In the next blog we’ll cover stats on usage, and some common mistakes. In the meantime, happy emailing!

Updates

We updated this blog on 09/11/2022, after some great feedback on LinkedIn:

1. As per the suggestion from Mark Alley, we:
   1. Now recommend SPF soft fail as the best option.
   2. Updated the definition on DKIM.
2. Following a comment from Freddie Leeman, we added a quick explanation of relaxed mode for DMARC.

Related Posts

Protect Your Domains From Email Spoofing & Phishing Attacks

24 August 2022

Are Big Companies Getting Email Security Right?

21 November 2022

Microsoft 365 Email Protections Settings For Administrators

23 August 2023

About Scott Lester

Scott is a technical Cyber Security professional with over fifteen years' experience across a broad range of roles within the public and private sectors. With a deep understanding of cyber security, he has in his career focussed on applied cryptography, network technologies, digital forensics and security research. At Hexiosec he leads the delivery of all of our cyber security services.