Domain-based Message Authentication, Reporting, and Conformance (DMARC) reduces 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.
Using DMARC with Email Security.Cloud
When you enable DMARC for a domain, inbound email to that domain is verified against the DMARC policy of the reported sender. If DMARC authentication passes, then the message is delivered normally. If DMARC authentication fails, then the message is quarantined, rejected, or delivered normally, according to the email sender's policy. If a message is from a sender on the approved senders list, then DMARC validation is bypassed even when DMARC is enabled.
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 authentication process
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. In relaxed mode, the [SPF]-authenticated domain and 5322.From domain must have the same Organizational Domain. In strict mode, only an exact DNS domain match is considered to produce Identifier Alignment. 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. For messages that fail validation, the reason for the failure is displayed on the Summary tab of the Track and Trace results. Messages that DMARC validates are listed in the Log View tab of the Track and Trace results.
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.
Enabling spoofed sender detection with DMARC
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.
Click Services > Email Services > Anti-Spam > Detection Settings.
Select Global Settings or select a domain from the drop-down list.
In the Spoofed Sender Detection section, check the Use DMARC check box.
Click Save and Exit.
Confirmation of the setting is displayed.
Adding a DMARC Record
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.
In this example, the sender requests that the receiver rejects all email that does not pass DMARC validation and send a report in a 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:
none: The Domain Owner requests no specific action be taken regarding delivery of messages.
quarantine: Mark affected messages as spam and quarantine into Spam Manager if available.
reject – Reject the message during the SMTP conversation.
|pct||Percentage of messages subjected to filtering||pct=20|
|ruf||Reporting URI for forensic reports||ruf=mailto:firstname.lastname@example.org|
|rua||Reporting URI of aggregate reports||rua=mailto:email@example.com|
|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. For the most current and update to date list, please refer to the DMARC Technical Specification.
Note: The steps required to publish a DMARC record depends on the DNS solution implemented for the domain. Refer to your DNS provider for more information.
Additional Resources to help implementing DMARC