Share via

What is the best combination for your SPF record, DKIM record, and DMARC record?

  • Article

Sometimes [1] people ask me what the best combination of SPF record is if they publish a DMARC record and DKIM record? How should we best present spoofing using authentication records that we publish in DNS?

Here’s what I think.

First, a domain should publish an SPF Hard Fail in its SPF record if they don’t have anything else (no DKIM, no DMARC).

This tells others to mark a message as spam – or give it a heavy weight – if a message comes from an IP that is not in the domain’s SPF record.

contoso.com IN TXT “v=spf1 include:spf.protection.outlook.com 192.168.0.0/24 –all”

This means that a message cannot be forwarded to another recipient at a different email receiver and subsequently pass SPF authentication, but better to forward and set up a skip filtering rule at the forwarded location than have weak authentication and accept spoofs into an organization.

Second, a domain should sign all of its email with DKIM.

Office 365 will support DKIM signing later this year (2015) so you’ll be all set if you use us for filtering.

selector._domainkey.contoso.com IN TXT “v=DKIM1; k=rsa; p=<public key>; n=<notes>”

When the DKIM feature is released, we’ll have more documentation about the syntax.

Third, a domain should publish a DMARC record with p=none as the policy.

Once an organization is confident they have all the IPs in its SPF record and signs all of its email with DKIM – both originating out of Office 365 and at any outsourced bulk mailers like SalesForce, SendGrid, or ExactTarget, they should move to publish p=quarantine and then p=reject (with an optional experimentation with the pct=xx field in the DMARC record to quarantine/reject only parts of the mail stream).

But, when an organization publishes p=reject, they should simultaneously change their SPF hard fail to SPF soft fail.

Huh?

This expands on what Microsoft has published in its official documentation for Office 365, but it goes back to my first point. A message that passes SPF and is forwarded will fail SPF. If a message hard fails SPF it will probably be marked as spam but if it soft fails, it will most likely still be accepted by the recipient. This forwarding failure possibility is why most organizations publish a soft fail record.

But, if a message is protected by DMARC p=reject, a message can fail SPF but pass DKIM (so long as the content isn’t modified), and still pass DMARC.

Thus, the idea is this:

  1. If a message comes from a spammer and soft fails SPF, and fails DKIM, and therefore fails DMARC, it will be rejected by the recipient.

  2. If a message comes from a good sender and passes SPF and DKIM, and therefore passes DMARC, it will be accepted by the recipient (if it is rejected, it’s not because of DMARC).

  3. If that message is subsequently forwarded by the recipient to another receiver (e.g., mail going to Office 365 and then forwarded to an outlook.com account), it will fail SPF but pass DKIM, and therefore pass DMARC. It will be accepted by the recipient. Since the message soft fails SPF, it will most likely not be marked as spam.

    However, if the forwarded message hard fails SPF, even though it still passed DMARC, it may still very well be marked as spam. A receiving spam filter may not understand “hard fail SPF should be negated by passing DMARC” and instead assign a heavy spam weight to the message, and cause a false positive or even reject the message back to the forwarder leading to mail queuing.

    So, the SPF soft fail / DMARC p=reject provides spoofing protection, and lowers the chances of false positives when it is forwarded. It prevents spoofing at the recipient and allows for forwarding which the sender cannot know might happen to its message.

Before going to a DMARC p=reject or p=quarantine, you really should have DKIM signing for your domain because of the chances of forwarding.

But if you don’t have DKIM signing, you should probably publish an SPF hard fail and DMARC record of p=none. It means that your email cannot be forwarded, but the flip side is that if you don’t do it, others can spoof your domain.

And that’s how I think SPF, DKIM, and DMARC records should optimally be set up. But I wouldn’t be upset if you stuck with an SPF hard fail, either.

[1] No one has ever asked me this, but let’s pretend for the sake of this blog post that they do.

Comments

  • Anonymous
    July 12, 2015
    Great information! DKIM will hopefully make DMARC reject easier to implement. I've seen some rejected "Out of Office" replies from Gmail/Google Apps when using DMARC reject since Office 365 sends the message from outlook.com rather than the senders domain. I guess DKIM would not solve this. Are there any plans to adjust the sender information from automatic replies?

  • Anonymous
    July 14, 2015
    For automatic replies, we still need to figure out a solution that aligns with DMARC.

  • Anonymous
    September 08, 2015
    I'm trying to find further syntax and if DKIM signing for sending is actually live and implemented on Office 365 yet. Any further info? Thanks

  • Anonymous
    December 16, 2015
    My production tenant (15,000 users) enabled DKIM in the background (meaning O365 turned it on and generated key pairs) over the weekend.  My test, First Release tenant has not had this done yet.

  • Anonymous
    January 11, 2016
    Automatic replies from Office 365 still does not align with DMARC. SPF passes but dmarc fails. Have you already find a solution to that ?