This comprehensive table provides a quick reference for all DMARC tags, their purposes, possible values, and examples. Use this as a handy reference when building your DMARC records.
Tag | Purpose | Values | Example | Status |
|---|---|---|---|---|
| v | Version | DMARC1 | v=DMARC1 | Required |
| p | Policy | none, quarantine, reject | p=quarantine | Required |
| rua | Aggregate Report URI | mailto: addresses | rua=mailto:dmarc@example.com | Recommended |
| sp | Subdomain Policy | none, quarantine, reject | sp=quarantine | Optional |
| pct | Percentage | 0-100 | pct=25 | Optional |
| ruf | Forensic Report URI | mailto: addresses | ruf=mailto:forensic@example.com | Optional |
| fo | Failure Reporting Options | 0, 1, d, s | fo=1 | Optional |
| adkim | DKIM Alignment Mode | r (relaxed), s (strict) | adkim=s | Optional |
| aspf | SPF Alignment Mode | r (relaxed), s (strict) | aspf=s | Optional |
| rf | Report Format | afrf | rf=afrf | Optional |
| ri | Reporting Interval | seconds | ri=86400 | Optional |
vVersion
v=DMARC1pPolicy
p=quarantineruaAggregate Report URI
rua=mailto:dmarc@example.comspSubdomain Policy
sp=quarantinepctPercentage
pct=25rufForensic Report URI
ruf=mailto:forensic@example.comfoFailure Reporting Options
fo=1adkimDKIM Alignment Mode
adkim=saspfSPF Alignment Mode
aspf=srfReport Format
rf=afrfriReporting Interval
ri=86400Quick tip
When building your DMARC record, start with the required tags (v and p) and the highly recommended rua tag. If you plan to use forensic reports (ruf), also add fo=1 for comprehensive failure reporting. A complete monitoring record with forensics might look like: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; fo=1;
Need help building your DMARC record?
Use our interactive DMARC generator tool to create a valid DMARC record step-by-step. The tool walks you through each tag and helps you choose the right values for your domain's security needs.
A DMARC record is like a security policy you hand to every email server that receives mail from your domain. The DMARC tags are the individual rules and instructions within that policy. They answer critical questions like "What should you do with an unverified email?" and "Where should you send a report about it?". Getting these tags right is essential for protecting your domain from phishing and spoofing. This page provides a comprehensive list of all available DMARC tags and explains their specific roles.
The version tag is the foundation of every DMARC record. It identifies which version of the DMARC specification your record follows and must always be the first tag in your record.
Purpose
Marks the TXT record as a DMARC policy. You MUST have v=DMARC1 or your entire DMARC record will be ignored by email servers.
Value
Must always be DMARC1. This is the only version of DMARC currently defined.
Example
v=DMARC1Common errors
v=dmarc1 (invalid)v=DMARC1.0 (invalid)p=none; v=DMARC1 (invalid)The policy tag is the heart of your DMARC record. It defines what action receiving mail servers should take when an email fails DMARC authentication checks.
Purpose
Instructs receiving mail servers what to do with emails that fail DMARC authentication. This directly affects whether your emails are delivered, quarantined, or rejected.
Available values
noneMonitoringNo action taken on failing emails. Used for monitoring and policy testing. Emails are delivered normally but failures are still reported.
quarantineQuarantineFailing emails are treated as suspicious. Typically moved to spam/junk folder or flagged for review. Delivery depends on receiving system.
rejectBlockFailing emails are rejected and not delivered. Strongest protection but requires confidence in your authentication setup.
Default value
None - this tag is required and has no default value.
Examples
p=nonep=quarantinep=rejectImplementation strategy
p=none for 1-2 weeks to monitorp=quarantine with low percentage (pct=10)p=reject when confidentThe aggregate reports URI specifies where daily summary reports should be sent. These reports are essential for monitoring your DMARC implementation and identifying authentication issues.
Purpose
Receives daily XML reports containing aggregated data about emails sent from your domain, including authentication results, IP addresses, and volume statistics. You can use your own email address or specialized DMARC monitoring services like Suped that parse and analyze these reports for you.
Format
Must be in URI format, typically mailto: followed by email address(es).
Default value
None - if omitted, no aggregate reports will be sent.
Examples
rua=mailto:dmarc-reports@example.comrua=mailto:dmarc-reports@example.com,mailto:security-team@example.comReport content
Size limits
You can specify maximum report size limits using the ! syntax.
rua=mailto:dmarc-reports@dmarc-reports@example.com.com!10mIn this example, you will only receive reports up to 10 megabytes in size.External addresses
If you wish to receive reports at addresses outside of your sending domain, and you own the report address, then you must set up an extra "External Reporting Authorization Records" DNS record.
This is not required if you are using a platform such as Suped to manage your report emails. We do this for you.
For example if you are sending email from hello@mynewsletter.com but wish to receive reports at security@mycompany.com, then you must configure an additional DNS TXT record for mycompany.com.
Read more about this advanced configuration here.
The subdomain policy tag allows you to specify a different DMARC policy for your subdomains than your main domain. This provides flexibility during implementation and allows for different security postures.
Purpose
Sets a specific policy for subdomains that may differ from the main domain policy. Useful for staged rollouts or different security requirements.
Available values
Same as the main policy tag: none, quarantine, or reject.
Default value
If omitted, subdomains inherit the policy specified in the main policy tag (p).
Examples
v=DMARC1; p=reject; sp=quarantinev=DMARC1; p=quarantine; sp=noneUse cases
The percentage tag enables gradual policy enforcement by specifying what percentage of emails failing DMARC should have the policy applied. This is crucial for safe policy rollouts.
Purpose
Controls what percentage of emails failing DMARC authentication should have the policy (quarantine or reject) applied. Allows for gradual rollout and testing.
Value range
Integer from 0 to 100, representing the percentage of failing emails to which the policy should be applied.
Default value
100 - if omitted, the policy applies to 100% of failing emails.
Examples
v=DMARC1; p=quarantine; pct=10v=DMARC1; p=quarantine; pct=50Implementation strategy
Important notes
The forensic reports URI requests detailed, real-time reports for individual emails that fail DMARC authentication. These provide in-depth troubleshooting information.
Purpose
Requests detailed reports for individual emails that fail DMARC authentication, including message headers and failure details.
Format
Same as rua - must be in URI format, typically mailto: followed by email address(es).
Default value
None - if omitted, no forensic reports will be sent.
Examples
ruf=mailto:dmarc-forensic@example.comruf=mailto:dmarc-forensic@example.com; fo=1Report content
Limitations
The failure options tag controls when forensic reports are generated, providing fine-grained control over report triggering conditions.
Purpose
Specifies the conditions under which forensic reports should be generated. Only relevant when the ruf tag is also present.
Available values
fo=0DefaultGenerate reports only when both SPF and DKIM fail to align with the From domain.
fo=1ComprehensiveGenerate reports when either SPF or DKIM fails to align. Most comprehensive option.
fo=dDKIM onlyGenerate reports for any DKIM signature failure, regardless of alignment.
fo=sSPF onlyGenerate reports for any SPF failure, regardless of alignment.
Default value
0 - reports generated only when both SPF and DKIM fail to align.
Examples
v=DMARC1; p=none; ruf=mailto:forensic@example.com; fo=1v=DMARC1; p=none; ruf=mailto:forensic@example.com; fo=dv=DMARC1; p=none; ruf=mailto:forensic@example.com; fo=0:1:sCombining multiple options
You can specify multiple failure reporting options by separating them with colons. This allows you to receive reports for different types of failures simultaneously.
Example combinations
fo=0:1Reports when both fail AND when either failsfo=1:d:sReports for alignment failures plus any SPF or DKIM failuresfo=0:1:sComprehensive reporting covering all scenarios except DKIM-only failuresChoosing the right option
Recommended: fo=1
For most implementations, fo=1 is recommended as it provides comprehensive coverage of authentication issues by generating reports when either SPF or DKIM fails to align.
The DKIM alignment mode controls how strictly the DKIM signature domain must match the From header domain for DMARC authentication to pass.
Purpose
Determines how closely the DKIM signature domain must match the From header domain for DMARC to consider DKIM as aligned.
Available values
adkim=rRelaxed (Default)Allows organizational domain matching. A DKIM signature from "mail.example.com" aligns with "newsletter@example.com".
adkim=sStrictRequires exact domain matching. The DKIM signature domain must exactly match the From header domain.
Default value
r (relaxed) - allows organizational domain matching.
Examples
v=DMARC1; p=quarantine; adkim=rv=DMARC1; p=quarantine; adkim=sAlignment examples
| From Header | DKIM Signature Domain | Relaxed (r) | Strict (s) |
|---|---|---|---|
| user@example.com | example.com | ✓ Pass | ✓ Pass |
| user@example.com | mail.example.com | ✓ Pass | ✗ Fail |
| user@sub.example.com | example.com | ✓ Pass | ✗ Fail |
Recommendation
Most organizations should use relaxed alignment (default) as it accommodates common email service configurations where DKIM signing domains may differ from the From domain while still belonging to the same organization.
The SPF alignment mode controls how the Return-Path domain (envelope from) must align with the From header domain for DMARC authentication to pass.
Purpose
Determines how closely the Return-Path domain must match the From header domain for DMARC to consider SPF as aligned.
Available values
aspf=rRelaxed (Default)Allows organizational domain matching. Return-Path "bounce@mail.example.com" aligns with "user@example.com".
aspf=sStrictRequires exact domain matching. The Return-Path domain must exactly match the From header domain.
Default value
r (relaxed) - allows organizational domain matching.
Examples
v=DMARC1; p=quarantine; aspf=rv=DMARC1; p=quarantine; aspf=sAlignment examples
| From Header | Return-Path | Relaxed (r) | Strict (s) |
|---|---|---|---|
| user@example.com | bounce@example.com | ✓ Pass | ✓ Pass |
| user@example.com | bounce@mail.example.com | ✓ Pass | ✗ Fail |
| user@example.com | bounce@mailservice.com | ✗ Fail | ✗ Fail |
Important considerations
The report format tag specifies the format for forensic reports. This tag exists primarily for future extensibility of the DMARC specification.
Purpose
Specifies the format for forensic reports. Allows for future extensibility if new report formats are developed.
Available values
Currently only afrf (Authentication Failure Reporting Format) is defined.
Default value
afrf - Authentication Failure Reporting Format is the default and only currently defined format.
Examples
v=DMARC1; p=none; ruf=mailto:forensic@example.com; rf=afrfv=DMARC1; p=none; ruf=mailto:forensic@example.comRecommendation
Most implementations can safely omit this tag since the default (afrf) is the only currently available format. Only specify if required by specific reporting tools or for documentation purposes.
The reporting interval tag suggests how often aggregate reports should be sent. However, this is largely advisory and most email providers send reports on their own schedule.
Purpose
Suggests the requested interval between aggregate reports, specified in seconds. This is a preference, not a requirement.
Value format
Positive integer representing seconds between reports.
Default value
86400 (24 hours) - daily reporting is the default and most common interval.
Examples
ri=86400ri=604800v=DMARC1; p=none; rua=mailto:reports@example.com; ri=86400Common intervals
| Interval | Seconds | Usage |
|---|---|---|
| Daily | 86400 | Standard, most common |
| Weekly | 604800 | Lower volume domains |
| Hourly | 3600 | High-volume, urgent monitoring |
Important limitations
Recommendation
Most implementations can omit this tag since the default (daily) is appropriate for most use cases and providers often ignore custom intervals anyway.
Here are practical examples of complete DMARC records for different deployment scenarios, from initial monitoring to full enforcement.
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;This record is in monitoring mode and requests aggregate reports to be sent to the specified email address. Perfect for initial deployment and understanding your email ecosystem.
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@example.com;This record will quarantine 10% of emails that fail DMARC and send aggregate reports. Useful for testing the impact of your policy before full enforcement.
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; fo=1;This record rejects all failing emails and requests both aggregate and forensic reports for any failure. Maximum protection for mature deployments.
v=DMARC1; p=reject; sp=quarantine; adkim=s; aspf=s; rua=mailto:dmarc-reports@example.com;This record enforces a reject policy on the main domain, a quarantine policy on subdomains, requires strict alignment for both SPF and DKIM, and sends aggregate reports.
What is the DMARC 'adkim' tag used for?
What DMARC tag specifies forensic reports?
Does the DMARC 'pct' tag affect aggregate reports?
What is the default value for the DMARC 'p' tag?
What DMARC alignment mode is stricter: 'relaxed' or 'strict'?
Does DMARC authenticate the 'From' header directly?
Which DMARC tag specifies the policy for subdomains?
What does the 'ruf' DMARC tag stand for?
