A DMARC Follow-Up: Nine Months In

It's been a full nine months since I first wrote about implementing DMARC controls, and over six months since I last wrote about fiddling with DMARC settings, so it's time to provide another quick update.

Reports Tell The Success Story

I haven't (yet) written anything to analyze the various (and sometimes numerous) daily reports from the domains on which I've configured DMARC controls, but it's on my list of things to fiddle with at some point -- perhaps this winter. The reports all come back in similarly-constructed XML, and it would be interesting to see some calculated/aggregate information based on the data. I want to complete some form of analysis before changing my primary policies from p=quarantine to p=reject (on domains I've not already modified).

What I have been doing is skimming through each report. It only takes a minute and after a few times some things stick out. For me, it's now come down to looking for the following pattern in any data:

    <row>
      <source_ip>123.234.56.78</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>quarantine</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>

Specifically the presence of <dkim>fail</dkim> and <spf>fail</spf>. Since my last major modifications in February, I can absolutely confirm that no report contains a valid source_ip and fails both of these controls.

Better yet, I'm seeing longer and longer periods of time between "burst" attempts on these domains, and when a burst comes through the counts are all now in the low single digits! This was not the case when I first implemented the controls, so clearly something is working as designed.

The Next Steps

As I mentioned, I'd like to do two things on domains I've not already cranked down the DMARC policies:

1. Write something (or find a tool) to do some basic aggregate analysis of the daily reports received.
2. Crank down the quarantine policy to a more firm reject.

One thing I've not written about is use of the pct DMARC tag, which is useful to selectively apply a more restrictive policy to a subset (by percentage) of messages. Given what I've been seeing, I am not inclined to set this tag as I move to reject since the volume of messages against which it would apply is so small. Further, the data I'm seeing indicates all of my trusted or known sending locations are properly configured, so there is no need to allow for additional flexibility. The exception to this might possibly be in an addition of a new service/provider, but the daily reports would indicate all the actionable information I would need anyway. The data would in theory be addressed accordingly during an onboarding or spin-up process.

So that's all good news! I'm glad to be doing my little part in reducing the spam flow!