Best Practices: Advancing Your DMARC policy

Though there can be a wide variation of size, complexity and stage of a DMARC project, they all share a common challenge of understanding when it’s appropriate to advance your policy. This guide will touch on key considerations, milestone validation tips, and DNS syntax guidelines necessary to help you confidently progress your domains to a stringent DMARC policy of p=reject.

DMARC Policies

First, a brief overview of DMARC policies; the sequence in which they are traditionally applied; and how they vary in protections against phishing, spoofing and unauthorized use of your domains:

• The three policy modes are none, quarantine and reject.
• These policies are most traditionally applied in the sequence listed above. Under certain circumstances, it may be appropriate to apply a more stringent policy at the beginning if, for example, you are applying DMARC to a parked or inactive domain.
• Organizations that receive your email, will look at the DMARC policy in your DNS as a means of honoring how you want your mail to be treated.
• Finally, the policies:
  • p=none is the first policy applied in a traditional DMARC project. “None” is used as a means of gaining full visibility into how your domain is being used without impacting or influencing how your email is treated by email receivers. It’s like telling Gmail or Yahoo, “don’t treat my email any differently than you ordinarily would, but please send me DMARC reports so I can make an informed decision about the rest of my project.” Plainly put, “none” provides zero protection but affords you the same visibility as the other, more restrictive policies.
  • p=quarantine is the second policy applied in a traditional DMARC project. The “quarantine” policy provides partial protections against unauthorized use of your domain and represents a significant milestone in a DMARC project. “Quarantine” instructs the email receiver that they should still accept the message but downgrade the trustworthiness of the email and place it into the recipient’s spam/quarantine folder.
  • p=reject provides the greatest amount of protection against unauthorized use of your domain. “Reject” instructs email receivers to outright block emails that fail the DMARC check. Unlike p=quarantine, with p=reject a message rejection notice is generated back to the sender. These blocking events are also made apparent in DMARC data so you can readily observe how many messages are rejected and by what email source.

Preparing for DMARC Policy Progression

Before you begin advancing DMARC policies, here are a few key considerations:

• Advancing your policy too soon, or without proper visibility, may result in blocked or degraded delivery of your legitimate email. You want to have an appropriate understanding of the DMARC standard as well as visibility into your email sources. We also recommend having a minimum of four weeks of data to react to.
• Bringing each of your legitimate email sources into DMARC alignment. Alignment refers to the relationship between the domain in the From Header address and the domains associated with SPF and DKIM records. Alignment requires that these domains match. Only emails that are aligned can pass DMARC.
• Interpreting your DMARC compliance percentage rate and how it should influence your DMARC policy progression. In most cases, upon reaching a 98% compliance rate or above, you can begin to advance your DMARC policy on a domain-by-domain basis. However, if there is an email source that you are aware of but choose not to bring it into alignment (possibly the vendor does not meet other internal policy/standards, etc.), you may very well be ready before the 98% mark.
  • Scenario: The IT security staff responsible for the DMARC project learns that someone within their organization is using a third-party email vendor to send shopping cart abandonment messages. This third-party email vendor was purchased by another team but failed to onboard the vendor according to the organization’s standards and policies established. This vendor is determined to be unauthorized to send on behalf of this particular organization. The IT security staff decides that they will continue to ramp up their DMARC policy, knowing full well that these unauthorized messages will be impacted.
• Be certain to socialize your DMARC project, the progress made, and provide a means for your colleagues to make an inquiry if they believe email is being affected.

The Role of DMARC’s Percentage Tag

While the pct tag is optional in a DMARC record, by gradually increasing the percentage, you can discover necessary actions and address them before establishing a 100% p=quarantine or p=reject DMARC policy. You’ll see our recommendations for pct tags in the section below.

If you don’t include the pct tag in a DMARC record, 100% is the default value; tag values range from 1% to 100%. Because p=none is a monitoring policy with no action taken on email flows, the pct tag is superfluous and should not be used with p=none.

Deliberate DMARC Policy Progression

The process of advancing a DMARC policy is a gradual one. Once you have your domains and email sources DMARC compliant, you can begin the process of advancing your policy from p=none to p=quarantine, then p=reject. You can also make good use of the optional percentage (pct) tag, affording you with finer control of your DMARC rollout.

After you have your domains and sources DMARC compliant, we recommend a risk-averse policy progression that looks like this:

When you advance your policies and increase pct tags, you want to pay close attention to your email flows to ensure that you have achieved and maintained a high rate of DMARC compliance. Generally speaking, a DMARC compliance rate above 98% per-domain is recommended.

