DMARC Setup Guide (2026): How to Get From p=none to Enforcement Safely

To set up DMARC safely, list every service that sends email as your domain, make each pass SPF or DKIM with your domain aligned, and publish p=none with a reporting address. Fix what the reports show, step up to p=quarantine, then move to p=reject once every sender DKIM-signs. RFC 9989, the 2026 update, keeps this path but retires pct.

Key takeaways

• DMARC tells receiving mail systems what to do with mail that fails authentication and where to send reports. A message passes only when SPF or DKIM passes for a domain that aligns with the From address people see.
• Start at p=none to learn who sends as you, fix alignment for every legitimate sender, then move to p=quarantine and, once every sender DKIM-signs with your domain, p=reject.
• DMARC was republished in May 2026 as RFC 9989, RFC 9990 and RFC 9991. The pct, rf and ri tags were retired, and np, psd and t were added.
• While mailbox providers catch up with the new standard, don't count on pct (or the new t tag) to soften a policy step. Make each step safe for all failing mail.
• DMARC protects against forgery of your exact domain. It doesn't stop lookalike domains or a criminal using a real, hijacked mailbox.

What does DMARC actually do?

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS TXT record at _dmarc.example.com. According to Microsoft's documentation, it checks that the domains verified by SPF and DKIM line up with the From address, tells receivers what to do with mail that fails, and says where to send reports.

The key idea is alignment. SPF checks the envelope sender (the hidden MAIL FROM, or bounce, address), and DKIM checks the domain that signed the message (the d= value). Neither one, on its own, requires those domains to match the From address your recipient sees. DMARC closes that gap: a message passes if SPF or DKIM passes and the domain it passed for aligns with the From domain. If both aligned checks fail, the message fails DMARC.

Alignment has two modes, set by the aspf (SPF) and adkim (DKIM) tags:

• Relaxed (r, the default): the organizational domains must match, so bounces.example.com aligns with example.com.
• Strict (s): the full domain names must match exactly, so bounces.example.com does not align with example.com.

What DMARC does not do matters just as much. Microsoft notes that a lookalike domain with its own valid SPF, DKIM and DMARC records can pass authentication, because it's simply a different domain. And when a criminal signs in to a real mailbox, the mail genuinely comes from you. Microsoft's Q2 2026 email threat report described an automated business email compromise (BEC) campaign that reached more than 67,000 users at more than 42,000 organizations in under three hours. The messages were sent from a DKIM-configured domain, so, in Microsoft's words, they "passed Sender Policy Framework (SPF) and achieved DKIM alignment." For the defenses that cover those gaps, see our guide on how to prevent email spoofing.

What changed in DMARC in 2026?

In May 2026 the IETF published the revised DMARC specification, often called DMARCbis, as three documents: RFC 9989 (the core protocol), RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting). They are Proposed Standards and replace RFC 7489, the earlier DMARC specification.

According to RFC 9989's list of changes and the IANA DMARC tag registry:

• Removed: pct (the sampling rate), rf (the failure-report format) and ri (the aggregate-report interval). The registry now marks them "historic."
• Added: np (a policy for non-existent subdomains), psd (a flag for public suffix domains) and t, which replaces some of what pct used to do.
• Changed behind the scenes: receivers now find your organizational domain with a "DNS tree walk" instead of relying on the Public Suffix List.

