Minimal DMARC

The intent of DMARC is to cause emails to silently vanish.
Ideally deploying DMARC would cause all malicious email that uses your domain in the From address, but which has absolutely nothing to with you to vanish, while still allowing all email you send, including mail that was sent through third parties or forwarded, to be delivered.
For some organizations you can get really close to that ideal. If you control (and know about) all the points from which email is sent, if your recipients are individuals with normal consumer or business mailboxes, their mailbox providers don’t do internal forwarding in a way that breaks DKIM before DMARC is checked and, most importantly, if your recipients are a demographic that doesn’t do anything unusual with their email – no vanity domain forwarding, no automated forwarding to other recipients, no alumni domain forwarding, no forwarding to their “real” mailbox on another provider – then DMARC may work well. As long as you follow all the best practices during the DMARC deployment process it’ll all be fine.
What, though, if you’re not in that situation? What if your recipients have been happily forwarding the mail you send to them to internal mailing lists and alternate accounts and so on for decades? And that forwarding is the sort that’s likely to break DKIM signatures as well as break SPF? And while everyone would advise you not to deploy DMARC p=reject, or at least to roll it out very slowly and carefully with a long monitoring period where you watch what happens with p-none, you have to deploy p=reject real soon now?
What can you do that’s least likely to break things, while still letting you say “We have deployed DMARC with p=reject” with a straight face?

1. Make sure that every bit of mail you send is sent with both valid SPF and a valid DKIM signature for the domain you use in the From address, so both are DMARC-aligned
2. Use “relaxed/relaxed” canonicalization (not “relaxed” canonicalization, as that’s quite different).
3. Don’t do anything “clever” with your SPF or DKIM configuration. Use simple configuration that’s likely to be well understood by recipients. Very simple.
4. DKIM sign a minimal subset of headers – e.g. “h=From:Subject:Date”. Definitely don’t sign Reply-To:, To: or Message-ID: headers, as they’re the most likely to be modified during forwarding. (From: is also likely to be modified – but if it is, it’s no longer going to trigger your DMARC policy so you don’t care).
5. If you’re generating bulk email, make sure that it’s not only entirely valid but that there’s nothing in the structure of the email that might trigger an intermediate server to rewrite it. Make sure that the headers aren’t excessively long, and are wrapped in a normal manner. Make sure that the mail doesn’t have any long lines in it (quoted-printable encoding is a good way to ensure that). Make sure there aren’t any non-ascii characters in the headers or body; that everything is encoded appropriately.
6. If possible, consider separating your mailstreams. Put all your supposedly “security critical” email on a DMARC p=reject domain, and offload your mail that’s not likely to be impersonated onto it’s own domain, one that isn’t covered by the DMARC p=reject diktat. Do everything right on that new domain, make sure it’s all sent cleanly and with DMARC-aligned authentication … just don’t publish a DMARC p=reject record for it.
7. Monitor how DMARC is affecting your mail. Make sure you’re receiving all the aggregate and forensic reports you can, and also that your postmaster and customer support teams notify you of any issue that looks at all like mail going missing (or being rejected, or going to a spam folder – as some mailbox providers won’t follow recommended practice for DMARC failures and will route the mail to a spam folder instead).
8. Monitor things for as long as you can with your DMARC set to p=none, and fix as much as you can identify via DMARC forensic reports before switching it to p=reject.
9. Track where mail that’s being impacted is being delivered to. If there’s low hanging fruit, maybe reach out to the forwarder and work with them to fix things so that their forwarding doesn’t break your DKIM signature. As a last resort, adding the forwarders IP address to your SPF record will allow DMARC to pass (at the cost of removing any pretense of DMARC protection for those recipients).

Have a relaxing picture of a forest. You’re going to need it.