Somewhere in your organisation there are 40 domains nobody remembers registering. A regional office bought one for a campaign in 2019. Marketing parked another for a product that never shipped. Someone in procurement grabbed a lookalike of your own brand just to keep it out of a squatter’s hands. Every one of them can send email. Every one of them needs a DMARC record, or it is a gap an attacker can walk through.
Now multiply that by the domains you actually use on purpose: regional TLDs, subsidiary brands, acquisitions still running their own mail, dozens of subdomains for marketing tools, ticketing systems, and transactional email. Enterprises and the MSPs who manage them routinely land in the hundreds. At that scale, “check the DMARC record” stops being a task you do and becomes a program you run.
Why this breaks the moment you scale past a handful
DMARC for one domain is a weekend project. Pull the mail flow, publish p=none, watch the aggregate reports for a few weeks, tighten to quarantine, then reject. Painful in places, but linear.
At 200 domains, three things happen at once:
The report volume becomes unreadable by hand. Each domain with a rua= tag generates its own aggregate XML report from every major receiver, daily. Two hundred domains means thousands of files a week, and the useful signal, an unauthorised source spoofing one specific subsidiary, is buried in noise from domains that barely send mail at all.
Domains drift out of sync silently. One team rotates a mail vendor and forgets to update SPF. Another lets a domain’s DKIM key expire. A marketing subdomain gets provisioned for a campaign and never gets a DMARC record at all, because nobody owns “new subdomain checklist” across 15 business units. Six months later you find out not from a dashboard but from a phishing report.
Nobody agrees on who is responsible for what. Central security owns the policy standard. Regional IT owns the DNS. Marketing owns the campaign tools sending the mail. When SPF breaks a legitimate newsletter, the ticket bounces between three teams before anyone touches the actual TXT record.
Manual tracking, usually a spreadsheet someone maintains part-time, cannot keep up with any of this. By the time an entry is updated, the DNS has already changed again.
Start with an honest inventory, not the domains you think you have
Most inventories used for DMARC rollout are built from the domain registrar list and the corporate DNS zone. That misses shadow domains bought outside procurement, subsidiaries from acquisitions still on their own registrar, and subdomains created by SaaS tools that get their own MX or SPF include without anyone in IT knowing.
Before setting policy anywhere, you need three things confirmed per domain: who owns it, what currently sends mail from it (including SaaS tools), and whether it sends mail at all. A domain with zero legitimate mail traffic should go straight to p=reject immediately. There is no rollout risk in blocking mail from a domain nobody uses to send.
DMARCS keeps this at the domain and subdomain level in one place, which matters once “check the DNS” stops being a single query and becomes 200 of them. Domain Health gives each one a posture score instead of making you open the zone file to guess.
Group domains by risk and rollout stage, not alphabetically
A spreadsheet sorted by domain name tells you nothing about what to do next. Group by what actually determines the plan:
- High-risk, low-volume: parked domains, old campaign domains, acquisitions with no active mail. These go to p=reject fast because breaking nothing is the whole point.
- Active sending, unverified alignment: the domains where you know mail flows but haven’t confirmed every sender is authenticated. These sit at p=none while you read the RUA data and fix SPF and DKIM gaps.
- Active sending, confirmed alignment: ready to move to quarantine, then reject, on a schedule.
- Complex, multi-vendor: the domains sending through five or six SaaS platforms where SPF’s 10-lookup limit is already a live problem. These need SPF flattening before enforcement, not just monitoring.
Policy Manager is built for exactly this: one view of every domain’s current policy stage, so a security lead can see at a glance which of 200 domains are still sitting at p=none for no good reason, and which are genuinely blocked on a vendor fix.
The SPF lookup limit turns into an operational headache at this scale
SPF allows 10 DNS lookups per record. One domain with Microsoft 365, one CRM, and a support tool stays under that easily. A domain shared across regional marketing, a global CRM, three transactional email providers, and a helpdesk blows past it fast, and once it does, SPF returns a PermError and the receiver can treat the entire domain as unauthenticated, including your legitimate mail.
Across hundreds of domains this is not a one-time fix, it is a recurring failure mode every time a business unit adds a new sender. Smart SPF flattens the record automatically as senders get added, so the limit stops being something someone has to track by hand across every domain in the portfolio.
Reading the reports at this volume needs one view, not a folder of XML
Manually opening RUA files for 200 domains does not scale, and forensic (RUF) data on top of that is worse. What you actually need is a single answer to two questions across the whole portfolio: which sources are sending as any of my domains right now, and which of those are failing authentication.
Reports Hub consolidates aggregate reports across every domain into one readable view, so a source spoofing a rarely-used subsidiary domain surfaces the same way a source hitting your main brand domain would, instead of sitting unread in a report nobody opened.
Vendor risk is the part most portfolios miss entirely
At scale, most of the domains sending mail on your behalf are not sending it directly. They’re going through a CRM, a marketing platform, a helpdesk, an HR system, a dozen SaaS tools each business unit picked independently. Every one of those is a third party authorised, deliberately or by accident, to send as your domain.
The question that matters is not “is our DMARC record correct” but “do we actually know every vendor sending as us, and is each one properly aligned.” Vendor Risk surfaces exactly that: the third parties sending on the organisation’s behalf, and which ones are doing it with weak or missing authentication. For an MSP managing client portfolios, this is often the single most useful view, because clients rarely know the full list of tools sending as their own domain.
Subdomains are where enforcement usually fails first
A parent domain at p=reject looks solid on paper. But DMARC’s subdomain policy (sp=) inherits from the parent unless explicitly overridden, and a huge share of real-world spoofing happens through unmonitored subdomains: a marketing subdomain spun up for one campaign, a dormant staging subdomain from a project that shipped two years ago, a subdomain nobody remembers exists at all. Attackers know this and target exactly those gaps.
Subdomain Monitor and SubdoMailing Guard track this across the whole domain tree, catching the subdomain that got created without anyone adding it to the DMARC rollout plan, rather than relying on someone remembering to check.
What a working program actually looks like at this scale
Not a spreadsheet, and not 200 separate manual reviews. One dashboard showing every domain’s policy stage, every subdomain under it, every third-party sender authorised across the whole portfolio, and an ongoing feed of new sources so nothing drifts unnoticed between reviews. New domains get triaged into the risk groups above the day they’re registered, not six months later when a report happens to surface them. Enforcement moves domain by domain on its own schedule, driven by actual RUA data for that domain, not a blanket policy applied to everything at once regardless of readiness.
That is the difference between DMARC as a checkbox on one domain and DMARC as an actual security control across an entire portfolio. Run your primary domain through the free DMARC Analyzer first if you haven’t already, then start a trial and bring in the rest of the list, all of it, including the domains you’d forgotten you owned.
