M365 Incident Investigation

A repeatable workflow for investigating Microsoft 365 / email security incidents — lookalike-domain fraud, header forensics, SPF/DKIM/DMARC checks, abuse reports, and IC3 filings.

The standard playbook for working an email security incident — most often a homoglyph (lookalike domain) fraud attempt where someone spoofs a known sender to redirect a payment or harvest credentials. The shape is always the same: collect evidence, confirm the spoof, report it, escalate if money is involved.

The short version

1. Collect the message + full headers via gmail_*
2. Identify the real vs. lookalike sender domain
3. Check SPF / DKIM / DMARC alignment
4. Draft abuse reports to the registrar and host
5. If money moved or was requested: file an IC3 report
6. Save notes, open a task to track follow-up

Steps 1–3 establish what happened. Steps 4–6 are what you do about it. Don’t skip the evidence collection — the abuse and IC3 reports are only as good as the headers you captured.

Investigation steps

1. Locate and pull the message

Find the suspect message and retrieve it with full headers intact.

gmail_search_emails(query="from:billing subject:invoice newer_than:7d")
gmail_get_message(message_id="<id from search>")

Pull the raw headers, not just the rendered body. The header block is where the spoof shows up — Return-Path, Received, Authentication-Results, From, and Reply-To are the fields that matter. A friendly display name (“Accounts Payable”) tells you nothing; the actual address and the authentication results tell you everything.

2. Identify the real vs. lookalike domain

Compare the sending domain against the legitimate one character by character. Homoglyph and typosquat tricks to watch for:

• Swapped letters (rn for m, vv for w, l for I)
• Inserted or dropped characters (super-ht.com vs. superht.com)
• Alternate TLDs (.co instead of .com, .net instead of .com)
• Unicode lookalikes (Cyrillic/Greek glyphs that render like Latin letters)
• Subdomain spoofing (super-ht.com.secure-mail.example)

The legitimate sender domain is whatever the system of record says it is — confirm against known-good correspondence rather than trusting the suspect message.

3. Check SPF / DKIM / DMARC alignment

Read the Authentication-Results header and confirm the result for each mechanism. A spoofed message typically fails or misaligns at least one.

DMARC alignment is the strongest single signal: a lookalike domain can publish its own SPF and DKIM and “pass” both, but it cannot make those align with the real From domain it’s impersonating. If the visible From is the real domain and DMARC fails, treat it as spoofed.

For domains under SuperHiTech control, the legitimate mail path is the Virtualmin / Postfix server at webserver.super-ht.com, which maintains DKIM and SPF — see Hosts. A message claiming to be from a super-ht.com address that didn’t traverse that path is suspect.

4. Look up the lookalike domain’s registration and host

Use web_search / fetch_url to gather WHOIS and hosting facts on the malicious domain:

• Registrar (where to send the registration-abuse report)
• Hosting provider / nameservers (where to send the hosting-abuse report)
• Registration date (newly registered domains are a strong fraud signal)
• Published abuse contact addresses

Record what you find — it goes straight into the abuse reports below.

5. Draft abuse reports

Draft separate reports to the registrar and the hosting provider of the malicious domain. Use gmail_create_draft (or gmail_send_email once reviewed). Each report should include:

• The malicious domain and a one-line description of the abuse (phishing / business email compromise / payment fraud)
• The relevant message headers as evidence
• The legitimate domain being impersonated
• A clear, specific request (suspend the domain / take down the host)

Keep it factual and concise. Abuse desks process volume — give them exactly what they need to act without reading a narrative.

6. File an IC3 report for financial fraud

If money was requested or moved, file at ic3.gov. The IC3 complaint should capture the timeline, the parties, the financial instrument involved, and the evidence collected above. File promptly — see the callout. After filing, advise the affected party to also contact their financial institution directly to attempt a recall or freeze.

7. Record and track

Close the loop in Leif’s persistent state:

save_note(content="<incident summary, domains, auth results, report status>")
create_task(content="Follow up on <domain> abuse report / IC3 case")

Later searches (search_notes) should be able to reconstruct the incident without re-doing the forensics.

Evidence-collection checklist

Capture all of these before drafting any report:

• Full raw message headers (Return-Path, all Received, Authentication-Results, From, Reply-To)
• The rendered message body and any attachments or links (do not click links — record the URL text)
• The exact lookalike sender address and the legitimate address it imitates
• SPF / DKIM / DMARC results for the message
• WHOIS / registrar / host / registration date for the malicious domain
• Published abuse contacts for the registrar and host
• Timeline of events (when received, when noticed, whether any payment was requested or sent)
• Any financial details relevant to an IC3 filing (instrument, amount, direction) — kept for the report, not invented

Notes

• Never click links in a suspect message during investigation. Record the URL as text and analyze it out-of-band.
• A lookalike domain that passes its own SPF and DKIM is still a spoof if DMARC alignment against the impersonated From fails. Don’t let a “pass” on the wrong domain talk you out of the conclusion.
• Newly registered domains (days old) impersonating an established sender are almost always malicious — registration date alone is strong corroboration.

Related pages

• Hosts — webserver.super-ht.com mail server (DKIM, SPF)
• Network Topology — public-facing mail and domain endpoints
• Workflow Patterns — the rest of the repeatable workflows