Domain-based Message Authentication, Reporting, and Conformance (DMARC) reduce email spam by detecting sender spoofing, which helps thwart phishing attempts that employ this spoofing method to penetrate an organization's defenses. DMARC standardizes how email recipients perform SPF and DKIM email authentication, and specifies appropriate actions if authentication fails.
Organizations can publish a DMARC policy that indicates that their emails are protected by SPF or DKIM authentication or both. The DMARC policy also tells a recipient what to do if neither of these authentication methods passes.
When you enable DMARC for a domain, inbound email to that domain is verified against the DMARC policy of the reported sender.
DMARC senders can choose to use the policy percentage tag (pct) in their policies, which allows senders to phase in and fine-tune their DMARC validation. The pct option allows senders to stipulate that only a certain percentage of messages that meet a particular criterion will have the specified action applied to them. For example, if the sender's policy includes the name-value pair reject, pct=10, then only ten percent of the messages that fail validation are rejected.
When it is enabled, quarantine is provisioned for all domains in that account. You cannot provision quarantine for a subset of domains in an account. If quarantine is enabled for one of your domains, and the sender's DMARC policy is quarantine, then messages that fail DMARC validation are quarantined for all of your domains. If the senders use the pct tag in their policies, then only the specified percentage of messages that fail DMARC will be quarantined.
Note: If the sender's policy is to quarantine the message but you do not have quarantine provisioned, then you must either enable quarantine or specify Subject Line Text to indicate that this message may be spam.
DMARC requires that a message not only pass DKIM or SPF validation, but also that it passes alignment.
To pass alignment for SPF, the message must pass the SPF check. Also, the domain in the 5322.From header must also match the domain used to validate SPF.
DMARC uses the result of SPF authentication of the 5321.MailFrom identity.
To pass alignment for DKIM, the message must be signed with a valid signature. Also, the d= domain of the valid signature must align with the domain in the 5322.From header. The domain must exactly match for strict alignment, or must share the org name for relaxed alignment. DMARC validation ignores DKIM signatures with fewer than 1024 bits because such signatures are too easily forged.
DMARC authentication results and actions (quarantine, reject, or deliver normally) are displayed on the Email AntiSpam tab's Spam Dashboard Summary. Results and actions are also included in the Email AntiSpam's Summary and Detail reports.
Note: DMARC provides a way for the email recipient to report back to the sender about the messages that pass or fail DMARC evaluation. This reporting functionality is not currently supported. However, the fact that reporting is not supported does not affect the ability of the recipient to do inbound authentication.
To perform its validation, DMARC consults authentication data from the sender, performs SPF and DKIM validation, and then adds the result to the message header as Authentication-Results. This information is added to message headers for the messages that are delivered normally as well as for those that are quarantined. Administrators can make use of this header information for ad hoc reporting or analysis.
You can enable DMARC for some or all of your domains. You cannot exclude specific senders from DMARC authentication, except by adding them to your Approved Senders list. You cannot enable DMARC for individual groups or users; you can only enable it at the domain level.
You can help prevent spoofing of your own domain by implementing a DMARC policy for your domain(s). A DMARC record is a TXT resource record published in DNS in a specifically defined subdomain. For example: _dmarc.example.com.
The record syntax consists of a tag and a value. Below is an example of what a DMARC record may look like.
"v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]"
In this example, the sender requests that the receiver rejects all email that does not pass DMARC validation and send a report in an aggregate format about the rejection to the specified email address. DMARC records follow a "tag-value" syntax and the following chart illustrates some of the available tags. From these, only the v (version) and p (policy) tags are required for the record. 3 possible policy (p tag) values are available:
Tag Name | Purpose | Sample |
v | Protocol version | v=DMARC1 |
pct | Percentage of messages subjected to filtering | pct=20 |
ruf | Reporting URI for forensic reports | ruf=mailto:[email protected] |
rua | Reporting URI of aggregate reports | rua=mailto:[email protected] |
p | Policy for organizational domain | p=quarantine |
sp | Policy for subdomains of the organizational domain | sp=reject |
adkim | Alignment mode for DKIM | adkim=s |
aspf | Alignment mode for SPF | aspf=r |
This table is not meant to be a comprehensive list of tags and their values. Please refer to the DMARC Technical Specification for the most current and updated date list.
Note: The steps required to publish a DMARC record depend on the DNS solution implemented for the domain. Refer to your DNS provider for more information.