To check the DMARC compliance rate of a particular domain, we recommend using the Detail Viewer and filtering for the domain(s) in question. As a reminder, DMARC compliance is achieved by configuring either SPF or DKIM to pass and align. The individual SPF-alignment or DKIM-alignment scores are not as important as the overall DMARC compliance rate.

The following is an example of a DMARC p=quarantine policy at 25%, where 25% of failing email will be moved to spam and the remaining 75% will be at p=none:

And here’s an example of a DMARC p=reject policy at 100%; the receiving server will reject all email that fails DMARC authentication:

What to Expect with a p=quarantine DMARC Policy

At p=quarantine enforcement, you are instructing receivers to send emails that fail the DMARC check to the local recipient’s spam folder. There are two important details to remember with this policy:

• The receiver is likely to accept these messages and treat them the same way as spam. If you are sending messages to a consumer-oriented mailbox (eg. gmail.com, hotmail.com, yahoo.com) these messages will be routed to the recipients own spam folder. If you are sending messages to a business-oriented mailbox (eg. Microsoft 365, Google Workgroups, Mimecast) these messages may be routed to a quarantine holding area managed by their IT staff. At no time will you have access to either of these environments to inspect what has been quarantined. The only exception is for mail destined for your own organization. DMARC platforms, such as dmarcian, should be used to help identify what mailstreams and at what frequency messages are being quarantined.
• The impact of p=quarantine is observed by the receivers. No notifications are sent to the senders; only the receivers will notice email suddenly being treated as spam or isolated into an email quarantine system. This signal exists in dmarcian’s Detail Viewer where we track the rate of mail getting quarantined or rejected to help you identify successes, gaps in authentication, and sending patterns.

Keep in mind that while the p=quarantine policy can help you gather data points and test your DMARC deployment, a policy of p=reject at 100% is the most secure state of domain protection and will prevent unauthenticated messages from being delivered from your domain. Even when there’s no DMARC in place, an email receiver will still do what it thinks is appropriate. Some fraudulent messages get rejected even without DMARC; when you deploy DMARC, you’re the one in control and making that determination and not leaving the decision with the receiver.

What to Expect with a p=reject DMARC Policy

This DMARC enforcement policy instructs the receiver to permanently reject the email. In many cases, a 5XX series hard bounce message is generated and communicated to the sending server.

To keep track of rejected messages, we recommend establishing a regular cadence of checking your DMARC data to discover pattern changes. The p=reject policy is the ultimate protection from unauthenticated email, including shadow IT and malicious email, originating from your domain.

Next Step: DMARC Maintenance

Once you have achieved your DMARC policy enforcement goal of p=reject, the next step is to establish a process for long-term management for DMARC compliance and to minimize potential problems related to your DMARC policy enforcement. The Life after Reject phase of the DMARC project is focused on preparing the organization for unexpected developments as well as planned changes. Here are some things to keep an eye on with the help of our DMARC Management Platform after reaching p=reject:

• Periodic checks of SPF records – Use our SPF Surveyor to ensure your SPF records are up-to-date by checking to see if any IPs or netblocks authorized to send email on behalf of the organization are in use or not. It’s always a good practice to review the contents of your record for vendors you no longer use or were added in error previously. This is referred to as over-authentication and is generally frowned upon by receivers.
• Process of approving SPF changes – Make sure no SPF changes are made without the approval of the DMARC project owner at your organization. Create alerts to notify you when any unexpected changes have taken place.
• Monitoring of periodic DKIM key rotation – DKIM keys should be rotated on a regular basis; this could be every few months or annually.
• Periodic check of DMARC data – Be sure to check for new sources of legitimate email. You can also launch other investigations such as tracking vendor consolidation opportunities, email volume changes, compliance regressions at a particular vendor, and unexpected delivery patterns.
• Reporting – Configure dmarcian to send reports about the use and abuse of your domains.
• Internal incident management – If there are email deliverability issues that are suspected to be DMARC-related, check for problems and solutions. You can get a much fuller picture by filtering DMARC data to understand the reach of the issue.

Read about the Life after Reject Phase of DMARC Management

dmarcian’s mission is to spread DMARC through the email ecosystem to make email and the internet safer. Advancing your DMARC policy to p=reject improves deliverability rates and stops criminals from using your domains for malicious purposes. Our progressive ramp up policy is a safe way to keep bad actors from picking up your domain.