Run a Phishing Tabletop Exercise Your Team Won't Hate

The alert fires. A user clicked. The .eml file is sitting in your triage queue. Now what?

Forget the tired, multiple-choice phishing tests that treat your team like rookies. The 'spot the typo' game is over. Real threats are subtler, woven into the very fabric of email authentication protocols. Your team's ability to dissect an email header under pressure is a far better indicator of readiness than their ability to spot a fuzzy logo.

This is a guide to running a 90-minute phishing tabletop that actually sharpens skills. We're not just asking 'Is it a phish?' We're asking 'Why did our defenses evaluate it this way, and how can we prove malicious intent using the headers alone?'

Design a Scenario That Doesn't Insult Their Intelligence

The foundation of a worthwhile exercise is a plausible pretext. Your team has seen a million Nigerian prince scams and fake password reset alerts. To create a real learning moment, the scenario needs to be something that could genuinely slip past both automated filters and a busy user.

BEC vs. Credential Harvesters

Go beyond the obvious. Instead of a generic attachment, build the exercise around one of two high-impact scenarios: a Business Email Compromise (BEC) attempt or a sophisticated credential harvester. A BEC attack is about social engineering, urgency, and authority—no links, no attachments, just a well-crafted request from a spoofed executive. A credential harvester uses a near-perfect landing page clone to steal credentials for a critical service like your VPN or SSO provider.

The key is to make the email *look* legitimate on the surface. The evidence of fraud should be buried in the headers, forcing the analyst to do the real work of an investigator.

The Power of Plausible Pretext

Consider these starting points: A fake invoice from a known vendor using a lookalike domain (`acme-corp.com` vs. `acme.com`). A calendar invite from a partner organization that was forwarded, breaking authentication along the way. A request from 'HR' to review a new benefits document hosted on a suspicious SharePoint-like domain. These scenarios mirror actual incidents and provide rich ground for technical analysis.

Assemble Your Crew and Set the Clock

This isn't a performance review or a red-team-versus-blue-team competition. It's a collaborative workout designed to build collective muscle memory. The tone should be one of professional curiosity, not adversarial scrutiny. Keep the group small—three to six participants is ideal.

Defining Roles

Assign clear roles to keep the exercise moving. You'll need a Facilitator to present the scenario, answer questions, and keep time. The Analyst(s) are the core participants, responsible for examining the evidence and verbalizing their thought process. Finally, a Scribe should capture key observations, decisions, and action items. The Scribe's notes are not just meeting minutes; they are the raw material for your after-action report.

The 90-Minute Cadence

A tight schedule maintains focus and energy. Stick to a cadence: 10 minutes for the scenario briefing. 45 minutes for hands-on analysis and discussion. 30 minutes for a 'hot wash' debrief where the team discusses findings and proposes improvements. A 5-minute wrap-up concludes the session. This structure respects everyone's time and ensures you walk away with concrete results, not just a vague sense of having 'done' a drill.

Craft Your .eml Payloads for Maximum Learning

This is where the magic happens. A good tabletop hinges on sample emails that test specific, often misunderstood, aspects of email security. Don't just find a generic phishing email; construct one to target a particular analytical skill. Your goal is to simulate the failure modes of real-world email delivery.

Scenario A: The SPF-Breaking Forwarder

Imagine a legitimate email from a vendor (`vendor.com`) sent to your company's general `sales@` alias, which then forwards to your analyst's inbox. The forwarding server is not listed in `vendor.com`'s SPF record (RFC 7208). The result? An SPF `fail` or `softfail` on a perfectly legitimate email. This forces the analyst to trace the `Received` headers, identify the forwarding hop, and look for corroborating signals like a passing ARC-Seal (RFC 8617), which is designed to preserve authentication results across hops. It teaches them that an SPF fail isn't always a smoking gun.

Authentication-Results: mx.google.com; arc=pass (i=1); dkim=pass header.i=@vendor.com; spf=softfail (google.com: domain of transitioning user@vendor.com does not designate 209.85.220.41 as permitted sender) smtp.mailfrom=user@vendor.com

Scenario B: The DMARC Alignment Trap

This is the classic BEC lookalike domain. The attacker registers `your-company.co` to impersonate `your-company.com`. They set up valid SPF and DKIM (RFC 6376) for `your-company.co`. An email from `ceo@your-company.co` will show SPF `pass` and DKIM `pass`. The critical failure, and the key teaching point, is DMARC alignment (RFC 7489). The domain in the `From:` header (`your-company.com`, which the user sees) does not *align* with the domain that passed SPF/DKIM (`your-company.co`). This exercise drills the crucial difference between authentication and alignment.

Scenario C: The Body Hash Mismatch

DKIM works by cryptographically signing parts of the email, including a hash of the body (`bh=` tag). Sometimes, an intermediate MTA will add a footer, a disclaimer, or even just modify whitespace, causing the body to change in transit. This invalidates the signature, leading to a DKIM `fail`. An analyst might see this fail and immediately condemn the email. This scenario teaches them to look for evidence of MTA meddling. Is the signature itself valid but the body hash doesn't match? This suggests modification, not necessarily malicious spoofing, and adds vital context to the investigation.

Scoring: It's a Rubric, Not a Report Card

The point of the exercise is to identify gaps, not to assign blame. A quantitative score is less valuable than a qualitative assessment based on a clear rubric. The Scribe's notes are your data source here.

Evaluate the team's process. Did they immediately jump to checking VirusTotal, or did they start with the fundamentals of the email path? Did they correctly interpret the `Authentication-Results` header? Did someone bring up DMARC alignment, or did the conversation get stuck on the simpler SPF/DKIM pass/fail verdicts? Did they trace the `Received` headers to map the email's journey from source to destination?

Your rubric should have categories like: Header Analysis Proficiency, Tool Usage (e.g., decoders, sandboxes), Communication & Collaboration, and Final Verdict Justification. For each category, note what went well and where the team struggled. This isn't about finding a single point of failure; it's about understanding the team's current state of practice.

The After-Action: Turn Findings into Playbooks

The debrief, or 'hot wash,' is the most critical phase. This is where learning solidifies into action. Without a structured debrief, the exercise is just an interesting academic puzzle with no operational impact.

Use a simple framework: `Observations`, `Insights`, and `Actions`. First, list the objective observations from the exercise ('We saw a DKIM fail but didn't investigate the body hash mismatch.'). Second, derive insights from those observations ('Our team defaults to treating any DKIM fail as malicious, which could lead to false positives on modified-but-legitimate emails.').

Finally, and most importantly, define concrete actions. An action isn't 'get better at header analysis.' It's 'Add a specific step to our phishing IR playbook: When DKIM fails, verify if it's due to a body hash mismatch vs. an invalid signature.' Or, 'Create a quick reference guide for interpreting DMARC alignment failures.' These small, tactical improvements are what elevate your team's capabilities over time.

The takeaway

Running a phishing exercise shouldn't feel like a pop quiz. When designed correctly, it's a sparring session—a chance for your security team to grapple with realistic ambiguity in a controlled environment. The goal isn't just to practice identifying threats, but to refine the analytical process itself, turning a chaotic flood of header data into a clear, defensible narrative.

The best defense isn't a user who never clicks; it's an analyst who knows exactly what to do when they inevitably do. As they build this expertise, tools like MailSleuth.AI can help automate the initial parsing and validation, freeing up analysts to focus on the truly ambiguous signals that require human judgment.