SPF, DKIM, DMARC and Exchange Online


We don’t like spam. And we need help fighting it, so this is what this post is about: Helping you help all of us that fight spam every day.

Let’s with concepts. I promise it’ll be quick:

SPF DKIM DMARC
What does it stands for? Sender Policy Framework DomainKeys Identified Mail Domain-based Message Authentication, Reporting and Conformance
What is it? A system to declare and verify who can send e-mails from a given domain An e-mail authentication system based on asymmetric cryptographic keys. An e-mail authentication system that helps determining what to do when messages fail SPF or DKIM checks.
How does it work? The receiving host checks if the sending host is allowed to send e-mails from the sender domain.

 

The information stating who can send e-mails is stored on a TXT record in the DNS zone.

The sending host signs email body and/or headers with its private key. The receiving host verifies the signature, identifying if the fields are intact.

 

No digital certificate is required. Public key is published using DNS TXT records.

The receiving hosts applies the DKIM and SPF checks. Then it validates the results against the published DMARC policy and decides what to do: Block, quarantine, deliver, report to sender.

 

The DMARC policy is published via DNS TXT record.

Why is it important? It helps preventing spoofing and can prevent damage to your brand. Greatly reduces the chances that your messages are treated as spam by digital signature. Helps receiving organization decide what to do with e-mails that fails checks and create a feedback loop to allow course correction.
Where can I learn more? Sender Policy Framework DomainKeys Identified Mail Domain-based Message Authentication, Reporting & Conformance

 

Enabling SPF, DKIM and DMARC on Exchange Online

The first thing we do is SPF, because it is simple and stops a lot of spam with little effort. Then we do DKIM and then DMARC, because this last one ties the others together.

 

Enabling SPF

It is important to understand where you are now so we don’t break anything. Take a look at the flowchart below:

SPF Decision Flow

 

Scenario 1 – Only Exchange Online can send e-mails from your domain

  1. Create a TXT record in your domain zone
     TXT Name: @
    
     Value: "v=spf1 include:spf.protection.outlook.com –all"
  2. Test your SPF record at Scott Kitterman’s SPF record testing tools

 

Scenario 2 – Add Exchange Online Protection to your SPF record

  1. Get your SPF record

     nslookup -querytype=txt contoso.com
    
     Server:  dns.external
     Address:  192.168.1.1
    
     Non-authoritative answer:
     contoso.com  text = "v=spf1 mx -all"
  2. Add Exchange Online Protection to your SPF record, just before the “all” verb.

     TXT Name: @
    
     Value: "v=spf1 mx include:spf.protection.outlook.com -all"
  3. Test your SPF record at Scott Kitterman’s SPF record testing tools

 

Scenario 3 – Create a SPF record for your e-mail gateways and Exchange Online Protection

  1. Define which hosts will send e-mail and build the SPF string with the below table:
    Record start v=spf1
    Exchange Online Protection include:spf.protection.outlook.com
    If your MX servers are also used for sending e-mail… mx
    If you use third party e-mail services… include:<3rd party SPF record>

    where <3rd party SPF record> will be provided by your service provider

    If you want to specify an IPv4 that will send e-mail… ip4:<IP v4 Address>

    where <IP v4 Address> will be replaced with the actual IPv4 address

    If you want to specify an IPv6 that will send e-mail… Ip6:<IP v6 Address>

    where <IP v6 Address> will be replaced with the actual IPv6 address

    Record end <enforcement rule>

    where <enforcement rule> can be:

    -all – Anything not in the list will fail

    ~all – Anything not in the list will soft fail (avoid using this)

     
    For example, if you want to allow Exchange Online and the IP address 40.124.14.27 to send e-mails from the domain contoso.com you can use the following SPF record at contoso.com DNS zone:

     

     TXT Name: @
    
     Value: "v=spf1 ip4:40.124.14.27 include:spf.protection.outlook.com –all"

     

  2. Test your SPF record at Scott Kitterman’s SPF record testing tools

 

Enabling DKIM

Publish two CNAME records for your domain in DNS

You’ll have to know a couple of things from your e-mail services at Office 365: Your domain GUID and your initial domain. Don’t worry, we’ll guide you through it:
  1. Get your domain GUID
    Your domain GUID is based on your domain name, replacing the dots with dashes and adding “.mail.protection.outlook.com” at the end. So let’s say your domain is contoso.com, then your domain GUID would be “contoso-com.mail.protection.outlook.com”

    Take note of your domain GUID because you’ll need it latter.

  2. Get your initial domain
    Initial domain is basically your tenant name in Office 365. You can get it from Admin Center – Domains. It is that domain ending with “.onmicrosoft.com”. For our Contoso company it could be “contoso.onmicrosoft.com”.

    Take note of your initial domain too.

  3. Create two CNAME records in you external DNS zone
    Host name selector1._domainkey.<domain>

    where <domain> is your domain name

    Points to selector1-<domainGUID>._domainkey.<initialDomain>

    where <domainGUID> is your domain GUID and <initialDomain> is your initial domain.

     

     Host name selector2._domainkey.<domain>

    where <domain> is your domain name

    Points to selector2-<domainGUID>._domainkey.<initialDomain>

    where <domainGUID> is your domain GUID and <initialDomain> is your initial domain.

     

    For Contoso.com, those would be the required records:

     

     Host name: selector1._domainkey.contoso.com
     Points to: selector1-contoso-com._domainkey.contoso.onmicrosoft.com
    
     Host name: selector2._domainkey.contoso.com
     Points to: selector2-contoso-com._domainkey.contoso.onmicrosoft.com

     

 

