How to Implement DMARC in 5 Steps: A Rollout Plan

To implement DMARC, list every service that sends mail as your domain, make each one pass SPF or DKIM on your domain, publish v=DMARC1; p=none; rua=mailto:..., read the reports until every real sender passes, then move to p=quarantine and finally p=reject. DMARC is defined in RFC 7489 and, since May 2026, RFC 9989.

The record is one line of DNS. The rollout is the real work, because a strict policy applied too early blocks your own invoices, password resets and newsletters. These five steps are the order that avoids that.

Should you implement DMARC?

Yes, if anyone could gain from pretending to be you, which covers any business that sends invoices or has customers. There are also hard requirements. Google's sender guidelines require SPF, DKIM and DMARC from anyone sending more than 5,000 messages a day to Gmail accounts. BIMI, the standard that shows your logo in the inbox, only works at quarantine or reject according to the BIMI Group.

You will not be alone at the end of it. In our scan of the Tranco top 1,000 domains on 19 October 2026, 508 of the 688 domains with an MX record (73.8%) were already at quarantine or reject. Another 101 (14.7%) were at p=none, which is where many rollouts stall.

Step 1: Inventory every service that sends as your domain

You cannot protect mail you do not know about. Before touching the DMARC record, write down every system that puts your domain in a From address.

Start with these places:

• Your SPF record. Every include: is a sender someone set up. Check it with the SPF checker, which also counts DNS lookups.
• DKIM selectors in DNS. TXT or CNAME records under _domainkey, such as google._domainkey or selector1._domainkey, point to mail platforms.
• Finance. The list of SaaS subscriptions turns up the CRM, help desk, billing platform, HR system and marketing tools.
• Teams. Ask sales, support, marketing, HR and IT what sends mail "from us". Include scanners, printers, monitoring alerts and website contact forms.

Keep it as a table. You will fill in the last two columns in step 2.

Do not worry about missing a few. Step 3 finds the rest.

Step 2: Set up SPF and DKIM for each sender, aligned with your domain

DMARC passes when either SPF or DKIM passes for a domain that matches your From domain. That match is alignment. A sender that passes SPF for its own bounce domain and signs DKIM with its own d= will pass both checks and still fail DMARC.

For each sender in your table:

1. DKIM first. Turn on custom-domain DKIM in the platform's settings and publish the key or CNAME it gives you. DKIM survives forwarding, so it is the alignment that lasts. Use 2048-bit keys where the platform allows it; Google accepts 1024-bit and recommends 2048.
2. SPF where it can align. If the platform supports a custom return-path or bounce domain (often bounce.example.com or em123.example.com), set it up. Then SPF aligns too.
3. One SPF record, ten lookups. All senders share a single SPF TXT record at the root. RFC 7208 section 4.6.4 caps it at 10 DNS-querying terms; past that, SPF returns permerror for everyone. Remove includes for services you no longer use.

A typical result:

example.com.                    TXT  "v=spf1 include:_spf.google.com -all"
google._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=<public key from the Google Admin console>"

Provider-specific steps are on the integration pages, for example Microsoft 365, Google Workspace, Amazon SES, SendGrid, Mailchimp, HubSpot, Salesforce and Zendesk. Check each DKIM key with the DKIM checker.

Step 3: Publish p=none with rua, then read the reports

Now publish the record. Create a TXT record at your DNS host with the host name _dmarc:

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

p=none changes nothing about delivery. rua is the point: without it, RFC 7489 says receivers must not send aggregate reports, and you are flying blind. Use a dedicated mailbox or group, not a person's inbox. Microsoft's DMARC guide gives the same advice. The DMARC record generator builds this line for you, and the DMARC checker confirms it is live.

Reports arrive about once a day as gzipped XML from each receiver that saw your mail, Google and Microsoft among them. Open them in the DMARC report analyzer, which parses them in the browser. Sort every source IP into one of four groups:

• Yours, passing aligned. Done.
• Yours, failing. A sender from step 1 that is not aligned yet, or one you missed. Go back to step 2 for it.
• Forwarded mail. Your own mail relayed by a forwarder or mailing list. SPF fails, DKIM often still passes. Nothing to fix if DKIM aligns.
• Not yours. Spoofing or spam using your domain. This is what the policy will stop.

