SEMblog

In this episode, Danial Welling, Luke Betteridge and I talk about the holy trinity for email delivery - DMARC, DKIM and SPF. 

DKIM, DMARC and SPF have been described as the holy trinity for email delivery. Configured correctly they can improve the deliverability of your email and provide some useful reporting. Even if you are using a hosted email platform, you still need to be aware of them and ideally configure them for all services using your domain for email. 

These are mainly DNS changes, with only DKIM requiring support from the email server to implement. 

With the news that Microsoft Office365 now sends out DMARC reports, the value of setting up that system in particular has increased.  

These three standards are not something that will impact the amount of spam or other junk email that you receive. This has been a common reason why admins don’t take the time to implement them, because they are only interested in something which deals with the spam problem for their own users. 

What they can do is improve the reliability of your email being delivered, and what remote sites do with emails that come from other sources, therefore enhancing the reputation of your email domain. On top of that, they can provide reporting on how those measures are doing and what recipient services did with the emails. 

Furthermore, they can also help identity other services which are using your domain name, which could be harming your domain’s reputation, or simply discover that a service has been setup by end users without the involvement of their IT people. 

All three are domain wide settings – it is not possible to exclude specific users. 

However, you can use sub domains, and configure different records for each sub domain. That would allow you to have a separate sub domain for bulk or transactional emails, with its own set of records, allowing for more accurate reporting and reputational management. 

SPF is the oldest of the three protocols, first discussed in the early 2000s.

As with the other two, it uses DNS extensively, but unlike DKIM, it does not require support of the sending server to work. 

In an SPF record, you list what servers are allowed to send email for your domain. This could include your primary email server (Exchange, Office365 etc), then any marketing or sales tools. It could also include things like a payroll system, monitoring platform etc. 

The drawback with this method is that because it simply lists IP addresses or hostnames, if a system gets compromised on the same network and starts sending emails from the same IP address, then it can pass the SPF test. 

There are limits on the size of the SPF record, and there are various methods that can be used to reduce the size of the record. You will find online tools which can help flatten the SPF record to within the allowed sizes. 

You can also only have one SPF record, so if a third party asks you to setup a SPF record, then you will need to incorporate their information in to your existing record (if you have one). 

Be careful though – if you don’t have an SPF record then do not just implement the one from the third party. That can mean that you are telling the rest of the internet to only accept email from the third party and not from your primary source. For a first SPF record, follow the guidance from your primary email provider (Office365 or Google for example), or configure it with your servers if you are still hosting your own. You can find tools online which can help you create the first record. Then add in other providers to that record. 

DKIM is not quite as old as SPF, but emerged in to the public view around the same time, and for a while was seen as a competitor to SPF as they both do the same thing – which is to tell the wider internet which servers are allowed to send email for that domain. However, as they do this in a different way, they are ideally suited to working together. 

DKIM signs the message, with the public key held in DNS. It therefore proves the server sending the email is allowed to do so – even if the DNS or IP address changes. 

DKIM uses a combination of DNS records and modifying the sent email, therefore requires support from the sending server. Exchange (on premises) doesn’t natively support DKIM, but Exchange Online from Office365 does, as do most third-party spam filtering services. 

If you have multiple services that support DKIM in your outbound email flow, then it should be applied to the last server you control – i.e. the last hop before it goes out to the internet. 

Each server or service which signs email using DKIM has its own set of DNS records – referred to as an identifier. 

DMARC is the newest of the three, from around 2012, and emerged to cover gaps in SPF and DKIM – specifically telling receivers what to do with the email if it fails one of those tests, and also to provide reporting on what those receivers did. 

As with the other two, it requires DNS records in each domain. As the sender, there is nothing to do on the server. As the recipient, you need to use a service that supports DMARC. 

A DMARC record contains two parts – action and report. 

The action element allows the sender to tell the recipient what to do with emails that fail the SPF and DKIM test. It has three stages – report (do nothing), quarantine (put in to the spam folder) and reject. On top of that, you can also set a percentage value – so the receiving server can be told to only quarantine or reject some of the failing email, allowing the email administrator to catch a potential configuration problem. 

The end goal is to get to 100% reject, but that can take some time while the various services are found and setup correctly - either by moving to a subdomain, adding to the SPF record, and ideally having a DKIM record setup (if supported). 

The reporting element is an email address, which is where the reports are sent to, and depending on the volume of email, you can receive multiple reports per day from the same recipient domain. The reports themselves are in XML format – they are not designed to be read by a human. The format is standard and they are designed to be sent to a service provider, who processes those reports and then presents them to their customer in a more structured format allowing for more sophisticated reports to be created. This allows patterns and trends to be noticed, and the configuration of the settings adjusted. As confidence grows, based on the reports, you can consider moving to quarantine and then reject, monitoring the reports to ensure that nothing is being rejected which shouldn’t be, due to incorrect or missing DNS records. 

