DMARC is an essential mechanism to prevent abuse of your domain. Sometimes, DMARC compliance can be hard.

In this article, we’ll introduce the most common strategy to reach full DMARC compliance, with the strictest configuration.

Read What is DMARC? for an introduction to email authentication and the main concepts around DMARC.

At a high level, the steps to rollout DMARC should be:

  • Start collecting DMARC reports to evaluate your current compliance level, while keeping the DMARC policy set to none.
  • Review the reports through the DMARCwise dashboard or through weekly email digests, to identify sources that are non-compliant or only partially compliant.
  • Try to reach alignment on both SPF and DKIM (and therefore DMARC) for all your sending sources.
  • Monitor your compliance level for at least a few weeks.
  • Start changing the DMARC policy, setting it to quarantine or reject for a subset of messages, and monitor if something goes wrong through the DMARCwise dashboard.
  • Complete the setup by setting the policy to reject for 100% of messages.
  • Finally, keep monitoring your DMARC compliance level through weekly email digests.

Let’s go through these steps in more detail.

Collecting the reports

To start collecting reports, you need to add a DMARC DNS record to your domain.

For DMARCwise, the _dmarc record of type TXT looks like this:

v=DMARC1; p=none; rua=mailto:rua+[token]@dmarcwise.email;

Don’t use this example record: you must use your domain-specific record taken from the DMARCwise dashboard. Read Adding your first domain for more details.

This DMARC record specifies a policy (or disposition) of none: it means that no action will be taken by email receivers in case of DMARC failures, so there’s no risk of your emails being rejected or marked as spam because of this new DNS record.

The record also includes the rua tag, which specifies where the aggregate email reports should be delivered. In this case, it’s an email address managed by DMARCwise.

Note that this DMARC policy also applies to all the subdomains of your domain.

Once you’ve added the record, DMARCwise will start receiving the reports (which are usually daily reports) in XML format, parse them and make them available in the dashboard.

Reviewing the reports

After a few days, depending on how much emails you send, there should be enough data to populate the dashboard.

Select your domain in the DMARCwise dashboard and switch to the Reports tab .

DMARCwise dashboard

DMARCwise automatically gives friendly names to the most popular sources (like “Outlook”), to identify them more easily.

It will also group the sources in categories: authorized sources, forwarded/unaligned sources, and non-compliant sources.

Your task in this phase is to identify and focus on the sources that belong to you. If your email sending configuration isn’t completely broken, you should find them in the Authorized sources section.

Be careful that you must take into consideration all your sending sources. This includes not only the email provider that you use for your inboxes (e.g. Google Workspace, Microsoft 365 or your on-premises servers), but also other services that send email with your domain as the sender, like newsletter tools (Mailchimp, Brevo, HubSpot, Mailerlite etc.) or your hosting provider.

Fixing authentication issues

Once you’ve identified your sources, you have to make sure that there are no authentication issues with them.

This means that both SPF alignment and DKIM alignment should ideally be 100% or very close to 100%.

You can achieve this by making sure that:

  • SPF is pass, meaning that you have a proper SPF record on your domain authorizing the source mail servers.
  • SPF is aligned, meaning that the Envelope From (or Return-Path) contains your domain name.
  • DKIM signatures are valid.
  • At least one DKIM signature is associated to (and therefore aligned with) your domain.

Fixing SPF and DKIM authentication issues

There’s no single solution to fixing these authentication or alignment issues, it really depends on how you send email and which services you rely on.

You can find more practical information and instructions for the most popular email providers on DMARC.wiki, our directory of email providers and their DMARC compliance level.

To gather more information in the DMARCwise dashboard:

  • Click on a source in the DMARCwise dashboard: you’ll be able to see important identifiers like the envelope from and the DKIM signatures domains.
  • Run a diagnosis to quickly get up-to-date and detailed information about SPF, SPF alignment, DKIM signatures and DKIM alignment.

Here are some quick tips on what you should be looking for to fix the issues:

  • For SPF, what you usually need to do is enable a custom Return-Path, or custom Envelope From or custom MAIL FROM. These are all the same thing, there are many names. Read more in Introduction to SPF.
  • For DKIM, look for a way to enable custom DKIM signatures specific for your domain.

Monitoring your compliance level

Keep monitoring the DMARC reports dashboard to see if your changes had an impact.

