DMARC: Moving to a Monitor-As-Necessary State

After a year-and-a-half of implementation (mostly monitoring), it is time to switch to a 'steady' or 'monitor-as-necessary state' for all of my things DMARC. I've written about this journey before, with the last major summary in November, 2021. In about April of this year, I changed my monitoring stance to an "as necessary" one where I essentially shut off report collection on the whole and only now monitor for a period of time around a change (which is infrequent).

Changes to SPF Records

The first step in this change were broad changes in the SPF records from "softfail" (~all) to "fail" (-all). It's important to note that most major mail systems won't trash or fail to deliver mail solely on this setting, but it does clear up aggregate reports moving forward. In my case over the course of a year, it was a safe move as I was confident all of the intended systems were properly included in the SPF record details.

Changes to DMARC Policies

The basics in DMARC policy changes was to change everything to a policy of reject (p=reject; sp=reject;). However, there are some nuances to my approach, namely:

1. If a domain is actively used (or expected) to send mail, in most cases the adkim and aspf values were explicitly set to 'strict' (adkim=s; aspf=s;)
2. If a domain is not actively used (or expected) to send mail...or is of specific interest for monitoring activity, keep the reporting (rua=mail@domain.tld;) 
3. Consistently set the policy values and TTLs across each set of domains (there are several vanity/alternate versions) to help Future Me not curse at the actions of Past Me.

So What About Reporting Again?

I was receiving a lot of aggregate reports each day, but after changes some 6+ months ago the value of said reports was significantly decreased. As noted above, I moved to a "selective" approach in the reporting, specifically for larger-volume domains where other/third-party systems are being used (such as the community theatre). This ongoing reporting, checked periodically or after larger campaigns, is helpful to ensure we're delivering successfully...especially when combined with other metrics from the content systems.

The nice part about removing reporting from most of the records is that should it be necessary in the future it's easy enough to re-add with the DNS change...and in most cases it'll take effect within a day. But it's also important to note that I was never intending to keep aggregate monitoring active indefinitely. It's a lot of stuff to sort through, and once you're set up with a solid configuration it's not as valuable as in the early days. Further, if something really needs to be evaluated there's always the "forensic" report (ruf) value, though in all honesty I've never received one from a major mail provider, so YMMV.

So, What's Next?

Nothing, really. By design!

I can (and will) as necessary change these records...but I have much greater confidence in both what I've set up for policies and my ability to change or modify as necessary. So the next steps are "nothing" unless it becomes necessary or useful. Changing provider(s), or service/hosts, yes...but I am also quite confident that any remaining (and periodic) "failures" are being addressed as designed by the mail systems in question. And that was the intent all along—do my part in helping to control and deal with unwanted email/spam.

It's been fun to learn about the whole thing, and most importantly I now have a set of "defaults" I can easily apply to any new domains.