Do you use let's encrypt?

4934 votes ~ 18 comments


Tying together SPF and DKIM with DMARC

Posted by Steve on Mon 3 Aug 2015 at 19:35

Tags: , ,

When it comes to increasing deliverabiity of email, and preventing spoofed/forged emails the preferred solution these days is DMARC, which allows the use of SPF and DKIM to be enforced for domains in a unified manner.

We've already documented the process of signing outgoing emails with DKIM, and briefly introduced the use of SPF to document the hosts which are permitted to send email for a particular domain. Both of these techniques are useful, especially when combined.

But there is a flaw regarding the use of DKIM-signatures, which we've mentioned before:

  • If you sign all your emails with DKIM a remote spoofer can still send mail, pretending to be from your domain, with no signature present.

In order to prevent this you need some way of saying "ALl our mail is signed with DKIM", such that a mail with a missing signature is treated just as harshly as a mail with an invalid signature, and DMARC is exactly how you achieve that.

DMARC allows you to specify how failures should be handled:

  • SPF failures
    • Should be treated strictly - and rejected if violated.
    • Should be treated in a relaxed fashion.
  • DKIM failures
    • Should be treated strictly - and rejected if missing/bogus/bad.
    • Should be treated in a relaxed fashion.

There are other abilities too, but the main reason for DMARC to exist is to publish how strongly/weakly you will be using SPF and/or DKIM.

As with the other systems DMARC-policies are published as TXT records, in DNS.

The basic record would look like this, and for the sending-domain it would be stored in the TXT record named

"v=DMARC1; p=reject; adkim=s; aspf=s"

Much like SPF & DKIM the record is comprised of several components:

  • v=DMARC1 - A version-identifier.
  • p=reject - The policy for failures, one of none, reject, or quarantine.
  • adkim=s - For DKIM-testing use strict handling, the alternative being =r for relaxed processing.
  • aspf=s - For SPF-testing use strict handling, the alternative being =r for relaxed processing.
  • fo=1 - Setting fo=1 will let you receive emails regarding failures of either SPF or DKIM. If you set =0 you'll receive reports only if both are in use and both of them fail.
  • - Where to receive reports of failure.

If you define a rua=-setting, such as you'll receive a daily report from providers who honor it letting you see how many mails were received by them, and how they were handled. This domain receives a regular summary from,, and similar sites. The summary is in XML-format and will look like this:


That report shows that two mails were received by Google, both from the same sending IP-address, and the mails each passed their SPF and DKIM testing.

To lookup the DMARC-record which might be present for a domain you merely need to use the dig command, or nslookup. As an example here is what the record looks like for this domain:

$ dig -t txt +short
"v=DMARC1\; p=reject\;\; fo=1\; adkim=s\; aspf=s"

As a final update it is worth noting that there are a few different more additional items you can add to yoru DMARC record, documented on the DMARC website, but the ones listed above are sufficient to define and publish a policy for your domain(s).



Re: Tying together SPF and DKIM with DMARC
Posted by Anonymous (92.86.xx.xx) on Fri 4 Dec 2015 at 07:50
The strict and relaxed modes refer to alignment processing only. In strict mode the an exact match between the "From:" domain and SPF and DKIM is required. In relaxed mode subdomains are allowed.
You make it sound like strict and relaxed have anything to do with overall disposition policy. No matter what you do DMARC is a pass, if AT LEAST ONE of SPF or DKIM is a pass. It is a fail, if both fail.

[ Parent | Reply to this comment ]

Re: Tying together SPF and DKIM with DMARC
Posted by Anonymous (159.118.xx.xx) on Tue 15 Dec 2015 at 02:22
As pointed out by the previous comment, "relaxed" and "strict" modes just deal with whether subdomains are allowed or not. It has nothing to do with how it should treat failures of SPF or DKIM.

[ Parent | Reply to this comment ]