DMARC Forensics in Email Incident Response

DMARC was designed as an email authentication policy mechanism — it tells receiving servers what to do with messages that fail authentication. But DMARC's aggregate and forensic reporting capabilities also make it one of the most powerful tools available for email security incident investigation. When a phishing campaign impersonates your domain, when a business email compromise attack uses a lookalike domain, or when an authentication misconfiguration allows unauthorised sending — DMARC reports provide the forensic data that reveals what happened, when, from where, and at what scale. This guide covers DMARC forensics as a security tool, not just as a deliverability tool.

DMARC as a Security Intelligence Tool

Most organisations deploy DMARC for deliverability — to ensure their legitimate email reaches the inbox by passing authentication. The security intelligence dimension of DMARC is less understood but equally valuable: DMARC aggregate reports show every source that sent email claiming to be from your domain, including malicious sources you did not authorise. This full visibility into who is using your domain in their From: address makes DMARC the closest thing to a real-time domain abuse detection system available without additional tooling.

The security use case for DMARC aggregate reports: daily review of the report data reveals unauthorised sending sources — IP addresses not in your SPF record, DKIM signatures from domains you did not configure — that represent either (a) misconfigured legitimate tools you forgot to authorise, or (b) malicious actors spoofing your domain. The difference is diagnosable from the report data: misconfigured legitimate tools show authenticated message content consistent with your business communication patterns; malicious spoofing shows patterns inconsistent with legitimate email (unusual sending times, unusual recipient domains, different message volume profiles).

DMARC forensic reports (RUF) provide per-message data when authentication fails, enabling direct examination of individual spoofed messages. The RUF report typically contains the From: header value, the Message-ID, the Subject line, the sending IP, and (at some ISPs) a redacted excerpt of the message body. This data allows the security team to assess whether a spoofing event is targeted (specific recipients, tailored content) or mass-scale (broad recipient list, generic content) — information that drives the incident response urgency and scope.

Reading Aggregate Reports During an Incident

When a security incident is suspected — a user reports receiving a spoofed email, IT receives an alert about phishing targeting the organisation's employees, or unusual DMARC failure volumes appear in the monitoring dashboard — the DMARC aggregate report is the first data source to analyse. The aggregate report XML contains exactly what the security team needs: which IP addresses sent email claiming to be from your domain, how many messages each IP sent, and whether those messages passed or failed SPF, DKIM, and DMARC authentication.

The key data fields in the DMARC aggregate XML for security investigation:

<record>
  <row>
    <source_ip>198.51.100.42</source_ip>   <!-- Sending IP -->
    <count>4721</count>                     <!-- Messages sent -->
    <policy_evaluated>
      <disposition>none</disposition>       <!-- What policy did (none/quarantine/reject) -->
      <dkim>fail</dkim>                     <!-- DKIM result -->
      <spf>fail</spf>                       <!-- SPF result -->
    </policy_evaluated>
  </row>
  <auth_results>
    <spf>
      <domain>spoofed-sender.com</domain>   <!-- MAIL FROM domain -->
      <result>pass</result>                 <!-- SPF pass at MAIL FROM, not From: -->
    </spf>
  </auth_results>
</record>

When investigating a spoofing incident: identify records where source_ip is not a known authorised sending IP AND count is significant (more than a few test messages). A record showing 4,721 messages from an unauthorised IP with SPF and DKIM failures is a spoofing campaign — scale and timing visible from the report. If the DMARC policy at time of the report was p=none, those 4,721 messages were delivered to their recipients despite failing authentication. If p=quarantine, they were delivered to spam. If p=reject, they were blocked entirely. The policy level determines the business impact of the spoofing event.

Forensic Report (RUF) Analysis

DMARC forensic reports provide per-message detail for authentication failures — they are the closest equivalent to packet capture for email security incidents. Not all ISPs send RUF reports (Gmail and most EU ISPs do not; Yahoo and some others do), and the data is redacted for privacy, but when available, RUF data provides message-level evidence for the incident investigation.

The RUF report format is an ARF (Abuse Reporting Format) email with the failed message's headers included. The security-relevant data in a typical RUF report: the From: header (confirming the spoofed address), the Reply-To header (often revealing the attacker's real collection address), the Subject line (enabling assessment of whether the attack is targeted or generic), the Message-ID (unique identifier for cross-referencing with other reports), and the sending IP (enabling geolocation and ISP lookup). When multiple RUF reports arrive for the same incident, the Message-ID values confirm whether the same message was rejected by multiple ISPs (indicating broad targeting) or unique messages were sent (indicating tailored targeting).

The privacy constraint on RUF data: most ISPs strip or redact recipient email addresses from RUF reports before sending them. This prevents the domain owner from learning which specific recipients were targeted by the spoofed messages — a privacy protection for the recipients that limits the scope of the investigation. In practice, the sending IP and sending pattern data in RUF reports is sufficient for most incident investigations without needing recipient addresses.

Detecting and Responding to Domain Spoofing

Domain spoofing — where an attacker uses your brand's domain in the From: header of malicious messages — is detectable through DMARC aggregate reports as a sudden appearance of a new, unauthorised IP address sending significant message volumes with DMARC failure. The detection workflow:

Investigating Active Phishing Campaigns

