Automating Enterprise Phishing Triage: SPF, DKIM, DMARC, and Raw Email Extraction

Most phishing triage backlogs are not a detection problem. They are a throughput problem: dozens of user-reported emails a day, each requiring the same handful of manual checks before an analyst can close it out. This is a write-up of the triage pipeline I built to take that repetitive first pass off analysts’ plates.

The manual baseline

Before automation, triage for a reported email looked like this: open the raw source, find the Authentication-Results header, manually read the SPF/DKIM/DMARC verdicts, check whether the visible “From” domain matched the DKIM d= domain, and decide whether the message was a spoof attempt or a legitimately misconfigured sender. Repeated across a queue, that adds up fast, and it is exactly the kind of check a script does more consistently than a tired analyst at 4pm on a Friday.

Extraction and parsing

The first stage extracts the raw artifact, whether it lands as a .eml from a mail-flow rule or a .msg from Outlook, and normalizes it into a common structure: headers, body, and attachments as separate fields. Handling .msg specifically means parsing the OLE compound file format rather than a plain MIME message, so the extraction step has to branch on file type before anything else can run.

Header alignment checks

With a normalized header set, the pipeline checks three things:

• SPF — does the sending IP appear in the authorized senders for the envelope-from domain.
• DKIM — does the signature verify, and does the d= domain match the domain the user actually sees.
• DMARC — does the message pass alignment (SPF or DKIM aligned with the From header domain), and what does the domain’s DMARC policy say to do if it fails.

The alignment check is the one that catches the most convincing spoofs. A message can pass SPF outright because the attacker sent from their own infrastructure, and still fail DMARC because their domain does not match the one displayed to the user. Flagging on alignment, not just pass/fail, is what surfaces those cases.

Wiring it to KnowBe4

User reports come in through the KnowBe4 Phish Alarm Button (PAB), which forwards the reported message to PhishER. From there, a webhook triggers the triage pipeline. Verdicts and extracted indicators get written back so an analyst opens a ticket that already has the header verdicts, the sender’s real domain, and any URLs or attachments flagged, instead of a blank raw email to work through from scratch.

Where AI fits

The header checks are deterministic and do not need a model. Where an AI-assisted layer helps is the ambiguous middle: a message that passes every technical check but reads like a pretext for credential harvesting, or an attachment name that is a near-miss for a legitimate vendor. That triage step runs through Microsoft Copilot Studio, orchestrated with Power Automate and a set of Python microservices that handle the actual parsing and header logic. The model does not make the close/escalate decision. It surfaces a recommendation and reasoning, and a human still signs off.

What I would still change

The biggest gap right now is attachment sandboxing. Header and URL checks run automatically, but suspicious attachments still need a manual detonation step. That is the next piece to fold into the pipeline.