DMARC Stuck at p=none? An RUA Triage Playbook

You did the right thing. You published a DMARC record, pointed the `rua` tag to an address you monitor, and set the policy to `p=none`. The RFC 7489 specification says this is the first step: monitor mode. Now, weeks later, your inbox is a graveyard of zipped XML files. The data is flowing, but it’s a firehose. Far from feeling in control, you’re staring at a list of non-compliant IPs and feeling a deep sense of dread.

The paralysis is real. You can't move to `p=quarantine` or `p=reject` because you don't know what you'll break. Is that IP in AWS a threat actor spinning up a server to spoof your CEO, or is it the new HR platform the benefits team just procured without telling IT? Blocking it could be a CLM (career-limiting move). Leaving it could be a breach.

This isn't a failure of DMARC. It's a failure of process. Getting from `p=none` to an enforcement policy isn't about flipping a switch; it's about systematically investigating the unknown. This is the triage playbook for doing just that.

First, Turn the Firehose into a Spreadsheet

Raw DMARC aggregate (RUA) reports are machine-readable, not human-readable. A single IP can appear in dozens of reports from different receivers like Google, Microsoft, and Yahoo. Your first task is to consolidate this chaotic stream into a single, workable dataset.

Aggregate and Normalize Your RUA Data

You need to parse all those XML files and merge them. The goal is a master list, grouped by sending source IP, that sums the total message counts and notes the authentication results. Dedicated DMARC report analyzers handle this automatically, but you can also script it. What matters is getting all the data into one place. You can't triage what you can't see.

Filter for the Failures

You don't care about the senders that are already compliant. Your mission is to investigate the exceptions. Filter your master list to show only sources where DMARC checks are failing. Specifically, you're looking for entries where messages failed both SPF and DKIM alignment, or passed one but failed the other, leading to an overall DMARC fail.

<record>
<row>
<source_ip>209.85.220.69</source_ip>
<count>42</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>yourdomain.com</header_from>
</identifiers>
<auth_results>
<spf>
<domain>some-forwarder.net</domain>
<result>pass</result>
</spf>
</auth_results>
</record>

This XML snippet is your typical starting point. An IP sent 42 messages using your `header_from` domain. DMARC failed. But notice the `auth_results` block—the SPF check passed against `some-forwarder.net`, not your domain. This is a classic forwarding scenario that breaks SPF alignment (as defined in RFC 7208). Now you have your first lead: 209.85.220.69. Sort your list by volume. The IPs sending the most non-compliant mail are your highest-priority targets.

The Triage Gauntlet: From IP to Identity

With your sorted list of failing IPs, the real investigation begins. For each IP, you will run a three-step gauntlet to build a profile of the sender. This isn't guesswork; it's forensics. An analyst's muscle memory for attribution is built on these three tools.

Check Reverse DNS (PTR Records)

The first command for any IP is a reverse DNS lookup. A `dig -x <IP>` or `nslookup <IP>` tells you what the owner of that netblock calls the server. The results are incredibly revealing. A generic PTR record like `ip-172-31-45-67.us-west-2.compute.internal` tells you it's an AWS EC2 instance. A branded record like `o1.ptr.sendgrid.net` tells you it's SendGrid. A non-existent PTR record, or one pointing to a generic residential ISP, is a major red flag. This query provides context. It's the difference between seeing a random stranger and seeing someone wearing a uniform.

Corroborate with WHOIS

Next, run a `whois <IP>` query. While rDNS tells you the server's name, WHOIS tells you who owns the entire apartment building. It reveals the organization that registered the CIDR block that the IP belongs to. Often, this confirms what rDNS suggested. If rDNS pointed to SendGrid, WHOIS will show the netblock is registered to Twilio. If the rDNS was a generic AWS name, WHOIS will confirm the block belongs to Amazon.

This step is crucial when rDNS is unhelpful. A threat actor might be using a server from a lesser-known hosting provider in a country you don't do business in. WHOIS will name that provider. Conversely, if you see an IP block registered to Salesforce, and your sales team is complaining about email delivery, you've just found a key piece of the puzzle.

Assess Reputation and Blocklists

