A DMARC warning

One challenge when implementing DMARC is to ensure that all mail, and I do mean ALL mail is authenticated correctly, before switching to a p=reject notice. The easiest way to do this is to set up a p=none record and check reports to see what mail isn’t authenticated. At least some of this mail is actually going to be valid but unauthenticated email.

I regularly recommend monitoring for 6 – 12 months in order to catch some irregular emails. Even then, someone should regularly monitor DMARC reports in order to identify systems that need authentication added.
One of the cases I worry about is system monitoring emails. These are emails intended to notify sys admins about problems and errors. They often don’t go through the main SMTP server. They usually don’t have an external facing IP and there are security arguments against putting internal IPs into external SPF records. These emails are important and are, usually, not authenticated.
Overall, I could imagine cases where a DMARC record would lead to some problems. And, well, it can. Reading through the postmortem of a significant system failure, one of the problems was no one knew backups weren’t running because notification emails were failing DMARC.

While notifications are enabled for any cronjobs that error, these notifications are sent by email. For GitLab.com we use DMARC. Unfortunately DMARC was not enabled for the cronjob emails, resulting in them being rejected by the receiver. This means we were never aware of the backups failing, until it was too late. GPostmortem of database outage of January 31

Ooops.
Backup failures happen. System outages happen. Crashes happen. (We once had a system crash and take out a disk while during the installation of backup software. #badthing). DMARC failures of this type are preventable.
Part of the challenge here is that gitlab is using google to host their domain and email. That give gitlab a little less control over handling DMARC rejections. Gmail applies the public policy to email. Internal systems sending mail to a SMTP server you control can be whitelisted and exempted from DMARC policy. But using a hosted system means giving up some overhead, and some flexibility.
Of course, DMARC reporting should show internal systems trying to send mail. But I don’t think most places are actually reading their DMARC reports. If anyone at Gitlab was, they didn’t understand the significance of these emails.
DMARC is, overall, a useful protocol and gives senders a little more control over their email. Sometimes, though, there are unexpected consequences. Like most things in email, you can’t set and forget. You have to monitor your DMARC reports and pay attention to systems sending legit but unauthenticated email.