DMARC Records for Email Authentication

(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

---

1. A message from me.com is received by you.com's mail server
2. You.com's server checks me.com's public DNS for any that apply: SPF/DKIM/DMARC
   • If the message aligns with either SPF or DKIM, no DMARC policy is applied
   • If the message fails SPF and DKIM, the specified DMARC policy of "none/quarantine/reject" is applied to the message
3. The message is delivered to the user's inbox, spam folder, or not delivered at all (also subject to the spam policies of the recipient server)
4. The recipient server generates and sends back a cumulative report for all messages received from me.com for the day

---

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."

---

One domain (which is not supposed to send any mail) of the more than 40 I administer was sending over 500,000 fraudulent messages per week.  The null SPF record with a -all and the DMARC policy of "reject" put an immediate stop to all of it.  I had no idea anything was being sent "from" that domain whatsoever, but now I know nothing is landing in peoples' inboxes.
Again: across >40 domains, one domain was sending over 500K fraudulent messages per week. That's over 2,000,000 per month! Fully 72% of my mail volume was fraudulent!

Further monitoring revealed a peak fraudulent output of >6 million messages in a month, 99.99% of which were being blocked.