Implementing DMARC for Active Domains: Policy & Review

This is the second post in a two-part series to implement DMARC controls for actively-used domains, where this post focuses on creating and reviewing/adjusting your DMARC policy and controls. Part one reviewed proper DMARC prerequisites and contains information you will need to have in place before creating your DMARC policy.

The following steps assume you already have messages being delivered and 'PASS'ing either/or/both SPF and DKIM.

1. Determine your Rollout and Reporting Plan

DMARC works on top of SPF and DKIM, so it's time to create your initial DMARC policy for your DNS DMARC record. DMARCLY has a nice explanation of all the possible options and Google also has a nice tutorial on their recommended rollouts along with some details on how alignments work.

Generally speaking, you'll work through tightening the restrictions over a period of time. I've chosen to do this over a period of 4-8 weeks, going from p=none to p=quarantine and ultimately to p=reject.

A quick note about sending reports to alternative domains (e.g. reports for example.com sent to an account @reportcollector.org):

DMARCLY has more detailed information about what is called 'External Destination Verification,' but if you're creating DMARC records with the rua tag with an email address for a different domain (as identified in the subheading above), the destination domain must publish appropriate TXT records to allow for the receipt of such reports. Basically it comes down to one of two options:

1. A TXT record published on the destination domain for each allowed domain, e.g. host example.com._report._dmarc. This is great for small sets of domains, or:
2. A TXT wildcard record published on the destination domain, which will allow for all domains' DMARC reports, e.g. host *._report._dmarc. For aggregate report collection over many domains, this may be the better option.

Either option requires the value to be set as v=DMARC1.

You will want this configured, if necessary, in advance of rolling out your first DMARC policy.

2. Define your initial DMARC policy and create your DMARC Record

With your rollout plan in place, it's time to craft the actual policy and record you'll start with. As I noted above, my rollout plan is to go from p=none to p=quarantine and ultimately to p=reject. In later phases (toward p=reject) I also intend to tighten down the alignment modes for SPF and DKIM to 'strict;' however, for the initial rollout I'm going with their 'relaxed' defaults.

I'm also going to set up reporting to the fictitious dmarcreports@reportcollector.org account. You would use the reporting account you've set up (and, if necessary, opened up to reports for external domains, as noted above). Note that reporting is optional; in that sense the rua tag is not necessary for a proper DMARC record.

To that end, my first-cut DNS record is for host _dmarc with TXT value v=DMARC1; p=none; rua=dmarcreports@reportcollector.org; aspf=r; adkim=r, as illustrated in the DNS entry:

I've left the TTL deliberately short, so I can more nimbly fiddle with this further down the road. Once I've reached my long-term preference/goal, I would likely change this to be upward of 1 week.

3. More Testing!

A quick test with the Google Admin Toolbox Check MX tool should give you output something like this if all is set up "acceptably:"

And after a day or so you should start to see message headers with the following happy news:

4. Give it Some Time; Adjust your DMARC policy

Assuming mail is being routed through the domain(s), you should start seeing some DMARC reports coming to your reporting account (as specified in the DMARC rua tag) if you included it in your policy. These reports are XML files, and as such will require a little bit of parsing. I usually use VS Code for this, as my incoming reports aren't usually too crazy or lengthy (which makes them easier to consume), but there are many ways one might further examine larger XML datasets.

Google and DMARCLY both have nice documentation about the structure and formatting of reports, including information on what to look for/how to visually parse them.

You'll want to keep an eye on these to look for things that are failing. If you set the policy to p=none, failed messages should still be delivered (though it's possible they still wound up in a SPAM folder). It's only once the policy is set to quarantine or reject that delivery is truly interrupted, which is why it's super important to start with none.

After a period of time, you'll either notice trends, or things that require a fix. I've found a few legitimate (server) senders that were outside my original SPF scope and have added them appropriately. Sources supporting DKIM should be added as well. Make these changes and see how they impact deliverability.

At some point, you will reach a point of satisfaction (or comfort) with your configuration and choose to tighten down your DMARC policy. At this point the most basic thing to change is the policy itself from p=none to p=quarantine, and later from p=quarantine to p=reject. Depending on your preference or need, you can change alignment modes for SPF and/or DKIM by modifying the record to aspf=s and adkim=s respectively. How, where, and when are up to you!

5. Give it Some [More] Time; Adjust as necessary

I've only implied one might further restrict these policies, but it is entirely possible you'll want or need to relax them as you work through the process. Time is the key here; make a change, let the dust settle, examine, and evaluate. There's really no rush or perfect configuration for all people.

Celebrate your achievements!

Assuming you've made it all the way through these steps, congratulations! I know myself I've not fully restricted everything, and I have different domains set with different configurations as necessary. The reports have been very useful, and once you wrap your head around their structure and how things work, it's easier to understand the nuanced changes that may (or not) be necessary in your environment.

Regardless, congratulations are in order! This topic is far from trivial (beyond the face value), and even if you weren't able to implement everything or it's a work in progress...I can guarantee you've learned something through this process! Congratulations!