Delen via


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 start with the 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

  • Anonymous
    July 16, 2016
    Thanks
  • Anonymous
    April 13, 2017
    The comment has been removed
    • Anonymous
      May 04, 2017
      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.
  • Anonymous
    July 05, 2017
    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?
    • Anonymous
      July 13, 2017
      The comment has been removed
  • Anonymous
    August 21, 2017
    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.
    • Anonymous
      August 21, 2017
      Did you have a support engineer take a look at the issue you present? It can help improve the product.Thanks for the feedback!
      • Anonymous
        October 24, 2017
        To be honest, there is a lack of knowledge regarding how DMARC works in relation to DKIM and SPF.The first time we've seen this issue was back in 2016, tried to file a case and it appears that it's difficult to get it to the right people.As far as I know the case has been raised with the Product Engineering team and that is where it still resides, unfortunately not getting any updates about this anymore.
  • Anonymous
    September 05, 2017
    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'
    • Anonymous
      September 05, 2017
      You should use selector1-contoso-com._domainkey.contoso.onmicrosoft.com, as stated on the example. Thanks for catching that.
      • Anonymous
        September 08, 2017
        Thanks. Great article by the way! Now getting it all set up.
  • Anonymous
    October 13, 2017
    How do I get my O365 tenant to generate outbound DMARC reports to other organisations? Are there settings in O365 or EOP I need to configure?
    • Anonymous
      October 16, 2017
      It really depends on the sender DMARC record configuration. The domain owner must create a _DMARC record with the fo set to 1, d or s.EM
      • Anonymous
        November 14, 2017
        To be crystal clear: Does Exchange Online send DMARC forensics and/or aggregate reports to domain owners with dmarc-records with ruf and rua defined? (hotmail/outlook.com does)
  • Anonymous
    February 02, 2018
    Using SPF with DMARC and DKIM authentication in place helps me resolve the grey-listing issue caused by the EOP that thinks that my Server is having low reputation just cause i sent few extra emails to my O365 users? Does DMARC helps me get rid of grey listing issue which is quiet general w.r.t EOP
    • Anonymous
      February 05, 2018
      DKIM, SPF and DMARC all help you raise your domain reputation. If you configure it right and your server has a uniform and fair behavior, you should reduce the chances of grey-listing.Of course there are other factors such as the external IP you use, the sender domain, etc. So... there is no simple answer to this issue. But I can say everything you do, counts towards your server evaluation.
  • Anonymous
    January 15, 2019
    Hi EuclidesReally nice article. can you just clarify one possible conflicting piece of information? I read on the official MS documentation to not include the custom domain name in the host field (CNAME record) but in your example you have:Host name: selector1._domainkey.contoso.comTheir example is Host name: selector1._domainkeyPlease let me know your thinking on this?