Stay at p=none until the "yours, failing" group is empty for a full business cycle. A month catches month-end invoices, payroll mail and monthly newsletters that a one-week sample misses.

Step 4: Move to quarantine, with a gradual ramp

When reports show only aligned passes, forwarding and spoofing, ask receivers to quarantine failing mail. Under RFC 7489 you can apply that to a share of failing mail with pct:

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

Microsoft's guide suggests stepping through pct=10, 25, 50, 75 and 100. Watch the reports and your help desk after each change. If a forgotten sender appears, fix it before the next step instead of rolling back.

Two cautions:

• RFC 9989, published in May 2026, removes pct. Its appendix A.6 says the tag "was usually not accurately applied, unless the value specified was either 0 or 100". Treat the ramp as a rough dial, not a precise one. The new t=y tag asks receivers to apply one level below your stated policy, so p=quarantine; t=y behaves like monitoring at receivers that support it.
• BIMI does not count anything below pct=100 as enforcement.

Step 5: Move to reject, then lock down subdomains and parked domains

After a few weeks at p=quarantine; pct=100 with no legitimate failures, move to reject:

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

Then cover the names around the main domain.

Subdomains with sp and np. Subdomains without their own record inherit the parent's policy, and sp overrides that for all of them. Microsoft's guide suggests rolling out on low-volume subdomains first and "saving the parent domain for last". The np tag, now part of RFC 9989, sets a policy for subdomains that do not exist in DNS. Phishers like those, because secure-billing.example.com looks real and has no record of its own. During a slow subdomain rollout this keeps made-up names blocked:

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

Receivers that only know RFC 7489 ignore np and apply sp, so finish with sp=reject as well.

Parked domains. Every domain you own but do not send from needs two records. Microsoft recommends v=DMARC1; p=reject; for them:

parked-example.com.         TXT  "v=spf1 -all"
_dmarc.parked-example.com.  TXT  "v=DMARC1; p=reject; sp=reject"

Keep reviewing. DMARC at reject is not finished forever. A new marketing tool signed up next quarter will fail and be rejected. Add a rule: no new service sends as the company domain until it has aligned DKIM. Keep reading reports weekly, and check the SPF lookup count whenever someone adds an include.

Implementing DMARC in Microsoft 365 (Office 365)

Microsoft's current DMARC documentation (Microsoft Defender for Office 365, updated July 2026) sets out the same order: SPF and DKIM for every custom domain first, then DMARC. Points specific to Microsoft 365:

• Custom domains (example.com): "There are no admin portals or PowerShell cmdlets in Microsoft 365" for their DMARC records. You create the _dmarc TXT record at your registrar or DNS host.
• The onmicrosoft.com domain is the exception. Add its record in the Microsoft 365 admin center under Settings, Domains, select the domain, DNS records, Add record, type TXT, name _dmarc. If you never send from it, Microsoft suggests v=DMARC1; p=reject.
• Failure reports. Microsoft 365 does not send DMARC failure (ruf) reports, even when your record asks for them. It sends aggregate reports only when the receiving domain's MX points directly to Microsoft 365.
• Outbound at enforcement. Mail from Microsoft 365 that fails DMARC at the destination is routed through Microsoft's high-risk delivery pool when your policy is quarantine or reject.

The Microsoft 365 integration page has the SPF and DKIM records.

A realistic timeline

A small company with one mailbox provider and one newsletter tool can run this in six to eight weeks. A larger one with dozens of senders should plan per business unit and expect months. DMARC+ was built around this same phased path from p=none to quarantine to reject, with SMS and email alerts when a new source starts failing.

Start today with step 3's record if you have none: a p=none record with rua changes no delivery and starts the reports flowing while you work through steps 1 and 2. Use the generator to write it, and read What is DMARC for how alignment works under the hood.

Frequently asked questions

Sources

• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 9989: DMARC (Proposed Standard, May 2026; removes pct, adds t and np)
• RFC 7208: Sender Policy Framework (10 DNS lookup limit, section 4.6.4)
• Microsoft Learn: Set up DMARC to validate the From address domain for cloud senders
• Google: Email sender guidelines
• BIMI Group: Implementation guide