Office 365 – SPF, DKIM and DMARC in Exchange Online (Part 2 of 2)

The fight against email spam is an on-going battle for mail administrators and while cluttering up a mailbox with junk mail is undesirable, phishing campaigns can be a serious security issue. Those with malicious intent are highly motivated and their practices have evolved over the years; fortunately, the technologies available to protect against such attempts have equally improved.
There are several technologies that can help your organization validate that an email has been sent from an authorized source. Office 365 expanded its support for some of these technologies earlier this year however it seems like these features get very little talk.
You’ve likely heard of SPF but what about DKIM and DMARC? Should you be implementing these?
Part 1 of this series provided a summary of these technologies and discussed how each builds on one another.
In Part 2 below, I’ll get into the actual configuration in Exchange Online and some of the things you’ll want to watch for.

SPF

The SPF record is created as a DNS “TXT” record within the root of your DNS zone. If you’re using Exchange Online, Microsoft provides a starting point of the value for your SPF but it will likely need to be customized.
The default value listed in your tenant will be:

This value will work if you’re only sending messages out of Exchange Online and have no on-premises infrastructure relaying messages. If you have other systems sending mail, you’ll want to make sure that you include these sources in your SPF record.
Common issues I see with SPF records are organizations that try to add more than one TXT record, add too many (>10) DNS queries within their SPF record or just have an improper syntax. There are a number of sites that can validate your SPF record including MxToolbox.

DKIM

Configuring DKIM signing in Exchange Online is relatively simple. You essentially need to create two DNS records and run three PowerShell commands for each of your SMTP domains.
First we need to determine the appropriate values for the DNS records. In the tenant, run the following command for each of your SMTP domains:

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

Then run the following to get the values:

Now it’s time to create the two DNS records. You’ll create the following two CNAMEs using the output from the above command:

Once the DNS records have propagated, return to PowerShell and run:

You’ll soon start to see that your messages now show as DKIM signed in the message headers.

DMARC

Once you have SPF and DKIM properly configured, you may choose to start using DMARC. Configuration of DMARC involves the creation of a DNS TXT record to advise recipients of what to do with DMARC failures and where to send the DMARC reports.
You’ll likely want to start with an action of “none” meaning that you just want to monitor emails not but take any action. Even if you can’t get to the point where you configure an action of “quarantine” or “reject”, you can still use DMARC to help mitigate phishing attempts.
After determining the action type, you will probably want to use a third-party service to help analyze the DMARC reports. Your published DMARC record will tell recipients that support DMARC to email reports to the address specified in the DNS record. These reports will arrive as a compressed attachment containing an XML file. There are a number of services that can assist with analyzing DMARC reports, some that are free, some that are paid and many that have 30-day trials. For my low-volume testing, I used “dmarcian” but there are a number of others listed at “dmarc.org“. These services will usually provide you two email addresses to publish: one for the aggregate reports and one for failure reports.
Now it’s time to publish your DMARC record. This record is a TXT record but instead of being at the root like your SPF, the record will have a host name of “_dmarc”. Some DNS providers do not support hostnames that begin with an underscore in which case you may need to switch DNS providers if you want to configure DMARC.
A typical DMARC record might look this this:

Again, you should use one of the validation sites like “MxToolbox” to check your published DMARC record.
You will now start seeing reporting data appear in your DMARC analyzer service from recipient organizations that support DMARC. The data presented will vary depending your service but you should have the ability to see which emails are passing DMARC and which emails are failing.
Here is a sample report out of “dmarcian”:

In the above report I could see that some emails (in red) that had my domain as a source have failed DMARC and depending on the action published in my DMARC record, I can help advise the recipient on what to do with those messages. You can even drill down into those failures, why they failed and what IP they were sourced from.
Because we’re now testing for “alignment” of the “from” and “mail from” fields, you may find that “legitimate” emails sent by third-parties on your behalf are now failing DMARC. Configuring DMARC will help expose messages not being sent using best practices.

Using DMARC To Your Benefit

While it’s great that using DMARC has given recipients more information on whether you actually sent the email that shows your domain as a source, it would be nice to have it help us too. Even if our action type is set to “none”, we can configure a Transport Rule for emails that have our domain as a source and fail DMARC. This is how we can help prevent phishing attempts sent to our employees using our own SMTP domains. Terry Zink at Microsoft has this configuration and a few other notes regarding DMARC documented in the blog post “Using DMARC in Office 365“.
Keep in mind that this will be dependent upon your MX records pointing to EOP as opposed to any on-premises infrastructure. You will want to test out this configuration and possibly use “incident reports” to monitor what items the Transport Rule catches before setting it to drop messages; you’ll find that some items like NDRs and out of office replies may get caught.

Summary

Office 365 supports functionality beyond SPF to help others validate the messages sent using your domain. Utilizing features like DKIM and DMARC in addition to SPF can improve your email reputation and help assist with internal phishing attempts.
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.