When to Set DMARC p=reject on Dormant Domains

You just finished a migration. You have 47 domains, maybe 12 you actually know something about, and the rest are ghost brands, parked acquisitions, and a few domains nobody can remember approving. Your legal team has told you not to send test mail from any of the acquired entities until the rebrand is finalized. And someone just asked you whether it is safe to set DMARC p=reject on the quiet ones.

This is a real problem that comes up constantly after mergers. It is also a problem with a defensible answer - if you know what to look for in your DMARC aggregate reports.

Why p=reject Fails Safe (And Why That Is Not the Same as No Risk)

Before the observation window question, the concept worth settling first: p=reject does not break your email. It breaks email that would fail DMARC alignment anyway. The distinction matters.

When a message passes SPF or DKIM and the aligned identifier matches the From domain, p=reject does nothing. The message arrives normally. When a message would fail DMARC alignment - because it comes from a domain that is not authorized, or was forwarded in a way that broke the authentication chain - p=reject causes it to be rejected at the receiving MTA.

The risk in going straight to p=reject on a dormant domain is not that you are breaking something fundamentally sound. It is that you may be cutting off a legitimate sender you did not know existed: a quarterly newsletter from a product brand you acquired in 2022, a legacy integration with a vendor that sends from a specific ESP, a marketing automation platform that was never documented.

You only find out by looking at what the domain has been receiving in aggregate reports - and by checking whether it is actually sending anything.

What DMARC Aggregate Reports Tell You About a Dormant Domain

Aggregate reports arrive at your rua endpoint whether or not a domain is actively sending. Each report tells you what other MTAs observed about mail appearing to come from your domain - including mail that failed DMARC alignment, which means it came from an unauthorized source.

For a domain you are trying to evaluate, there are three signals worth checking in the RUA data.

Mail volume over time. Zero legitimate mail in 90 days is a useful data point, but it is not the same as no sending ever. Some domains have legitimate quarterly send patterns. Look for a rolling 90-day window with no authenticated mail - not just a quiet week.

Source IP diversity. A domain that has never sent mail will show no source IPs in aggregate reports. A domain that was sending last year will show historical source IPs, potentially including old ESPs or internal mail servers that no longer apply. If you see source IPs from an ESP you do not recognize, that is a lead worth following before you lock the domain down.

SPF pass rates. A sudden drop to zero SPF-passing mail from a domain that previously had consistent passing volume is often a signal that the sending infrastructure changed - a vendor cut over, an internal mail server was decommissioned - without the DNS records being updated. That is a domain to watch longer before pushing to p=reject.

The Observation Windows That Actually Work

Here is the practical breakdown, not a guarantee. Apply it to each domain based on what the RUA data shows.

Minimum: 30 Days

You can move a domain to p=reject in 30 days if and only if it meets all of these conditions:

- No MX record, or MX pointing to a host that has not accepted mail for the domain in the observation period - No source IPs in aggregate reports for the full 30 days - No SPF includes pointing at third-party ESPs or external mail infrastructure in passive DNS history - Not a domain that was actively sending within the last 12 months according to historical RUA data or passive DNS

This is a narrow path. If any of those conditions are not met, keep observing.

Standard: 90 Days

Start here for most inherited domains. 90 days of aggregate reports gives you a full quarterly cycle and covers most legitimate send patterns, including newsletters, billing systems, and transactional email that may only send monthly or quarterly.

At 90 days without any authenticated mail from a domain - no passing SPF, no DKIM, nothing in the aggregate reports - you have a strong case for p=reject even if the domain has an active MX record. The MX alone does not mean the domain is sending mail: parked domains often retain MX records indefinitely for receiving mail but generate no outgoing RUA volume.

Extended: 180 Days

Use this window when legal requires it, when the domain is high-value (a primary brand domain rather than a legacy product name), or when the 90-day window showed some ambiguous signal - a single stray source IP, a one-time authentication pass from an unknown sender - that you want to rule out before locking it down.

180 days also covers the scenario where an acquired company sent annual tax forms or compliance notifications that would only appear once a year. If you hit 180 days with no authenticated mail after an acquisition, you have a solid case to present to legal for p=reject.

How to Handle the Forgotten Newsletter Problem Without Test Mail

The hardest case: a domain that was definitely sending mail last year, but the person who set up the sending infrastructure is gone, the documentation does not exist, and legal will not let you send test mail to find out if it is still active.

Here is how to narrow it down without sending anything:

Cross-reference the SPF record against passive DNS history. If the SPF record includes a third-party ESP - SendGrid, Amazon SES, Mailchimp, etc. - and passive DNS shows no activity from that ESP for the observation window, that ESP relationship is likely dead even if the DNS record has not been updated.

Check for subdomains in the SPF record. If the primary domain shows no activity but a subdomain has active sending, that subdomain may be the real sender for certain brand communications. Locking the parent domain to p=reject will not affect it.

Use RUA source IP patterns to find the internal mail servers. In aggregate reports, the source IPs that successfully authenticate are your known-good senders. If you see only one or two source IPs with SPF passing, and those IPs belong to your own infrastructure after an acquisition, you have found the legitimate sending path. Anything outside that set is a candidate for blocking.

A Decision Framework for Your Migration Plan

Work through each domain in your portfolio with these questions in order:

1. Does the domain have an active MX record? If no MX and no history in RUA, consider the 30-day minimum window. 2. Does the SPF record include external ESPs? If yes, check passive DNS for whether those ESPs have been active recently. If no, the 90-day window is your baseline. 3. Has the domain appeared in any RUA reports with authenticated mail in the last 90 days? If yes, keep observing until you can identify the sender. 4. Does the domain have historical sending data from before your observation window? If yes, the 90-day window is the minimum - the previous sending confirms the domain was active, which means silence may indicate a known gap rather than a truly dormant domain. 5. What is the business risk if you set p=reject and something breaks? Primary brand domains get the 180-day window. Legacy product domains or clearly abandoned subdomains can move faster.

DMARCFlow was built for exactly this: aggregate report collection across your entire domain portfolio, with source IP tracking, volume trends, and authentication health - applied to every domain in your portfolio without building custom monitoring infrastructure.