Domain-based Message Authentication, Reporting and Conformance (DMARC) establishes operating rules on how to interpret the technical results of DKIM and SPF validation.
DMARC was initiated in 2011 to combat phishing attacks. An email sender uses a DNS TXT field to publish instructions on what actions an email receiver should take when an unauthenticated email is received. It includes a feedback look where email receivers report these actions to the sender.
I use DMARC to minimize return email failure notifications when a spammer uses my domain in a forged "from" field of an email. After the receiving server checks SPF and DKIM to identify the forged email as spam, DMARC communicates my instructions on how the receiver should handle that message. Since I do not want to receive notifications of failed attempt to deliver spam, I instruct the receiver to discard the message.
However, I do want to receive reports of messages that have failed SPF or DKIM validation. DMARC allows me to define what reports I want to receive and where to send them. These reports assure me that my mail systems are working normally and not rejecting valid messages.
Example DNS TXT Record
In this example, aggregation (rua) and forensic( ruf) reports are sent to me by email. Aggregation reports come from the ISP receiving email. Forensic reports are sample messages that failed SPF and DKIM validation.
I tell the ISP to use strict validation for DKIM (adkim) and SPF (aspf), check all of my messages (pct) and reject (p) the ones that failed.
This is the final setting for my DMARC record. When it was first deployed, the parameters were more relaxed to allow for troubleshooting. The initial record was:
This DNS TXT record should added with a host name of "_dmarc.example.com".