How to Build a DMARC Record: Every Tag Explained

A DMARC record is a specialized DNS TXT string that tells receiving mail servers how to treat emails claiming to originate from your domain name. By evaluating specific dmarc record tags, receiving security gateways determine whether an incoming message passes authentication checks, where to route delivery telemetry, and how strictly to enforce compliance rules.

Without a functional DMARC policy, major mailbox providers like Google and Yahoo outright block or flag unauthenticated domain traffic. Building a resilient DMARC policy requires mastering its full array of configuration tags, setting appropriate alignment parameters, and publishing the finalized string to your domain's DNS management console.

---

The Anatomy of a DMARC Record

Every DMARC string consists of discrete key-value pairs separated by semicolons. A standard string follows a precise syntax where keys represent standard parameters and values specify the corresponding instruction.

At a minimum, every published DMARC record requires two mandatory tags:

1. v (Version): Must be set to DMARC1.
2. p (Policy): Defines the handling strategy for failing messages (none, quarantine, or reject).

A baseline monitoring record without placeholder values follows this exact structure:

v=DMARC1; p=none; rua=mailto:[email protected];

If the version tag is placed anywhere other than the beginning of the string, or if mandatory tags are omitted, receiving resolvers treat the record as invalid and ignore your domain policy entirely.

---

Complete Reference of DMARC Record Tags

The official DMARC specification includes nine standard tags. Each tag controls a specific operational aspect of authentication, reporting telemetry, or subdomain control.

Version Tag (v)

Status: Mandatory
Accepted Values: DMARC1
Description: Identifies the record as a DMARC configuration string. It must be the first key-value pair in the DNS entry. Any deviation in capitalization, spelling, or position invalidates the entire record.

Policy Tag (p)

Status: Mandatory
Accepted Values: none, quarantine, reject
Description: Commands the receiving Mail Transfer Agent (MTA) how to treat messages that fail both SPF and DKIM authentication checks.

• none: Collects diagnostic telemetry without modifying message delivery. Use this setting during initial rollout to observe sending activity. To understand how mailbox providers interpret these policy directives, review our guide on DMARC Explained: What p=none, quarantine and reject Really Mean.
• quarantine: Directs receiving gateways to filter unauthenticated mail directly into spam or junk folders.
• reject: Orders receiving gateways to block unauthenticated messages at the SMTP level, preventing delivery entirely.

Aggregate Reporting URI Tag (rua)

Status: Optional (Strongly Recommended)
Accepted Values: mailto: followed by one or more destination email addresses separated by commas.
Description: Designates the endpoint where receiving mail systems send daily aggregate XML reports. These reports summarize traffic volume, sending IP addresses, SPF pass/fail states, and DKIM signature outcomes across all global receivers.

Failure / Forensic Reporting URI Tag (ruf)

Status: Optional
Accepted Values: mailto: followed by destination email addresses.
Description: Specifies the destination for real-time failure (forensic) reports. Unlike aggregate reports, forensic reports trigger immediately when an individual email fails authentication. Privacy frameworks like GDPR and CCPA have led many major inbox providers to deprecate ruf reports, making aggregate rua reporting the primary telemetry tool.

Percentage Tag (pct)

Status: Optional
Accepted Values: 0 through 100 (Default: 100)
Description: Defines the percentage of unauthenticated email traffic subject to your selected policy (quarantine or reject). Setting pct=20 alongside p=quarantine applies enforcement to 20% of unauthenticated messages, while the remaining 80% revert to p=none. This allows infrastructure teams to roll out strict security enforcement gradually.

Subdomain Policy Tag (sp)

Status: Optional
Accepted Values: none, quarantine, reject
Description: Overrides the primary domain policy (p) for all subdomains under your root domain. If this tag is absent, subdomains automatically inherit the parent domain policy defined in the p tag.

DKIM Alignment Mode Tag (adkim)

Status: Optional
Accepted Values: r (relaxed), s (strict). Default: r.
Description: Sets domain alignment requirements for DKIM verification. In relaxed mode (r), alignment passes if the root organizational domain in the visible From: header matches the domain in the DKIM d= signature tag. In strict mode (s), both domains must match character-for-character, including subdomains.

SPF Alignment Mode Tag (aspf)

Status: Optional
Accepted Values: r (relaxed), s (strict). Default: r.
Description: Sets domain alignment requirements for SPF verification. In relaxed mode (r), subdomains in the envelope return-path (MAIL FROM) address align with the organizational root domain in the visible From: header. Strict mode (s) requires exact character-for-character matching between both header addresses.

Failure Reporting Options Tag (fo)

Status: Optional
Accepted Values: 0, 1, d, s (Default: 0)
Description: Dictates the trigger condition for forensic reports when the ruf tag is active.

• 0: Triggers a report if both SPF and DKIM fail alignment checks.
• 1: Triggers a report if either SPF or DKIM fails alignment.
• d: Triggers a report if DKIM evaluation fails, regardless of SPF status.
• s: Triggers a report if SPF evaluation fails, regardless of DKIM status.

---

Step-by-Step Guide to Assembling a DMARC Record

Creating an error-free DMARC string requires systematic audit, syntax validation, and DNS publication.

Step 1: Audit Outbound Email Infrastructure

Ensure all external and internal mail sources—such as corporate accounts, marketing automation tools, transaction gateways, and CRM systems—have functional alignment.

Verify that active SPF records list authorized sending hosts and that valid cryptographic keys are enabled. For complete technical steps on signature configuration, read What Is DKIM and How Does Email Signing Actually Work?.

