First find out who sends mail with this domain
Consider a hypothetical enterprise whose finance staff receive a message forwarded by a customer: someone used an address on the company domain to announce a "change of payment account". When the administrator signs in to DNS, they find an SPF record configured years ago but no DMARC, and nobody can say how the marketing platform, ticketing system, recruiting system and overseas subsidiaries each send mail. The easiest mistake at this point is to publish a reject policy at once. The next day invoices and ticket notifications land in customers' spam folders in large numbers, business teams demand an immediate rollback, and the effort stalls. The real first step is not changing policy but finding every system that sends external mail with this domain.
RFC 9989, published in May 2026, is the current DMARC core specification. It replaces RFC 7489 from 2015, and the record version is still written as v=DMARC1. DMARC lets a domain owner state that receivers may take no action on, quarantine or reject mail that fails SPF or DKIM alignment, and that aggregate reports can be sent back to the domain owner. NIST's guidance on trustworthy email likewise recommends deploying SPF, DKIM and DMARC. Building on these mechanisms, JOTOglobal suggests that the mail administrator lead a sending-source inventory together with procurement, marketing, HR and regional IT, recording the system name, business owner, sending domain or subdomain, whether a third party sends on the company's behalf, and whether DKIM signing is already in place. Sources that nobody claims are flagged separately for verification against the reports.
Use monitoring mode to read aggregate reports
Once the inventory has a first version, the administrator publishes a DMARC record with the policy none and designates a dedicated mailbox or report-processing platform to receive aggregate reports. This stage does not change delivery outcomes; its purpose is to observe what receivers actually see. RFC 9990 defines the aggregate report format, which summarizes message counts by sending IP together with SPF and DKIM check and alignment results. Each week the administrator compares report sources with the inventory item by item. Sources that appear in both and are aligned are marked as passing. Sources that appear in reports but not in the inventory go to the security team to decide whether they are forgotten business systems or impostors. Sources in the inventory that never align go to the relevant business owner for remediation. Reports may contain information about recipients and forwarding paths, so access to the receiving mailbox should be limited to the mail and security teams, with an agreed retention period.
Remediation usually falls into three kinds of problems. The first is a third-party platform that signs DKIM with its own domain; the platform needs to be configured to sign with the company domain or a dedicated subdomain. The second is an SPF record that keeps accumulating include statements until the number of lookups approaches the protocol limit; retired services should be removed, and high-volume senders such as marketing can be moved to a separate subdomain where needed. The third is that forwarding and mailing lists change the message path and may cause SPF to fail, which makes it more important that DKIM signatures survive intact. Each fix is recorded in the inventory with its completion date and verification method, for example a test message sent by the business owner and confirmed as aligned in the reports or in the recipient's authentication results header.
Tighten policy in stages and plan rollback
Only when all known sources in the reports are consistently aligned, and several reporting cycles in a row show no new legitimate source, should the policy move from none to quarantine. RFC 9989 no longer treats pct as part of the current mechanism, so an enterprise should not rely on applying policy to only a share of messages as a transition. A steadier approach is to enforce first on a lower-impact subdomain, or tighten a separate marketing subdomain first, and then handle the primary domain. Before each change, the mail administrator writes down what will change, the observation period, the contact who receives business complaints, and the conditions and person responsible for returning to the previous stage if widespread misclassification occurs.
During the quarantine stage, business owners focus on whether critical mail such as invoices, contracts, password resets and customer notices still reaches the inbox, and the support team records anomalies reported by customers. Only after confirming that no legitimate mail is affected should the team assess whether to move to reject. For subdomains that never send mail, RFC 9989 provides the np tag for non-existent subdomains, and the enterprise can consider declaring a stricter policy for them to reduce the room for abuse. DNS change records, report summaries and business confirmations from every stage should be kept in the change ticket, so that if anyone later asks why a message was rejected, the basis at the time can be traced.
Acceptance evidence, common mistakes and limits
For acceptance, keep four kinds of evidence: lookup results for the currently published SPF, DKIM selectors and DMARC records; a summary of the latest aggregate report cycle showing that all legitimate sources are aligned; test messages from key business systems with their authentication results headers; and sign-off by each business owner for their systems in the inventory. Common mistakes include believing that publishing DMARC stops all phishing, when it only addresses direct use of the company's own domain and has no direct effect on look-alike domains or impersonation through outside accounts, and believing that reports no longer need reading after reject is set, when new systems or a change of supplier can create new unaligned sources. For that reason the sending-source inventory should become a checklist item for new system launches and supplier changes, with procurement or the project owner notifying the mail administrator before go-live.
The inventory, staged tightening and acceptance workflow described here is organizational guidance from JOTOglobal. The length of each stage, the indicators to watch and whether to reach reject in the end should be decided by each enterprise according to its own mail volume and business risk. Receivers may enforce DMARC policies differently, and aggregate reports may be delayed or missing, so reports are only one input to judgment. If corporate mail is operated by an outsourced provider, the contract or ticket should state who is authorized to change DNS and who is responsible for rollback, and industries with regulated communications must also follow their own retention and notification requirements.