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.

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, 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.

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 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:

• none: The Domain Owner requests no specific action be taken regarding the delivery of messages. This will cause no action to be taken even if there is a hard fail set for SPF.
• quarantine: Mark affected messages as spam and quarantine them into Spam Manager if available.
• reject – Reject the message during the SMTP conversation.

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.

Additional Resources to help to implement DMARC

• Implement SPF records in Email Security.cloud
• Configuring DKIM signing for outbound Email Security.cloud
• DMARC Homepage
• DKIM Homepage