Blog · Dmarc
How to Manage DMARC Across Dozens of Domains (Without Breaking Legitimate Mail)
Managing one domain's DMARC policy is a contained problem. Managing it across 80 domains - some active, some dormant, some from companies you acquired three years ago and haven't fully integrated - is a different class of problem entirely.
The specific pain that surfaces in practice: you want to move everything to p=reject because that's what the security team recommends, but you don't actually know who all the legitimate senders are. Some third-party service is sending marketing email from your domain and you inherited it. Legal has told you not to send any test mail from the acquired brands until the rebrand is finalized. So you sit there with DMARC aggregate reports piling up, trying to read the runes.
This is the actual situation the post covers.
---
Why Acquisitions Create DMARC Debt
When you acquire a company, you inherit their email ecosystem. That means their sending infrastructure, their third-party ESPs, their legacy systems that send transactional email using their domain - and their DMARC posture.
Most acquired companies are not at p=reject. Many are at p=none. Some have no DMARC record at all. When those domains come under your control, they become your liability.
The problem is compounded because you often don't have a complete sender inventory. The IT lead who left didn't document it. The acquisition was fast. The brand team sends quarterly newsletters through a vendor you haven't audited. There are probably subdomains with their own MX records.
DMARC doesn't protect what you don't know about.
---
What the Aggregate Report Is Actually Telling You
Before touching any policy, you need to read the data you already have. If your DMARC reports are flowing to an aggregator, you have everything you need - you just have to look at the right fields.
Zero vs. Unknown: The Key Distinction in Your Aggregate Reports
When you pull an aggregate report for a dormant domain, the relevant rows are:
- Authenticate results showing pass on SPF or DKIM - these are known legitimate senders
- Authenticate results showing fail - these are either attacks or legitimate senders you haven't yet identified
- Policy evaluations showing reject, quarantine, or none
The trap is treating "no pass results" as equivalent to "no legitimate senders." They aren't the same thing. A domain can have zero SPF/DKIM passes in your reports because all the failures are from receivers that haven't authenticated anything, not because no legitimate email is flowing. Meanwhile, a "pass" result for a sender you didn't know about is a signal that you need to investigate before changing anything.
What to Check for Each Dormant Domain
For each domain in your portfolio, collect the following before making any policy change:
1. MX record status
If a domain has no MX record or a null MX, it is almost certainly not sending email legitimately. That doesn't automatically mean you can go to p=reject - something could be using it as a sending domain without an MX (transactional email services sometimes do this) - but it's a strong indicator.
2. SPF includes in passive DNS history
Run a passive DNS lookup on the domain. Look for SPF records that include third-party ESPs: SendGrid, Amazon SES, Mailgun, Mandrill, etc. If you see these, there are legitimate senders you need to account for before changing policy.
3. Aggregate report volume over the observation window
How much mail is flowing? If a domain is receiving 50,000 failure notifications per day and the failures all come from different source IPs, that's probably abuse. If it's receiving 3 failures per week from known large mail providers, that's noise.
4. Failure patterns
Are failures concentrated from a single large receiver (likely just mail provider policy differences)? Or scattered across hundreds of sources with different HELO names and sending patterns (more likely spoofing)?
---
The Observation Window: How Long Is Long Enough?
The commonly cited figure is 90 days. In practice, 90 days is the absolute minimum and it's often not enough.
The scenario that bites you: a domain has a quarterly newsletter that goes out through a vendor you didn't know about, and it sends to a mailing list that was imported during the acquisition. In a 90-day window with no other activity, you see nothing. Then at day 104, a large European mailbox provider rejects your test message because you're now at p=reject and the vendor's authentication is broken.
The question to ask before moving any domain to p=reject: what is the longest regular sending cadence I could have missed?
If your passive DNS and aggregate reports show no activity for 90+ days and the domain has no MX record and you can confirm no SPF includes are pointing at active sending infrastructure, you have a strong case for moving to p=reject. The longer your observation window, the stronger that case.
For domains with any ambiguity - MX exists but no recent mail, SPF includes present but you can't confirm they're still active - push the observation to 180 days. It costs you nothing but time, and the cost of a false positive rejection is higher.
---
The Checklist Before Moving to p=reject
Use this before promoting any dormant domain:
- [ ] No MX record or null MX confirmed
- [ ] No SPF includes pointing at active ESPs in passive DNS history
- [ ] Zero legitimate pass results in aggregate reports for 90+ days
- [ ] No A/MX records that suggest active subdomain use
- [ ] Legal has confirmed the domain is not in active sending use
- [ ] You have a rollback plan if mail starts failing after the policy change
If any box is uncertain, extend the observation window.
---
How to Work the Rebrand Constraint
Legal won't let you send test mail from acquired domains. This is common, and it means you need to be more conservative with policy transitions than you would be if you could simply send a test message and check the aggregate reports the next day.
What you can do instead:
Use a forwarding rule from the aggregator side. If your DMARC aggregator can deliver sample reports on demand, you can check what's hitting the domain without sending anything yourself.
Check public DNS history. Securitytrails, PassiveTotal, and similar services maintain historical DNS records. Look for MX, SPF, and DKIM records going back 12+ months. If something was there and is now gone, something changed. If nothing was ever there, the domain is more likely dormant.
Monitor for 30 days after policy change. Even if you go to p=reject without test mail, watch the aggregate reports daily for the first two weeks. A sudden increase in failures from a new source you don't recognize is a signal you need to investigate before it becomes an incident.
---
How DMARCFlow Fits This Problem
DMARCFlow is designed for exactly this scenario: large domain portfolios, limited visibility into third-party senders, and the need to make policy decisions without test mail as an option.
What DMARCFlow provides at this scale:
Multi-domain aggregate report normalization. Instead of juggling XML reports from multiple providers, DMARCFlow consolidates everything into a readable dashboard that shows you failure volume, source concentration, and policy evaluation outcomes across all your domains in one view.
Observation window tracking. DMARCFlow timestamps the last time each domain showed meaningful activity, making it easier to identify which domains are genuinely dormant and which are quietly sending mail you haven't accounted for.
Automated policy change alerting. When you promote a domain to p=reject, DMARCFlow can alert you within hours if failure volume spikes - which is the fastest way to catch a broken sender before it becomes a ticket.
Portfolio-level reporting. One of the practical advantages of DMARCFlow's multi-domain view is that it surfaces anomalies across your entire portfolio, not one domain at a time. A single domain with unusual failure volume stands out more clearly in a portfolio view than in a pile of individual reports.
For organizations managing 10 or more domains, the 1 EUR/month entry point makes this accessible to companies that would otherwise be running spreadsheets and manual report parsing - which is exactly the situation that leads to missing the quarterly sender problem.