DMARC record example and tags explained: how to go from p=none to p=reject

DMARC record example: the short answer

A DMARC record example that works for almost any domain on day one is v=DMARC1; p=none; rua=mailto:[email protected], published as a TXT record on the host _dmarc.example.com. That record tells receiving mail servers to deliver everything as usual, but to send you a daily report on who is sending mail with your domain in the From address. Once those reports show that all your legitimate mail passes, you tighten the DMARC policy step by step: first to quarantine, then to reject.

This guide gives you copy-ready DMARC records for each stage, a table of every tag defined in the DMARC specification (RFC 7489), a safe rollout plan from p=none to p=reject, a walkthrough of aggregate reports and the record errors that break DMARC most often. For the basics, see our DMARC overview and the FAQ what is a DMARC record; this article is about example records and rollout.

Key takeaways

• A DMARC record is a single TXT record at _dmarc.yourdomain. It must start with v=DMARC1 and contain a p= policy.
• The DMARC policy has three values: none (monitor only), quarantine (treat failing mail as suspicious) and reject (refuse failing mail).
• A message passes DMARC when SPF or DKIM passes and the domain that passed is aligned with the domain in the visible From address.
• Always start with p=none and an rua address, read the reports, fix every legitimate sender, then move to quarantine and reject.
• Only one DMARC record per domain. Two records at the same host means neither is applied.

What does a DMARC record look like?

A DMARC record looks like a short line of tag=value pairs separated by semicolons, stored as a DNS TXT record on the _dmarc subdomain of the domain you send from. If your From address is [email protected], the record lives at _dmarc.example.com. The DMARC record format is always the same: the version tag first, then the policy, then optional tags in any order.

DMARC does not replace SPF or DKIM; it sits on top of them. If you have not set those up yet, start with our explanation of what SPF is and how it works, and come back to DMARC once both are in place.

DMARC record examples for every situation

The DMARC record examples below use example.com and invented report addresses. Replace them with your own domain and a mailbox you actually read (or a reporting tool's address).

1. Monitoring only (p=none): the starting record

v=DMARC1; p=none; rua=mailto:[email protected]

Nothing changes for delivery. Receivers apply their usual filtering and send you aggregate reports. Use this record for the first weeks, while you discover every service that sends mail as your domain.

2. Quarantine a share of failing mail (p=quarantine with pct)

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]

A quarter of the messages that fail DMARC are treated as suspicious (in practice, usually sent to the spam folder). Under RFC 7489, the remaining 75% are handled as if the policy were none. This is a cautious first step towards enforcement.

3. Full quarantine

v=DMARC1; p=quarantine; rua=mailto:[email protected]

Without a pct tag, the policy applies to 100% of failing mail, because 100 is the default value.

4. Full enforcement (p=reject)

v=DMARC1; p=reject; rua=mailto:[email protected]

Receivers are asked to refuse any message that fails DMARC. This is the record that stops other people from sending mail that claims to come from your exact domain. Keep the rua tag: you still want to see what is being blocked.

5. Different policy for subdomains (sp)

v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]

The main domain is at reject, while mail from subdomains such as shop.example.com that have no DMARC record of their own is quarantined. Without an sp tag, subdomains inherit the p value.

6. Strict alignment (adkim=s, aspf=s)

v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:[email protected]

Strict alignment requires an exact domain match: a DKIM signature from mail.example.com no longer counts for a From address at example.com. Use it only when you are sure every sender signs and bounces with the exact From domain.

7. Domain that never sends email

v=DMARC1; p=reject; sp=reject

For a parked or defensive domain, reject everything. Pair it with an SPF record that authorizes no one (v=spf1 -all). Adding an rua address is optional here, but it shows you who tries to abuse the domain.

8. Several report addresses and failure reports (ruf, fo)

v=DMARC1; p=none; rua=mailto:[email protected],mailto:[email protected]; ruf=mailto:[email protected]; fo=1

