DMARC: how it works, setup and policy guide

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a security mechanism, specified in RFC 9989 , that works alongside SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) to help protect email domains from being used in phishing and spoofing attacks.

Implementing DMARC alongside SPF and DKIM allows domain owners to specify a policy as to how emails from their domain should be handled if the recipient server fails to validate and authenticate the checks performed by SPF and DKIM.

Why is DMARC Important?

Insecurely configured DMARC policies are commonly found during external penetration testing engagements. The main reason that DMARC is important is how it can help to protect your email domain from being used in phishing and spoofing attacks against your organisation, your customers, or others.

Essentially, consider DMARC to be a way to tell recipient email servers what to do if an email fails SPF or DKIM checks. It is a way to enforce your email authentication policies and ensure that only legitimate emails from your domain are delivered to recipients.

How Does DMARC Work?

The way DMARC works is by allowing a domain owner to publish a public policy that defines how their email recipients should handle emails that fail SPF and/or DKIM validation. This policy is published as a TXT record in the DNS settings for the domain (e.g. _dmarc.yourdomain.com).

There are a number of different configurations that can be set within a DMARC policy, which allows some flexibility with how strict the policy is, or to allow granular control over subdomains and reporting options.

A basic DMARC policy may look something like this:

v=DMARC1; p=quarantine; rua=mailto:example@yourdomain.com; ruf=mailto:example@yourdomain.com; fo=1; pct=100

In this example:

• v=DMARC1 specifies the version of DMARC being used.
• p=quarantine indicates that emails that fail DMARC checks should be treated as suspicious and placed in the recipient’s spam or junk folder. Other options include none (no action taken) and reject (emails that fail the DMARC checks are rejected outright).
• rua=mailto:... specifies the email address where aggregate reports should be sent. These reports provide information about how many emails passed or failed DMARC checks.
• ruf=mailto:... specifies the email address where forensic reports should be sent. These reports provide detailed information about individual emails that failed DMARC checks.
• fo=1 indicates that a forensic report should be sent if either SPF or DKIM fails.
• pct=100 indicates that the policy should be applied to 100% of emails from the domain. This can be configured to a lower percentage (e.g., pct=50) to gradually roll out the DMARC policy.

With the TXT record deployed, recipient email servers will check incoming emails against the DMARC policy and take the appropriate action based on the policy defined.

Each of the received emails contain a “From” header that indicates the domain that the email is purportedly from. The recipient server will check the SPF and DKIM records for that domain to see if the email passes either of those checks.

If the email fails both checks, the recipient server will then refer to the DMARC policy published in the DNS for that domain to determine how to handle the email.

Setting Up and Configuring a DMARC Policy

There are many more DMARC options in the form of a key-value pair that can be configured to suit your organisation’s needs. Below are the different options that can be set within a DMARC policy:

The fo option can be useful to help reduce the volume of forensic reports that are sent, especially when first implementing DMARC. For example, setting fo=1 will generate a report if either SPF or DKIM fails, whereas setting fo=0 will only generate a report if both checks fail.

This feature can be set to include multiple options by combining them with a colon (e.g., fo=1:d would generate a report if either SPF fails or if DKIM fails).

Whilst the recommended setting for this is fo=1, the full options for this are:

• 0: Generate a report if both SPF and DKIM fail.
• 1: Generate a report if either SPF or DKIM fails.
• d: Generate a report if DKIM fails.
• s: Generate a report if SPF fails.

Example DMARC Policies

Say you would like to implement a DMARC policy that does not implement any policy for the root domain, but applies a quarantine policy to all subdomains, and you would like to receive aggregate reports at example@yourdomain.com. Your DMARC record would look something like this:

v=DMARC1; p=none; sp=quarantine; rua=mailto:example@yourdomain.com;

As another example, if you wanted to implement a DMARC policy for strict SPF alignment, but not for DKIM, you could use the following DMARC record:

