(This article is a part of a series on email and domain protection)
DMARC's role is twofold: 1) It is used to specify what to do with incoming messages, based on whether they align with SPF and DKIM records of a given domain; and 2) It generates reports back to a domain owner regarding email volume, sources, and what policies were applied to those messages.
While there are plenty of how-to guides out there, the purpose of this article is to give a helpful overview of exactly what DMARC is and why it's important for everyone to implement on every domain.
Without SPF and/or DKIM records in place, DMARC still has some value (reporting), but no power to accomplish anything. At a minimum, an SPF record is required in combination with DMARC in order for receiving servers to apply any policies to inbound messages.
DMARC Message delivery workflow
For domains that send mail, DMARC is a huge step in protecting not only IP-based reputation, but also domain-based reputation. The domain administrator publishes an SPF or DKIM record (preferably both), then a DMARC record. The DMARC record specifies what to do with messages that don't align with SPF or DKIM, as well as where to send reports on the quantity and sources of email received on behalf of the administrator's domain.
For any domain that sends mail, it is recommended to start with a DMARC policy of "none," which does nothing to break any mailflow, but allows for reporting. The often-underrated significance of this reporting is that the administrator gets to see how many messages are coming from his domain as a whole, including servers not under his control. Anyone can read the logs of their own equipment, but when, for example, a Russian spam server is sending mail from that same domain without permission, there is no other way to get reporting on that than DMARC. DMARC allows receiving servers to report back to domain owners exactly what is being sent on their behalf.
These reports help domain owners to understand what email is being sent in their name, both legitimate and illegitimate. These reports can be used to ensure all legitimate sources of mail have been accounted for before tightening down the SPF policy from ~all to -all. The reports continue to be useful in fine-tuning DMARC policy when switching from "none" to "quarantine" and again from "quarantine" to "reject."
After accurately accounting for all legitimate sources of mail and accommodating them in SPF/DKIM records, the DMARC record can be changed from "none" to "quarantine." Note, as in the illustrated example above, the policy is only applied to messages that fail both SPF and DKIM. If both exist and the message aligns with either of them, the DMARC policy is not applied.
Quarantining a message generally means shoving it into a SPAM folder. For the smoothest application of a policy of "quarantine" or "reject," DMARC allows for the policy to be applied to any percentage of messages, rather than all of them. For example: when quarantining messages, it's prudent to start with 1% and wait for reporting to come in, then use the forensic reporting to view the raw HTML body of the affected messages. Once comfortable that all the quarantined messages are illegitimate, the percentage can be increased so more and more messages are delivered to the spam folder instead of the inbox. Gradually, this percentage is increased until all messages not aligning with SPF/DKIM are quarantined, then the process is restarted with a policy of "reject."
Domains that send no mail should have both a "null" SPF policy and a DMARC policy of "reject."
Further monitoring revealed a peak fraudulent output of >6 million messages in a month, 99.99% of which were being blocked.