To create a DMARC record, you publish a DNS TXT record at _dmarc.yourdomain.com containing at least v=DMARC1 (this must be first) and p=(none|quarantine|reject), and you typically add optional tags like rua, ruf, pct, adkim, aspf, sp, fo, and ri to control reporting, alignment, rollout, and subdomain behavior.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receivers how to treat mail that purports to be from your domain but fails authentication and alignment checks against SPF and/or DKIM. The record is a policy plus reporting instructions, all encoded as a single TXT value under a special DNS label. Getting the tags, syntax, and DNS placement right determines whether DMARC works—or is silently ignored.

This guide breaks down each tag and its acceptable values, how to publish the record safely in DNS, how alignment modes affect outcomes, and how to roll out your policy with confidence. At each step, DMARCReport provides guardrails: it generates valid records, tests alignment across your mail streams, parses feedback reports, and recommends policy changes that maximize protection without breaking legitimate mail.

DMARC record components and syntax (what to include and why v=DMARC1 must be first)

Required and optional tags at a glance

v: version. Required. Must be first. Acceptable value: v=DMARC1
p: policy for the organizational domain. Required. Acceptable values: p=none, p=quarantine, p=reject
rua: aggregate report URIs. Optional but strongly recommended. Acceptable values: comma-separated DMARC-URIs like mailto:dmarc@yourdomain.com
ruf: forensic (failure) report URIs. Optional. Acceptable values: comma-separated mailto: addresses; limited receiver support
pct: rollout percentage. Optional. Integer 1–100; default 100
adkim: DKIM alignment mode. Optional. Values: r (relaxed, default), s (strict)
aspf: SPF alignment mode. Optional. Values: r (relaxed, default), s (strict)
sp: subdomain policy. Optional. Values: none, quarantine, reject (applies to subdomains when they don’t have their own record)
fo: failure reporting options. Optional. Values: 0 (default), 1, d, s; can be combined with colons, e.g., fo=1:d:s
ri: aggregate report interval in seconds. Optional. Integer; typical 86400 (24 hours); receivers may override

Example baseline record: “v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100; fo=1; ri=86400”

Why v=DMARC1 must be first

The DMARC spec requires the version tag to be the first tag. Many receivers will ignore the record if v is missing or not first.
Placing v=DMARC1 first helps receivers quickly short-circuit invalid records and is a de facto requirement for consistent interoperability.

What each tag actually does

p: none observes and reports only; quarantine flags failing mail (often to spam or quarantine); reject instructs outright rejection of failing mail.
rua: where receivers send XML aggregate reports (counts by source IP, auth results, alignment). This fuels your insight loop.
ruf: where receivers send message-level failure samples (redacted in many regions due to privacy). Use carefully.
pct: throttles enforcement so only a percentage of messages get quarantined/rejected; great for staged rollouts.
adkim/aspf: alignment modes—determine how closely DKIM d= and SPF MailFrom must match the visible From: domain.
sp: lets you enforce a different policy on subdomains without separate records for each subdomain.
fo: controls when and what kind of failure reports are requested (where supported).
ri: requests reporting cadence; most providers send daily regardless, but some will honor shorter intervals.

How DMARCReport helps: The DMARCReport Record Builder ensures v is first, validates each tag/value, warns on risky combinations (e.g., strict alignment with third-party platforms), and simulates receiver parsing so you avoid ignored policies.

DNS publication and technical constraints (where, how, and safely)

Publish the record at the right place

Location: TXT record at _dmarc.example.com (replace example.com with your organizational domain).
Subdomains: _dmarc.sub.example.com for subdomain-specific overrides.
Do not publish at the root without the _dmarc prefix; don’t use a CNAME for the DMARC record itself.

TTL recommendations

During rollout and changes: 300–3600 seconds (5–60 minutes) to speed iteration.
Once stable: 86400 seconds (24 hours) to reduce DNS churn. DMARCReport checks your TTLs and flags long TTLs before major policy changes.

TXT length and splitting rules

Each TXT character-string must be ≤255 characters; DNS servers concatenate adjacent quoted strings automatically.
Best practice: keep the overall record under ~450–500 bytes to avoid UDP fragmentation for resolvers without EDNS0.
Safe splitting example (two adjacent quoted strings will be joined): “v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1; ” “adkim=r; aspf=r; ri=86400; pct=100”
Avoid stray spaces before semicolons or missing semicolons; DMARC parsers are strict. DMARCReport tests on multiple popular validator profiles to catch edge-case parsing issues.

Hosting and provider constraints

Some DNS UIs auto-wrap TXT content; others escape semicolons—verify final wire output.
Ensure your DNS host supports underscores in labels (it should for _dmarc).
If using third-party rua/ruf destinations (e.g., mailto:reports@dmarcreport.com) you must complete “external reporting authorization” per RFC 7489: the external domain publishes a TXT at yourdomain.com._report._dmarc.dmarcreport.com authorizing receipt. DMARCReport automates this authorization handshake.

