Forensic Report Analysis
Forensic reports (RUF) provide real-time samples of authentication failures. Unlike aggregate reports, forensic reports show you the actual email headers, making them invaluable for debugging and detecting spoofing attempts.
What Are Forensic Reports?
Forensic reports are sent immediately when an email fails DMARC authentication. They contain samples of the actual email with full headers, making them perfect for investigating specific failures.
Real-Time Delivery
Sent within minutes of failure (vs aggregate reports sent daily). Critical for detecting active spoofing attacks.
Full Email Headers
Contains complete email headers including Authentication-Results, DKIM-Signature, Received headers, and more.
Limited Adoption
Gmail stopped sending RUF in 2023 due to privacy concerns. Yahoo and Outlook still send them but volume is low.
Anatomy of a Forensic Report
Here's what a real forensic report looks like. These arrive as email messages (not XML):
From: noreply@dmarc.yahoo.com To: forensic@yourdomain.com Subject: FW: DMARC Failure Report for yourdomain.com This is an authentication failure report for an email message received from IP 185.220.101.45 on Mon, 01 Jan 2025 14:23:15 +0000. Feedback-Type: auth-failure User-Agent: Yahoo!-DMARC/1.0 Version: 1 Original-Envelope-Id: <unique-id@yahoo.com> Authentication-Results: yahoo.com; dkim=fail reason="signature verification failed" spf=fail smtp.mailfrom=yourdomain.com Source-IP: 185.220.101.45 Reported-Domain: yourdomain.com Arrival-Date: Mon, 01 Jan 2025 14:23:15 +0000 --- BEGIN ORIGINAL MESSAGE HEADERS --- Received: from unknown (185.220.101.45) by mx.yahoo.com with SMTP; Mon, 01 Jan 2025 14:23:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=default; h=from:to:subject:date; bh=invalid-body-hash; b=invalid-signature From: support@yourdomain.com To: victim@customer.com Subject: Urgent: Verify Your Account Date: Mon, 01 Jan 2025 14:23:00 +0000 Message-ID: <fake123@attacker.com> --- END ORIGINAL MESSAGE HEADERS ---
Key Fields to Analyze
1. Source-IP
Source-IP: 185.220.101.45
What to do:
- Run WHOIS lookup to identify owner
- Check if IP is from known ESP or cloud provider
- Search IP in threat intelligence databases
- Compare against your authorized sending IPs
2. Authentication-Results
Authentication-Results: yahoo.com;
dkim=fail reason="signature verification failed"
spf=fail smtp.mailfrom=yourdomain.com
What it means:
- dkim=fail: DKIM signature invalid or missing
- spf=fail: Source IP not authorized in SPF record
- Both failing = likely spoofing (or major misconfiguration)
3. DKIM-Signature Header
DKIM-Signature: v=1; a=rsa-sha256;
d=yourdomain.com;
s=default;
bh=invalid-body-hash;
b=invalid-signature
Check:
- d= domain: Should match your domain
- s= selector: Does this selector exist in your DNS?
- Invalid signature suggests attacker tried to forge DKIM
4. From/To/Subject
From: support@yourdomain.com
To: victim@customer.com
Subject: Urgent: Verify Your Account
Red flags: Generic support email, urgency language ("Urgent", "Verify"), targeting customers. Classic phishing pattern.
5. Received Headers
Received: from unknown (185.220.101.45)
by mx.yahoo.com with SMTP;
Shows email path: "from unknown" confirms attacker didn't properly configure reverse DNS. Legitimate senders have proper hostnames.
Step-by-Step Investigation
Identify the Source IP
Run WHOIS and reverse DNS lookup:
whois 185.220.101.45
dig -x 185.220.101.45
Check if it's a known ESP, cloud provider, or suspicious network.
Determine: Legitimate or Spoofing?
✅ Likely Legitimate If:
- IP belongs to known ESP (SendGrid, Mailchimp, etc.)
- Reverse DNS has proper hostname
- You recognize the From address
- Email content looks like your templates
❌ Likely Spoofing If:
- Unknown IP from suspicious country/network
- No reverse DNS or generic hostname
- Phishing content (verify account, urgent action)
- Targeting your customers/partners
If Legitimate: Fix Authentication
- Add source IP to SPF record
- Configure DKIM signing for this service
- Test email from this source
- Wait 24-48 hours for DNS propagation
- Verify no more failures in forensic reports
If Spoofing: Document & Monitor
- Log source IP and timestamp
- Report to abuse contact if high volume
- Check if DMARC policy blocked it (disposition=reject)
- Alert security team if targeting customers
- Monitor for repeat attempts from same network
Track Patterns Over Time
Keep spreadsheet of forensic reports: date, source IP, type (legitimate/spoofing), action taken. Look for patterns: repeated IPs, attack campaigns, configuration issues.
Common Scenarios
Scenario 1: New ESP Not Configured
Source-IP: 167.89.123.45 (SendGrid)
dkim=fail, spf=fail
From: marketing@yourdomain.com
Diagnosis: Marketing team added SendGrid but didn't configure authentication.
Fix: Add include:sendgrid.net to SPF, set up DKIM in SendGrid dashboard.
Scenario 2: Email Forwarding Issues
Source-IP: 172.253.x.x (Gmail forwarding)
spf=fail
dkim=pass
Diagnosis: User forwarded your email to Gmail. SPF fails but DKIM passes.
Action: No fix needed. DMARC still passes with DKIM alignment. This is normal.
Scenario 3: Active Phishing Campaign
Source-IP: 185.220.x.x (Tor exit node)
dkim=fail, spf=fail
From: support@yourdomain.com
Subject: Urgent: Verify Account
Diagnosis: Spoofing attack from Tor network.
Action: Document attack, report to abuse contact, confirm DMARC p=reject blocked it. Alert customers if needed.
- • Gmail stopped sending RUF in 2023 due to privacy concerns (GDPR compliance)
- • Many ISPs limit RUF volume to avoid overwhelming recipients (send samples, not all failures)
- • Privacy regulations restrict sharing PII in forensic reports
- • RUF is optional - ISPs can choose not to send them
- • Aggregate reports (RUA) are now the primary monitoring tool
Real-Time Spoofing Alerts
TrustYourInbox analyzes forensic reports and sends instant alerts when spoofing attempts are detected. Stop attacks before they spread.