DMARC Record Syntax: Every Tag and Parameter Explained

A DMARC record is a single line of text made up of tags separated by semicolons. Each tag controls a specific aspect of how receiving mail servers handle messages from your domain. Some tags are required, most are optional, and all have specific rules about what values they accept.

This is the complete reference. Every DMARC tag is listed below with its purpose, valid values, default behavior when omitted, and practical usage guidance.

DMARC Record Structure

A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com. The basic structure is:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; [additional tags]

Tags are written as tag=value pairs, separated by semicolons. Spaces after semicolons are optional but common for readability. The order of tags does not matter, except that v=DMARC1 must always come first.

Required Tags

v — Version

Purpose: Identifies the record as a DMARC policy.

Valid values: DMARC1 (only valid value)

Required: Yes. Must be the first tag in the record.

v=DMARC1;

There is no DMARC2 or any other version. If this tag is missing or is not the first tag, the entire record is invalid and will be ignored by receiving servers.

p — Policy

Purpose: Tells receiving servers what to do with messages that fail DMARC alignment.

Valid values:

• none — Take no action. Deliver the message normally and send a report.
• quarantine — Treat the message as suspicious. Usually means routing to the spam folder.
• reject — Block the message entirely. It is not delivered anywhere.

Required: Yes.

v=DMARC1; p=none;

This is the most important tag in your record. Start with p=none when setting up DMARC for the first time, then move to quarantine and eventually reject after confirming all legitimate senders pass authentication. Our DMARC policy levels guide covers the progression in detail, and our quarantine vs reject comparison helps you understand the practical tradeoffs between enforcement levels.

Optional Tags

rua — Aggregate Report URI

Purpose: Specifies where aggregate (summary) reports should be sent.

Valid values: A mailto: URI pointing to an email address.

Default if omitted: No aggregate reports are sent.

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com;

You can specify multiple addresses by separating them with commas:

rua=mailto:dmarc@yourdomain.com,mailto:dmarc@thirdparty.com;

If the reporting address is on a different domain than the one being protected, the receiving domain must publish a special DNS record to authorize it. Without the rua tag, you are flying blind — there is no way to know who is sending email as your domain or whether your authentication is working.

ruf — Forensic Report URI

Purpose: Specifies where forensic (failure) reports should be sent for individual messages that fail DMARC.

Valid values: A mailto: URI pointing to an email address.

Default if omitted: No forensic reports are sent.

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.com;

Forensic reports contain more detail than aggregate reports, including email headers from individual failing messages. However, many large providers (notably Gmail) do not send forensic reports due to privacy concerns. Treat these as supplementary data, not your primary source.

pct — Percentage

Purpose: Controls what percentage of messages that fail DMARC are subject to the policy.

Valid values: An integer from 0 to 100.

Default if omitted: 100 (the policy applies to all failing messages).

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com;

This is your safety valve for gradual rollout. If you set p=quarantine; pct=25;, only 25 percent of failing messages are quarantined. The remaining 75 percent are treated as if the policy were none. This lets you phase in enforcement while monitoring for problems.

Messages not covered by the percentage are treated as one policy level lower: reject falls back to quarantine, and quarantine falls back to none. For a full breakdown of how SPF, DKIM, and DMARC interact during this process, see SPF vs DKIM vs DMARC.

sp — Subdomain Policy

Purpose: Sets a separate policy for subdomains of your domain.

Valid values: none, quarantine, or reject (same as the p tag).

Default if omitted: Subdomains inherit the p policy.

v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@yourdomain.com;

This is useful when your main domain is ready for enforcement but your subdomains (like mail.yourdomain.com or app.yourdomain.com) are not yet fully authenticated. You can also do the reverse — set sp=reject for subdomains that never send email while keeping the main domain at a lower enforcement level.

adkim — DKIM Alignment Mode

Purpose: Controls how strictly the DKIM signing domain must match the From domain.

Valid values:

• r — Relaxed. The DKIM domain can be a subdomain of the From domain (or vice versa).
• s — Strict. The DKIM domain must exactly match the From domain.

Default if omitted: r (relaxed).

v=DMARC1; p=reject; adkim=s; rua=mailto:dmarc@yourdomain.com;

Under relaxed alignment, if your From address is info@yourdomain.com and your DKIM signing domain is mail.yourdomain.com, that is a pass. Under strict alignment, it would fail because the domains do not match exactly. Most organizations should leave this at relaxed unless they have a specific security reason to require strict matching. Developer teams automating DNS record management should be aware of these alignment implications when configuring third-party senders.

aspf — SPF Alignment Mode

Purpose: Controls how strictly the SPF-authenticated domain (the Return-Path domain) must match the From domain.

Valid values:

• r — Relaxed. Subdomains are allowed.
• s — Strict. Exact match required.

Default if omitted: r (relaxed).

v=DMARC1; p=reject; aspf=s; rua=mailto:dmarc@yourdomain.com;

The same logic as adkim applies here. Relaxed allows bounce.yourdomain.com to align with yourdomain.com. Strict does not. Relaxed is the right choice for most setups.

fo — Failure Reporting Options

Purpose: Controls when forensic reports (ruf) are generated.

Valid values:

• 0 — Generate a report only when both SPF and DKIM fail alignment. (Default)
• 1 — Generate a report when either SPF or DKIM fails alignment.
• d — Generate a report when DKIM fails, regardless of alignment.
• s — Generate a report when SPF fails, regardless of alignment.

Default if omitted: 0.

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:forensics@yourdomain.com; fo=1;

Setting fo=1 is recommended because it gives you reports for any authentication failure, not just complete failures. This is especially valuable during the monitoring phase when you are identifying all your legitimate senders. You can combine values with colons: fo=1:d:s.

ri — Report Interval

Purpose: Requests a specific interval (in seconds) between aggregate reports.

Valid values: An integer representing seconds.

Default if omitted: 86400 (24 hours).

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ri=43200;

Setting ri=43200 requests reports every 12 hours instead of every 24. However, this is only a request — receiving servers are not required to honor it, and most still send reports once per day regardless of this setting.

Example Records for Common Scenarios

Monitoring only — first-time setup

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1;

Collects detailed reports without affecting email delivery. The right starting point for every domain.

Gradual quarantine rollout

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com; ruf=mailto:forensics@yourdomain.com; fo=1;

Quarantines 25 percent of failing messages. Increase pct over several weeks as you confirm no legitimate email is affected.

Full enforcement with subdomain protection

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r;

The goal state for most domains. All failing messages — on the main domain and subdomains — are rejected.

Strict alignment for high-security domains

v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@yourdomain.com; ruf=mailto:forensics@yourdomain.com; fo=1;

Requires exact domain matching for both DKIM and SPF. Use this only after confirming all senders pass with strict alignment.

Parked or non-sending domain

v=DMARC1; p=reject; sp=reject;

Maximum protection with no reporting needed since no legitimate email should ever come from this domain.

Monitor Your DMARC Record

You've created your DMARC record — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.