Table of Contents
- Copy-Paste DMARC Record Examples by Policy
- Ten examples from monitoring to enforcement
- How to verify it
- Where the DMARC Record Lives in DNS
- The exact host and record type
- How to verify it
- What Each DMARC Tag Means
- DMARC tag reference
- The three tags that cause the most confusion
- Setting Up Reporting With rua, ruf and External Addresses
- Multiple addresses and external authorization
- How to verify it
- What Quarantine Does and How pct Limits It
- What pct changes
- The exit check before raising pct
- How to verify it
- Enforcing Reject With sp, adkim and aspf
- Controlling subdomains with sp
- Tightening alignment with adkim and aspf
- How to verify it
- Staged Rollout From p=none to p=reject
- The six rollout steps
- Rollout stages and exit checks
- How to verify it
- Common DMARC Record Mistakes and Fixes
- The mistakes that hide behind a valid looking record
- Common DMARC Record Questions Answered
- What should you do when a legitimate third party fails alignment
- Can a domain that never sends mail use p=reject
- Why are there no DMARC reports after publishing
- Does passing SPF and DKIM make DMARC optional
- Verify Your Record Before Moving to Reject
- How to verify it
Do not index
Do not index
Copying the most popular DMARC record example,
v=DMARC1; p=none; rua=mailto:dmarc@example.com, doesn't protect a domain from spoofing. That record is valid, but p=none only requests monitoring, so receivers still deliver failing mail normally. Protection starts only after reports prove every legitimate sender aligns, and the policy moves safely toward quarantine or reject.Table of Contents
Copy-Paste DMARC Record Examples by PolicyTen examples from monitoring to enforcementHow to verify itWhere the DMARC Record Lives in DNSThe exact host and record typeHow to verify itWhat Each DMARC Tag MeansDMARC tag referenceThe three tags that cause the most confusionSetting Up Reporting With rua, ruf and External AddressesMultiple addresses and external authorizationHow to verify itWhat Quarantine Does and How pct Limits ItWhat pct changesThe exit check before raising pctHow to verify itEnforcing Reject With sp, adkim and aspfControlling subdomains with spTightening alignment with adkim and aspfHow to verify itStaged Rollout From p=none to p=rejectThe six rollout stepsRollout stages and exit checksHow to verify itCommon DMARC Record Mistakes and FixesThe mistakes that hide behind a valid looking recordCommon DMARC Record Questions AnsweredWhat should you do when a legitimate third party fails alignmentCan a domain that never sends mail use p=rejectWhy are there no DMARC reports after publishingDoes passing SPF and DKIM make DMARC optionalVerify Your Record Before Moving to RejectHow to verify it
Copy-Paste DMARC Record Examples by Policy
A DMARC policy is one TXT record published at _dmarc.example.com, starting with v=DMARC1 followed by a p tag. Each record below belongs to a rollout stage, and each stage pairs with an exit check: the condition reports must satisfy before the policy tightens.
Ten examples from monitoring to enforcement
Every address and domain below uses example.com as a placeholder. These are syntax examples, not deployed configurations, so the domain and report mailboxes must be replaced before publication.
Stage | Record value | What it does | Exit check before moving on |
Monitor | v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com | Collects aggregate reports without changing delivery | Reports identify every legitimate sender, and each one aligns on SPF or DKIM |
Monitor with two report addresses | Sends aggregate reports to two mailboxes | Both mailboxes receive reports, so no sender's results are lost | |
Partial quarantine | v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com | Applies quarantine to about 25% of failing mail | Reports show the quarantined share contains only illegitimate mail |
Full quarantine | v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com | Asks receivers to treat all failing mail as suspicious | A quarantine period ends with no legitimate mail among the failures |
Reject | v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com | Asks receivers to reject failing mail outright | Reports confirm remaining failures are spoofing, not misconfigured senders |
Subdomain policy | v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc-reports@example.com | Rejects on the root domain while subdomains are quarantined | Every subdomain that sends mail is inventoried and its sources align |
Strict alignment | v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:dmarc-reports@example.com | Requires exact domain match for DKIM and SPF | All legitimate senders authenticate with the exact From domain |
Forensic reporting | v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com; fo=1 | Requests failure reports when any check fails; support varies by receiver | The forensics mailbox demonstrably receives and stores the reports |
External reporting | v=DMARC1; p=reject; rua=mailto:dmarc@reports.example.net | Sends aggregate reports to a third-party domain that must authorize them | The receiving domain has published the authorization record permitting it |
Production baseline | Full enforcement on the domain and all subdomains | Ongoing reports show zero legitimate failures, rechecked after any new sender is added |
Read the last column carefully. A policy is safe to adopt when its check passes, not when a calendar date arrives.
The fastest way to assemble the right text is to pick a policy in the mailX DMARC generator, which returns the record name and value ready to publish. Publishing is still a manual step in the DNS console. When the policy changes, the existing record is edited in place. A second DMARC TXT record at the same host creates ambiguity rather than a stronger policy.
How to verify it
After publishing, check the live DMARC record before treating the stage change as done. A good result shows one record at _dmarc beginning v=DMARC1 with the intended p value and the correct rua address. A bad result shows a missing record, a duplicate record, or a different p value than planned. Fix the discrepancy, wait for DNS propagation, and check again.
Stage changes fail on small publishing errors: the right record at the wrong host, or the old policy still cached by resolvers. The live answer is what receivers act on, so it is the only version worth trusting.
Where the DMARC Record Lives in DNS
Domain-based Message Authentication, Reporting, and Conformance checks whether SPF or DKIM passes and aligns with the visible From domain, then applies the policy the domain owner published. That single mechanism is defined by RFC 7489, the DMARC specification. Readers who need the wider SPF and DKIM context can use the complete email authentication guide and then return to the record itself.
The exact host and record type
According to RFC 7489 in HTML form, a DMARC record is published as a DNS TXT record at the exact host _dmarc.example.com, using semicolon-separated tag-value pairs. The v tag is mandatory and must appear first, and the p tag is also mandatory. That makes
v=DMARC1; p=none the minimal valid record.A CNAME at the _dmarc host doesn't substitute for that TXT record. Receivers look for DMARC policy text, so the published answer must be the tag-value string itself. Whitespace around tags also doesn't substitute for correct semicolons or required tags.
How to verify it
Run a TXT lookup for the _dmarc host to see the raw DNS answer. A good result is one TXT string beginning v=DMARC1 at _dmarc.example.com. A bad result is no answer, a CNAME response, or more than one DMARC string.
DNS changes take time to appear because of TTL caching, so an old answer shortly after an edit isn't always an error. Confirm current TTL behavior in the DNS provider's official documentation, then recheck after the previous TTL expires.
What Each DMARC Tag Means
Only v and p are required for a DMARC policy record, and receivers ignore unknown tags. Per RFC 7489 from the RFC Editor, the record must begin with v=DMARC1, followed immediately by the mandatory p tag, as in
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r. Placing reporting or alignment tags before v and p can make the record invalid or ineffective, even when every individual value looks correct.DMARC tag reference
Tag | Required | Accepted values | Purpose | Example |
v | Yes, must be first | DMARC1 | Identifies the DMARC protocol version | v=DMARC1 |
p | Yes | none, quarantine, reject | Policy for messages that fail DMARC | p=reject |
sp | No | none, quarantine, reject (defaults to the p value) | Policy for subdomains | sp=quarantine |
rua | No, recommended | mailto: URIs, comma-separated | Destinations for aggregate reports | rua=mailto:dmarc-reports@example.com |
ruf | No | mailto: URIs | Destinations for failure reports; receiver support is limited | ruf=mailto:dmarc-forensics@example.com |
pct | No | Integer 0 to 100 (default 100) | Share of failing mail the policy applies to | pct=25 |
fo | No | 0 (default), 1, d, s | Controls when failure reports are generated | fo=1 |
adkim | No | r (relaxed, default), s (strict) | DKIM identifier alignment | adkim=s |
aspf | No | r (relaxed, default), s (strict) | SPF identifier alignment | aspf=s |
The three tags that cause the most confusion
pct defaults to 100 and applies only to mail that fails DMARC under quarantine or reject. It's a rollout dial, not a guaranteed statistical sample, because receivers decide which failing messages fall inside the percentage. With p=none, changing pct doesn't create enforcement, since the requested action itself is still monitoring.
fo controls when failure reports get generated, and it only matters when ruf is present. The default, fo=0, requests a report only when neither SPF nor DKIM produces an aligned pass. fo=1 requests a report when either mechanism fails to produce an aligned pass, while d and s narrow reports to DKIM or SPF evaluation failures. Teams often add fo=1 expecting a rich debugging feed, then receive little because receiver support for failure reporting is limited.
adkim and aspf control how closely the authenticated domain must match the visible From domain. Both default to r, relaxed alignment, where a subdomain can align with the organizational domain. Both accept s, strict alignment, which requires closer domain matching. A DMARC record example such as
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r therefore makes the defaults explicit without changing behavior.Tag behavior comes from the IETF specification, and edge cases shouldn't rest on memory. Confirm current behavior in the latest version of that specification before relying on an unusual tag combination, especially around reporting and percentage sampling. The safe baseline stays simple: v, p, and rua, in that order.
Setting Up Reporting With rua, ruf and External Addresses
The dashboard view below separates the three reporting choices domain owners usually mix together.
rua is the primary reporting mechanism and belongs in the record at every stage. It requests aggregate reports, which summarize authentication results from receivers over a reporting period. Those summaries show source IP addresses, SPF and DKIM outcomes, alignment results, and the disposition applied, which is how forgotten senders get discovered before enforcement. Reporting only becomes useful once somebody reviews those summaries consistently, so teams should improve deliverability with DMARC report analysis rather than treating the mailbox as an archive.
ruf requests failure reports for individual failing messages. It's optional, it isn't universally supported, and reports can contain message-related details. Enabling ruf is a privacy decision, so decide who receives the data first. A domain that routes failure data to a third party should weigh whether the diagnostic value justifies exposing that information.
Multiple addresses and external authorization
Two aggregate destinations go in one rua tag, separated by a comma, like this:
rua=mailto:dmarc-reports@example.com,mailto:security@example.com. Publishing two rua tags breaks the record, since each tag can appear only once. The comma form keeps both mailboxes in the single policy record.External reporting needs one more step. When reports go to another domain, the destination domain must publish an authorization TXT record at source-domain._report._dmarc.destination-domain. If example.com sends reports to reports.example.net, the authorization host is example.com._report._dmarc.reports.example.net, and its value is
v=DMARC1. Without that record, receivers won't send the reports to the external domain.The short walkthrough below shows how those report destinations fit into a published record.
How to verify it
External reporting fails when the authorization record is missing, so check the destination side before assuming the setup works. Query the authorization host with the mailX TXT lookup and look for a TXT entry containing v=DMARC1. If the lookup returns nothing at that hostname, the destination domain hasn't authorized the reports and nothing will arrive until it publishes that record. Then check the source record, because a correct authorization doesn't fix a misspelled rua address.
What Quarantine Does and How pct Limits It
Quarantine asks receivers to treat mail that fails DMARC as suspicious. In practice that usually means spam folder placement, though each receiver decides the final handling. It is enforcement, but recoverable enforcement, which is why it sits between monitoring and rejection.
These two records show the difference between full and partial quarantine:
- Full quarantine:
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com, covering all failing mail.
- Partial quarantine:
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com, covering roughly one failing message in four.
What pct changes
pct accepts an integer from 0 to 100 and defaults to 100. With pct=25, receivers apply the requested quarantine policy to about a quarter of failing mail and handle the rest as if the policy were none. Passing mail is never sampled, because selection only happens after DMARC evaluation fails.
Reporting is unaffected. Aggregate reports still cover all traffic, including failing messages that escaped quarantine, so visibility stays complete while the delivery impact stays limited. One caveat: receivers apply the percentage independently, so a thin traffic stream may not match the ratio exactly during a short window.
A sender that passes SPF but fails DMARC alignment needs fixing before pct rises. Misaligned legitimate mail is exactly the mail quarantine will filter once the percentage grows. Raising the dial first and investigating later just converts a reporting problem into a delivery problem.
The exit check before raising pct
Raise pct only when aggregate reports show failing traffic coming from expected unauthorized sources. Reports should cover a full sending cycle, including weekly campaigns, monthly invoices, and other periodic streams that don't appear every day.
How to verify it
The live record should show p=quarantine and pct=25 exactly as planned. The mailX DMARC checker returns the published record and its policy, so a missing pct tag means the default 100 still applies, and p set to none means the policy change never reached DNS.
Enforcing Reject With sp, adkim and aspf
Reject asks receivers to refuse messages that fail DMARC, so failing mail never reaches the inbox or the spam folder. That strength cuts both ways: legitimate mail that breaks alignment, including some forwarded messages, gets dropped entirely instead of filtered. The basic enforcement DMARC record example is
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com.The delivery failure pictured here is the outcome domain owners should expect for misaligned mail once reject is live.
Controlling subdomains with sp
The sp tag sets the policy for subdomains of the domain where the record is published. When sp is absent, subdomains inherit the p value. That default surprises teams that move a root domain to reject while a marketing subdomain still sends through a platform nobody inventoried.
This record separates the two cases:
v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc-reports@example.com. Failing mail using the root domain gets rejected, while failing subdomain mail gets quarantined. That split suits organizations whose subdomains host third-party senders still finishing alignment work. The exit check before setting sp=reject is aggregate reports showing clean subdomain traffic across a full sending cycle.Tightening alignment with adkim and aspf
adkim and aspf accept r for relaxed alignment, the default, and s for strict alignment. Relaxed alignment passes when the DKIM d= domain or the SPF-authenticated domain shares the organizational domain with the From domain. Strict alignment requires an exact match. Senders that need to compare strict and relaxed DMARC alignment should test subdomain senders carefully, because mail from mail.example.com authenticated only as example.com fails strict alignment.
The strict record looks like this:
v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:dmarc-reports@example.com. Strict mode works only when every legitimate platform signs DKIM with the exact sending domain or passes SPF for that exact domain. Transactional providers such as Amazon SES, SendGrid, Mailgun, and Postmark need DKIM configured on your sending domain before that holds, so strict alignment belongs at the end of a rollout.Build the final record text with the mailX DMARC generator. It accepts a dmarc_policy parameter with three options: none for monitor only, quarantine to mark as spam, or reject to block entirely, and returns the record name, value, and type ready to paste into DNS. Publish the reject record only after the quarantine stage holds without legitimate failures.
How to verify it
Open the DMARC checker on the domain and confirm the live record shows p, sp, adkim, and aspf matching the plan exactly. A good result displays every tag as intended, explained in plain English. A bad result shows a missing tag, an inherited subdomain policy nobody intended, or a policy raised before quarantine results were reviewed.
Staged Rollout From p=none to p=reject
p=none is a valid policy that blocks nothing. That single fact shapes the whole rollout: a domain can be fully DMARC compliant and completely spoofable at the same time. The staged path from p=none to p=reject closes that gap one stage at a time, and each stage pairs one record with one exit check. Skipping the exit check is how legitimate mail gets blocked.
The six steps in the infographic below mirror that sequence.
The six rollout steps
- Inventory every sending source: Include the company mailbox platform, such as Google Workspace or Microsoft 365, SaaS tools, transactional providers such as Amazon SES, SendGrid, Mailgun, or Postmark, and marketing platforms.
- Publish p=none with rua: Collect aggregate reports for at least one full sending cycle, including weekly and monthly sends, so periodic senders appear in the data.
- Fix alignment per source: Enable DKIM signing on the sending domain for each legitimate platform and confirm SPF includes the sender without exceeding lookup limits.
- Start quarantine at pct=10: Raise pct to 25, then 50, then 100 only while reports stay clean at each step.
- Move to p=reject: Switch once full quarantine shows only expected failures from unauthorized sources.
- Add sp and strict alignment last: Change subdomain policy and adkim or aspf only after subdomain traffic has been reviewed separately.
Rollout stages and exit checks
Stage | Record | Move on when |
1. Inventory | No change yet, or the existing record | Every sending source is listed |
2. Monitor | v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com | Every legitimate source passes SPF or DKIM with alignment |
3. Partial quarantine | v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@example.com | Failing mail comes only from unknown or unauthorized sources |
4. Ramp up | v=DMARC1; p=quarantine; pct=25, then 50, then 100 | Failure volume stays low and expected at each step |
5. Reject | v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com | Full quarantine has run without legitimate failures |
6. Subdomains and strict alignment | v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc-reports@example.com | Subdomain traffic is reviewed and each sender aligns exactly |
Bulk sender rules explain why monitoring became the floor for large senders. Under Google's email sender guidelines, senders of more than 5,000 messages per day must publish DMARC with at least p=none, align the authenticated domain with the From domain, and keep their spam complaint rate below 0.3 percent. Those requirements set a minimum, and a domain can meet every one of them while still being fully spoofable, because p=none satisfies the mandate without blocking a single forged message.
The common stall happens at stage two. Reports arrive, nobody owns them, and p=none stays in place for months while the domain remains spoofable. Assign an owner and a review date at publication, because DMARC monitoring without review is just storage. The exit checks in the table only work when someone reads the reports they depend on. Teams sequencing authentication work alongside wider sending preparation can also consult email warming options reviewed by Flowkon as separate background reading, while keeping DMARC decisions driven by report data.
How to verify it
Verification at each stage is a two-part comparison. The mailX DMARC checker confirms the live record matches the row in the table, which catches edits that never propagated or a tag that landed in the wrong position. Aggregate reports then get compared against that row's exit check before the next change. A matching record with dirty reports means hold position. Clean reports with a stale record mean the DNS edit didn't take effect.
Common DMARC Record Mistakes and Fixes
Most DMARC failures share one trait: a record that looks valid but does nothing. The table maps each symptom to its likely cause and the fix, so diagnosis starts with what receivers see.
Symptom | Likely cause | Fix |
Record ignored or not found | Published as a CNAME or at the wrong host | Publish a TXT record at _dmarc.example.com; check with the TXT lookup |
Two DMARC records on one domain | A provider wizard or second tool added a duplicate | Keep one TXT record beginning v=DMARC1 and merge the tags |
Policy has no effect | p missing, misspelled or placed after other tags | Put v first, then p; check with the DMARC checker |
Legitimate mail fails DMARC | SPF or DKIM passes but does not align with the From domain | Enable DKIM signing on the sending platform's domain |
Reports show unknown senders | Forgotten SaaS or transactional sender | Add the sender to SPF and DKIM, then review reports before reject |
External reports missing | Authorization record absent at source-domain._report._dmarc.destination-domain | Publish a TXT record with v=DMARC1 at that host |
SPF permanent error | More than 10 DNS lookups in the SPF record | Flatten or trim includes; check with the SPF checker |
DKIM check fails | Selector in the record does not match the sender's selector | Confirm the selector and check it with the DKIM checker |
The mistakes that hide behind a valid looking record
Duplicate DMARC records often appear unnoticed. A mailbox provider setup wizard adds one record, a security tool adds another, and the domain ends up with two policy strings at _dmarc. Merge the tags into a single record, because receivers need one unambiguous policy.
Alignment failures hide differently. SPF can pass for a bounce domain and DKIM can pass for a provider domain while DMARC still fails, because neither authenticated domain aligns with the visible From domain. The fix is usually provider-side DKIM signing using the sending domain, not another SPF include.
Two related checks close the remaining gaps. Count lookups and includes with the SPF checker, since SPF returns a permanent error when evaluation needs more than 10 DNS lookups, a standard SPF limit. Confirm selector records with the DKIM checker, because a wrong selector makes a correctly signed message look unsigned.
Check the policy after every publish, including changes that appear trivial in the DNS panel. Unknown senders in reports should be treated as inventory gaps until proven hostile, because enforcing reject against a forgotten invoicing platform breaks real business mail. The report data decides, not guesswork.
Common DMARC Record Questions Answered
What should you do when a legitimate third party fails alignment
Treat it as a sender-configuration gap, not a reason to weaken DMARC. Use aggregate reports to name the service, then fix authentication in that platform: enable its DKIM signing for your visible From domain, or configure the custom return path it documents so SPF can align. Keep adkim and aspf at the values planned for the current stage, because relaxing them to rescue one sender loosens checking for every sender. Re-test that mail stream before any policy move.
Can a domain that never sends mail use p=reject
Yes, after confirming nothing depends on it. The exit check is stricter than for an active domain: no department, form, vendor, or legacy system should send with that name, and reports should show no expected source. Then
v=DMARC1; p=reject is a clean control, because there is no legitimate traffic to break. Keep rua only if someone will review reports; silence is acceptable for an idle domain.Why are there no DMARC reports after publishing
DMARC does not create traffic. Receivers generate aggregate reports after they see mail claiming the domain and after the record supplies a valid rua destination. Confirm the TXT answer exists at _dmarc, the mailto: address is spelled correctly, and the mailbox can accept report attachments. Low-volume domains can need time. An empty report folder is not proof that everything passes.
Does passing SPF and DKIM make DMARC optional
No. DMARC adds the requirement that the authenticated identity align with the visible From domain, then tells receivers how to handle failures. SPF can pass for a bounce address and DKIM can pass for a provider domain while the message still fails DMARC alignment. The record is the policy and reporting layer that turns those underlying checks into an enforceable decision.
Verify Your Record Before Moving to Reject
Verification checks live DNS, which is what receivers read. The checker result below shows the record, policy, and fix guidance format used for that final confirmation.
How to verify it
- Run the checker: Validate your DMARC record against the domain. The dmarc-check endpoint returns the live DMARC record, its policy, and a fix suggestion.
- Match the tags: Confirm p, sp, pct, rua, adkim, and aspf match the rollout stage exactly.
- Inspect DNS when missing: If no record appears, run a TXT lookup against _dmarc.example.com to confirm a TXT answer exists at the host.
- Automate when needed: The same checks can run from an AI agent through the MCP server, documented in the MCP documentation.
Compare the output against the stage tables earlier in this article. Each stage already defines what a passing result looks like, so this check confirms the record matches the stage you are in and catches drift: a tag left over from an earlier stage, a pct value that was never raised, or an rua address that no longer receives reports. Treat any mismatch as a fix to make before the next stage change.
For a wider pass, the audit-deliverability prompt runs spf_check, dmarc_check, dkim_check, and blacklist_check in parallel, then reports a pass/fail summary with copy-pasteable DNS fixes for any gaps.
The DMARC generator returns a record name, value, and type ready to publish; mailX does not publish it, so add the record in the DNS provider. Allow time for propagation before judging the result, and recheck after every policy change.
Before the next policy change, run the free, no signup mailX DMARC check to confirm the live record at _dmarc shows the intended policy, reporting address, and alignment tags. Results come with plain-English explanations of what each finding means and what to fix, on the web, through the API and MCP server, and inside ChatGPT. Start at mailX and verify the record before moving any domain to reject.