The final step is to check the IP's reputation. Is this a known-good sender, or is it a known source of spam and malware? Run the IP against reputable blocklists like Spamhaus, SURBL, and the Barracuda Reputation Block List (BRBL). A long history of abuse is a strong indicator of a malicious source. A clean record doesn't automatically mean an IP is safe—a threat actor could be using a fresh server—but it makes a 'Shadow IT' or 'Forgot IT' scenario more likely. This step helps you weigh probabilities.

Profiling the Unknowns: Shadow IT, Legacy Skeletons, or Threat Actors

After running your IPs through the gauntlet, patterns will emerge. You can now start categorizing these unknown senders into actionable profiles. Most fall into one of three buckets.

The Legacy Skeleton

This is the server everyone forgot about. It's an old, on-premises mail relay that was supposed to be decommissioned, a test web server in a developer's cloud account that's still sending notifications, or a script running on a forgotten VM. The rDNS and WHOIS data for these often point back to your own company or a provider you used to work with. These are time bombs of technical debt, often unpatched and unmonitored, but they aren't actively malicious. They're just embarrassing.

The Shadow IT Platform

This is, by far, the most common source of DMARC failures in a typical organization. Your investigation points to a legitimate SaaS provider—a marketing automation platform, a customer survey tool, an e-signature service, an applicant tracking system. Some department signed up for it and, following the vendor's instructions, tried to send email 'from' your domain without looping in IT. They don't have access to DNS, so they skipped the SPF and DKIM setup steps described in RFC 7208 and RFC 6376. The result is a flood of unauthenticated mail that gets flagged by your DMARC policy. This isn't a malicious attack; it's a business process problem.

The Threat Actor

This is what you were worried about. The IP address has a garbage or non-existent PTR record. WHOIS points to a cheap VPS provider in a strange geolocation. The IP has a bad reputation or is on multiple blocklists. The volume of mail might be low and targeted. This is an external adversary attempting to abuse your domain's reputation for phishing, business email compromise (BEC), or other scams. They are counting on you being stuck at `p=none`. These are the sources you need to block without hesitation.

The Decision: Onboard, Decommission, or Block

Categorization is useless without action. With each failing IP now profiled, you can move forward with a clear decision for each category. This is how you clear the board and prepare for enforcement.

For Shadow IT, the answer is to onboard. Find the business owner of the SaaS platform. Don't lead with an accusation; lead with an offer to help. 'I see you're using MarketingTool X. To make sure your emails are delivered properly and don't get marked as spam, we need to authorize it.' Work with them to get the necessary DNS records. Most SaaS vendors provide a specific SPF `include:` directive and a CNAME record for a DKIM signature. Add them to your DNS. This makes them a legitimate, authorized sender.

For Legacy Skeletons, the answer is to decommission. If it's an old server under your control, shut it down. If it's a partner's system that shouldn't be sending mail as you anymore, contact them and get them to update their configuration. The goal is to eliminate the source entirely. Don't just add it to your SPF record as a workaround; that just legitimizes a piece of unmanaged infrastructure.

For Threat Actors, the answer is simple: let DMARC do its job. Your investigation has confirmed these sources are illegitimate. You don't need to do anything other than have confidence that when you switch to `p=quarantine`, their mail will be sent to spam. You might also proactively add these IPs to your firewall or secure email gateway's blocklist for good measure. This is the payoff for all your hard work.

The takeaway

Moving your DMARC policy from `p=none` to `p=quarantine` isn't a leap of faith. It's the result of diligent, systematic triage. By categorizing every non-compliant sender, you transform a list of scary IPs into a concrete action plan. The process reveals more than just mail servers; it exposes gaps in business processes, uncovers forgotten infrastructure, and confirms active threats.

Once you've onboarded the legitimate services and decommissioned the old ones, your RUA reports will become quiet. The only failures you see will be the threat actors you correctly identified. Now, you can flip the switch to `p=quarantine` or `p=reject` with confidence. You're not guessing; you know exactly what you're blocking and why. Platforms like MailSleuth.AI can automate much of the RUA parsing and source intelligence gathering, but the fundamental triage discipline is what truly gets you to an enforced DMARC policy.