Investigate email spoofing by collecting Authentication-Results, the Received chain, From vs Return-Path, and DMARC aggregate reports before any containment action. A forged From header alone is not proof; alignment failures and missing signatures are. ArawaMail gives you standard mailbox access and MCP search/read on one mailbox—no specialized forensic dashboard.
Why forged From headers create real business risk
Spoofed messages that appear to come from a CEO, vendor, or partner bypass visual checks and trigger wire fraud or credential theft. The problem is not the display name; it is whether the message actually originated from an authorized sender on the claimed domain.
Decision-makers need a repeatable evidence process that distinguishes true spoofing from legitimate forwarding or lookalike domains. Without it, teams either ignore real attacks or over-react and disrupt normal mail.
Evidence checklist: what actually proves or disproves spoofing
- Authentication-Results header — Look for spf=pass/fail, dkim=pass/fail, and dmarc=pass/fail with explicit alignment notes. A DMARC fail with p=quarantine or reject is strong evidence of spoofing or misconfiguration.
- Received headers — Trace the hop chain backward. Unexpected early hops or missing DKIM signatures on the claimed domain are red flags.
- From vs Return-Path / MAIL FROM — Misalignment here is the classic spoof signal. See From, Reply-To, and Return-Path for the precise roles.
- DMARC aggregate (RUA) reports — These show volume of unauthorized sources. Use them for pattern detection, not single-message forensics. Start with How to read a DMARC report.
Alignment is the decisive factor. An SPF pass on a completely different domain does not authorize the From domain. Read DMARC Alignment vs SPF Pass before concluding a message is legitimate.
Step-by-step header and report analysis
- Export the full raw message (including all headers) from the mailbox.
- Locate Authentication-Results and record the exact spf, dkim, and dmarc results plus the domains they evaluated.
- Map the Received chain. Note the first external hop and whether DKIM was applied by the claimed domain.
- Compare the visible From domain against the Return-Path domain and any DKIM d= value.
- Search DMARC RUA reports for the same source IP or domain over the past 24–72 hours.
- Check whether the message was ARC-sealed (common in legitimate forwarding). See ARC Email Authentication.
How we analyzed this: We reviewed standard Authentication-Results syntax (RFC 8601), DMARC reporting formats, and ArawaMail’s documented mailbox and MCP capabilities. No proprietary forensic logging is claimed.
What ArawaMail users can actually do
ArawaMail provides a standard mailbox with Inbox, Sent, Drafts, Starred, Archive, Spam and Trash folders, plus search. Normal search excludes Spam. You can report spam to route future messages from that outside sender into Spam for the mailbox.
MCP (Model Context Protocol) lets an approved AI assistant search one mailbox by folder, text, sender, recipient, subject, unread status, and date range, then read conversations without marking them read by default. It cannot access other mailboxes, manage Spam, download attachments, or administer domains. See the Connect an AI Assistant (MCP) guide.
Domains must have SPF, DKIM, and DMARC configured through the Cloudflare activation flow before authentication results are meaningful. There is no automated spoofing dashboard or specialized incident-response tooling.
Containment and reporting steps
- Do not reply to or forward the message internally until evidence is recorded.
- If it is clear spoofing of your domain, tighten DMARC (move toward p=reject once you understand the impact) and review recent RUA reports.
- Report the message as spam inside the mailbox so future mail from that sender is isolated.
- For financial or credential requests, follow your existing incident-response playbook: verify via a known channel, reset exposed credentials if any, and document the headers.
- If the spoof targets a partner or vendor, share the Authentication-Results and Received headers so they can investigate their side.
Difference from legitimate forwarding
Legitimate mailing lists and forwarding services often fail DMARC alignment and rely on ARC. A message that fails DMARC but carries a valid ARC seal from a known forwarder is usually not spoofing of your domain. Pure forged From headers typically lack any valid authentication for the claimed domain and show an unrelated Return-Path.
Lookalike domains (paypa1.com vs paypal.com) can pass SPF and DKIM on their own domain while the visual From looks familiar. That is a different problem—domain monitoring and user education—not classic From spoofing.
FAQ
What headers prove an email is spoofed?
A DMARC fail combined with SPF and/or DKIM failure or misalignment for the From domain, plus a Received chain that does not originate from authorized infrastructure. A forged display name alone proves nothing.
Can I use ArawaMail MCP to investigate spoofing?
Yes, for one approved mailbox: search by sender, subject, or date and read full conversations. It will not give you cross-mailbox views, spam folder management, or automated report generation.
Should I immediately set DMARC to reject after seeing a spoof?
No. First confirm you understand all legitimate sources (including third-party senders and forwarders). Moving from p=none to p=reject without data creates delivery outages. Use aggregate reports to guide the change.
How is this different from a phishing email that passes authentication?
Phishing that passes SPF/DKIM/DMARC usually comes from a compromised legitimate account or a lookalike domain. Classic spoofing fails authentication for the claimed domain.
Related reading: SPF, DKIM, and DMARC explained, Why your emails go to spam, and the DNS & Deliverability guides.