Complete DMARC tags reference
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 |
Values: DMARC1
Example: v=DMARC1
Values: none, quarantine, reject
Example: p=quarantine
Values: mailto: addresses
Example: rua=mailto:dmarc@example.com
Values: none, quarantine, reject
Example: sp=quarantine
Values: 0-100
Example: pct=25
Values: mailto: addresses
Example: ruf=mailto:forensic@example.com
foFailure Reporting Options
Values: 0, 1, d, s
Example: fo=1
Values: r (relaxed), s (strict)
Example: adkim=s
Values: r (relaxed), s (strict)
Example: aspf=s
Values: afrf
Example: rf=afrf
Values: seconds
Example: ri=86400
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.
Understanding DMARC tags
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.
What DMARC tags do
- • Define email authentication policies
- • Specify report destinations
- • Control alignment requirements
- • Configure failure reporting
- • Enable gradual policy enforcement
Why they matter
- • Prevent domain spoofing
- • Protect brand reputation
- • Improve email deliverability
- • Provide security visibility
- • Enable compliance reporting
v: Version tag
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.
RequiredMust be first tag
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.
Common errors
- Using lowercase:
v=dmarc1 (invalid) - Adding version numbers:
v=DMARC1.0 (invalid) - Placing it anywhere but first:
p=none; v=DMARC1 (invalid)
p: Policy tag
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.
RequiredImpacts deliverability
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
noneMonitoring
No action taken on failing emails. Used for monitoring and policy testing. Emails are delivered normally but failures are still reported.
quarantineQuarantine
Failing emails are treated as suspicious. Typically moved to spam/junk folder or flagged for review. Delivery depends on receiving system.
rejectBlock
Failing 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=none
p=quarantine
p=reject
Implementation strategy
- Start with
p=none for 1-2 weeks to monitor - Move to
p=quarantine with low percentage (pct=10) - Gradually increase percentage as you verify legitimate mail isn't affected
- Finally move to
p=reject when confident
rua: Aggregate reports URI
The aggregate reports URI specifies where daily summary reports should be sent. These reports are essential for monitoring your DMARC implementation and identifying authentication issues.
RecommendedMultiple addresses allowed
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
Single address:rua=mailto:dmarc-reports@example.com
Multiple addresses:rua=mailto:dmarc-reports@example.com,mailto:security-team@example.com
Report content
- IP addresses sending email for your domain
- Authentication results (SPF, DKIM, DMARC)
- Message volumes and disposition
- Organizational domain information
- Policy evaluation results
Size limits
You can specify maximum report size limits using the ! syntax.
Example: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.
sp: Subdomain policy
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.
OptionalInherits from parent if omitted
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
Conservative approach:v=DMARC1; p=reject; sp=quarantine
Monitoring subdomains:v=DMARC1; p=quarantine; sp=none
Use cases
- Staging subdomain policies during implementation
- Different security requirements for different subdomains
- Protecting main domain while monitoring subdomains
- Accommodating third-party services on subdomains
pct: Percentage
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.
OptionalGradual enforcement
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
Testing at 10%:v=DMARC1; p=quarantine; pct=10
Gradual increase:v=DMARC1; p=quarantine; pct=50
Implementation strategy
- Start with pct=10 when moving to quarantine or reject
- Monitor reports for 1-2 weeks
- Increase gradually: 10% → 25% → 50% → 75% → 100%
- Remove pct tag when reaching 100% (default)
Important notes
- Only affects quarantine and reject policies (not "none")
- Emails not subject to policy are still delivered normally
- All emails are still included in aggregate reports
- Percentage selection is typically random
ruf: Forensic reports URI
The forensic reports URI requests detailed, real-time reports for individual emails that fail DMARC authentication. These provide in-depth troubleshooting information.
OptionalLimited provider support
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
Basic forensic reporting:ruf=mailto:dmarc-forensic@example.com
With failure options:ruf=mailto:dmarc-forensic@example.com; fo=1
Report content
- Complete email headers from failed messages
- Authentication failure details
- Policy evaluation results
- Sometimes partial message content (often redacted)
Limitations
- Many email providers don't send forensic reports due to privacy concerns
- Reports may be heavily redacted or incomplete
- Volume can be high for domains with many authentication failures
- Not reliable for primary monitoring - use aggregate reports instead
fo: Failure options
The failure options tag controls when forensic reports are generated, providing fine-grained control over report triggering conditions.
OptionalRequires ruf tag
Purpose
Specifies the conditions under which forensic reports should be generated. Only relevant when the ruf tag is also present.
Available values
fo=0Default
Generate reports only when both SPF and DKIM fail to align with the From domain.
fo=1Comprehensive
Generate reports when either SPF or DKIM fails to align. Most comprehensive option.
fo=dDKIM only
Generate reports for any DKIM signature failure, regardless of alignment.
fo=sSPF only
Generate reports for any SPF failure, regardless of alignment.
Default value
0 - reports generated only when both SPF and DKIM fail to align.
Examples
Comprehensive reporting:v=DMARC1; p=none; ruf=mailto:forensic@example.com; fo=1
DKIM failure focus:v=DMARC1; p=none; ruf=mailto:forensic@example.com; fo=d
Multiple failure types:v=DMARC1; p=none; ruf=mailto:forensic@example.com; fo=0:1:s
Combining 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.
fo=0:1Reports when both fail AND when either fails
fo=1:d:sReports for alignment failures plus any SPF or DKIM failures
fo=0:1:sComprehensive reporting covering all scenarios except DKIM-only failures
Choosing the right option
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.
- fo=0: Conservative, fewer reports, focuses on complete failures
- fo=1: Most popular and recommended, comprehensive coverage of authentication issues
- fo=d: Useful when troubleshooting DKIM-specific issues
- fo=s: Useful when troubleshooting SPF-specific issues
adkim: DKIM alignment mode
The DKIM alignment mode controls how strictly the DKIM signature domain must match the From header domain for DMARC authentication to pass.
OptionalDefaults to relaxed
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=sStrict
Requires exact domain matching. The DKIM signature domain must exactly match the From header domain.
Default value
r (relaxed) - allows organizational domain matching.
Examples
Relaxed alignment:v=DMARC1; p=quarantine; adkim=r
Strict alignment:v=DMARC1; p=quarantine; adkim=s
Alignment 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.
aspf: SPF alignment mode
The SPF alignment mode controls how the Return-Path domain (envelope from) must align with the From header domain for DMARC authentication to pass.
OptionalDefaults to relaxed
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=sStrict
Requires exact domain matching. The Return-Path domain must exactly match the From header domain.
Default value
r (relaxed) - allows organizational domain matching.
Examples
Relaxed alignment:v=DMARC1; p=quarantine; aspf=r
Strict alignment:v=DMARC1; p=quarantine; aspf=s
Alignment 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
- Many email service providers use their own domains in Return-Path for bounce handling
- SPF alignment is often more challenging than DKIM alignment
- Relaxed alignment accommodates common email service configurations
- Strict alignment may break legitimate email from third-party services
rf: Report format
The report format tag specifies the format for forensic reports. This tag exists primarily for future extensibility of the DMARC specification.
OptionalRarely used
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
Explicit format specification:v=DMARC1; p=none; ruf=mailto:forensic@example.com; rf=afrf
Typically omitted (uses default):v=DMARC1; p=none; ruf=mailto:forensic@example.com
Recommendation
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.
ri: Reporting interval
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.
OptionalAdvisory only
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
Daily reporting (default):ri=86400
Weekly reporting:ri=604800
Complete record:v=DMARC1; p=none; rua=mailto:reports@example.com; ri=86400
Common intervals
| Interval | Seconds | Usage |
|---|
| Daily | 86400 | Standard, most common |
| Weekly | 604800 | Lower volume domains |
| Hourly | 3600 | High-volume, urgent monitoring |
Important limitations
- Most email providers ignore this tag and send reports on their own schedule
- Typically daily reports regardless of this setting
- Some providers may send reports less frequently based on volume
- Don't rely on this for time-sensitive monitoring
Recommendation
Most implementations can omit this tag since the default (daily) is appropriate for most use cases and providers often ignore custom intervals anyway.
Complete DMARC record examples
Here are practical examples of complete DMARC records for different deployment scenarios, from initial monitoring to full enforcement.
👁️
Monitoring only
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.
⚡
Gradual quarantine
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.
🔒
Full protection with forensics
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.
🎯
Advanced configuration
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.
