DMARC Recon: Profiling a Target’s Security From a Single DNS Record

Before you send a single phish, you send a single DNS query: `dig txt _dmarc.target.com`. The response isn't just a policy. It's a roadmap to the target's email security maturity, a public statement about their priorities, and a treasure map for an attacker willing to read between the lines.

Most defenders see DMARC (RFC 7489) as a protective shield. They're not wrong, but they're only half right. For an attacker, it's a recon tool. Every tag, every URI, and every missing setting tells a story about the organization's operational discipline, their security vendors, and the attack paths they've likely overlooked.

This isn't about guessing. It's about drawing high-probability inferences from published data. Let's put on the black hat and break down what a simple DMARC record tells us about our next target.

Reading the Tea Leaves: What 'p=none' Really Signals

The policy (`p`) tag is the heart of DMARC. It instructs receivers what to do with mail that fails DMARC checks. `p=reject` and `p=quarantine` are the enforcement modes that actually stop spoofed emails. Then there's `p=none`.

On the surface, `p=none` means 'do nothing'. No blocking, no sending to spam. It's often called monitoring mode. But from an attacker's perspective, `p=none; pct=100` is the most telling policy of all. It signals an organization that wants to do email security but is stuck. They've deployed the record, they're collecting reports, but they haven't been able to solve the underlying alignment issues that would let them move to an enforcement policy.

The Indecisive Organization

Why do they get stuck? The usual suspect is the sprawling mess of third-party services that send email on their behalf: Salesforce, Marketo, Zendesk, SendGrid. Each one needs to be configured correctly to pass SPF (RFC 7208) or DKIM (RFC 6376) alignment. When a DMARC policy has been `p=none` for months or years, it’s a strong indicator of low operational maturity or a lack of internal political capital to force business units to fix their shadow IT mail streams.

This is your green light. It means you can spoof their domain with a high degree of confidence that your payload will be delivered to user inboxes. The receiving mail server will note the DMARC failure, dutifully report it, and then drop the message right into the user's line of sight, often with no 'unverified sender' warning. The SOC gets an alert in their DMARC dashboard; you get initial access.

The 'rua' Tag: An OSINT Goldmine

The `rua` (Reporting URI for Aggregate data) tag is required by the DMARC standard. It tells mail receivers where to send the daily XML reports summarizing authentication results. For a defender, it's a mailbox. For an attacker, it's a billboard advertising the target's security stack.

Look at the URI. Is it `mailto:dmarc_agg@pobox.agari.com`? You're looking at an Agari customer. Does it point to `dmarcreports.proofpoint.com`? They're a Proofpoint shop. `dmarc.valimail.com`? Valimail. A generic `mailto` address at the company's own domain suggests they're rolling their own solution or using a smaller open-source parser. This is not just trivia; it profiles their defense.

v=DMARC1; p=none; rua=mailto:dmarc-rua@us.dmarcian.com,mailto:re+target@dmarc.agari.com; — Example DMARC record showing multiple vendors

Seeing two different vendors in the `rua` field is particularly interesting. It often signals a painful migration in progress, a trial bake-off between technologies, or a complex corporate structure where a parent company and a subsidiary use different providers. This chaos is a fertile ground for misconfigurations and policy gaps.

Likewise, the `ruf` (Reporting URI for Forensic data) tag can be even more revealing. These reports contain message samples, including headers and potentially parts of the body. Because of privacy concerns, few companies use `ruf`. If you see one, it's often an address pointing directly to a SOC or IT team's ticketing system or a security appliance. Sending a deliberately failing email can now be used to poke their internal infrastructure directly.

Alignment Gaps in an Enforcement Policy

Finding `p=quarantine` or `p=reject` is a sign of a more mature organization. You can't just send a basic spoof and expect it to land. But 'mature' doesn't mean 'invulnerable'. It just means you have to be more subtle. Your new goal is to find a sender that is *authenticated*, but not *aligned*.

DMARC requires that the domain in the `From:` header (what the user sees) aligns with the domain used for the passing SPF or DKIM check. A common failure mode is a third-party service that sends with its own domain in the mail-from/envelope-from (for SPF) or the DKIM signature (`d=`) tag, while using the target's domain in the `From:` header. The mail authenticates, but it doesn't align.

Relaxed vs. Strict Alignment

Now look for the alignment tags: `aspf` and `adkim`. By default, they are `r` (relaxed). Relaxed alignment allows any subdomain of the `From:`-header domain to pass. For example, if the `From:` header is `ceo@corp.com`, a DKIM signature from `d=marketing.corp.com` would pass relaxed alignment.

If the policy is `adkim=s` (strict), the domains must match exactly. A relaxed policy is your invitation. Your recon task is now to find a legitimate, authenticated sender that uses a different subdomain. Scan the target's public SPF record (RFC 7208) for `include:` mechanisms. Do you see `include:_spf.salesforce.com`? `include:servers.mcsv.net` (Mailchimp)? These are your vectors. Craft a phish that perfectly mimics a legitimate notification from one of these services. Even with `p=reject`, a receiving gateway might have an allow-list for these major providers, creating a seam you can slip through.

Weaponizing Your Findings: The Full Picture

Let's synthesize this into an attack plan. You've run your initial `dig` query on `_dmarc.bigcorp.com`.

The result: `v=DMARC1; p=none; sp=none; rua=mailto:d@rua.agari.com; pct=100;`. You instantly know several things. They are an Agari customer. They are in monitoring mode and have been for a while. The `sp=none` tag means this permissive policy also applies to all subdomains. There is no enforcement whatsoever.

Next, you check their SPF record. It's a mile long, full of `include:` statements for various SaaS platforms, and it ends with `~all` (a softfail). Это means even unlisted senders won't be hard-rejected by many mail servers. You see `include:_spf.google.com`, hinting they use Google Workspace. You also see `include:mail.zendesk.com`.

The attack is obvious. You craft a pixel-perfect fake Zendesk support ticket notification. The email `From:` header is `support@bigcorp.com`. The mail-from envelope sender is your own attacker-controlled domain. The email will fail SPF and DKIM checks for `bigcorp.com`. But because the DMARC policy is `p=none`, the receiving mail server (likely Google Workspace, from your SPF recon) will note the failure and deliver it anyway. The link in the email, 'Click here to view your ticket,' points to your credential harvesting page. Game over.

This isn't a theoretical exercise. This is precisely how Business Email Compromise (BEC) attacks bypass millions of dollars in security tooling every day. They don't break the protocol; they exploit the policies that govern it.

The takeaway

A DMARC record is not a firewall configuration; it's a public declaration. It announces to the world how much an organization has managed to tame the chaos of its own email ecosystem. For the defender, achieving `p=reject` is a monumental effort of logistics and technical hygiene. For the attacker, every policy short of that is a gap to be exploited.

This initial DNS query is just step one. From here, you'd move on to analyzing SPF density, checking for an MTA-STS policy (RFC 8461) to assess downgrade attack potential, and hunting for misconfigured mail exchangers. Automating this initial recon with tools like MailSleuth.AI is standard practice, but understanding the 'why' behind each tag is what separates a script kiddie from a professional operator.