Violations of my own DMARC policy
First of all, there are acceptable impersonators. Assume you get a secure email from a ProofPoint or IronPort customer, and your or another non-customer sends a reply. These vendors will use the unmodified non-client address as the From address, violating DMARC. (The default is to send the sender a copy of the message.) I have opened a ticket with the CIRT offices of both companies, and nothing has happened. (I think they assume that they are important enough to get a pass.)
A US Government website that we use allows users to request document delivery by email. It asks for both the sender email address and the recipient address, without restriction. Our users use it to send documents to themselves.
Forwarded mail
Messages which are not DKIM-signed will fail DMARC if they are forwarded. Naturally the sender should sign everything, but some are sloppy.
Messages which are forwarded through an Email list will often be tagged with additional content in the Subject, Body, or both. This will of course invalidate DKIM signatures. Just the same, the message may be acceptable to users who participate in those forums.
RFC 7960 is a formal discussion of the problem with unwanted FAIL, mostly focused on forwards.
RFC 8617 defines the ARC protocol, which attempts to solve some of the problems with loss of credentials as a result of forwarding.
Exception Management
DKIM is not likely to be useful for exceptions, so my exceptions are based on the SMTP MailFrom address.
DMARC is based on a verified MailFrom address having an acceptable relationship to a From address. The standardized relationships are "strict" (exact match) and "relaxed" (same organization), but the concept is easily extended. My exceptions are of the form:
(MailFrom is trusted for a specific From address):
"When Mailfrom is verified and Mailfrom = <value> and From = <value> then treat the message as equivalent to DMARC PASS."
or
(MailFrom is trusted to impersonate but never impersonate maliciously):
"When Mailfrom is verified and Mailfrom = <value>, then treat the message as equivalent to DMARC PASS."
SPF has even more problems, but the solution is similar:
When Sever is a specific value and verified, then treat specific or all MailFrom domains as equivalent to SPF PASS. For servers, the Source IP is assumed to be true. HELO or REVERSE DNS can be verified by forward-confirmed DNS. Filtering on server domain is usually preferred.
Extending DMARC
As defined, DMARC is useless until the domain owner publishes a policy with a value other than None. In practice, many messages can be given the equivalent of DMARC PASS without worrying about the policy. The SPF and DKIM alignment tests only depend on your choice of alignment rules, and this is a decision that can be mode as a matter of local policy as a substitute or override for domain owner policy. A high percentage of messages will produce DMARC-equivalent PASS, even without a policy.
This becomes important because some messages need to be whitelisted (allowed to bypass content filtering), and it is crazy to whitelist an address without ensuring that the address is not impersonated. Senders that needs whitelisting are not perfectly correlated with vendors that publish DMARC p=reject, so we need a way to assess authentication on any message.
Effectively, there are three types of sender authentication:
- Explicitly verified based on domain owner information published in DNS, using SPF and/or DMARC.
- Explicitly verified by local policy
- Implicitly treated as verified by allowing the message to be delivered to the user, on the assumption that malicious impersonation is a tiny portion of all mail.
Doug Foster