After making changes you should wait at least two weeks, but in practice the time you should wait depends on how complex your email setup is.

Take into consideration that there might be services that send emails very rarely and overlooking those could have catastrophic consequences.

For example, during a famous GitLab outage in 2017 the company discovered that their main backup had been failing for a while, but they never got notified because the notification emails were being rejected as requested by their DMARC policy!

You must spend some time thinking if you considered all your sending sources before proceeding further.

Gradually enforcing a DMARC policy

Once you know, thanks to the reports, that your sending sources are fully DMARC compliant, you should start thinking of enforcing a stricter DMARC policy.

Don’t hurry this step. You’ll risk your email being rejected or being marked as spam if you don’t get this right.

Your DMARC record should still look like this:

v=DMARC1; p=none; rua=mailto:rua+[token]@dmarcwise.email;

A first step might be to set the policy (or disposition) to quarantine for a subset of messages. “Quarantine” means that a failing message should be treated as suspicious. Most of the time this leads to the email being moved to the spam folder.

For example, the following record applies the quarantine policy to 10% of all the messages received by a server (the policy is executed only on messages that fail alignment checks, obviously):

v=DMARC1; p=quarantine; pct=10; rua=mailto:rua+[token]@dmarcwise.email;

Be careful that the pct tag must come after the p tag, and its value must not include the % symbol. Also, make sure you spell quarantine correctly: it shouldn’t be translated in other languages, as it’s often seen online.

If you leave out pct, the policy will be applied to 100% of the messages.

For a stricter handling, you may consider using reject directly. Under this policy, non-compliant messages will be rejected by receiving mail servers (or at least should be rejected, the DMARC specification isn’t strict about this).

Possible DMARC enforcement strategies

There are many possible paths to reach the strictest DMARC configuration.

For an extra careful approach, you might choose to:

  • Set p=quarantine; pct=10; for a few days, then increase the percentage up until 100%.
  • Start with 10% if you have a low volume of messages, or use a lower percentage like 1% if you send many emails (hundreds of thousands or millions per month).
  • When you reach 100% and see no legitimate mail being quarantined, you’re ready to switch to reject (next step of this guide).

A variation would be to enforce the policy only on the main domain and not on subdomains:

  • You can do that with the sp tag, like this: p=quarantine; sp=none; pct=10;.

If you’re confident you’re doing the right thing, you could also follow a more drastic approach:

  • Set p=reject; pct=50;.
  • Monitor the results and after a few days switch to fully reject (next step of this guide).

Summary of DMARC policies

Here’s a summary of all the policies supported by DMARC:

  • none: no action should be taken by mail servers on incoming messages failing alignment checks. Messages are accepted, or at least not penalized by DMARC checks.
  • quarantine: treat messages failing DMARC checks as suspicious. Most of the time this leads to the email being moved to the spam folder.
  • reject: the mail server should reject a message failing DMARC checks. Note that it’s not mandatory for mail servers to reject (and bounce) the message: they could also just treat the message as highly suspicious.

Enforcing the reject policy

While you change the policy to be increasingly stricter, you’ll be able to monitor the effects in the DMARCwise dashboard.

We extract the number of emails that got quarantined or rejected from the raw reports and present them in the dashboard:

DMARCwise dashboard showing the disposition stats

If you don’t see significant changes in these numbers, it likely means you’re ready to enable the strictest DMARC policy, which would look like this:

v=DMARC1; p=reject; rua=mailto:rua+[token]@dmarcwise.email;

There’s no need to specify pct=100;, as 100% is the default value.

Continuous monitoring

At this point, you’ve reached the strictest DMARC configuration.

Congratulations! Many companies don’t monitor their DMARC configuration as you just did.

Next steps:

  • Every Monday you’ll receive an email digest from DMARCwise.
    • These digests contain a summary of the previous week of email activity, so make sure you take a look at them. It’s the easiest way to spot new issues that might arise.
    • Mail sending configurations may change with time and you don’t want to miss email rejections.
  • When you add a new source or change email provider, carefully consider the impact of the operation:
    • Running a diagnosis is a good way to ensure that email sending from the new source works correctly.
    • If you’re changing your email setup in a radical way (e.g. you’re moving to an on-premises deployment with several servers), consider going back to a more relaxed DMARC policy if you’re not certain that everything’s configured correctly.