DMARC Tags Explained: A Field-by-Field Breakdown

A DMARC record looks deceptively simple: a single line of text published in DNS. But that line is made up of several distinct DMARC tags, each controlling a different piece of behavior, from how strictly failures are enforced to where reporting data gets sent to whether alignment needs to be strict or relaxed. Misunderstanding even one of these tags can mean the difference between a record that quietly does nothing and one that starts rejecting legitimate mail—or causing a DMARC failure for valid email messages.

How a DMARC Record Is Structured

A DMARC record is published as a TXT record at a specific subdomain, _dmarc.yourdomain.com, and follows a tag=value; format, with semicolons separating each pair. Email receivers discover the record through DNS lookups and DMARC record requests. A typical record might read: v=DMARC1; p=quarantine; rua=mailto:reports@yourdomain.com; pct=50; adkim=r; aspf=r.

The v tag, short for version, is required and must be the first tag in the record, always set to DMARC1. Every other tag is technically optional, though in practice a record without at least a policy tag and a reporting address provides little practical value for a successful DMARC implementation.

DMARC Tags at a Glance

Among all DMARC tags, p is the core policy directive, telling receiving mail servers what to do with messages that fail DMARC alignment. Three values are available: none, which takes no enforcement action and simply allows reporting to happen; quarantine, which asks receiving servers to treat failing messages with suspicion, typically routing them to spam; and reject, which asks receiving servers to refuse failing messages outright. This helps protect a brand from spoofed and fraudulent messages.

The sp tag allows a different policy to apply specifically to subdomains, separate from the primary domain's p value. Without an explicit sp tag, subdomains inherit the policy set by p. The pct tag controls what percentage of failing messages the specified policy applies to, expressed as a number from 1 to 100, useful during the transition from none to a stricter policy.

Reporting Tags: rua, ruf, fo

The rua tag specifies where aggregate reports should be sent, formatted as one or more mailto: addresses. Of all DMARC tags, this is the one responsible for the daily or near-daily summary data that most monitoring relies on. These DMARC aggregate reports provide visibility into authentication results and help identify sources contributing to a DMARC failure.

The ruf tag specifies where forensic reports, containing details about individual failing messages, should be sent. A forensic report can provide more granular information about a specific DMARC failure. Forensic reporting support has become significantly more limited across major mailbox providers over time, largely due to privacy considerations. The fo tag controls the conditions under which forensic reports get generated, for providers that support them.

Alignment Tags: adkim, aspf

Alignment is the mechanism that distinguishes DMARC from SPF and DKIM operating independently. The adkim and aspf tags, among the more misunderstood DMARC tags, control how strict that alignment requirement is.

Set to r, for relaxed, which is the default if unspecified, alignment allows the authenticated domain to be an organizational match with the From domain. Set to s, for strict, the domains must match exactly, with no subdomain flexibility permitted. Strict alignment offers tighter security but requires more careful coordination with any third-party senders using subdomains.

Common Tag Configuration Mistakes

A few mistakes involving DMARC tags show up repeatedly, and most are avoidable with careful review before publishing:

1. Missing or malformed semicolons, which can cause a record to be ignored entirely by receiving servers rather than partially applied.
2. Jumping straight to a strict policy without a reporting period, risking rejection of legitimate mail from sources that weren't properly identified in advance.
3. Omitting the rua tag entirely, even at a policy of none, which forfeits the visibility that makes DMARC valuable in the first place.
4. Inconsistent policy between root domain and subdomains, without a deliberate sp tag, leading to unexpected enforcement.

Frequently Asked Questions

What's the minimum viable set of DMARC tags?

At minimum, a functional record needs v=DMARC1 and a p tag. In practice, adding a rua tag is strongly recommended even at this minimal stage, since without reporting, there's no visibility into whether the policy is having any unintended effect.

Can I have different DMARC policies for different subdomains?

Yes, using the sp tag to set a subdomain-specific policy that differs from the root domain's p value. This is one of the more useful DMARC tags for organizations with subdomains serving distinct purposes.

Is strict alignment always better than relaxed alignment?

Not necessarily. Strict alignment offers tighter protection, but it requires that all legitimate sending infrastructure precisely matches the From domain, which isn't always practical. Relaxed alignment, the default, is a reasonable starting point for most domains.

How do I safely move from p=none to p=reject?

Gradually. Start with none and use rua reporting to confirm every legitimate sending source is authenticating correctly. Move to quarantine with a low pct value, monitor for any unexpected impact, and increase pct incrementally before finally moving to reject.

Learn how Mailora helps you monitor DMARC tags, dmarc record requests, and reporting data together, so moving toward stronger enforcement never means guessing.