DMARC record and policy examples that move safely to enforcement

Start with monitoring, fix SPF and DKIM alignment, then move through quarantine before reject.

A practical DMARC policy usually starts with visibility, not enforcement. For most domains, the safe path is: publish a monitoring record with p=none, identify every legitimate sender, fix SPF and DKIM alignment, move a small percentage of failing mail to quarantine, then enforce with p=reject only when normal mail is passing.

That sequence matters because DMARC is not only a DNS record. It is an operating process. The record tells receiving mail servers what to do when mail fails DMARC authentication, but your reports tell you whether your real mail stream is ready for that policy.

In plain terms, a DMARC record is a TXT record published at _dmarc.example.com. It combines a policy, report destinations, and optional alignment rules. DMARC checks whether SPF or DKIM passes in a way that aligns with the visible From domain. If neither aligned result passes, the DMARC policy decides what receivers should do next.

Start with a monitoring record

The simplest first record is monitoring only:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;

v=DMARC1 identifies the record as DMARC. p=none tells receivers not to enforce a failure. rua asks for aggregate reports, usually daily XML reports that summarize authentication results by source.

This is the right starting point when you do not yet know every service that sends mail for the domain. Marketing platforms, billing systems, help desks, CRMs, product notifications, and internal mail infrastructure can all appear in DMARC reports. If you skip this discovery step, a stricter policy can affect real customer or employee mail.

If you need a quick starting point for syntax and tags, a DMARC generator can help assemble a valid record before you publish it in DNS.

Add failure reporting only when it helps troubleshooting

A more detailed monitoring record can request aggregate and failure reports:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; fo=1;

The ruf tag requests failure reports, and fo=1 asks for reporting when either SPF or DKIM fails. This can help when you are actively debugging authentication issues. It is not a substitute for aggregate reporting, and it is best used when someone is prepared to review what comes in.

Monitoring is successful when you can answer three questions: which services send mail for the domain, which ones pass aligned SPF or DKIM, and which failures are unauthorized spoofing rather than legitimate mail misconfiguration.

Move to quarantine in percentages

Once legitimate senders are known and authentication problems are fixed, quarantine is the next enforcement step:

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@example.com;

This asks receivers to quarantine 10 percent of mail that fails DMARC, while the remaining 90 percent of failing mail is not subject to that enforcement request. It is a controlled rollout, not a permanent end state.

A practical pattern is to start with pct=10 for one to two weeks, review the reports, then increase to 25 percent, 50 percent, 75 percent, and finally 100 percent. When you reach full quarantine, remove the pct tag because 100 percent is the default.

Quarantine gives you protection while preserving some delivery tolerance. Failed mail is typically routed to spam or junk instead of being accepted normally. That makes it a useful intermediate step before you ask receivers to reject failures outright.

Use reject only after legitimate mail is authenticated

The strongest common policy is reject:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com;

This asks receivers not to deliver mail that fails DMARC. It provides the most direct protection against unauthenticated spoofing of the domain, but it should come after a successful monitoring phase, a gradual quarantine rollout, and confirmation that SPF and DKIM are correctly configured for all legitimate senders.

Reject does not mean you stop watching reports. DMARC reporting remains useful after enforcement because mail systems change. Vendors add new sending infrastructure, teams launch new tools, and forgotten systems can start failing when DNS or platform settings drift.

Use subdomain policy for staged rollouts

DMARC also lets you set a separate policy for subdomains:

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc-reports@example.com;

Here the organizational domain uses p=reject, while subdomains use sp=quarantine. That can be useful when the main domain is ready for enforcement but some subdomains still support third party services or older workflows.

You can also make alignment stricter:

v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:dmarc-reports@example.com;

adkim=s requires strict DKIM alignment. aspf=s requires strict SPF alignment. Strict alignment is more restrictive than the default relaxed behavior, so use it only when the sending environment is controlled enough to support exact domain matching.

Checklist before stronger enforcement

Before moving from monitoring to quarantine, or from quarantine to reject, check the operational basics:

• Every legitimate sending service is visible in aggregate reports.
• Each sender passes aligned SPF or aligned DKIM for the visible From domain.
• Forwarding, help desk, CRM, billing, and marketing mail have been reviewed.
• The rua mailbox or monitoring platform is receiving reports.
• Recent failures have a clear explanation: either unauthorized mail or a known configuration issue.
• The team has a rollback record ready if legitimate mail is affected.

A DMARC monitoring tool makes this easier because raw XML reports are hard to review manually at scale.

Keep a rollback record for troubleshooting

If legitimate mail is being blocked, or if you are changing authentication infrastructure, a temporary rollback can stop enforcement while keeping visibility:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; fo=1;

This should be temporary. The goal is to preserve delivery while you identify what failed, then return to the prior rollout path. Do not leave a domain in monitoring mode indefinitely after the legitimate sources are fixed.

For deeper troubleshooting, you can request more reporting detail:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; fo=0:1:d:s; ri=3600;

The fo options ask for different failure conditions, and ri=3600 requests hourly aggregate reporting. In practice, hourly reporting is rarely honored, so treat it as a request rather than a guarantee.

The useful DMARC policy is the one your mail can support

The best DMARC record is not the strictest record you can type. It is the strictest record your actual mail stream can support without blocking legitimate messages. Start with reporting, fix authentication, raise enforcement in visible steps, and keep watching reports after the domain reaches reject.

That gives you better email security without treating deliverability as an afterthought. It also turns DMARC from a one time DNS change into a maintainable control for domain reputation, sender reputation, and spoofing protection.

Reference: Read the detailed Suped article.