Aggregate reports go to two mailboxes (separate them with a comma). Failure reports go to a third, and fo=1 asks for a failure report when either SPF or DKIM fails, not only when both do.

DMARC tags explained: v, p, sp, rua, ruf, pct, adkim, aspf

RFC 7489 defines a small set of DMARC tags. Only v and p are required; everything else has a default value that applies when the tag is missing.

What does each DMARC policy do: none, quarantine or reject?

The DMARC policy tells receivers how to handle mail from your domain that fails DMARC. It only affects failing mail: messages that pass are delivered according to the receiver's normal filtering.

A quarantine or reject policy is what actually blocks people who put your domain in the From address of their own mail. Our article on how to prevent email spoofing covers the attacks themselves and the other defenses that go with DMARC.

DMARC only works when SPF and DKIM are set up for every service that sends as your domain. See how email authentication works with Mailpro™ and get those foundations right first.

How does DMARC alignment work?

DMARC passes when at least one of two checks succeeds and is aligned with the From domain: SPF passes and the Return-Path (bounce) domain matches the From domain, or DKIM passes and the signing domain (the d= value in the signature) matches the From domain. Passing SPF or DKIM on someone else's domain is not enough.

Here is how alignment plays out for a message whose visible From address is [email protected]:

• DKIM signed with d=example.com: aligned in both relaxed and strict mode.
• DKIM signed with d=mail.example.com: aligned in relaxed mode (same organizational domain), not aligned in strict mode.
• DKIM signed with d=sending-platform.net: DKIM may pass, but it is not aligned, so it does not count for DMARC.
• Return-Path at bounce.example.com and SPF passes: aligned in relaxed mode, not in strict mode.

This is the most common reason a domain fails DMARC even though "SPF and DKIM pass" in the headers: they pass for the sending service's domain, not yours. The fix is to set up DKIM signing with your own domain at each service, which is also why shop notifications often land in spam; our guide to order confirmations going to spam shows that setup for an online store.

How to add a DMARC record to your DNS

To add a DMARC record, create one TXT record at the _dmarc host of your domain in the DNS panel of whoever hosts your DNS (registrar, hosting company or DNS provider).

1. Check that no DMARC record exists yet. Look up the TXT records for _dmarc.yourdomain. If one exists, edit it instead of adding a second one.
2. Create a mailbox or alias for reports, for example dmarc-reports@yourdomain. Reports arrive as compressed XML attachments, so a dedicated address keeps them out of anyone's inbox.
3. Add the TXT record: host _dmarc, value v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.
4. Save and wait for DNS propagation, typically minutes to a few hours depending on the TTL.
5. Look the record up again to confirm it returns exactly one value that starts with v=DMARC1.

If you send through Mailpro, our step-by-step FAQ on configuring DMARC with Mailpro covers the account side of the setup.

How to go from p=none to p=reject, step by step

Moving from p=none to p=reject safely means proving, with reports, that every legitimate source of your mail passes DMARC before you ask receivers to block what fails. The timing below is an example of a cautious rollout for a domain with several sending services; a small domain with one sender can move faster, a large organization more slowly.

1. Weeks 1 to 4: publish p=none with rua. Let reports accumulate over at least one full business cycle, so monthly invoices, newsletters and rare system emails all show up.
2. List every sender. Group report rows by source and match each one to a service: your mailbox provider, your newsletter platform, your shop, your CRM, your helpdesk, your billing tool, printers and scanners that send mail.
3. Fix each legitimate sender. Add it to SPF if it uses your Return-Path, and set up DKIM signing with your own domain. Wait for new reports to confirm it now passes with alignment.
4. Move to p=quarantine; pct=25. Watch the reports and your support inbox for a week or two. Then raise pct to 50, then 100 (or remove pct, since 100 is the default).
5. Move to p=reject; pct=25, then raise in the same way. With pct below 100 on a reject policy, RFC 7489 says the rest of the failing mail is quarantined instead.
6. Stay at p=reject and keep reading reports. Every new tool that sends as your domain needs SPF and DKIM before it goes live, or its mail will be refused.

