I Built MailGuard XDR: An AI-Powered Email Security Platform for SOC Analysts
A suspicious email almost never has a single tell. The sender name can look fine while the return path points somewhere else entirely. The domain can look plausible while a link underneath it doesn't. An attachment can look like an ordinary invoice while its hash matches something already flagged elsewhere. Looking at any one of those signals in isolation — just the sender, just the subject line — misses the picture that only shows up when you look at all of them together.
That's the problem MailGuard XDR is built to solve. It's not a spam filter or a simple "does this look like phishing" scanner — it's an AI-powered email security platform built around how a SOC analyst actually investigates a suspicious email: pulling apart headers, content, links, and attachments, extracting indicators of compromise, and arriving at a risk assessment backed by evidence rather than a gut feeling.
The Problem: One Signal Isn't Enough
Most consumer-facing "is this phishing" tools work off a single heuristic — a domain reputation check, or a keyword scan for "urgent" and "verify your account." Real phishing has gotten past that a long time ago. A convincing email today can pass a domain check on the surface, use clean language, and still be malicious — the tell is often buried in a header field nobody looks at, or a mismatch between what a link says and where it actually goes.
MailGuard XDR's whole design starts from that observation: no single indicator is reliable enough on its own. Multiple weak signals, correlated together, are far more trustworthy than any one strong-looking signal alone.
The Analysis Pipeline
Every submitted email runs through the same structured pipeline, moving from raw structure to evidence to a final verdict:
Email Threat Analysis
At a high level, here's what the tool is actually looking for across an email:
Header Inspection: Where the Real Evidence Lives
This is the part of email analysis most people never look at, and it's often the most revealing. Email headers carry the actual routing and authentication history of a message — much harder for an attacker to fake convincingly than the sender name shown in an inbox.
Phishing Detection in Action
Content and social-engineering analysis run alongside header inspection — urgency language, credential requests, and spoofed branding are weighed together with the technical evidence rather than treated as a separate, lesser signal.
Attachment Analysis
Attachments get evaluated for characteristics associated with malware delivery — file type mismatches (a "PDF" that's actually an executable), naming patterns designed to look mundane, and other structural red flags — all without needing to actually execute or open the file.
IOC Extraction & Visualization
Once the pipeline has pulled evidence out of the headers, content, links, and attachments, it consolidates everything into a structured set of indicators of compromise — the concrete artifacts an analyst can actually act on, track, or search for elsewhere.
├── Domain — sending/lookalike domains
├── URL — embedded links and true destinations
├── IP — originating and routing addresses
├── Hash — attachment file hashes
└── Attachment — file names and types
Representing indicators this way — as a tree branching out from the email itself — mirrors how an analyst actually thinks about an investigation. It's not one flat list of suspicious things; it's an email that produced a domain, which relates to a URL, which resolves to an IP, alongside an attachment with its own hash. Seeing the relationships, not just the individual artifacts, is what turns a pile of data into an actual investigative lead — the same reason IOC pivoting is such a core skill in real threat intelligence work.
Final Verdict & Risk Assessment
Every stage of the pipeline feeds into a final risk assessment — not a single arbitrary score, but a verdict backed by exactly which pieces of evidence drove it: failed authentication, a mismatched Reply-To, a suspicious attachment hash, whatever combination applies. The AI layer's job here is to explain that reasoning clearly, the same way a senior analyst would walk a junior analyst through why a specific email got flagged.
How This Connects to Real SOC Work
The entire design of MailGuard XDR maps directly onto the same investigation loop that runs through real SOC work — the same one I explored in SOCVerse AI:
A suspicious email is the alert. Header, content, link, and attachment analysis is the investigation. The extracted IOCs are the evidence. The risk assessment is the verdict. And whatever action follows — block the domain, quarantine the email, escalate further — is the response. MailGuard XDR isn't a separate idea from that loop; it's that loop, applied specifically to email.
I didn't expect header inspection to end up being the most technically interesting part of this project. But the more I worked with real header data, the clearer it became that this is where attackers have the hardest time hiding — a convincing subject line costs an attacker nothing, but faking a clean SPF/DKIM/DMARC pass, or a Received chain that doesn't contradict itself, is a much higher bar. That's exactly why building strong header analysis felt like the highest-leverage part of the whole pipeline.
What This Approach Teaches
Core Takeaways From Building MailGuard XDR
- No single indicator is trustworthy alone: Correlated weak signals beat one strong-looking signal every time.
- Headers are harder to fake than content: Authentication results and routing history carry more evidentiary weight than anything in the visible message body.
- IOCs are relationships, not just a list: Visualizing them as a tree branching from the email mirrors how real investigation and pivoting actually works.
- AI's role is explanation, not verdict-by-fiat: The value is in clearly explaining which evidence drove a risk score, not just outputting a number.
- This is the SOC loop, not a different idea: Alert → investigation → evidence → verdict → response is the same structure whether the alert is an email, a network event, or an endpoint anomaly.
Submit an email and see the full header-to-verdict investigation play out.
Open MailGuard XDRWhat's Next
I'm planning to expand the IOC visualization to show relationships across multiple analyzed emails, not just within a single one — so patterns across a campaign, not just a single message, become visible. If there's a header field, IOC type, or attachment characteristic you think the pipeline is missing, I'd like to hear about it.
0 Comments