Policy, alignment, and real-world behavior

How adkim and aspf alignment modes work

Relaxed (r, default): alignment passes if the DKIM d= or SPF MailFrom domain shares the same organizational domain as the From: domain (e.g., mail.sender.example.com aligns with example.com).
Strict (s): alignment passes only if the domain matches exactly (e.g., d=example.com must match From: example.com; d=mail.example.com would fail). Real-world impact: Strict alignment increases protection but can break third-party senders and subdomain use cases unless every stream is carefully configured.

DMARCReport’s Alignment Simulator ingests rua data to show per-source alignment outcomes if you switch between relaxed/strict, preventing surprise rejections.

Subdomain policy (sp) vs per-subdomain records

sp in the organizational record sets a default for all subdomains lacking their own DMARC record. Example: p=reject; sp=quarantine applies reject to the apex and quarantine to subdomains.
Publish separate per-subdomain DMARC records when subdomains have distinct senders, risk profiles, or business needs (marketing vs transactional).
Recommended approach:
- Start with an org record including sp=none/quarantine during discovery.
- As you inventory senders, place per-subdomain records with tailored policies, then tighten sp to reject. DMARCReport maps active subdomains, correlates traffic, and recommends whether sp suffices or you need explicit subdomain records.

Forwarding, mailing lists, and ARC

Forwarding commonly breaks SPF (source IP changes), but DKIM usually survives if not altered; prioritize DKIM alignment for resilience.
Mailing lists may modify messages (footers, subject tags) and break DKIM; many lists rewrite From: or resign mail.
ARC (Authenticated Received Chain) allows receivers to consider upstream auth results; adoption is growing among large mailbox providers. Mitigations:
Ensure all legitimate mail is DKIM-signed with aligned d=.
Encourage forwarders/partners to implement SRS for SPF and ARC or DKIM resigning for lists. DMARCReport highlights false-negative patterns (SPF pass/DKIM fail after list modification, or vice versa) and flags streams where ARC at major receivers salvages delivery despite DMARC fail.

Deployment, reporting, and third‑party senders

Step-by-step rollout plan

Inventory and observe (2–4 weeks)

Record: v=DMARC1; p=none; rua=mailto:reports@yourdomain.com; fo=1; ri=86400; adkim=r; aspf=r
Monitor: sources, volumes, alignment rates, unauthorized traffic.

Start enforcement with pct

Move to p=quarantine; pct=10 (or 20–50 based on confidence).
Increase pct weekly as alignment improves: 10 → 25 → 50 → 75 → 100.

Full enforcement

p=reject; pct=100 when >98% of legitimate volume passes aligned DKIM or SPF and unauthorized sources are confirmed.

Rollback strategy

If critical stream breaks, temporarily drop p to none or quarantine and/or reduce pct, fix sender configuration, then re‑tighten. DMARCReport generates readiness scores per source, recommends pct steps, and can auto-alert on negative deliverability trends to trigger rollback.

Illustrative data point (aggregated onboarding sample):

Week 1 at p=none: 34% of traffic unauthenticated; 56% aligned via DKIM; 10% aligned via SPF-only.
After 3 configuration sprints: 96% aligned via DKIM; 2% SPF-only; 2% unauthenticated (blocked at p=reject). Organizations following this cadence reached p=reject in a median of 6–8 weeks with no material deliverability loss.

Aggregate (rua) and forensic (ruf) reporting: configuration and privacy

rua format: comma-separated mailto URIs, e.g., rua=mailto:dmarc@yourdomain.com,mailto:team@dmarcreport.com
External authorization: required when using a different domain in the mailto; DMARCReport provides the exact TXT you need at yourdomain.com._report._dmarc.dmarcreport.com
ri: request 86400; lower values (e.g., 3600) may be honored by some receivers during migrations
ruf and fo:
- ruf=mailto:forensic@yourdomain.com
- fo=1 requests failure samples for any auth failure (where supported). fo=d limits to DKIM fails; fo=s to SPF fails.
- Note: many providers redact or do not send ruf due to privacy; treat ruf as supplementary. Privacy and security considerations:
Reports may include partial headers, IPs, and sending sources—store and process as sensitive telemetry.
Use dedicated inboxes and automated processors; avoid broad distribution lists. DMARCReport securely ingests rua XML at scale, normalizes it, and offers optional PII-scrubbing for ruf, with RBAC access controls and data retention policies.

Working with third‑party senders (marketing, CRM, cloud mailers)