Some mailbox providers already expect a DMARC record from bulk senders. Our article on the Gmail and Yahoo sender requirements explains where DMARC fits in those rules.

How to read DMARC aggregate reports

DMARC aggregate reports are XML files, usually zipped or gzipped, that a receiver sends to your rua address to summarize all the mail it saw from your domain over a period, usually one day. Each report lists sending IP addresses with the number of messages and their SPF, DKIM and DMARC results. You can open them in a text editor, but a reporting tool that parses and charts them is much faster once volume grows.

When you review a report, sort each row into one of four cases:

• Known service, DMARC pass: nothing to do.
• Known service, DKIM pass but not aligned: the service signs with its own domain. Set up DKIM with your domain in that service.
• Known service, SPF fail: the service is missing from your SPF record, or it uses its own Return-Path (then rely on aligned DKIM instead).
• Unknown IP, everything fails: either a forgotten internal system (find it) or someone sending mail as your domain, which is exactly what quarantine and reject will stop.

Mail that is forwarded or passes through a mailing list can also appear as failing, because forwarding usually breaks SPF and list software may alter the message and break DKIM. A small, steady share of failures from forwarding servers is normal and is not a reason to stay at p=none.

Common DMARC record errors and how to fix them

Most DMARC problems come from a handful of record and rollout mistakes:

• Two DMARC records at the same host. Under RFC 7489, receivers then ignore DMARC for the domain. Merge them into one record.
• v=DMARC1 not first, or misspelled (DMARC 1, dmarc1 with a space, a leading quote). The record is not recognized.
• Record on the wrong host. Some DNS panels append the domain automatically, so entering _dmarc.example.com creates _dmarc.example.com.example.com. Enter just _dmarc in those panels.
• rua without mailto:, or addresses separated by semicolons instead of commas. Reports never arrive.
• Report address on another domain without authorization. If example.com sends reports to an address at reports.example.net, the receiving domain must publish a TXT record at example.com._report._dmarc.reports.example.net with the value v=DMARC1, or receivers will not send the reports.
• Jumping straight to p=reject. Any sender you forgot, such as the invoicing tool or the website contact form, gets its mail refused.
• Strict alignment by default. adkim=s and aspf=s break services that sign or bounce from a subdomain. Relaxed alignment is the default for a reason.
• Staying at p=none forever. Monitoring alone does not stop anyone from using your domain. Plan the move to enforcement from the start.
• Forgetting subdomains. Without sp, subdomains inherit p, which is usually what you want, but check that any subdomain that sends mail is covered in your reports before you reach reject.

Once your domain is at quarantine or reject, you meet one of the prerequisites for showing your logo next to your emails; see our guide to BIMI for the rest. For a one-line definition you can share with colleagues, see the DMARC glossary entry.

Frequently asked questions about DMARC records

What is a good DMARC record example to start with?

Start with v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain, published as a TXT record on _dmarc.yourdomain. It changes nothing for delivery and starts the reports you need before enforcing a policy.

What does "DMARC policy not enabled" mean?

"DMARC policy not enabled" means your domain has no DMARC record, or has one at p=none, so receivers are not asked to act on failing mail. Publishing a record and moving to quarantine or reject resolves it; our FAQ on the DMARC policy not enabled warning explains the message in detail.

Is p=none enough?

p=none is enough to get reports and to have a DMARC record in place, but it does not protect your domain. Only quarantine or reject asks receivers to stop mail that fails DMARC.

Do subdomains need their own DMARC record?

No. If a subdomain has no DMARC record, receivers use the record of the organizational domain and apply its sp value, or p when sp is absent. Publish a separate _dmarc record on a subdomain only when it needs a different policy.

How long does it take to receive DMARC reports?

Aggregate reports are usually sent once a day, because the default reporting interval in the DMARC standard is 86,400 seconds. Expect the first reports within a day or two of publishing your record, from the receivers that saw mail from your domain.