Mailbox providers, cold email tools, CRM, support, invoices, forms, calendars, marketing platforms, and forwarders.
Collect aggregate reports until legitimate volume, seasonal systems, and low-frequency senders are represented.
Watch failed aligned authentication, user complaints, vendor changes, and indirect mail before escalating.
Dedicated, tightly controlled domains can be candidates. General-purpose user domains need more caution.
The safest DMARC rollout is not a DNS edit. It is an inventory, alignment, reporting, and rollback project. If you change a busy outbound domain from p=none to p=reject before proving every legitimate sending path, the first messages you block may be your own.
The opposite failure is staying at p=none forever. Monitoring produces useful reports, but it does not ask participating receivers to quarantine or reject mail that fails DMARC. A domain can look fully authenticated in a setup tool while attackers are still free to spoof the visible From address.
The short answer
Start by listing every service that sends as the domain. Make each legitimate stream pass either aligned SPF or aligned DKIM, with DKIM preferred as the durable route through forwarding. Publish p=none with an aggregate-report address, monitor long enough to see low-frequency systems, then move controlled domains to p=quarantine. Consider p=reject only after quarantine produces no unexplained legitimate failures and after you account for mailing lists, aliases, and forwarded mail.
For a dedicated outbound domain used only by a small, known mailbox fleet, reject may be a sensible end state. For a general corporate domain used by people, mailing lists, aliases, and many third-party systems, the new DMARC standard explicitly warns against treating reject as an automatic destination.
Do not confuse authentication with alignment. DMARC passes when SPF or DKIM passes and the authenticated domain aligns with the domain in the visible From address. A vendor can pass SPF for its own bounce domain and still fail DMARC for yours.
The DMARC standard changed in May 2026
Most rollout articles still point to RFC 7489. In May 2026, the IETF published RFC 9989 as an Internet Standards Track document and explicitly obsoleted RFC 7489 and RFC 9091.
The change matters operationally. RFC 9989 removes the old pct tag because receivers did not apply intermediate percentages consistently. It adds a testing tag, t=y, but a receiver that has not adopted RFC 9989 can ignore an unfamiliar tag. That means publishing p=reject; t=y across the open internet and assuming every receiver will downgrade the action is not a safe rollout plan.
Google and Microsoft guidance still describes percentage-based ramps. Those pages remain useful for inventory, report review, and the none-to-quarantine-to-reject sequence, but the percentage mechanic now conflicts with the current standard. In 2026, the more defensible rollout unit is a controlled domain or subdomain cohort.
Gate one: inventory every service that uses the From domain
Begin with DNS, but do not end there. SPF records and DKIM selectors show some systems. They do not prove that you found every form, notification tool, low-volume billing app, or employee workflow.
Your sender inventory should include:
- Google Workspace, Microsoft 365, or another mailbox provider.
- Cold email platforms and every connected mailbox fleet.
- CRM sequences, marketing automation, newsletters, and transactional email.
- Support desks, applicant tracking systems, invoicing tools, calendars, and website forms.
- Security products, monitoring systems, scanners, and devices that send alerts.
- Forwarders, aliases, mailing lists, and external agencies sending on your behalf.
Give each stream an owner, sending domain, RFC5321.MailFrom domain, DKIM signing domain, provider, expected volume, last-seen date, and approval status. If nobody owns a sender, it is not ready for enforcement.
Gate two: prove aligned SPF or DKIM
DMARC needs one aligned authentication path to pass. SPF alignment compares the visible From domain with the authenticated envelope sender. DKIM alignment compares the visible From domain with the domain in a valid DKIM signature.
Use DKIM on every platform that supports a custom signing domain. SPF often breaks during forwarding because the forwarding server is not authorized by the original sender's SPF record. A valid DKIM signature can survive forwarding unless an intermediary changes the signed content.
Check real production samples, not only test messages sent from the admin console. For each stream, capture the Authentication-Results header and verify:
- SPF or DKIM returns pass.
- The passing domain aligns with the visible From domain.
- The result is consistent at Gmail and Microsoft 365 recipients.
- Reply handling, forwarding, and tracking do not change the signing path.
Gate three: monitor at p=none long enough to see reality
A basic monitoring record looks like this:
_dmarc.example.com TXT v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
RFC 9989 advises general-purpose domains considering reject to monitor at p=none for at least a month, then spend an equally long period at quarantine before comparing results. That is more conservative than older one-week rollout advice, and it catches monthly invoices, seasonal campaigns, rare alerts, and mailing-list behavior that a short sample misses.
Aggregate reports should answer five questions: which sources send the most mail, which legitimate sources fail alignment, which unknown sources are spoofing the domain, whether subdomains behave differently, and whether any receiver is applying an unexpected disposition.
Gate four: move one controlled cohort to quarantine
Do not change the busiest parent domain first. Start with a low-volume subdomain or dedicated outbound domain whose senders, users, and rollback owner are known. Microsoft recommends the same order: begin with lower-volume domains or subdomains and save the parent domain for last.
_dmarc.outbound.example.com TXT v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com
During quarantine, watch aggregate reports, mailbox-provider logs, support tickets, reply volume, and delivery failures together. A clean DMARC report does not prove inbox placement, and a delivery complaint does not automatically prove DMARC caused it. Keep the Microsoft 365 and Gmail provider split visible while diagnosing.
Gate five: decide whether reject is appropriate
A reject record asks participating receivers to reject failing mail, subject to their local policy. It can be appropriate for parked domains, non-sending domains, and dedicated outbound domains with tightly controlled senders.
_dmarc.outbound.example.com TXT v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com
RFC 9989 says domains hosting general users who may post to internet mailing lists should not publish p=reject casually. Mailing lists, role aliases, and forwarders can produce legitimate indirect mail that fails DMARC. The standard also says a domain using reject must not rely on SPF alone and must apply valid DKIM signatures.
Build the rollback before the policy change
A rollout is not safe until someone can reverse it. Record the current DNS value, TTL, owner, change window, escalation route, and the exact condition that triggers rollback.
Useful rollback triggers include a confirmed legitimate sender failing DMARC, a material rise in support tickets, a critical notification system disappearing, or a known mailing-list workflow breaking. Lower the policy only long enough to restore legitimate flow, then fix the authentication source. Do not leave the domain at p=none indefinitely because one vendor was misconfigured.
Public case study: 36,642 spoofed messages fell to five
The UK's National Cyber Security Centre published a Mail Check case in which a university detected 36,642 malicious emails sent from its domain over two weeks. After the service helped the university implement the right DMARC controls, the following two weeks produced five malicious messages, all successfully quarantined. NCSC described that as a 99% reduction in spoofing.
This is evidence for enforcement, not evidence that every domain should jump straight to reject. The value came from monitoring, identifying abuse, and applying the right controls. The same sequence protects legitimate outbound operations: observe first, fix the source, then enforce.
A DMARC enforcement checklist for outbound teams
- Separate primary corporate domains, dedicated outbound domains, parked domains, and non-sending domains.
- Inventory every approved sender and assign an owner.
- Configure custom DKIM signing wherever possible.
- Verify aligned SPF or aligned DKIM from real production messages.
- Publish aggregate reporting and monitor the complete sending cycle.
- Resolve every legitimate failure before enforcement.
- Move a low-risk domain or subdomain cohort to quarantine.
- Monitor reports, delivery logs, and human complaints through the change.
- Use reject only where domain usage and indirect-mail risk support it.
- Keep a tested rollback record and a named owner.
Frequently asked questions
What is DMARC enforcement?
DMARC enforcement means the applicable policy is not p=none. A domain asks receivers to treat failing mail as suspicious with p=quarantine or to reject it with p=reject, subject to receiver policy.
How long should DMARC stay at p=none?
For general-purpose domains considering reject, RFC 9989 recommends at least one month at none and an equally long period at quarantine. A dedicated domain with a small, controlled sender inventory may be easier to validate, but it still needs a complete reporting cycle and evidence for every legitimate stream.
Should outbound domains use p=quarantine or p=reject?
Use quarantine as the first enforcement step. Reject is a stronger fit for dedicated outbound or non-sending domains after complete alignment and indirect-flow testing. Mixed-use corporate domains need more caution because users, aliases, forwarders, and mailing lists create legitimate edge cases.
Is the DMARC pct tag still valid?
RFC 9989 removed pct in May 2026 because intermediate percentages were not applied consistently. Some provider documentation and existing receivers still reflect RFC 7489. Do not build a safety plan that assumes every receiver will honor an intermediate percentage.
Can a message pass SPF and still fail DMARC?
Yes. SPF can pass for a vendor-controlled envelope domain while the visible From address uses your domain. DMARC requires the authenticated SPF or DKIM identifier to align with the visible From domain.
