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. So let’s say your domain is contoso.com, then your domain GUID would be “contoso-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 (10)

  1. Aaron says:

    So DMARC settings exist only in the external DNS zone and are outside of Office 365. In other words, no action required within Office 365?

    1. Exactly. You don’t have to do anything in Exchange Online in order to enable DMARC. However, I strongly recommend to make sure you have everything in place for SPF and DKIM.

  2. Dan says:

    by default Office 365 use SPF, DKIM and DMARC to filter or tag emails?. Can we re-configure that action for every protocol (SPF, Dmark, DKIM)?. I receive emails from third parties supplanting the real domain, how can I prevent this from O365?

    1. Yes, Exchange Online will consider SPF, DKIM and DMARC when filtering e-mails. There are some things you can do to make Exchange Online Protection more strict, such as making messages as SPAM when SPF hard fails (Exchange admin center\protection\spam filter\select your policy\Advanced options\SPF record: hard fail:On.

      But that will depend on their SPF record. And if they don’t do a good job keeping their SPF record, they will probably affect their domain’s reputation.

      Another important thing you can do is to report the spam to Microsoft:

      – Create a new, blank email.
      – Address the email to the Microsoft team that reviews messages as follows:
      + For junk messages, address your email to junk@office365.microsoft.com.
      + For phishing scam messages, address your email to phish@office365.microsoft.com.
      – Copy and paste the junk or phishing scam message into that email (as an attachment).
      – Click Send.

  3. To become fully DMARC compliant there is still a bug in Office 365 authentication when operating more complex tenants.
    If you happen to use Send on Behalf functionality and users are on different domains within the same tenant you’ll end up with DMARC rejects if both domains are using a DMARC reject policy.

    DMARC resides on the 5322.From domain, while SPF resides on the 5321.from (aka Return-Path, aka envelope-from, etc.) and to make things ‘easier’ DKIM may be signed on the 5321.from or 5322.From. To be DMARC aligned the 5322.From domain needs to match with the 5321.from (sub)domain and the DKIM signature which is set using the 5322.From domain.

    Back to the problem, we observe with Office 365 and the Send on Behalf functionality that all authentication is done on the email address of the person Person #1 (person1@example.com) who is Sending On Behalf of another user Person #2 (person2@example.net). Both users are in the same Office 365 tenant.

    With DMARC this results in the email having no authentication for the 5322.From domain (@example.net), because the 5321.from domain (@example.com) is used to authenticate the email.

    1. Did you have a support engineer take a look at the issue you present? It can help improve the product.

      Thanks for the feedback!

  4. Dave B says:

    Hi. You state the GUID is domain with hyphens + .mail.protection.outlook.com however your example doesn’t contain the ‘mail.protection.outlook.com’ bit ;

    **Points to: selector1-contoso-com._domainkey.contoso.onmicrosoft.com **

    can you please clarify whether I need the ‘mail.protection.outlook.com’

    1. You should use selector1-contoso-com._domainkey.contoso.onmicrosoft.com, as stated on the example. Thanks for catching that.

      1. Dave B says:

        Thanks. Great article by the way! Now getting it all set up.

Skip to main content