DMARC and mailing lists: We survived!

It's been a little over a year since Yahoo and AOL implemented restrictive "p=reject" DMARC policies, saying you essentially aren't allowed to use their domains outside of their infrastructure. Death to mailing lists was predicted; but what seems to have actually happened is, popular mailing list software was updated to handle the new way of things. Google Groups and Yahoo Groups were quickly updated to handle mailing list posts from users at DMARC-restrictive domains. Mailman version 2 was updated at about the same time.

DMARC can be a little scary to set up if you're a sender. It's useful tool in the anti-spoofing arsenal. But before you turn on a "p=reject" policy, you have to know of all your possible legitimate mail streams. The example I use when talking to clients is the HR department -- my employer was just one of many who used to outsource management of resumes and job applications to a third party service that sent its own emails from its own server, using our domain name. Turning on a restrictive "p=reject" DMARC policy in that scenario without being aware of this means I likely wouldn't have ensured that this mail is properly authenticated and allowed, thus I would have caused problems relating to mail delivery of truly wanted mail to or from job applicants.

Dealing with mailing lists, though, is pretty easy by this point. You still run into some mailing lists that haven't been updated, and that's a problem, but as I note above, the most common mailing list managers have already provided DMARC support. And it only took a couple hours to add DMARC support to my custom mailing list manager. So get with it, dudes. Fix your stuff already, holdouts.

(Mail forwarding is a whole other ball of wax. I have notes I've written up, working toward best practice recommendations, but it isn't quite ready for public consumption at this point. I'll try to share thoughts on DMARC and mail forwarding in the future.)