Decoding DMARC Tags: A Deep Dive Into p, sp, rua, and ruf

Understanding dmarc tags explained thoroughly is essential for taking control of your domain's email deliverability and stopping spoofing attacks in their tracks. A Domain-based Message Authentication, Reporting, and Conformance (DMARC) record is simply a DNS TXT record that tells receiving mail servers what to do when an incoming email fails SPF (Sender Policy Framework) or DKIM (DomainKeys Identified Mail) checks. Without properly configured tags, your domain remains vulnerable to phishing, and your legitimate emails might land in the spam folder.

To see how your current domain configuration stacks up right now, you can use the DMARC Checker to instantly validate your record syntax and spot missing mandatory tags. Let's dive deep into the core mechanics, exact syntaxes, and best practices for setting up every DMARC tag.

The Anatomy of a DMARC Record

A DMARC policy lives in your DNS zone as a TXT record. The host name for this record must always be _dmarc.example.com, where example.com is your actual domain name. Every DMARC record starts with the mandatory protocol identifier tag v=DMARC1, followed by a series of semicolon-separated tags that dictate policy and reporting behavior.

Here is a production-ready DMARC record example:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc-reports@example.com; pct=100"

Every tag serves a specific function in guiding receiving mail servers on authentication alignment and forensics.

Core DMARC Tags Breakdown

The Version Tag (v)

The version tag is mandatory and must always appear as the very first tag in your DMARC record.

• Syntax: v=DMARC1
• Purpose: Identifies the TXT record as a DMARC policy. Receiving servers will ignore any record that does not start with this exact string.

The Policy Tag (p)

The policy tag tells mail servers how to handle emails that fail DMARC authentication for your primary domain.

• Syntax: p=none | p=quarantine | p=reject
• Purpose: Defines your enforcement level.

Policy Value	Action on Failure	Best Use Case	Risk Level
p=none	Deliver normally, send reports	Initial monitoring phase	Zero risk of blocking legitimate mail
p=quarantine	Send to spam/junk folder	Intermediate phase	Low risk, some false positives go to spam
p=reject	Block the email entirely at SMTP level	Full enforcement phase	High if misconfigured, maximum security

The Subdomain Policy Tag (sp)

By default, the policy set in p= applies to your root domain and all subdomains. However, you can override this behavior for subdomains.

• Syntax: sp=none | sp=quarantine | sp=reject
• Purpose: Sets a distinct DMARC policy specifically for all subdomains (e.g., mail.example.com) without altering the root domain policy.

Aggregate Reporting Tag (rua)

Data is your best friend when moving a domain from monitoring to enforcement. The rua tag specifies where mail servers should send daily XML aggregate reports.

• Syntax: rua=mailto:reports@example.com
• Purpose: Collects daily summaries of all email traffic claiming to be from your domain, showing passing and failing authentication sources. You can specify multiple comma-separated URIs, though they must all use the mailto: scheme.

Forensic Reporting Tag (ruf)

While aggregate reports give you statistical summaries, forensic reports provide near real-time, copy-and-paste details of individual failing messages.

• Syntax: ruf=mailto:forensics@example.com
• Purpose: Instructs servers to send individual failure reports for messages that fail DMARC. Note that many mailbox providers truncate or omit forensic reports due to privacy regulations like GDPR, making rua much more reliable.

Advanced DMARC Tags

Beyond the core policy and reporting settings, several modifier tags let you fine-tune how mail servers process your domain's authentication.

Percentage Tag (pct)

The percentage tag allows you to gradually roll out enforcement policies rather than hitting your entire traffic volume at once.

• Syntax: pct=20
• Purpose: Applies the p= policy to only a specified percentage of failing messages. For example, p=reject; pct=20 means 20% of failing emails are rejected, while the remaining 80% are only monitored or quarantined. This tag is only valid with p=quarantine or p=reject.

Alignment Mode Tags (aspf and adkim)

DMARC relies on identifier alignment between the sender address in the From: header and the domains used in SPF and DKIM checks.

• Syntax: aspf=r | aspf=s and adkim=r | adkim=s
• Purpose: Sets alignment mode to relaxed (r, the default) or strict (s). Relaxed mode allows subdomains to match the organizational domain, while strict mode requires an exact, character-for-character match between the From: domain and the signing domain.

Step-by-Step Implementation Guide

Moving your domain from zero protection to full rejection requires a methodical, step-by-step approach to avoid breaking legitimate email flows.

Step 1: Audit and Fix SPF and DKIM

Before adding any DMARC record, ensure your SPF record is valid and your email service providers are correctly signing messages with DKIM. Test your SPF record using command-line tools:

nslookup -type=txt example.com

Step 2: Deploy a Monitoring Record

Start with a p=none policy to collect data without impacting delivery. Log into your DNS provider's management console (names may differ slightly such as DNS Manager, Zone Editor, or DNS Hosting) and create a TXT record:

• Host/Name: _dmarc
• Type: TXT
• Value: v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com;

Step 3: Analyze Reports and Transition

Review your incoming XML aggregate reports for two to four weeks. Identify any third-party services sending mail on your behalf that lack proper SPF or DKIM setup. Once all legitimate sources pass alignment, update your policy tag to quarantine:

v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@example.com;

Step 4: Enforce Full Rejection

After a week of clean quarantine metrics, graduate to full protection:

v=DMARC1; p=reject; rua=mailto:dmarc-rua@example.com;

Common Mistakes and How to Fix Them

• Syntax Typos: Misspelling tags like writing policy=reject instead of p=reject will cause receivers to ignore your record entirely. Always double-check tag names.
• External Reporting Without Consent: If you send rua reports to an external domain (e.g., partner.com), that domain must publish a DMARC external destination verification record permitting your domain to send reports to them. Without this, mailbox providers will silently drop the reports.
• Multiple DMARC Records: Publishing more than one _dmarc TXT record breaks parsing. Mail servers will encounter a syntax error and ignore your policy.

DMARC Configuration Checklist

• Valid SPF record published for your root domain.
• DKIM signing active and verified for all legitimate mail streams.
• DNS TXT record created at _dmarc.example.com.
• Mandatory v=DMARC1 and p= tags included.
• Active monitoring mailbox configured for rua aggregate reports.
• Policy successfully graduated from none to reject over time.