What DMARC is:
DMARC is a mechanism that uses the email authentication protocols DKIM and SPF to ensure that the use of a domain in the “From” line of an email message, or the sender address, is authorized by the domain owner. A domain owner announces that a domain’s authorized usage can be validated by publishing a specially formatted TXT record in the DNS.
What DMARC does:
- DMARC is designed to prevent unauthorized use (spoofing) of the domain in the “From” line of an email message. When domains participate in DMARC, any site that receives an email message, or the receiving site, can apply the DMARC mechanism to validate whether the domain owner authorized its usage.
- DMARC lets domain owners request that email messages that do not pass DMARC validation checks be routed to the spam folder (quarantined) or rejected entirely. A receiving site can use this handling request to inform its decision for disposition of such messages.
- DMARC also provides a method for domain owners to receive emailed reports from receiving organizations. These reports contain aggregate data about DMARC validation results for those messages that use the domain in the sender address.
What DMARC does not do:
- DMARC does not attest to the legitimacy or quality of the message content or sender. A DMARC pass only means that the use of the domain in the message’s “From” line was authorized by the domain owner.
- Because it relies on DKIM and SPF, DMARC is subject to the same fragility as these protocols as it relates to message alteration and indirect message flows, such as forwarding and mailing lists.
- DMARC does not prevent abuse using “lookalike” or “close cousin” domains. For example, a bank might protect its “bigbank.com” domain with DMARC, but this by itself will not prevent bad actors from using “b1gbank.com” or similar spoofing tactics.
- DMARC does not prevent “display name” attacks, where the attacker sends email using an arbitrary domain and a well-known or trusted name in the display name, such as in this example:
From: “Big Bank” <badguy@example.com>
References:
- Domain-based Message Authentication, Reporting, and Conformance (RFC 7489)
- Proposed updates to RFC 7489 (DMARCbis)
- Sender Policy Framework (RFC 7208)
- DomainKeys Identified Mail Signatures (RFC 6376)
- M3AAWG Email Authentication Recommended Best Practices
- M3AAWG Protecting Parked Domains Best Common Practices
- M3AAWG Technology Summaries - SPF
- M3AAWG Technology Summaries - DKIM
1