DMARC Record Explained: Syntax, Tags, and Examples

A DMARC record is a TXT record in your domain's DNS that tells email receivers how to handle messages that fail authentication. Understanding the syntax helps you configure it correctly and troubleshoot problems.

Here's everything you need to know about DMARC record structure, tags, and configuration options.

Where DMARC Records Live

DMARC records are published at a specific location in DNS:

_dmarc.yourdomain.com

For example, if your domain is example.com, your DMARC record goes at _dmarc.example.com.

This is a TXT record containing your DMARC policy and settings.

Basic DMARC Record Structure

Every DMARC record follows this format:

v=DMARC1; p=<policy>; [optional tags]

The minimum valid DMARC record requires only two things:

v=DMARC1; p=none

This declares it as a DMARC record (v=DMARC1) and sets the policy (p=none).

Required Tags

Version Tag (v=)

Every DMARC record must start with the version tag:

v=DMARC1

This must be the first tag in the record. There's currently only one version, so it's always DMARC1.

Policy Tag (p=)

The policy tag tells receivers what to do with emails that fail DMARC:

Example:

v=DMARC1; p=reject

Optional Tags

Subdomain Policy (sp=)

Sets a separate policy for subdomains:

v=DMARC1; p=reject; sp=quarantine

If not specified, subdomains inherit the main policy. Use this when subdomains have different email needs.

Percentage Tag (pct=)

Applies your policy to only a percentage of failing messages:

v=DMARC1; p=reject; pct=10

This applies reject to 10% of failures, treating the other 90% as if p=none. Useful for gradual rollout.

Default is pct=100 (apply to all failures).

Aggregate Report URI (rua=)

Specifies where to send aggregate reports:

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

Aggregate reports are XML summaries sent daily (usually), showing authentication results for all email claiming to be from your domain.

You can list multiple addresses separated by commas:

rua=mailto:dmarc@example.com,mailto:reports@thirdparty.com

Forensic Report URI (ruf=)

Specifies where to send forensic (failure) reports:

v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com

Forensic reports contain details about individual failing messages. Note: Many email providers don't send forensic reports due to privacy concerns.

Forensic Report Options (fo=)

Controls when forensic reports are sent:

You can combine values: fo=1:d:s

v=DMARC1; p=quarantine; ruf=mailto:forensic@example.com; fo=1

Report Format (rf=)

Specifies the format for forensic reports:

rf=afrf

Currently only afrf (Authentication Failure Reporting Format) is standardized. This is the default, so you rarely need to specify it.

Report Interval (ri=)

Requests a specific interval for aggregate reports in seconds:

v=DMARC1; p=none; rua=mailto:dmarc@example.com; ri=3600

Default is 86400 (24 hours). Not all receivers honor this setting.

SPF Alignment Mode (aspf=)

Controls how strictly SPF domains must match:

Relaxed: mail.example.com aligns with example.com Strict: mail.example.com does NOT align with example.com

DKIM Alignment Mode (adkim=)

Controls how strictly DKIM domains must match:

v=DMARC1; p=reject; aspf=r; adkim=s

This uses relaxed SPF alignment but strict DKIM alignment.

Complete DMARC Record Examples

Monitoring Only

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

Collects reports without affecting email delivery. Start here.

Quarantine with Reports

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

Sends failing email to spam and collects both report types.

Full Enforcement

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

Rejects all failing email from main domain and subdomains.

Gradual Rollout

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

Rejects 25% of failing email. Increase pct gradually as you gain confidence.

Strict Alignment

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

Requires exact domain matching for both SPF and DKIM.

Multiple Report Destinations

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

Sends reports to your mailbox and a third-party service.

Common Syntax Mistakes

Missing Version Tag

# Wrong
p=reject; rua=mailto:dmarc@example.com

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

Version Not First

# Wrong
p=reject; v=DMARC1

# Correct
v=DMARC1; p=reject

Missing mailto: in Report URIs

# Wrong
rua=dmarc@example.com

# Correct
rua=mailto:dmarc@example.com

Invalid Policy Value

# Wrong
p=block

# Correct
p=reject

Extra Spaces

# May cause problems
v=DMARC1 ; p=reject

# Safer
v=DMARC1; p=reject

Multiple DMARC Records

You should have exactly one DMARC record per domain. Multiple records can cause:

• Unpredictable behavior from receivers
• Authentication failures
• Missing reports

If you need to update your DMARC record, modify the existing one rather than adding a second.

Creating Your DMARC Record

If you need to create a new DMARC record, use DMARC Creator to generate valid syntax. Then add it to your DNS as a TXT record at _dmarc.yourdomain.com.

After adding the record, wait for DNS propagation (typically 1-4 hours) and verify with a DMARC checker.

Monitor Your DMARC Records

Checking once is good. Monitoring continuously is better. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.