HowTo: DMARC and Microsoft 365 part 1
This article is split in multiple parts.
– The first part will explain DMARC and the relationship with DKIM and SPF.
– The second part will show you how to configure DMARC for your Microsoft 365 Exchange Online (Office 365).
– The third part will show you some of the online tools you should consider for parsing the DMARC reports and finding the hosts that are sending mails from your domain.
Understanding DMARC, DKIM and SPF
First of all; Why DMARC?
Put simply it is a pretty efficient way to prevent or at least minimize phishing and spoofing globally. It is a way to validate yourself as an owner of a domain when you are sending out emails, making your customers feel a lot more safe, and reducing the risk of your employees being victims of phishing.
In some countries like Denmark it has even been decided by law that all government owned domains should be DMARC complaint per July 1st 2020.
To understand DMARC you need to also understand a bit about DNS, DKIM and SPF. I won’t be going in to details about DNS, but let’s look at the other two in a somewhat simplified explanation.
This is how the path of your email could look when DMARC is correctly configured.
So let’s take a deeper look at the details;
DKIM is ‘DomainKeys Identified Mail’.
In essence it is a way to prove that you are the rightful owner of a domain by assigning a digital signature to your domain.
Like all other digital signatures it consists of a private and a public key. The private key of the signature is known only by you (and your mail server). The public key of the signature is published as a TXT record in your domain DNS.
When you send an email the header will include a DKIM-signature (signed automatically with your private key by the mail server) that can be confirmed by the receiving SMTP server using your public key from your DNS TXT record.
On my domain the DNS record looks like this
SPF is ‘Sender Policy Framework’.
It’s like a whitelist of your mail server(s). You define the IP addresses or hostnames of the hosts that are allowed to send email on behalf of your domain. Again, this is done with the TXT record in your DNS. Why all the DNS based settings? Well hopefully you or your colleagues are the only ones in the world with access to modify your DNS entries, making it a near perfect validation of ownership.
My SPF TXT record is the default Exchange Online SPF record provided by Microsoft 365 and looks like this:
The include=spf.protection.outlook.com tag tells the world to search this host for a matching valid SMTP server. This is currently the default SPF record when using Exchange Online since it allows Microsoft to define their large cluster of valid SMTP servers for outbound mail.
If you have an on-premise server that needs to send mails as well, you can add its IP to the string with the ip4: tag or the hostname (A record) with the a: tag. See this link for an SPF syntax table: https://dmarcian.com/spf-syntax-table/
DMARC is ‘Domain-based Message Authentication, Reporting and Conformance’.
Like with SPF there is a ton of different tags that you can use to tweak the behavior of mail delivery from your domain.
However, let’s keep it simple to begin with.
You can say that DMARC is bringing it all together – without DKIM and SPF you have no DMARC. Again this is defined with a TXT record in your DNS and it could look like this:
_dmarc.norvig.dk v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1;Note that the DMARC DNS record is always called _dmarc.domain.com.
The first interesting tag here is p=none.
This defines your DMARC policy, i.e. what should happen to mails that fail DMARC validation. The two other options are p=quarantine and p=reject.
Setting your policy to ‘none‘ is generally considered best practice to begin with while you gather reports about the array of hosts that send emails on your behalf. Reports are usually only sent to you once a day and you should spend at least 14 days gathering reports and parsing through the results before you upgrade your policy to something more strict.
As you may have figured, ‘quarantine‘ should throw failed mails in to quarantine or spam folders, and ‘reject‘ should throw failed mails into the void. In reality a lot of mail servers (Exchange Online included) will still just quarantine mails even if the policy is reject to avoid accidentally deleting false positives. But keep in mind that a lot of DMARC validation sites will not mark you as completely compliant unless your policy is ‘reject‘, so that should be your ultimate goal in the end.
The rua=mailto: tag will tell the world where to send their aggregate reports regarding your domain, and the ruf=mailto: tag is for forensic reports.
Aggregate reports are usually .zip files containing a lot of data about the hosts that are sending emails using your domain as email address, including whether the SPF and DKIM checks were OK or failed. These can be used to pinpoint hosts that you missed in your SPF record that needs to be whitelisted.
The forensic reports are a bit more detailed and may contain email address of the sender, the recipient and the subject of the mail. These are more helpful in your ‘hunt’ for the source of the system that is sending out emails since an aggregate report with a bunch of hostnames may require a bit of detective work to track down.
However, a lot of system wont send you forensic reports anymore since they can reveal sensitive data from mail subjects which is a GDPR concern. The last tag, fo=1, is a forensics tag that tells systems to send you reports if either DKIM or SPF fails.
This concludes the first part of this guide. I hope DMARC, DKIM and SPF makes a bit more sense and that you are ready for part 2 where we are configuring the Microsoft 365 tenant.
Pingback: Securing domain at Cloudflare – Acoon Net