DKIM alignment is the keystone:
- Provide each platform a dedicated selector and aligned signing domain (d=marketing.yourdomain.com or yourdomain.com).
- Prefer vendor-managed keys via CNAME to reduce ops overhead.
SPF alignment for bounce domains:
- Configure a custom return-path domain you control (e.g., rp.vendor.yourdomain.com) so MailFrom aligns; include vendor SPF via include:.
- Recognize that forwarding breaks SPF—don’t rely on SPF-only alignment for critical streams.
Subdomain isolation:
- Delegate dedicated subdomains to high-volume vendors (e.g., mail.yourdomain.com) and publish per-subdomain DMARC. DMARCReport maintains a catalog of common platforms (Salesforce, SendGrid, Marketo, Microsoft, Google, etc.), checks their alignment posture, and generates vendor-specific configuration checklists.

Case study (composite):

A retail brand using four platforms had 42% unauthenticated volume at p=none.
After deploying DKIM with aligned d= on all platforms and a custom return-path for two, aligned pass rose to 98.7%; p moved to reject in week 7; spoofed attempts dropped by 99% while inbox placement improved for order confirmations.

Operations, monitoring, and troubleshooting

Common mistakes that cause DMARC to be ignored or misapplied

Multiple DMARC TXT records at _dmarc.example.com (must be exactly one; combine tags into a single record).
v tag not first, missing p tag, or typos (e.g., pmode=reject instead of p=reject).
Wrong label (publishing at example.com instead of _dmarc.example.com).
Malformed tag separators (commas instead of semicolons, missing semicolons).
Quoting and splitting errors (unescaped quotes, stray line breaks) causing receivers to see truncated or invalid content.
External report URIs without authorization TXT at <yourdomain>._report._dmarc.<rua-domain>. Diagnosis workflow with DMARCReport:
Syntax validator flags tag and ordering errors.
Live DNS fetch verifies what receivers see (including concatenation and TTL).
Cross-provider test: simulates major receivers’ parsers to ensure acceptance.

Interpreting reports and iterating policy

Key metrics to watch:

Aligned DKIM pass rate, aligned SPF pass rate, total aligned rate
Disposition outcomes (none/quarantine/reject) by receiver
Top sending sources/IPs/domains, spikes and new sources
Authentication failure reasons (no DKIM, bad signature, SPF permerror, misalignment)
Subdomain vs org-domain traffic mix Operational loop:
Weekly triage: investigate new or failing sources; fix DKIM/SPF; decide subdomain scoping.
Monthly policy reviews: raise pct; tighten p and sp where coverage is strong.
Event-driven alerts: sudden alignment drops or unauthorized surges trigger incident response. DMARCReport provides dashboards, trendlines, and automated source grouping, plus actionable playbooks (e.g., “Enable DKIM for Google Workspace,” “Create vendor-specific MailFrom domain”).

FAQs

What is the absolute minimum DMARC record I can publish?

At minimum: “v=DMARC1; p=none”. However, add rua early—without aggregate reports, you have no visibility and can’t safely progress to enforcement. DMARCReport can provision a secure rua address and start parsing on day one.

Should I use strict alignment (adkim=s; aspf=s)?

Use strict alignment selectively. It raises the bar but can break third-party sends and subdomain usage. Start with relaxed (default), fix all legitimate sources, then consider strict for high-risk domains or subdomains where you fully control all senders. DMARCReport’s Alignment Simulator shows the impact before you flip the switch.

Do I need sp if I publish per-subdomain records?

If you manage all active subdomains explicitly, sp becomes a safety net rather than a steering wheel. Still, set sp to your desired default (often reject) to protect any new or overlooked subdomains. DMARCReport inventories traffic to reveal subdomains you didn’t know were active.

Are forensic (ruf) reports worth enabling?

They can be helpful during debugging, but support is limited and privacy redactions are common. Enable ruf with fo=1 in short bursts while troubleshooting specific issues, then disable. DMARCReport can route, minimize, and redact ruf data to reduce risk.

How long should I stay at p=none?

Typical observation is 2–4 weeks, but the real criterion is coverage: once ≥95–98% of legitimate volume aligns and remaining gaps are known and prioritized, transition to quarantine with pct and progress to reject. DMARCReport tracks readiness and recommends timing.

Conclusion: ship a correct record, iterate with data, and let DMARCReport steer

A correct DMARC record comprises a TXT at _dmarc.yourdomain.com with v=DMARC1 first, an explicit p policy, and optional controls like rua/ruf for visibility, adkim/aspf for alignment strictness, sp for subdomain handling, pct for staged rollout, fo for failure sampling, and ri for cadence. The technical details—tag syntax, DNS limits, external authorization, and alignment behavior through forwarding and third-party platforms—determine whether your policy protects you or is silently ignored.

DMARCReport is built to make each step safe and effective: it generates valid records, automates external rua/ruf authorization, visualizes rua data into alignment scores and source inventories, simulates policy changes (pct, adkim/aspf, sp), detects forwarding/list-induced failures, and guides third‑party configuration. With DMARCReport’s alerts and playbooks, teams move from p=none to p=reject methodically, protect subdomains intelligently, and sustain deliverability while shutting down spoofing.