Setup SPF, DKIM and DMARC for Office 365-based mail systems.

John Torrance, our Service Team Technical Specialist, wrote a brilliant blog post on how to enable SPF, DKIM and DMARC for your mailing system. SPF, DKIM and DMARC are the Holy Trinity when it comes to email authentication. Email authentication helps to improve the delivery and credibility of your emails by implementing protocols that verify your domain as the sender of your messages.

Put simply, SPF, DKIM and DMARC are ways to authenticate your mail server and to prove to ISPs, mail services and other receiving mail servers that senders are truly authorized to send email

Not only does this prove that you are who you say you are but it always proves that this isn’t a phishing mail or that you have not been breached.

This setup will best apply to Office365 based mailing systems.

What you will need to have available to you

1. Mx records.
2. Access to your DNS registrar.
3. A valid email account for receiving dmarc alerts on your domain (cannot be an alternative domain).

SPF

Firstly, we will setup an SPF record. This is based on a TXT record which denotes which servers your mails may be sent from. If the mail is delivered by any other system, this SPF record proves that those mails are spoofed and not from the original company.

To setup an SPF record, we need to know all services that send mail for us. Normally this is your MX record. However, many companies also send mail via signature hosts, or mail backup/ archiving software systems. (ex. Mimecast). This causes our SPF record to grow slightly in size and needs to include multiple sources.

SPF records always start with v=spf1

Next you need to add any IP address ranges you might have as your mx records. This will be denoted by the type of IP. So either ip4:xxx.xxx.xxx.xxx or ip6:abcd:1234:0000:0000:4321:dcba

Finally, you will include any 3^rd party senders using the ‘include’ tag. i.e. include:3rdpartydomain.com

To finish off the SPF record you need to state which rules to follow using the tag ‘all’

There are 3 tags that can be used. Commonly though -all is the most often used. And is used on our current setup.

• -all                   Fail – servers that aren’t listed in the SPF record are not authorized to send email (not compliant emails will be rejected).
• ~all                  Softfail – If the email is received from a server that isn’t listed, the email will be marked as a soft fail (emails will be accepted but marked).
• +all                  We strongly recommend not to use this option, this tag allows any server to send email from your domain.

Once you have configured your SPF record, it should look end up like this:

v=spf1 ip4:xxx.xxx.xxx.xxx ip6:abcd:1234:0000:0000:4321:dcba include:3rdpartydomain.com -all

** **Please keep in mind that your SPF record cannot be over 255 characters and has a maximum of 10 include tags

You can then connect to your DNS registrar and edit your domain’s DNS entries.

1. Create a new TXT record.
2. Host/hostname is your domain
3. TTL can be set to 3600 or left default
4. And finally input your SPF record and apply the changes.

Once you have applied these changes, you can then verify the details by going to https://www.dmarcanalyzer.com/spf/checker/

DKIM

Next we can move onto DKIM. This is an interesting setup as I would best describe it, as similar to an ‘SSL certificate’. You must setup a private key and a public key for decryption of email headers. The private key being held via your internal mailing system and the public key is associated to your published DKIM DNS record.

Since our email exchange is running on Office365, there is a tool available within Exchange Online to create these keys. But this requires a bit of initial setup to ensure communication with O365 as well as your trusted domains.

Publish two CNAME records for your custom domain in DNS**

For each domain for which you want to add a DKIM signature in DNS, you need to publish two CNAME records.

Run the following command:

New-DkimSigningConfig -DomainName -Enabled $false

Get-DkimSigningConfig -DomainName domain | fl Selector1CNAME, Selector2CNAME

Create CNAMEs referenced in Get-DkimSigningConfig output

Then turn on DKIM again

Set-DkimSigningConfig -DomainName domain -Enabled $true

The CNAME records in your DNS will point to already created A records that exist in DNS on the Microsoft DNS servers for Office 365.

Office 365 performs automatic key rotation using the two records that you establish. If you have provisioned custom domains in addition to the initial domain in Office 365, you must publish two CNAME records for each additional domain. So, if you have two domains, you must publish two additional CNAME records, and so on.

Use the following format for the CNAME records.

Host name:                                                    selector1._domainkey

Points to address or value:                         selector1- ._domainkey.

TTL:                                                                3600

Host name:                                                    selector2._domainkey

Points to address or value:                         selector2- ._domainkey.

TTL:                                                                3600

For example, if your customized domain is “contoso.com” your domainGuid becomes “contoso-com”, any periods are replaced with a dash. So, regardless of what MX record your initialDomain points to, you’ll always use the above method to calculate the domainGuid to use in your CNAME records.

initialDomain is the domain that you used when you signed up for Office 365. Initial domains always end in onmicrosoft.com

Enable DKIM signing for your custom domain in Office 365

Once you have published the CNAME records in DNS, you are ready to enable DKIM signing through Office 365. You can do this either through the Microsoft 365 admin center or by using PowerShell.

To enable DKIM signing for your custom domain through the admin center

1. Sign into O365 with your work or school account.
2. Select the app launcher icon in the upper-left and choose Admin.
3. In the lower-left navigation, expand Adminand choose Exchange.
4. Go to Protection> dkim.
5. Select the domain for which you want to enable DKIM and then, for Sign messages for this domain with DKIM signatures, choose Enable. Repeat this step for each custom domain.

To enable DKIM signing for your custom domain by using PowerShell

1. Connect to Exchange Online PowerShell.
2. Run the following command:

Set-DkimSigningConfig -DomainName -Enabled $true

Where domain is the name of the custom domain that you want to enable DKIM signing for.