Step 2: Establish the Baseline Record String

Construct a monitoring configuration using p=none to aggregate delivery data without disrupting active email streams.

Combine compulsory tags:

• Start with v=DMARC1;
• Add your baseline policy p=none;
• Add an aggregate reporting endpoint rua=mailto:[email protected];

Step 3: Configure Alignment and Subdomain Parameters

Determine if your organization requires isolated subdomain policies or strict header alignment. For standard corporate setups, keeping relaxed alignment (adkim=r; aspf=r;) prevents legitimate multi-service software from tripping authentication flags.

Step 4: Validate String Formatting

Ensure every tag pair ends with a semicolon. Eliminate trailing spaces within tag declarations. To avoid syntax errors, construct your configuration using our free DMARC Record Generator.

Step 5: Publish the TXT Record to DNS

Open your domain's DNS manager (Cloudflare, AWS Route 53, GoDaddy, or Namecheap) and create a record entry with these exact parameters:

• Record Type: TXT
• Host / Name: _dmarc
• TTL: 3600 seconds (1 hour) or Automatic
• TXT Value: v=DMARC1; p=none; rua=mailto:[email protected];

Save the record and wait for global DNS propagation to finalize across public resolvers.

---

What a DMARC Record Cannot Do

While critical for domain reputation, DMARC is not a complete email security strategy. Understanding its explicit boundaries prevents security teams from overestimating their posture.

• Lookalike Domains: DMARC enforcement only applies to the exact root domain and subdomains where the TXT record exists. It does not stop malicious actors from registering visually similar typosquatting domains to send phishing messages.
• Inbound Phishing Protection: Publishing a policy tells external servers how to treat your outgoing messages. It does not automatically safeguard your corporate employee mailboxes from incoming spam unless your internal incoming gateway enforces inbound DMARC filtering.
• Payload Inspection: DMARC authenticates domain header ownership. It does not scan attachments for malware, filter zero-day exploits, or inspect links embedded inside validly signed emails.

---

Deployment Timing: When to Enforce vs. Hold Off

Deploy Immediately (p=none) If:

• Bulk Delivery Requirements: You send bulk email campaigns. Major email providers mandate valid DMARC records for domains sending high volumes of daily messages.
• Brand Protection: Attackers target your organizational domain to execute brand impersonation attacks against customers or vendors.
• Vendor Discovery: You need visibility into all third-party cloud services sending mail using your corporate domain name.

Hold Off on Policy Enforcement (p=reject) If:

• Unmapped Sending Services: You have not audited every transactional service, automated server notification, or third-party CRM sending mail on your behalf. Enforcing p=reject prematurely will drop legitimate business communications.
• Recent DNS Migrations: You recently updated mail hosts or updated cryptographic signing keys. Maintain a monitoring policy for 2 to 4 weeks while evaluating aggregate daily reports. For a detailed deployment timeline, read How to Set Up DMARC from Scratch: A Non-Expert's Walkthrough.

---

Common Implementation Errors

1. Publishing at the Root Level (@)

A widespread DNS mistake is creating the TXT record under the root hostname rather than the dedicated _dmarc host prefix. Mail servers strictly query _dmarc.your-domain-name.com. If the record sits at root, receivers fail to discover it.

2. Semicolon Omission and Typographic Errors

DMARC parsers require a semicolon separator after every single tag. Writing v=DMARC1 p=none without a semicolon breaks parsing engines, causing security gateways to ignore the policy entirely.

3. Multiple DMARC Records

A domain must contain exactly one DMARC record. Publishing multiple TXT records under the _dmarc host creates an immediate syntax conflict, forcing receiving MTAs to reject all published policies and fall back to unauthenticated handling.

---

Testing and Maintaining DMARC Compliance

Maintaining deliverability requires continuous validation as email pipelines change. When engineering teams deploy automated notification systems, transactional email triggers, or user verification pipelines, testing authentication in isolated environments protects production domain reputation.

For QA workflows and automated CI/CD integration testing, Best-TempMail offers instant disposable inbox access paired with real-time updates across clean, pre-configured domains. Developers building automated signup testing suites can leverage the live Best-TempMail API to programmatically generate isolated test endpoints and verify that operational messages clear SPF and DKIM validation without cluttering corporate infrastructure.

---

Frequently Asked Questions

What is the difference between p=none, p=quarantine, and p=reject?

The p=none policy collects telemetry without affecting message delivery. The p=quarantine policy directs receiving mail servers to route unauthenticated emails to spam or junk folders. The p=reject policy commands receiving servers to block unauthenticated messages at the gateway entirely.

What is the difference between rua and ruf reporting tags?

The rua tag delivers daily aggregate XML reports summarizing message volume, sending IP addresses, and alignment outcomes. The ruf tag requests real-time failure (forensic) reports for individual unauthenticated messages, though many mailbox providers omit ruf data due to privacy regulations.

How long does a DMARC record take to take effect?

Once added to your DNS manager, a DMARC record takes effect as soon as global DNS propagation completes—typically between 15 minutes and 48 hours depending on your domain's Time-To-Live (TTL) setting.

Why is my DMARC record failing alignment?

DMARC alignment fails when the visible domain in the email's From: header does not match the envelope return-path domain evaluated by SPF or the signature domain specified in the DKIM d= key. To resolve alignment failures, configure your third-party mail providers to use customized branded return-path domains and DKIM selectors.