What this means for you: the basic rollout path (monitor, fix, quarantine, then reject where it's safe) doesn't change, and a small business doesn't need the removed tags. The catch is the transition: mailbox providers adopt new standards at different speeds, and some documentation still uses pct. Microsoft's DMARC setup guide shows pct=10 through pct=100 steps, and Google's BIMI setup guide asks for pct=100. So:

1. Leave pct out, or use pct=100 if a provider asks for it. Under RFC 7489, a record without pct already applies to 100% of failing mail, and RFC 9989 drops the tag, so both mean the same thing.
2. Don't rely on pct or t to soften a policy step. A receiver that has moved to RFC 9989 may ignore pct, and one that hasn't may not recognize t. Treat every policy change as if it applies to all failing mail.
3. Don't count on np= alone. A receiver that hasn't adopted RFC 9989 may not recognize it, so for that receiver your sp= policy (or p=, if there's no sp=) is what covers non-existent subdomains.

Is DMARC required now?

For many senders, a basic record is effectively mandatory. Google's sender rules, in force since February 2024, require anyone sending more than 5,000 messages a day to Gmail accounts to set up SPF, DKIM and DMARC, and a policy of p=none is accepted. Yahoo requires bulk senders to use SPF and DKIM and to publish a valid DMARC policy of at least p=none. Microsoft set similar rules for domains sending more than 5,000 messages a day to Outlook.com, including DMARC of at least p=none aligned with SPF or DKIM, and began enforcing them on May 5, 2025. Our Google and Yahoo bulk sender guide covers the rest of those rules.

Notice how low that bar is. p=none keeps your mail flowing, but it doesn't protect anyone, because it asks receivers to take no action. Microsoft's sender guidance for its Azure email service recommends p=reject where possible (p=quarantine otherwise) and treats p=none, sp=none and pct below 100 as temporary states to leave as quickly as possible.

What do you need before you publish DMARC?

• Access to your DNS. You create the DMARC record at your domain registrar or DNS host, the same place your SPF record lives.
• A list of every service that sends as your domain: newsletters, CRM, invoicing, help desk, store receipts, website forms, scan-to-email copiers.
• One valid SPF record within the 10-DNS-lookup limit (two SPF records on the same name cause an error), plus DKIM signing with your own domain wherever it's supported. Our SPF record guide explains the syntax.
• A dedicated mailbox or a reporting service to receive reports. Microsoft advises against delivering them to a person's own mailbox.

How do you set up DMARC step by step?

Step 1: Inventory your senders

Run your domain through our free domain scanner to see your current SPF, DKIM and DMARC records. Then list every system that sends email with your domain in the From address, and ask accounting, sales and marketing which tools they use.

Step 2: Set up SPF and DKIM for each sender

For each service, add it to your SPF record or, better, turn on DKIM signing with your domain (d=example.com). Microsoft notes that DKIM can still pass on messages that fail SPF, such as mail that goes through server-based forwarding. It also recommends putting bulk and marketing services you don't directly control on a subdomain, such as news.example.com, to protect your main domain's reputation; each subdomain also gets its own SPF lookup budget.

Step 3: Publish a monitoring record

Create a TXT record with the name _dmarc and this value, using your own reporting address. (Throughout this guide, example.com stands for your domain and example.net for an outside company's domain; both are reserved for documentation, so replace them with real domains.)

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

p=none asks receivers to take no DMARC action while they send you aggregate reports. It isn't meant to change delivery.

Step 4: Read the aggregate reports

Receivers send aggregate reports, typically once a day, as XML attachments that are usually compressed. Each row shows a sending IP address, a message count, whether SPF and DKIM passed, whether they aligned, and what the receiver did. Microsoft's documentation highlights the most useful pattern: SPF or DKIM passed, but alignment failed. That is usually a legitimate service that isn't yet configured to send as your domain.

Keep monitoring long enough to cover your whole business cycle, such as month-end invoices, payroll and newsletters.

Step 5: Fix alignment

For each legitimate source that fails alignment, set the service up to DKIM-sign with your domain, or to use your domain (or a subdomain) as its MAIL FROM (bounce) domain. Unfamiliar sources that fail every check at high volume may be spoofing attempts, which an enforcement policy is designed to block. Microsoft says no action is needed for those.

Step 6: Move to quarantine

When every legitimate source passes aligned SPF or DKIM, change the policy:

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

Receivers are asked to accept failing mail but mark it as suspicious, which often means the junk or spam folder. Keep reading reports: a forgotten sender now shows up as mail landing in junk rather than bouncing.

Step 7: Move to reject

Once quarantine runs clean, you can finish the job:

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

Check two things first. RFC 9989 says domains at p=reject must DKIM-sign their mail rather than rely on SPF alone, since forwarding breaks SPF, so make sure every sender signs with your domain. It also says domains whose users might post to internet mailing lists should not publish p=reject, because list messages can bounce. If your staff use mailing lists, p=quarantine may be the better place to stop.

Microsoft suggests going domain by domain, starting with lower-volume domains or subdomains and leaving your main domain until last.

Step 8: Cover subdomains and unused domains

A domain's DMARC record also covers subdomains that don't have their own record, including subdomains that don't exist. The sp= tag sets a different policy for subdomains, and RFC 9989's np= sets one for non-existent subdomains. For domains that never send email, Microsoft recommends a DMARC record of v=DMARC1; p=reject; plus an SPF record of v=spf1 -all. If you use Microsoft 365 but don't send from your *.onmicrosoft.com domain, Microsoft says to protect that one too.

What does each DMARC tag mean?

Do you need a DMARC reporting service?

Probably, unless you enjoy reading XML. Microsoft describes aggregate report data as vast and difficult to parse, and suggests either building your own automation or using an external reporting service. When you choose one:

• Check the authorization record. If your rua address is at another company's domain, that domain must publish a TXT record (example.com._report._dmarc.example.net) authorizing it. Without it, receivers won't deliver your reports, so ask your service to confirm it's in place.
• Don't expect failure reports. Support for ruf reports is limited, Microsoft 365 doesn't send them, and they can include message details. Microsoft suggests starting with rua only.

What are the most common DMARC mistakes?

• Stopping at p=none. It meets the bulk-sender rules but doesn't stop spoofing.
• Publishing two DMARC or two SPF records. Duplicates cause errors. Keep one of each per name.
• Going over SPF's 10-lookup limit by adding every vendor's include:. Move vendors to subdomains or rely on their DKIM signing instead.
• Assuming "SPF pass" means "DMARC pass." A service can pass SPF for its own bounce domain and still fail alignment.
• Switching to strict alignment too early. aspf=s breaks senders that use a subdomain as their bounce address.
• Forgetting forwarding and mailing lists. Forwarding can break SPF, and changes to the message can break DKIM. That's why DKIM matters so much before p=reject (see Step 7).

Frequently asked questions

Is p=none enough to protect my domain?

No. p=none asks receivers to report, not to act, so forged messages are still delivered as normal. It meets the Google, Yahoo and Microsoft bulk-sender minimums, and it's the right place to start while you learn who sends as you. Protection begins at p=quarantine, and p=reject gives receivers the strongest instruction.

Should I still use the pct tag in 2026?

Generally, no. RFC 9989 retired pct, and mailbox providers are moving to the new standard at different speeds, so a partial-percentage rollout may not behave the same everywhere. Leave pct out, which under the older RFC 7489 rules means 100%. Move between policies only when your reports show legitimate mail passing aligned SPF or DKIM.

Does DMARC stop all email impersonation?

No. DMARC lets receivers block messages that forge your exact domain in the From address. It doesn't stop lookalike domains, which pass authentication with their own records, and it can't tell when a criminal is using a real, compromised mailbox. Pair it with lookalike monitoring, phishing-resistant multifactor authentication and phone call-backs before any change to payment details.

Do I need DMARC on domains I don't use for email?

Yes. Unused domains carry your name and can be spoofed just like your main one. Microsoft recommends a DMARC record of v=DMARC1; p=reject; and an SPF record of v=spf1 -all for parked domains. Together they tell receivers that no legitimate mail should ever come from the domain. It takes minutes, and you don't need reports for it.

How long does it take to reach p=reject?

It depends on how many services send as your domain and how quickly each can be configured, not on a fixed calendar. A business with one mailbox provider and a newsletter tool can move quickly; one with a dozen sending services needs longer. Take each step when your reports show every legitimate source passing aligned SPF or DKIM.

If you'd rather have someone walk you through it, call us at (818) 574-8240.

Sources

1. RFC Editor — RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (May 2026)
2. RFC Editor — RFC 9990: DMARC Aggregate Reporting (May 2026)
3. RFC Editor — RFC 9991: DMARC Failure Reporting (May 2026)
4. dmarc.org — IETF Publishes Updated DMARC Specification (May 2026)
5. Red Sift — DMARC is now a Proposed Standard: What it means for you (2026)
6. DMARCguard — DMARCbis Is Published: RFC 9989, 9990, 9991 Replace 7489 (2026)
7. Microsoft Learn — Set up DMARC to validate the From address domain for cloud senders (reference documentation, undated)
8. Microsoft Learn — Set up SPF to identify valid email sources for your custom cloud domains (reference documentation, undated)
9. Microsoft Learn — Email authentication in cloud organizations (reference documentation, undated)
10. Microsoft Learn — Anti-phishing policies in cloud organizations (reference documentation, undated)
11. Microsoft Learn — Best practices for sender authentication support (Azure Communication Services) (reference documentation, undated)
12. Microsoft Security Blog — Email threat landscape: Q2 2026 trends and insights (July 23, 2026)
13. Google — Email sender guidelines (Gmail Help) (help article, undated)
14. Yahoo Sender Hub — Best practices (help article, undated)
15. Microsoft Tech Community — Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders (2025)
16. Google Workspace Admin Help — Set up BIMI (help article, undated)
17. Cloudflare Docs — Email authentication (reference documentation, undated)

Editor's note: This article was researched and written with AI assistance. Every factual claim was checked against the sources listed above; see our fact-check process for details.