How to set up SPF, DKIM, and DMARC records for Microsoft Office 365

In this particular post, i would like to talk about 3 very important DNS records for any mail server and in this individual case Office 365. SPF, DKIM, and DMARC are ways to authenticate your mail server and to prove to the world, and other receiving mail servers that senders are truly authorized to send email and when properly set up, all three prove that the sender is legitimate, that their identity has not been compromised and that they’re not sending email on behalf of someone else.

SPF – Sender Policy Framework

SPF is a DNS TXT record that specifies which IP addresses and/or servers are allowed to send email on behalf of a domain. When you set up an SPF record, in a simple way, basically you inform the recipient mail services that if the originator of this mail is from this IP range or servers then they are coming from a legitimate server! Very simple string that the domain administrator can easily add to that domain’s DNS record as a TXT entry. This record can be retrieved while setting up an Office 365 custom domain.

If Office 365 is your only sender your SPF record will look like the below example:

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

If you want the specific IP address to be able to send the mail on behalf of the domain you should include IP in the record like:

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

How to check SPF Record: MXToolBox SPF Checker

DKIM – Domain Key Identified Mail

DKIM also known as “email signing” is a mechanism to sign the mail and Just like an SPF record, DKIM is a TXT record that’s added to a domain’s DNS. DKIM intends to prove that the contents of an email message haven’t been tampered with, that the headers of the message have not changed – adding in a new “from” address- and that the sender of the email owns the domain that has the DKIM record attached to it. Unlike SPF, however, DKIM uses an encryption algorithm to create a pair of electronic keys -a public and a private key- that handles this “trust”.

To enable the DKIM record for Office 365, first, you need to create 2 selector CNAME records on your public DNS as follows:

Host name:			selector1._domainkey.<domain>
Points to address or value:	selector1-<domainGUID>._domainkey.<initialDomain> 
TTL:				3600

Host name:			selector2._domainkey.<domain>
Points to address or value:	selector2-<domainGUID>._domainkey.<initialDomain> 
TTL:				3600

In my case it would be like this:

Host name:			selector1._domainkey.mkvlab.com
Points to address or value:	selector1-mkvlab-com._domainkey.mkvlab.onmicrosoft.com 
TTL:				3600

Host name:			selector2._domainkey.mkvlab.com
Points to address or value:	selector2-mkvlab-com._domainkey.mkvlab.onmicrosoft.com 
TTL:				3600

You can also get these values from the Office 365 admin portal.

At this stage, you need to enable email signing in the Office 365 admin portal:

Sign in to Microsoft 365 Admin Center and Navigate to Exchange Admin Center> protection > dkim and after selecting the domain on the right panel you need to enable “Sign messages for this domain with DKIM signatures”

If you have correctly created the CNAME records, you should be able to enable the message signing otherwise go and check your records. If the message signing option in Office 365 is graded out or If you are configuring DKIM for the first time and see the error ‘No DKIM keys saved for this domain you need to connect to Exchange Online PowerShell and run the following command:

Generate the signing key:

New-DkimSigningConfig -DomainName <domain> -Enabled $false

and the option will be there in the Office 365 Portal now after creating records you can enable the signing using:

Set-DkimSigningConfig -Identity <domain> -Enabled $true

Which in our case will be:

Set-DkimSigningConfig -Identity mkvlab.com -Enabled $true

And to check the status of DKIM:

Get-DkimSigningConfig -Identity <yourdomain.com> | Format-List

How to check DKIM Record: MXToolBox DKIM Checker

DMARC – Domain-based Message Authentication, Reporting, and Conformance

DMARC is an email authentication, policy, and reporting protocol that’s built around both SPF and DKIM. It has three basic purposes:

1. It verifies that a sender’s email messages are protected by both SPF and DKIM,
2. it tells the receiving mail server what to do if neither of those authentication methods passes, and
3. it provides a way for the receiving server to report back to the sender about messages that pass and/or fail the DMARC evaluation.

DMARC is also TXT Record which has the following format:

Host name:			_dmarc.<domain> 
Value:				"v=DMARC1; p=policy; rua=mailto:<mail adress>;
TTL:				3600
Type:				TXT	

For <p> or policy -policy tag- you have 3 policy options: none, quarantine, or reject. It tells the receiving server which policy to apply to a message that fails DMARC: “none” or do nothing to a message, “quarantine” a message or “reject” the message. Having a “none” policy is similar to having no DMARC enabled, however, you can still receive and analyze the aggregate reports.

DMARC record in our case would be like this:

Host name:			_dmarc.mkvlab.com 
Value:				"v=DMARC1; p=reject; rua=mailto:aggregate@mkvlab.com;
TTL:				3600
Type:				TXT	

RUA: you will receive the aggregate report under this email address. These reports provide visibility into the health of the sending server by helping to identify potential authentication issues or malicious activity.

How to check DMARC Record: MXToolBox DMARC Checker

What I would like to do also, at the end of configuring all the records and checking them using MXToolBox checker, to send a test email from a domain in which we configured and analyzed the header using header analyzer to see the fact that we are using all of the records in the right way and see them as a recipient perspective. this allows me to confirm all the work has been done correctly and taking effect.