v=DMARC1; p=reject; aspf=s; adkim=r;

Moving from monitoring to enforcement

Starting immediately with p=reject risks breaking legitimate email delivery if SPF or DKIM are not yet correctly configured for every service that sends on your behalf. A staged rollout is the recommended approach to implementing DMARC:

1. Deploy with p=none first and set an rua address to receive aggregate reports. Monitor for at least a few weeks to build a complete picture of which sources send email from your domain.
2. Review the aggregate reports. Identify any services you did not expect, such as marketing platforms, CRMs, helpdesk tools, and similar. Ensure each legitimate sender has correct SPF or DKIM alignment before moving to enforcement.
3. Switch to p=quarantine, initially with a low pct value (for example, pct=10) to limit exposure. Increase the percentage gradually as you confirm that legitimate email is still being delivered correctly.
4. Move to p=reject once you have reached pct=100 with no delivery issues. At this point, emails that fail DMARC checks will be rejected outright by receiving servers.

Some organisations can move through these stages in a few weeks. Others may take longer, particularly those with multiple teams sending from the same domain through a range of platforms. Aggregate reports make the process more visible and manageable at a larger scale.

Benefits of Implementing DMARC

1. Protects Against Email Spoofing: DMARC helps prevent attackers from sending emails that appear to come from your domain, reducing the risk of phishing attacks and protecting your brand and domain reputation.
2. Improves Email Deliverability: By implementing DMARC, you can improve the deliverability of your legitimate emails, as recipient servers are more likely to trust emails that pass DMARC checks.
3. Provides Visibility: DMARC provides reporting features that allow domain owners to monitor email traffic and identify potential issues with email authentication.
4. Enhances Security Posture: Implementing DMARC is a proactive step towards enhancing your organisation’s overall security posture and protecting sensitive information.

What DMARC Cannot Do

Whilst DMARC is a strong addition to an existing security posture, it is a piece of a larger puzzle and not a single solution to email security. It requires both SPF and DKIM to be implemented correctly to be effective. If SPF and DKIM are not configured, but a DMARC policy exists, there’s a risk that outgoing emails could be flagged as failed.

DMARC cannot protect against all types of email-based attacks, such as those using similar looking domain names (e.g. microsoft.com and rnicrosoft.com) or attacks that do not involve email spoofing, such as malware or ransomware delivered through email attachments or links.

Additionally, DMARC does not protect against attacks that originate from compromised email accounts within your organisation. If an attacker gains access to a legitimate email account, they can send emails that can pass the SPF, DKIM, and DMARC checks.

What we find in penetration tests

During external penetration testing, DMARC misconfigurations are a consistent finding. The specifics vary between organisations, but the same patterns appear regularly.

Monitoring mode with no enforcement plan. The most common finding is a p=none policy that has been in place for months or years with no progress towards enforcement. A p=none policy does not prevent spoofing; it only records that it is happening. If your aggregate reports show no unexpected sending sources and your SPF and DKIM are correctly configured, there is no good reason to remain at p=none.

No aggregate reporting address. A DMARC record without an rua address generates no reports of policy failures. Without that data it is difficult to understand who is sending email on your behalf, or to confidently move to enforcement.

SPF or DKIM not aligned. DMARC requires at least one of SPF or DKIM to pass and be correctly aligned with the From: header. Third-party services, such as marketing platforms, CRMs, and transactional email providers, frequently send on behalf of a domain but are not included in the SPF record or do not sign with DKIM for that domain. This causes DMARC failures for those senders, either forcing the policy to remain at p=none to avoid breaking delivery, or causing legitimate email to be rejected once enforcement is in place.

Subdomains without explicit coverage. If the sp tag is not specified, subdomains inherit the root domain’s policy. This is often unintentional, particularly where subdomains are used for automated or transactional email and the sending configuration has not been fully reviewed as part of the DMARC rollout.