The Domain-based Message Authentication, Reporting and Conformance (DMARC) DNS record allows an email sender (which is already using DKIM, SPF or both) to indicate to a mail receiver one or more of the following:
Indicate the mechanisms the sender uses to authenticate its email (DKIM, SPF or both). Some of this functionality is already provided for separately within DKIM (the ADSP capability) and SPF (the pre field) but DMARC enables a comprehensive definition covering both systems.
Indicate comprehensively for DKIM, SPF or both how to handle mail that fails validity checks.
Optionally requests the receiver to send a feedback report (defined by the Abuse Report Format – RFC 5965 or the Incident Object Description Exchange Format – RFC 5070) which allows the mail sender to monitor and change its policies based on receiver feedback. Both individual and aggregate report formats are allowed. This capability is uniquely triggered by the DMARC RR.
DMARC can be viewed as a meta RR that describes the sender’s email policy, comprising DKIM or SPF or both, for any domain. While the draft RFC does not explicitly say anything about the ADSP feature of DKIM it does go out of its way to identify ADSP shortcomings. On balance it would probably be confusing, if not a serious mistake, to have both ADSP and DMARC RRs for any domain.
DMARC is defined by RFC 7489. The DMARC.org web site claims that more than 2 billion email accounts are covered by DMARC. RFC 7960 describes various methods by which, what it charmingly calls ‘indirect email flows’, can be prevented from wreaking untold havoc on email delivery to DMARC enabled recipients.
1. Single Domain Name using DKIM and SPF – Aggressive
just add to you DNS zone line:
_dmarc TXT ( “v=DMARC1;p=reject;sp=reject;pct=100; adkim=r;aspf=r;fo=1;ri=86400;rua=mailto:firstname.lastname@example.org”)
If you want do not be aggresive change policy p=reject; with p=none;