Guide to DMARC compliance

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.

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.
• Depending on the complexity of your setup, gradually change the DMARC policy from none to quarantine, and finally reject. While doing this, monitor DMARC failures and message dispositions through the DMARCwise dashboard to ensure that the policy is not harming deliverability.
• 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 daily reports from mail receivers 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 Sources tab .

DMARCwise automatically assigns 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 are legitimate. If you’ve done a good job in setting up email authentication, you should find these sources in the Authorized sources section.

It’s important to understand 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, ensure that there are no authentication issues with them.

This means that both SPF alignment and DKIM alignment should ideally be as close as possible 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.

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 a week or two, but in practice this period depends on how complex your email setup is.

Take into consideration that there may be services that send emails very rarely in your organizations. 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 your sending sources are DMARC compliant, it’s time to start enforcing a stricter DMARC policy.

You can choose between two policies:

• quarantine, which means that messages failing DMARC should be treated as suspicious. Most of the time, this leads to the message being moved to the spam/junk folder.
• reject, which asks receiving mail servers to reject failing messages. Mail servers are not strictly required to reject failing messages and often use this as a signal of suspect among many. Nonetheless, p=reject is the strictest policy available.

A first step may be to set the policy to quarantine, like this:

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

Optionally, you can use the pct tag to have the policy applied only to a portion of the messages, like so:

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

Note that the pct tag is applied inconsistently by mail servers and is now deprecated. In many cases, it won’t work as expected. You can alternatively consider using the t (testing mode) tag, which is however less granular.

After making changes to a DMARC record, keep an eye on the DMARCwise dashboard. You’ll be able to quickly see:

• If the DMARC record is still syntactically valid after the change.
• The effect of the new policy on the delivery of messages. Look at the quick disposition stats or use the Explorer tab to filter by Disposition (applied policy). Check if legitimate email flows are being blocked as a result of the new policy.

You can also choose to enforce the policy only on the domain where the policy is published and not on subdomains, with the sp tag. For example, if the following DMARC record is published on example.com, messages will be quarantined when sent from example.com while no policy will be applied to messages sent from subdomains such as marketing.example.com:

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

Depending on the email volume and complexity of your email setup, you can come up with your own enforcement strategy: you can start with p=quarantine, you can use message sampling (pct), you can be more drastic and jump straight to p=reject, etc.

Enforcing the reject policy

Most of the time, the final aim is to reach the so-called enforcement mode, where your DMARC record publishes a p=reject policy.

Once you’re ready, change your DMARC record to have p=reject in it, like so:

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

A note on mailing lists

In most cases, enforcing the reject policy is the result you should aim at. Unfortunately, this configuration doesn’t work well when mailing lists are involved.

When sending messages to a mailing list (a service that forwards your email to many other users), it’s likely that both SPF and DKIM will fail, causing email rejections and possibly interfering with other mailing lists members too.

If your organization uses mailing lists, think twice about enforcing DMARC. You have a few options:

• Check with the mailing lists you use if they have workarounds in place to avoid rejections caused by DMARC. For example, the popular Mailman software can be configured to mitigate this issue.
• Consider using a dedicated domain or subdomain for emails sent to mailing lists, and keep DMARC in monitoring mode (p=none) on that domain.
• If the other solutions aren’t applicable, avoid enforcing DMARC for now. There are standardization initiatives underway to address this issue (DKIM2).

Next steps: continuous monitoring

Congratulations! By actively monitoring and refining your DMARC setup, you’ve taken an important step toward protecting your domain from email spoofing.

However, DMARC compliance isn’t a one-time task. Email providers, sending sources, and authentication configurations can change over time, potentially causing legitimate messages to fail DMARC.

To keep your domain protected without disrupting legitimate email, continue monitoring your DMARC reports:

• Review your weekly email digest. Every Monday, DMARCwise will send you a summary of the previous week’s email activity. Check it for new authentication issues or unexpected rejections.
• Review changes to your email setup. When adding a sending source or changing email providers, run a diagnosis to verify that the new configuration passes DMARC.
• Temporarily relax your policy when necessary. Before making major changes to your email infrastructure, consider switching to a less restrictive policy until you’ve confirmed that every legitimate sending source is correctly configured.