A DMARC record is a set of policy decisions expressed in the DNS. Two DMARC records can both be technically valid while representing completely different security postures – one actively blocking unauthorized messages, the other wide open to spoofing.
This post is a practical DMARC record format reference. It covers what each DMARC tag controls, how each affects enforcement, and what different configurations signal about security stance. Understanding the DMARC record format means treating each tag as a deliberate choice – not a default to leave unchanged.
See what your current DMARC record format is signaling. Run a free domain analysis.
The Baseline: What Every DMARC Record Must Include
Only two DMARC tags are mandatory – everything else is a deliberate addition.
v= (Version)
v=DMARC1 identifies the record version. It must appear first. There are no alternatives or variations.
p= (Policy)
The
p= DMARC tag is the core enforcement decision. It has
three values, each representing a different posture:
- p=none – Monitoring only. Emails are delivered regardless of their authentication results. No domain protection is in place.
- p=quarantine – Failing messages are directed to Spam or Junk. Partial protection.
- p=reject – Failing messages are blocked outright. Full enforcement.
The policy value is the most consequential decision in any DMARC record. This DMARC record example shows the minimum valid configuration:
| Host |
Type |
Value |
_dmarc.yourdomain.com |
TXT |
v=DMARC1; p=none; |
This DMARC record example is technically valid but provides no protection and no reporting visibility. It is only appropriate as a temporary starting point.
Use this table as a quick reference when auditing or
building a DMARC record for your environment.
| Tag |
Values |
Default |
Enforcement Implication |
rua= |
mailto: URI |
None |
Aggregate report destination |
v= |
DMARC1 |
None |
Version identifier |
p= |
none, quarantine, reject |
None |
Core policy decision |
ruf= |
mailto: URI |
None |
Forensic report destination |
fo= |
0, 1, d, s |
0 |
Forensic report scope |
adkim= |
r, s |
r (relaxed) |
DKIM alignment strictness |
aspf= |
r, s |
r (relaxed) |
SPF alignment strictness |
sp= |
none, quarantine, reject |
Inherits p= |
Subdomain coverage |
Configuration One: New Deployment
Scenario: A domain publishing DMARC for the first time. SPF and DKIM are configured, but sending sources haven’t been fully mapped. The goal is to collect aggregate report data before making any enforcement decisions.
This DMARC record format is the recommended starting point:
| Host |
Type |
Value |
_dmarc.yourdomain.com |
TXT |
v=DMARC1; p=none; rua=mailto:[email protected]; |
DMARC tags breakdown:
- p=none – No action taken on failing messages. Protects against disruption while infrastructure is being mapped.
rua= – The reporting DMARC tag that directs aggregate reports to a monitored mailbox or reporting service. Without it, the monitoring phase produces no usable data.
What this record signals: The domain owner is beginning the DMARC process. No
enforcement is in place. The domain remains vulnerable to spoofing.
This DMARC record format is only appropriate as a starting point. Remaining at
p=none indefinitely is not a security strategy.
Configuration Two: Partial Enforcement
Scenario: Aggregate reports have been reviewed. Most legitimate sending sources are authenticated. The domain is moving toward enforcement, but the team wants to validate before committing to reject.
This DMARC record format introduces quarantine and forensic reporting. The DMARC record example below is appropriate when most senders are authenticated, but the team isn’t yet ready to move to reject:
DMARC tags breakdown:
- p=quarantine – Failing messages are directed to Spam or Junk rather than rejected. Allows the team to catch edge cases before moving to p=reject.
ruf= – The forensic reporting DMARC tag. Enables reports for individual failing messages. Note that support for RUF reporting varies across receiving providers and is not universally supported.fo=1 – Generates a forensic report if either SPF or DKIM fails (the default fo=0 only reports when both fail). Recommended for broader visibility during this phase.
What this record signals: Active enforcement in progress. The domain is protected against most spoofing attempts, but failing messages are still delivered to Junk rather than blocked.
Configuration Three: Full Enforcement
Scenario: All legitimate sending sources are authenticated and passing. The domain is ready for full enforcement.
This DMARC record format represents the target enforcement state. The DMARC record example below applies when all sending sources are authenticated and passing:
| Host |
Type |
Value |
_dmarc.yourdomain.com |
TXT |
v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=r; aspf=r; |
DMARC tags breakdown:
- p=reject – Failing messages are blocked. This is the target state for any domain serious about email security.
adkim=r and aspf=r – Relaxed alignment (the default). Allows the root domain to match even when messages are sent from a subdomain or a third-party. Strict alignment (adkim=s, aspf=s) should only be used when the sending environment is tightly controlled and fully mapped.
What this record signals: Full enforcement. Unauthorized messages are rejected. This DMARC record format is appropriate for most sending environments.
Configuration Four: Complex Sending Environment
Scenario: A domain sends through multiple third-party services – a marketing platform, CRM, transactional email provider, and HR system. Subdomains are used by separate business units with different sending sources.
This DMARC record format balances full enforcement on the primary domain with subdomain flexibility. The DMARC record example below suits companies with multiple sending services and independently managed subdomains:
DMARC tags breakdown:
- p=reject – Full enforcement on the organizational domain.
sp=quarantine – A more cautious policy for subdomains. Useful when subdomain sending sources are still being mapped or when different teams manage subdomain sending independently.adkim=r and aspf=r – Relaxed alignment is essential here. Strict alignment would cause failures across third-party senders that use their own subdomains.ruf= and fo=1 – Forensic reporting DMARC tags enabled with broad scope. Critical when investigating authentication failures across a distributed sending environment.
What this record signals: A mature DMARC record format balancing full enforcement on the primary domain with caution on subdomains. Appropriate for businesses with distributed teams and complex sending infrastructure.
Getting the DMARC record format right for a single domain is one challenge. Keeping it accurate across a growing portfolio – and knowing when a configuration needs to change – is where the work starts.
Security and IT teams dealing with unauthenticated senders, misconfigured DMARC tags, or distributed sending environments run into the same problems: Manual investigation, gaps in visibility, and policy drift across departments and regions. Auditing DMARC tags across dozens of domains manually is not a scalable process.
Sendmarc’s
DMARC Management Platform gives teams continuous visibility into every record, every sending source, and every authentication failure across all domains.
Sendmarc helps you:
- Gain unified visibility into all SPF, DKIM, and DMARC configurations
- Identify unauthorized or unknown email senders before they cause damage
- Reduce manual investigation of misconfigurations across domains and subdomains
- Standardize email authentication policies across departments, regions, and subsidiaries
- Maintain continuous security improvements without increasing internal workload
See what full DMARC visibility looks like.