When an active phishing campaign targeting the organisation is reported (employees receiving spoofed emails, IT receiving abuse reports from partners), DMARC data helps answer the investigation's most urgent questions: How many messages were sent? Who sent them? Are they still sending? Are they being blocked by DMARC policy?

The DMARC-based phishing investigation workflow: retrieve the most recent 7 days of aggregate reports for all sending domains. Identify the unauthorised source IP(s) and the message volume timeline — is the volume increasing, stable, or declining? Check the RUF reports if available for subject line and Reply-To data that characterises the attack. Cross-reference the source IP with threat intelligence feeds (VirusTotal, Shodan, AbuseIPDB) to assess whether the IP is a known malicious actor or a newly compromised legitimate server.

If DMARC policy is at p=reject and the attack source is failing authentication, the attack is effectively contained for recipients at ISPs enforcing DMARC. However, recipients at ISPs that do not enforce DMARC (smaller ISPs, corporate mail systems without DMARC enforcement) may still be receiving the spoofed messages. This makes p=reject the most important incident containment action available — but it must be deployed correctly to avoid blocking legitimate mail in the process of blocking spoofed mail.

BEC Detection Using DMARC Data

Business Email Compromise (BEC) attacks often use look-alike domains (brand-eu.com instead of brand.com, brand-invoices.net instead of brand.net) rather than direct domain spoofing — because DMARC at p=reject blocks direct spoofing but does not block look-alike domains that pass their own authentication. DMARC data alone cannot detect look-alike domain attacks; but DMARC data combined with email brand monitoring provides two-layer BEC protection.

The DMARC component of BEC detection: monitor all subdomains of the primary domain for unauthorised sending. A DMARC record at brand.com applies to brand.com messages; a BEC attacker using mail.brand.com may not be covered if mail.brand.com does not have its own DMARC record. Publishing wildcard DMARC records or explicit DMARC records for all used subdomains closes this gap. The aggregate reports for each subdomain DMARC record then provide visibility into any sending from those subdomains — legitimate or not.

DMARC data also reveals internal BEC patterns: if an employee account is compromised and sending phishing messages, those messages will pass SPF and DKIM (because they are sent from the legitimate infrastructure) but may show unusual sending patterns in the aggregate report volume data — sudden high-volume sending from an account that normally sends low volume. Monitoring for volume anomalies in per-source aggregate report data provides an early-warning signal for compromised account sending that authentication-based checks alone cannot surface.

Building an Incident Timeline from DMARC Data

DMARC aggregate reports are dated by the reporting period they cover — typically 24-hour periods ending at midnight UTC. By analysing the aggregate reports for a domain over a multi-day window, the security team can reconstruct the precise timeline of a spoofing or phishing incident: when the first spoofed messages were sent, when the volume peaked, and when it declined (if it has). This timeline is essential for the incident report and for assessing the number of recipients who may have received spoofed messages before DMARC policy was advanced to block them.

The timeline reconstruction process: for each day of DMARC report data, extract the source IP volumes for unauthorised senders. Plot the daily message count from each unauthorised IP against the calendar date. The resulting timeline shows the attack trajectory — rising volume indicates an active, scaling campaign; declining volume may indicate the attacker moved to a different approach or was blocked upstream. Correlate the DMARC timeline with the organisation's incident discovery date to assess how long the attack was active before detection.

Hardening Authentication Post-Incident

Every spoofing or phishing incident that DMARC data reveals should trigger an authentication hardening review. The hardening actions that close the gaps a DMARC-visible incident exposes: advance DMARC policy from p=none or p=quarantine to p=reject for any domain where all legitimate sources are confirmed to pass authentication. Publish DMARC records for all subdomains that currently lack them. Enable automated monitoring of DMARC aggregate reports with alerts for any new source IP sending above a threshold volume. Register the domain with email brand monitoring services that detect look-alike domain registrations and flag them for investigation before they are weaponised in BEC attacks.

The post-incident hardening investment is the direct application of the incident's lessons to the organisation's future protection. An organisation that experiences a spoofing incident, advances DMARC to p=reject, enables aggregate report monitoring, and registers for brand monitoring has converted the incident cost into a permanent security improvement. The same attack attempted 6 months later will be blocked at the DMARC policy level rather than delivered to recipients — the security investment that the incident motivated producing its return on every subsequent attack attempt that the organisation now automatically defeats.

DMARC forensics is the security capability that converts email authentication data into actionable incident intelligence. Build the reporting infrastructure (RUA processing, alert thresholds, forensic mailbox), advance the policy to enforcement, and maintain the daily review discipline that catches new unauthorised sources within 24-48 hours of their first message. That combination — complete reporting, enforcement policy, and daily review — makes DMARC the real-time domain abuse detection system that protects the organisation's email brand from the spoofing and phishing attacks that target every high-profile domain consistently.

DMARC data transforms an opaque email security incident into a documented, evidence-based investigation. The organisation that has built the DMARC reporting infrastructure before the incident arrives — aggregate report processing, forensic report mailbox, automated source monitoring — conducts its incident investigation in hours rather than days. Build the infrastructure now, while there is no incident to respond to. The investment in preparation is always smaller than the cost of the investigation it shortens when the incident eventually arrives.