Not all providers support all functionality of DMARC. Google does for example, not only respecting the first part about what to do with the email if it fails a SPF or DKIM test, but also returning the reports back to the sending domain. 

Microsoft Office365 have respected the DMARC policy settings, but were not sending out the reports, but that changed in March of 2023, with reports now being sent for most of their tenants where the MX records point directly to Microsoft, although at the time of writing it is still in preview. If you are using a third-party filtering service in front of Office365, then that service needs to send DMARC reports instead. 

Their consumer targeted service (Hotmail/Outlook.com) has been sending DMARC reports for some time. 

Full details on DMARC on the project web site at https://dmarc.org/ 

If you have domains that do not send email at all, then configure an SPF and DMARC record to indicate that. Spammers will often use dormant domains as their spoofed from address. Therefore, by configuring SPF to say that there are no servers authorised and setting DMARC to 100% reject, you help out the rest of the internet community by not allowing your domain to be abused. You can omit the reporting email addresses from the record if you not want to receive reports for those domains. 

All of this can seem daunting, particularly if you are an MSP. It can also take months to get to the point where you can confidently set the DMARC record to reject, so it is difficult to know where to begin. 

The strategy I use is very simple. 

On each client I will setup an email address for DMARC END User reports – these are the reports generated by the various DMARC reporting services. This could be something like dmarc-reports@example.com. The email address is on a group, and as the service provider, I will have an email address on my system that is a member of that group. You can also include any internal recipients at the client in that list. 

Next, I will create another email address – dmarc@example.com which is used to receive the actual XML files. Again, a group, and could also include something like a public folder so that you can see who is actually sending reports. 

I then start with the free Postmark weekly DMARC report - https://dmarc.postmarkapp.com/ 

That will give you the first DNS record for DMARC and ensure that you have configured it correctly. Set it up for each domain you control, using the dmarc-reports@example.com email address that you setup earlier. 

Once it has been configured you need to test the DMARC setup. There are lots of test sites out there, but I find the most user friendly one is https://www.learndmarc.com/ .

If you decide to use additional services, simply take the email address that postmark provided to you and add it to the dmarc@example.com group as a member. Then change the email address in the DNS record to dmarc@example.com. As you sign up for other services, simply add the email address they provide to you to the group – that allows multiple services to get the same emails. 

You can add multiple email addresses to the DNS record itself, but eventually you will hit a limit on the record size, and the group method is a good way to get round that. 

For DKIM, if you are not using a third-party email filtering services for outbound email on Office365, then enable it in the Office365 console. Microsoft have instructions on how to do that here: https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/email-authentication-dkim-configure?view=o365-worldwide 

It takes a few minutes to configure DMARC per domain. 

For DKIM, if you are using a third-party service for outbound email, then look in their service guides on how to configure DKIM. 

Similarly, if you know that the client is using other email services, such as SendGrid or Salesforce, then setup DKIM in their service as well. Remember each service has its own DKIM records, with a unique identifier. 

For SPF, you may already have an SPF record as they are in the standard DNS records suggested for Office365, and most third-party spam providers will also ask you to configure one. If you don’t have one, then wait. 

With that done, leave it a week or more, for the reports to build up. Review the reports to see what services are sending email as your domain. You can then investigate whether they are in the SPF record, whether they support DKIM etc. If you don’t have an SPF record then you can look up what the service provider suggests and use the various tools to create the SPF record. 

When you start looking at DMARC reporting providers you will usually see that they charge per domain and also per email volume. The volume will be the number of emails that generate DMARC reports, not the total volume of email that you send. Use the trial periods to see what kind of volume emails are generating reports and then shop accordingly. 

I see a lot of errors with DNS records, including duplication and multiple records not being supported, usually because service providers will provide a record presuming that it is only their service you are using, when you actually need to combine records. Therefore, to be clear on the DNS records:

It is important that the reports are reviewed regularly (which is why I like to start with the Postmark report as I get it once a week), to ensure that no new services have been introduced which need to be included in the various DNS records. As the confidence in what services are sending email grows, you can move from the default report setting, to a quarantine setting.

The holy trinity of SPF, DKIM and DMARC can be a very useful tool for IT service providers, whether internal or an MSP. It can not only help with email delivery, but it also identifies other email services that are being used and ensure that they are setup correctly in compliance with the best practises for email configuration. It can also show if the domain is being abused so that the client is aware. As the initial setup takes a few minutes and costs nothing, it can be something that all IT service providers can setup and configure for their clients. 

DMARC Service Providers and useful links

The most comprehensive and independent list of DMARC service providers and other resources is available at https://dmarcvendors.com/