Implementing SPF, DKIM and DMARC in M365

I recently decided to take a look at how SPF, DKIM and DMARC actually work under the hood, whilst I've always had a rough, wishy washy idea of what the purpose was I never fully understood the implementation or what the records meant.

So I learnt, and what better way to implement the theory than to implement these records in my developer instance?

This post will detail the implementation process in a M365/Exchange Online only environment and won't touch so much on the nitty gritty of what or how.

SPF

SPF, or Send Policy Framework is a technology that will look to verify that the email has come from a source that is authorised to act as a mail transfer agent for the author of the email.

When it comes to SPF records, they utilise normal TXT records within your DNS records, implementing the correct portion of an SPF record for an Exchange Online environment is relatively simple, if you utilise the normal M365 environment then it will, at it's basic level look something like:

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

Breaking this down, we have:

v=spf1 - This is just the version of spf to use include: spf.protection.outlook.com - This portion is saying use the spf records at the domain within the include part. -all - This states to reject anything else.

There are other ways that you may need to build up your SPF record, for example if you have on premise mail servers you may have these within an ip4: tag or something similar. Also, if you utilise other Microsoft environments such as Gov or Germany then you can view the table on the following link to work out what your SPF record should look like.

DKIM

DKIM is, in it's simplest form a way of signing your emails, once configured you authorise your domain to sign it's own name to the email. Then, when your email is received, the receiving server will utilise the DKIM signature and a public key in a DNS record to verify that the email actually came from your domain.

A quick note, when utilising Microsoft 365 the initial domain (typically onmicrosoft.com) will utilise DKIM by default. Also, if you do not configure DKIM for a custom domain, Microsoft will create a private and public key automatically and enable DKIM signing on your behalf.. So technically you could skip DKIM, although, if you want to enable DMARC, you should configure it.

Configuring DKIM

To get things started you will need to ensure that you have Exchange Online Powershell installed. For Windows, this is a simple process of running Install-Module -Name ExchangeOnlineManagement to install it for all users on your system, if you need to you can add -Scope CurrentUser to install for the current user. For other OS's see the following article.

Generate the Selectors

With the module installed and connected via Connect-ExchangeOnline cmdlet we can:

1. Run the following commands:

New-DkimSigningConfig -DomainName <domain> -KeySize 2048 -Enabled $false
Get-DkimSigningConfig -Identity <domain> | FL Selector1CNAME, Selector2CNAME

Create your CNAME records

Head over to your domain registrar that manages the domain name specified in the commands above and create two new CNAME records with the host names of selector1._domainkey and selector2._domainkey, populating the value for each with the output from the above command.

The exact steps will vary for each domain registrar so I won't cover these here but it should be reasonable straight forward.

With each CNAME configured you can run: Set-DkimSigningConfig -Identity <domain> -Enabled $true

This may take a few minutes or days depending on your DNS registrar. If you get an error but you are confident the records have been published, wait a few minutes and run the command again.

DMARC

DMARC is a method to validate both SPF and DKIM, checking the alignment of either when an email is received. If either pass alignment (i.e. match) then the DMARC check will pass. DMARC can also help you generate reports to investigate mail that may be incorrectly getting blocked by a potential policy and to view Failure reports.

Creating a target mailbox

First of, I like to create a target mailbox within my tenant to be the recipient of aggregate reports so that I can analyse any potential legitmate traffic which might get blocked. Typically something such as aggreports@domain.co.uk or dmarc.rua@domain.co.uk etc.

I won't cover the steps to do this here, I'd suggest using a mailbox as opposed to a Distribution list as this will mean the email is kept in the shared mailbox.

Setting your DMARC policy

DMARC is, at it's simplest level, just another TXT record for your domain. You create a special TXT record with the hostname of _dmarc.domain where domain is your domain name, by doing so this will cover the root domain and all subdomains.

In this example I will only show a simple DMARC record that doesn't specify a DMARC policy, but by simply creating the TXT record you will be able to then see any failures and will allow you to monitor for email that may get incorrectly blocked, after a period of time you can then increase the policy into Quarantine mode to send the email to a local spam or junk folder, finally you should up this to reject once you are confident that no legitmate mail is getting blocked, setting your policy to reject will not deliver any email that fails DMARC.

The value for your TXT record for monitoring mode or 'none' should look similar to:

v=DMARC1; p=none; rua=mailto:aggreports@domain.co.uk

Just a word of warning when it comes to the reporting side of things, there is also the option to enable 'failure reports' or forensic reports by utilising the 'ruf' tag. Whilst these reports sound useful, they have the potential to contain troves of personal data, care should be taken when dealing with failure reports to ensure that personal data is not accidently sent to your mail systems.

As always thanks for reading!