DMARC

What is a DMARC record?

DMARC, which stands for Domain-based Message Authentication, Reporting, and Conformance, is a policy framework that works alongside SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) to provide enhanced email authentication and protection against email spoofing and phishing attacks. DMARC helps domain owners specify how email servers should handle messages that fail SPF or DKIM checks.

To learn more about DMARC see dmarc.org.

How does DMARC work?

• Alignment: DMARC requires both SPF and DKIM to be in place. It checks for alignment between the “From” domain in the email’s header, the domain used in the SPF record, and the domain used in the DKIM signature. All three domains must match or align properly for DMARC to consider the email authenticated.
• DMARC Policy: The domain owner publishes a DMARC policy in their DNS settings. This policy indicates how receiving email servers should treat emails that don’t pass SPF or DKIM authentication. The policy can instruct the recipient server to either quarantine the message, mark it as spam, or reject it entirely.
• Reporting: DMARC also provides a reporting mechanism that allows domain owners to receive feedback from email receivers about the authentication results of their emails. These reports provide information about which emails passed or failed DMARC checks and how they were handled by recipient servers.

What are the benefits of DMARC?

By implementing a DMARC policy, domain owners can achieve several benefits:

• Improved Authentication: DMARC ensures that only legitimate emails from authorized senders are delivered, reducing the risk of phishing and spoofing attacks.
• Visibility: The reporting feature of DMARC provides insights into how email traffic is being handled across different receiving servers, helping domain owners identify unauthorized senders and authentication issues.
• Enhanced Reputation: Properly configured DMARC policies can contribute to a domain’s reputation, as it demonstrates a commitment to email security.

It’s important to note that implementing DMARC can be complex, especially for larger organizations. It requires careful configuration of SPF and DKIM records, as well as understanding the potential impact of policy settings on email deliverability. It’s recommended to gradually roll out DMARC policies, starting with a monitoring-only mode to gather data and ensure that legitimate email sources are properly aligned before moving to a stricter enforcement policy.

What are DMARC tags?

A DMARC record is made up of required and optional tags.

An example of a basic DMARC record:

v=DMARC1; p=quarantine; pct=100; rua=mailto:security@yourdomain.com

Required tags

The following tags must be included in a DMARC record for it to be valid:

• v – Always DMARC1 and listed first. It identifies the record as DMARC .

• p – The DMARC policy for the record that email providers use when your email fails DMARC authentication and alignment checks.

There are three DMARC policies that you can set:

• p=none – Not recommend. Also known as the monitor policy, it allows you to track emails but instructs the email provider to do nothing if there is a DMARC alignment or authentication issue.
• p=quarantine – Recommended. Tells the email provider to send the message to the junk folder if it fails the DMARC check. It also tracks all of the emails that are sent on your behalf.
• p=reject – Tells the email provider to reject all emails that fail DMARC authentication and alignment. It also completely prevents the delivery of the email and tracks all emails sent on your behalf.

We recommend implementing strict policies with quarantine as the minimum applying to 100% of emails.

Optional, but recommended tags

These additional tags provide additional options for tailoring your DMARC record:

• fo – It lets email providers know to send samples of the text sent in the emails that failed SPF or DKIM. There are four options:
  • 0 – Send a report if both SPF and DKIM fail to generate an aligned PASS result. This is the default.
  • 1 – Send a report if the SPF or DKIM record generates any other type of alignment result that is not PASS. This is recommended.
  • d – Send a report if the email’s signature failed its evaluation, despite the alignment’s result.
  • s – Send a report if the email’s SPF failed its evaluation, despite the alignment result.

• ruf=mailto:address@domain.com – The email address where more detailed forensic reports should be sent to by mailbox providers.
• ri – The number of seconds between sending reports by email providers. The default is 86400 (24 hours).
• adkim – Whether the DKIM identifier alignment is strict or relaxed. The default is relaxed.
• aspf -Whether the SPF identifier alignment is strict or relaxed. The default is relaxed.

Tags that can be ignored for now

We’ll update this when changes are made, but for now they can be ignored.

• rf – The format for message failure reports. The default is afrf (Authenticate Failure Reporting Format), which is the only value supported for now.