Updated on June 16, 2026: We refreshed the DMARCbis facts for RFC 9989, RFC 9990, and RFC 9991, including active np, psd, and t tags, historic pct, rf, and ri tags, and DNS Tree Walk policy discovery.
Complete DMARC tags reference
This table provides a quick reference for active DMARCbis tags, historic DMARC tags, their purposes, possible values, and examples. Use this as a handy reference when building or reviewing your DMARC records.
|
|
|
|
|
|---|---|---|---|---|
v | Version | DMARC1 | v=DMARC1 | Required |
p | Domain Owner Assessment Policy | none, quarantine, reject | p=quarantine | Recommended |
rua | Aggregate Report URI | mailto: addresses | rua=mailto:dmarc@example.com | Recommended |
sp | Existing Subdomain Policy | none, quarantine, reject | sp=quarantine | Optional |
np | Non-existent Subdomain Policy | none, quarantine, reject | np=reject | Optional |
psd | Public Suffix Domain Flag | y, n, u | psd=n | Optional |
t | Policy Test Mode | y, n | t=y | Optional |
pct | Historic Sampling Rate | 0-100 (historic) | pct=25 | Historic |
ruf | Failure 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 | Historic Report Format | afrf (historic tag) | rf=afrf | Historic |
ri | Historic Reporting Interval | seconds (historic tag) | ri=86400 | Historic |
DMARC tag reference
Quick tip
When building your DMARC record, start with the version tag (v), include the policy tag (p) even though RFC 9989 treats it as p=none if omitted, and add the highly recommended rua tag. If you plan to use failure reports (ruf), also add fo=1 for comprehensive failure reporting. A complete monitoring record with failure reports (forensic reports) might look like:
Monitoring record with failure reports
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.
DMARC record generator
Choose your policy, reporting addresses, and alignment settings.
DNS TXT record
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
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. RFC 9989 also defines DNS Tree Walk policy discovery, so policy lookup can find applicable records up the DNS hierarchy instead of relying on the older Public Suffix List method. This page provides a list of active and historic DMARC tags and explains their roles.
What DMARC tags do
- Define: Email authentication policies
- Specify: Report destinations
- Control: Alignment requirements
- Configure: Failure reporting
- Signal: Policy test mode
Why they matter
- Prevent: Domain spoofing
- Protect: Brand reputation
- Improve: Email deliverability
- Provide: Security visibility
- Enable: Compliance reporting
DMARC record tags grouped by version, policy, reporting, and rollout controls.
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.
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
Version tag
v=DMARC1
Common errors
- Lowercase: Using v=dmarc1 is invalid.
- Version numbers: Adding v=DMARC1.0 is invalid.
- Tag order: Placing it anywhere but first is 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.
Purpose
Instructs receiving mail servers what to do with emails that fail DMARC authentication. It can apply to the domain and to subdomains unless sp or np says otherwise. This directly affects whether your emails are delivered, quarantined, or rejected.
Available values
- none: No action taken on failing emails. Used for monitoring and policy testing. Emails are delivered normally but failures are still reported.
- quarantine: Failing emails are treated as suspicious. Typically moved to spam/junk folder or flagged for review. Delivery depends on receiving system.
- reject: Failing emails are rejected and not delivered. Strongest protection but requires confidence in your authentication setup.
Default value
If omitted in an otherwise valid RFC 9989 DMARC record, receiving servers treat it as p=none. You should still publish p explicitly so the record is clear to humans and older implementations.
Examples
Policy tag examples
p=none p=quarantine p=reject
Implementation strategy
- Monitor: Start with p=none for 1-2 weeks to monitor.
- Test: Move to p=quarantine with t=y if you want DMARCbis test mode before full application.
- Review: Monitor aggregate reports as you verify legitimate mail is not affected.
- Enforce: Remove t, or set t=n, when confident.
DMARC policy rollout stages
A practical rollout usually starts with reporting, then test mode, then full enforcement.
Monitoring
p=none
Collect reports before changing delivery handling.
Testing
t=y
Signal test mode while reviewing policy impact.
Full enforcement
t=n or omit t
Apply the chosen policy to failing mail.
rua: Aggregate reports URI
The aggregate reports URI specifies where regular summary reports defined by RFC 9990 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 DMARC monitoring 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
Aggregate report addresses
rua=mailto:dmarc-reports@example.com rua=mailto:dmarc-reports@example.com,mailto:security-team@example.com
Report content
- Senders: IP addresses sending email for your domain.
- Results: Authentication results (SPF, DKIM, DMARC).
- Volume: Message volumes and disposition.
- Domain: Organizational domain information.
- Policy: Policy evaluation results.
Size limits
Older DMARC records used the ! syntax to request maximum report size limits. RFC 9989 marks that size suffix as obsolete syntax, so reporters should ignore the limit if it appears in a record. In older records, this example requested reports up to 10 megabytes in size.
Obsolete aggregate report size limit
rua=mailto:dmarc-reports@example.com!10m
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.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
sp: Subdomain policy
The subdomain policy tag allows you to specify a different DMARC policy for existing subdomains than your main domain. RFC 9989 separates existing subdomains from non-existent subdomains, which use the np tag when it is present.
Purpose
Sets a specific policy for existing subdomains that differs 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, existing subdomains inherit the policy specified in p unless a more specific DMARC Policy Record applies through DNS Tree Walk policy discovery. Non-existent subdomains can be controlled separately with np.
Examples
Subdomain policy examples
v=DMARC1; p=reject; sp=quarantine v=DMARC1; p=quarantine; sp=none
Use cases
- Staging: Staging subdomain policies during implementation.
- Security: Different security requirements for different subdomains.
- Protection: Protecting main domain while monitoring subdomains.
- Services: Accommodating third-party services on subdomains.
np: Non-existent subdomain policy
The non-existent subdomain policy tag lets a DMARC Policy Record set a separate policy for subdomains that do not exist. RFC 9989 uses np during DNS Tree Walk policy discovery when the Author Domain is a non-existent subdomain of the discovered policy domain.
Purpose
Sets the Domain Owner Assessment Policy for non-existent subdomains when the applied DMARC Policy Record is found at the Organizational Domain or PSD.
Available values
Same as p: none, quarantine, or reject.
Default value
If np is omitted, non-existent subdomains use sp when sp is present. If neither np nor sp applies, they use the p policy.
Examples
Non-existent subdomain policy examples
v=DMARC1; p=none; sp=quarantine; np=reject v=DMARC1; p=quarantine; np=reject
Use cases
- Anti spoofing: Reject mail claiming to come from subdomains that should not exist.
- Safer inheritance: Keep a different policy for active subdomains and non-existent subdomains.
- DNS Tree Walk: Applies when the discovered policy record covers a missing Author Domain.
psd: Public suffix domain flag
The public suffix domain flag tells receivers whether the DMARC Policy Record is published for a Public Suffix Domain, a normal organizational domain, or an unknown case that requires DNS Tree Walk evaluation.
Purpose
Helps receivers determine the Organizational Domain and DMARC Policy Domain during RFC 9989 DNS Tree Walk policy discovery.
Available values
- psd=y: The record is published by a Public Suffix Operator for a Public Suffix Domain.
- psd=n: The record is not a PSD record, and this domain is the Organizational Domain for itself and its subdomains.
- psd=u: The default unknown state. Receivers use DNS Tree Walk to determine the Organizational Domain.
Default value
u - unknown, use DNS Tree Walk to determine domain role.
Examples
Public suffix domain flag examples
v=DMARC1; p=reject; psd=n v=DMARC1; p=reject; psd=y
Important notes
- PSO use: Public Suffix Operators that publish DMARC Policy Records must use psd=y.
- Organizational domains: psd=n can mark a normal domain as the Organizational Domain for its subtree.
- Default: Most ordinary domain records can omit psd unless they need explicit Organizational Domain handling.
t: Policy test mode
The policy test mode tag signals whether the Domain Owner wants the declared p, sp, or np policy applied normally or treated as a test. It replaces some old pct rollout use cases in DMARCbis.
Purpose
Lets a domain publish a quarantine or reject policy while asking receivers to apply a one-level-lower policy during testing.
Available values
- t=y: Test mode. quarantine is handled like none, and reject is handled like quarantine for failing mail.
- t=n: Normal policy application. This is also the default when t is omitted.
Default value
n - apply the declared Domain Owner Assessment Policy normally.
Examples
Policy test mode examples
v=DMARC1; p=quarantine; t=y v=DMARC1; p=reject; t=y v=DMARC1; p=reject; t=n
Important notes
- Reports: The t tag does not affect DMARC report generation.
- No effect on none: t has no effect on a policy value of none.
- Rollout: Use t=y for policy testing, then remove t or set t=n for normal enforcement.
pct: Percentage
The percentage tag is historic under RFC 9989. It was used by RFC 7489 deployments to request percentage-based enforcement, but new records should use staged policy changes and the t tag for DMARCbis test mode instead.
Purpose
Historically controlled what percentage of emails failing DMARC authentication should have the policy applied. RFC 9989 removed pct from active DMARC Policy Record syntax because operational results were inconsistent.
Value range
Historic RFC 7489 syntax allowed integers from 0 to 100.
Default value
Under RFC 7489 the default was 100. Under RFC 9989, pct is historic and should be omitted from new records.
Examples
Percentage examples
v=DMARC1; p=quarantine; pct=10 v=DMARC1; p=quarantine; pct=50
Implementation strategy
- Start: Use p=none with rua until legitimate sending sources pass DMARC.
- Test: If you need DMARCbis test mode, publish the target policy with t=y instead of pct.
- Monitor: Review aggregate reports for 1-2 weeks.
- Enforce: Remove t, or set t=n, when you are ready for the full policy.
Important notes
- Historic tag: Do not use pct in new DMARCbis records.
- Reports: Aggregate reports are controlled by rua, not pct.
- Test mode: Use t=y when you need DMARCbis policy testing behavior.
- Receiver handling: Older receivers might still recognize pct, but RFC 9989 marks it historic.
Example policy rollout
A staged rollout can move from monitoring to DMARCbis test mode, then full enforcement after report review.
Rollout stage
ruf: Failure reports URI
The failure reports (forensic reports) URI requests detailed reports for individual emails that fail DMARC authentication. RFC 9991 defines DMARC failure reporting, and many receivers still limit or redact these reports.
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). RFC 9991 covers the DMARC failure report format.
Default value
None - if omitted, no failure reports will be sent.
Examples
Failure report examples
ruf=mailto:dmarc-forensic@example.com ruf=mailto:dmarc-forensic@example.com; fo=1
Report content
- Headers: Complete email headers from failed messages.
- Failures: Authentication failure details.
- Policy: Policy evaluation results.
- Content: Sometimes partial message content (often redacted).
Limitations
- Support: Many email providers do not send failure reports because of privacy concerns.
- Redaction: Reports are often heavily redacted or incomplete.
- Volume: Volume can be high for domains with many authentication failures.
- Monitoring: Not reliable for primary monitoring - use aggregate reports instead.
fo: Failure options
The failure options tag controls when failure reports are generated, providing fine-grained control over report triggering conditions.
Purpose
Specifies the conditions under which failure reports defined by RFC 9991 should be generated. Only relevant when the ruf tag is also present.
Available values
- fo=0: Generate reports only when both SPF and DKIM fail DMARC alignment with the visible from domain.
- fo=1: Generate reports when either SPF or DKIM fails DMARC alignment. Most comprehensive option.
- fo=d: Generate reports for any DKIM signature failure, regardless of alignment.
- fo=s: Generate reports for any SPF failure, regardless of alignment.
Default value
0 - reports generated only when both SPF and DKIM fail DMARC alignment.
Examples
Failure option examples
v=DMARC1; p=none; ruf=mailto:forensic@example.com; fo=1 v=DMARC1; p=none; ruf=mailto:forensic@example.com; fo=d v=DMARC1; p=none; ruf=mailto:forensic@example.com; fo=1:d:s
Combining multiple options
You can specify multiple failure reporting options by separating them with colons, but RFC 9989 makes 0 and 1 mutually exclusive. This allows you to receive reports for different types of failures simultaneously.
- fo=0:d: Reports when all underlying aligned mechanisms fail, plus DKIM-specific failures.
- fo=1:d:s: Reports for alignment failures plus any SPF or DKIM failures.
- fo=1:s: Reports when any aligned mechanism fails, plus SPF-specific 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 DMARC alignment.
- 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. Under RFC 9989, relaxed alignment uses the Organizational Domain found through DNS Tree Walk.
Purpose
Determines how closely the DKIM signature domain must match the From header domain for DMARC to consider DKIM as aligned.
Available values
- adkim=r: Allows organizational domain matching as determined by DNS Tree Walk. A DKIM signature from "mail.example.com" aligns with "newsletter@example.com".
- adkim=s: Requires exact domain matching. The DKIM signature domain must exactly match the From header domain.
Default value
r (relaxed) - allows organizational domain matching as determined by DNS Tree Walk.
Examples
DKIM alignment examples
v=DMARC1; p=quarantine; adkim=r v=DMARC1; p=quarantine; adkim=s
Alignment examples
- Exact match: user@example.com with example.com passes relaxed and strict.
- Subdomain signer: user@example.com with mail.example.com passes relaxed and fails strict.
- Subdomain from: user@sub.example.com with example.com passes relaxed and fails strict.
Recommendation
Most organizations should use relaxed alignment (default) as it accommodates common email service configurations where DKIM signing domains differ from the visible 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 match the From header domain for DMARC authentication to pass. Under RFC 9989, relaxed alignment uses the Organizational Domain found through DNS Tree Walk.
Purpose
Determines how closely the Return-Path domain must match the From header domain for DMARC to consider SPF as aligned.
Available values
- aspf=r: Allows organizational domain matching as determined by DNS Tree Walk. Return-Path "bounce@mail.example.com" aligns with "user@example.com".
- aspf=s: Requires exact domain matching. The Return-Path domain must exactly match the From header domain.
Default value
r (relaxed) - allows organizational domain matching as determined by DNS Tree Walk.
Examples
SPF alignment examples
v=DMARC1; p=quarantine; aspf=r v=DMARC1; p=quarantine; aspf=s
Alignment examples
- Same domain: user@example.com with bounce@example.com passes relaxed and strict.
- Subdomain bounce: user@example.com with bounce@mail.example.com passes relaxed and fails strict.
- External bounce: user@example.com with bounce@mailservice.com fails relaxed and strict.
Important considerations
- Providers: Many email service providers use their own domains in Return-Path for bounce handling.
- Difficulty: SPF alignment is often more challenging than DKIM alignment.
- Compatibility: Relaxed alignment accommodates common email service configurations.
- Strictness: Strict alignment can break legitimate email from third-party services.
rf: Report format
The report format tag is historic under RFC 9989. Earlier DMARC records used rf to request a failure report format, but new DMARCbis records should omit it.
Purpose
Historically specified the format for failure reports. RFC 9989 moved rf to historic status; DMARC failure reporting is now defined by RFC 9991 and the active report format registry.
Available values
The historic value was afrf (Authentication Failure Reporting Format). The afrf report format remains registered, but rf is no longer an active DMARC policy tag.
Default value
No active default under RFC 9989. Older records defaulted to afrf.
Examples
Report format examples
v=DMARC1; p=none; ruf=mailto:forensic@example.com; rf=afrf v=DMARC1; p=none; ruf=mailto:forensic@example.com
Recommendation
Omit this tag in new DMARCbis records. Only leave it in place when maintaining an older record and you have confirmed the receiver still expects it.
ri: Reporting interval
The reporting interval tag is historic under RFC 9989. Earlier DMARC records used ri to request how often aggregate reports should be sent, but RFC 9990 now defines aggregate reporting without ri as an active DMARC policy tag.
Purpose
Historically suggested the requested interval between aggregate reports, specified in seconds. This was always a preference, not a requirement, and it is now historic.
Value format
Historic syntax used a positive integer representing seconds between reports.
Default value
No active default under RFC 9989. Under RFC 7489, 86400 seconds was the default.
Examples
Reporting interval examples
ri=86400 ri=604800 v=DMARC1; p=none; rua=mailto:reports@example.com; ri=86400
Common intervals
- Daily: 86400 seconds. This was the common historic value.
- Weekly: 604800 seconds. This was used by some lower volume domains.
- Hourly: 3600 seconds. This was advisory and not reliable for urgent monitoring.
Important limitations
- Historic tag: RFC 9989 removed ri from active DMARC Policy Record syntax.
- Provider control: Most email providers sent reports on their own schedule even when ri was present.
- Volume: Some providers sent reports less frequently based on volume.
- Urgency: Do not rely on ri for time-sensitive monitoring.
Recommendation
Omit this tag in new DMARCbis records. Use aggregate reports when receivers send them and build monitoring around the actual report cadence you receive.
Complete DMARC record examples
Here are practical examples of complete DMARC records for different deployment scenarios, from initial monitoring to full enforcement.
Monitoring only
Monitoring only
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;
This record is in monitoring mode and requests aggregate reports defined by RFC 9990 to be sent to the specified email address. Perfect for initial deployment and understanding your email ecosystem.
Gradual quarantine
Gradual quarantine
v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-reports@example.com;
This record requests a quarantine policy while signaling DMARCbis test mode. Receivers that honor t=y can apply handling one level below the requested policy while aggregate reports continue.
Full protection with failure reports
Full protection with failure reports
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 aggregate reports plus DMARC failure reports defined by RFC 9991. Maximum protection for mature deployments.
Advanced configuration
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 existing subdomains, requires strict alignment for both SPF and DKIM, and sends aggregate reports.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Conclusion
A working DMARC record needs only two tags, v and p, but a useful DMARC deployment usually includes rua so you can see who is sending mail for the domain. The optional tags then help you control subdomains, staged enforcement, failure reports, and matching rules.
After publishing a record, use a DMARC checker to confirm the syntax, then monitor reports before moving to a stricter policy. Suped is the best overall DMARC platform for teams that want these tags monitored and managed, not just documented. Suped's product turns aggregate reports into source inventory, automated issue detection, real-time alerts, hosted DMARC, hosted SPF, hosted MTA-STS, SPF flattening, blocklist (blacklist) monitoring, and multi-tenant workflows for MSPs.