For example, for the domain contoso.com:

Set-DkimSigningConfig -DomainName contoso.com -Enabled $true

To Confirm DKIM signing is configured properly for Office 365

Wait a few minutes before you follow these steps to confirm that you have properly configured DKIM. This allows time for the DKIM information about the domain to be spread throughout the network.

• Send a message from an account within your Office 365 DKIM-enabled domain to another email account such as outlook.com or Hotmail.com.
• Do not use an aol.com account for testing purposes. AOL may skip the DKIM check if the SPF check passes. This will nullify your test.
• Open the message and look at the header. Instructions for viewing the header for the message will vary depending on your messaging client. For instructions on viewing message headers in Outlook, see View e-mail message headers.

The DKIM-signed message will contain the host name and domain you defined when you published the CNAME entries. The message will look something like this example:

From: Example User [email protected] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;     s=selector1; d=contoso.com; t=1429912795;     h=From:To:Message-ID:Subject:MIME-Version:Content-Type;     bh=;     b= ;

• Look for the Authentication-Results header. While each receiving service uses a slightly different format to stamp the incoming mail, the result should include something like DKIM=passor DKIM=OK.

You can then also do a check on whether your DKIM is valid using dmarcanalyzer

https://www.dmarcanalyzer.com/dkim/dkim-check/

DMARC

Finally, we will look towards a DMARC setup

The main goal of DMARC is to detect and prevent email spoofing. For example, phishing scams using domains from banks to send out email on their behalf. Customers from that bank think they receive a legit email, that their bank card isn’t valid anymore. The link to click on will lead to a fraudulent website. This website is exactly the same as the real website and logging in will provide the cyber criminals the possibility to use your credentials.

Originally the email authentication techniques DKIM and SPF helped to protect your domains from scams like this. However cyber criminals can bypass these security measures. In order to fully secure your domain and email channel, DMARC will create a link between SPF & DKIM. When implementing DMARC into your DNS record you gain insight in your email channel. ISPs will provide Aggregate (RUA) and Forensic (RUF) DMARC reports on a daily basis and these reports can be sent to the email address that’s published in your DMARC record. There are two available types of DMARC reports. The Aggregate Reports (RUA) and Forensic DMARC reports (RUF):

Aggregate DMARC reports (RUA)

• • • Sent on a daily basis
• Provides an overview of email traffic
• Includes all IP addresses that have attempted to transmit email to a receiver using your domain name

Forensic DMARC reports (RUF)

• • • Real time
• Only sent for failures
• Includes original message headers
• May include original message

Within DMARC it is possible to instruct email receivers what to do with an email which fails the DMARC checks. In the DMARC record a DMARC policy can be defined that, depending on the setting, instructs an ISP how to handle emails that fail the DMARC checks. Email receivers check if incoming messages have valid SPF and DKIM records and if these align with the sending domain. After these checks a message can be considered as DMARC compliant or DMARC failed. After the email receiver verifies the authentication status of a message they will handle the message differently based on the DMARC policy that is set.

There are 3 possible DMARC policies available: None (monitoring only), Quarantine and Reject.

Monitor policy: p=none

The first policy is the none (monitor) policy: p=none. The DMARC policy none instructs email receivers to send DMARC reports to the address published in the RUA or RUF tag of the DMARC record. his is known as a Monitoring only policy because with this (recommended starting) policy you gain insight in your email channel. The none policy will give insight in the email channel but does not instruct email receivers to handle emails failing the DMARC checks differently, this is why it is also known as the monitor policy. The none policy only gives insight in who’s sending email on behalf of a domain and will not affect the deliverability.

Quarantine policy: p=quarantine

The second policy is the quarantine policy: p=quarantine. Besides sending DMARC reports, the DMARC policy quarantine instructs email receivers to put emails failing the DMARC checks in the spam folder of the receiver. Emails that pass the DMARC checks will be delivered in the primary inbox of the receiver. The quarantine policy will already mitigate the impact of spoofing, but spoof emails will still be delivered to the receiver (in the spam folder).

Reject policy: p=reject

The third policy is the reject policy: p=reject. The DMARC policy reject. Besides sending DMARC reports, the DMARC policy reject instructs email receivers to not deliver emails failing the DMARC checks at all. Emails that pass the DMARC checks will be delivered in the primary inbox of the receiver. This policy mitigates the impact of spoofing. Since the DMARC policy reject makes sure all incorrect setup emails (spoofing emails) will be deleted by the email receiver and not land in the inbox of the receiver.

DMARC has the benefit of being extremely straightforward to setup using a 3^rd party tool. I used mxtoolbox for this

https://mxtoolbox.com/DMARCRecordGenerator.aspx

We just need to input:

Domain

What policy to apply

Which mail address to use

And finally, what percentage of mails to apply DMARC to.

You can then connect to your DNS registrar and edit your domain’s DNS entries.

1. Create a new TXT record.
2. Host/hostname is _dmarc
3. TTL can be set to 3600 or left default
4. And finally input your DMARC record and apply the changes.

You can test your records via https://dmarcian.com/dmarc-inspector/

Once you have applied DMARC using a policy. (quarantine or reject) you will start receiving mails with included DMARC xml reports, these can be viewed by a few helpful sites to understand what the xml contains

https://mxtoolbox.com/DmarcReportAnalyzer.aspx

https://us.dmarcian.com/xml-to-human-converter/

And there you have it, you can now setup SPF, DKIM and DMARC on your Office 365-based mailing systems. We know it might be difficult to enable so if you have any issues, contact the A Team and let us help you enable productivity in your business.