Enable DKIM signing for your domain in Office 365

  1. Sign-in at Exchange Admin Center with an administrative credential
  2. Go to Protection > dkim
  3. Select the domain for which you want to enable DKIM and then, for Sign messages for this domain with DKIM signatures, choose Enable.

 

Enabling DMARC

Covering the basics of DMARC

The most important things to consider when enabling DMARC are 1 – to make sure you got SPF + DKIM right and 2 – wisely define your policy. If you get any of those two wrong, there can be a lot of noise.

 

For the first part, we recommend you to test your SPF and DKIM implementation before moving forward with DMARC. We will help you with the second part.

 

The table below summarizes the options you have when configuring your DMARC policy:
Tag Purpose Options
v Version – Required DMARC1
p Policy – Required none: No specific action be taken regarding delivery of messages.

quarantine: E-mail that fails DMARC check should be considered suspicious.

reject: E-mail that fails DMARC check should be rejected.

sp Policy for all the subdomains – Optional, defaults to the parent domain policy if omitted. none: No specific action be taken regarding delivery of messages – useful for monitoring.

quarantine: E-mail that fails DMARC check should be considered suspicious.

reject: E-mail that fails DMARC check should be rejected.

adkim Indicates whether strict or relaxed DKIM Identifier Alignment mode is required – Optional, defaults to r if omitted. r: relaxed mode – Both the authenticated signing domain and the sender domain can be a subdomain of each other to be considered aligned.

s: strict mode – Only an exact match between both of the domains is considered to produce Identifier Alignment.

aspf Indicates whether strict or relaxed SPF Identifier Alignment mode is required – Optional, defaults to r if omitted. r: relaxed mode – Both the authenticated signing domain and the sender domain can be a subdomain of each other to be considered aligned.

s: strict mode – Only an exact match between both of the domains is considered to produce Identifier Alignment.

rua Addresses to which aggregate feedback is to be sent – Optional E-mail addresses in the format mailto:mbx@domain.com. Multiple addresses should be comma separated.
ruf Addresses to which message-specific failure information is to be reported – Optional E-mail addresses in the format mailto:mbx@domain.com. Multiple addresses should be comma separated.
rf Format to be used for message-specific failure reports – Optional, defaults to afrf if omitted. afrf: Authentication Failure Reporting Using the Abuse Reporting Format, as described in RFC 6591.

iodef: Incident Object Description Exchange Format, as described in RFC 5070

ri Interval requested (in seconds) between aggregate reports – Optional, defaults to 86400 if omitted. 32-bit unsigned integer, from 0 to 4,294,967,295.
fo Provides requested options for generation of failure reports – Optional, defaults to 0 if omitted. 0: Generate a DMARC failure report if all underlying mechanisms fail.

1: Generate a DMARC failure report if any underlying mechanism produced something other than an aligned “pass” result.

d: Generate a DKIM failure report if the message had a signature that failed evaluation.

s: Generate an SPF failure report if the message failed SPF evaluation.

pct Percentage of messages to which the DMARC policy is to be applied. It allows to enact a slow rollout enforcement of the DMARC mechanism. – Optional, defaults to 100 if omitted. Integer between 0 and 100, inclusive

 

You can use one of the DMARC record assistant listed at DMARC Deployment Tools. They can greatly reduce the chances of misspelling. However, you have to understand the options you have on the table above.

 

DMARC implementation best practices

We recommend you to follow the best practices below when implementing DMARC:

  1. Form the DMARC TXT record using one of the DMARC record assistant listed at DMARC Deployment Tools
  2. Start monitoring the impact of DMARC applying a monitoring-only policy (p=none). You can do this even before implementing SPF and DKIM, as it can give an insight of what is going to happen when you implement those mechanisms.
  3. Move to quarantine policy after the testing phase (p=quarantine).
  4. Only request that external mail systems not accept messages that fail DMARC (p=reject) if it makes sense for you and after extensive testing.

 

Form and deploy the DMARC TXT record

  1. Define the DMARC policy you want to apply.
  2. Use one of the record assistant listed at DMARC Deployment Tools to build the DMARC TXT record.
  3. Select the options according to the policy you defined.
  4. Publish the DMARC TXT record in your external DNS zone
    For example, we can use the DMARC TXT record below for contoso.com:

     TXT Name: _dmarc.contoso.com
    
     Value: "v=DMARC1; p=none; rua=mailto:rua@contoso.com; ruf=mailto:ruf@contoso.com; fo=1"

 
Euclides Miguel
FastTrack Engineer

Comments (1)

Skip to main content