What Is DMARC? Email Security Protocol Explained

Why DMARC exists

SPF and DKIM each address specific aspects of email authentication, but neither, on its own, tells receiving mail servers what to do when authentication fails. A message could fail SPF — meaning it was sent from an unauthorised IP — and most mail servers would still deliver it, perhaps with a reduced trust score. DMARC (Domain-based Message Authentication, Reporting and Conformance) completes the picture by providing a policy that instructs receiving servers explicitly how to handle authentication failures, and by feeding reporting back to domain owners.

DMARC was created by a coalition of major technology companies and email providers and published as an IETF standard (RFC 7489) in 2015. Adoption has grown significantly since then, particularly following Google and Yahoo's 2024 requirements for bulk email senders. The NCSC recommends DMARC implementation as a baseline email security control for all UK organisations.

How DMARC works

DMARC is published as a TXT record in your domain's DNS at the address _dmarc.yourdomain.co.uk. A typical DMARC record looks like:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.co.uk; ruf=mailto:dmarc-forensics@yourdomain.co.uk; pct=100

The key components are:

• v=DMARC1: Identifies this as a DMARC record
• p=reject: The policy — what to do with email that fails. Options are none (take no action), quarantine (send to spam), or reject (refuse delivery)
• rua=: The email address to receive aggregate reports — summaries of all email from your domain and authentication results
• ruf=: The email address for forensic reports — individual copies of failing messages
• pct=100: The percentage of failing email to apply the policy to. Starting at a lower percentage (e.g., pct=10) during rollout allows gradual implementation

DMARC alignment

DMARC introduces a concept called alignment: for DMARC to pass, the domain used in the SPF or DKIM check must align with the From header domain that recipients see. This closes a gap where an attacker might construct a message that passes SPF (from an authorised server for a different domain) but displays a spoofed From header.

There are two alignment modes:

• Strict alignment: The domains must match exactly
• Relaxed alignment (default): The authenticated domain can be a subdomain of the From header domain — mail.amvia.co.uk authenticating for amvia.co.uk would pass relaxed alignment

For most businesses, relaxed alignment is appropriate. Strict alignment is occasionally needed to prevent subdomain impersonation in high-security environments.

DMARC aggregate reports (RUA)

Aggregate reports are sent daily by participating receiving mail servers and provide a summary of all email from your domain, including: the sending IP addresses, whether SPF and DKIM passed or failed, which policy was applied, and the volume of messages processed. These reports are in XML format and require a DMARC reporting service or tool to parse into readable dashboards.

Services such as DMARC Analyzer, Postmark DMARC, Valimail and DMARCian provide free or low-cost reporting dashboards. Reading your aggregate reports during the initial DMARC rollout is essential — they reveal all the services sending email on behalf of your domain, including those you may have forgotten about or not intended to permit.

The rollout process

Jumping directly to p=reject is risky without preparation, as it can block legitimate email from services that are not yet properly authenticated. The safe rollout process is:

1. Configure SPF and DKIM for all legitimate sending sources
2. Deploy DMARC with p=none and configure RUA reporting
3. Review aggregate reports over 2-4 weeks to identify all sending sources and their authentication pass rates
4. Resolve any SPF or DKIM failures on legitimate sources
5. Advance to p=quarantine (initially at low pct, increasing to 100%)
6. Monitor for false positives over 2-4 weeks
7. Advance to p=reject

The entire rollout typically takes 6-12 weeks. Attempting to shortcut this process frequently results in legitimate email being blocked and pressure to revert to p=none.

DMARC and subdomain policy

By default, a DMARC policy applies to the exact domain and its subdomains. The sp= tag allows a separate policy for subdomains. This is relevant for organisations that use subdomains for different purposes (marketing email from mail.domain.co.uk, transactional email from notify.domain.co.uk) and want different policies to apply.

AMVIA configures DMARC from initial deployment through to p=reject enforcement for UK businesses, managing the reporting analysis and SPF/DKIM remediation that a safe rollout requires.