One Email, Two Different DKIM Verdicts

Four mailboxes at a national insurance and employee-benefits brokerage received the same notification inside a three-minute window. Each copy said a message was waiting, and each was addressed to a different person, a first name merged into an otherwise identical template, which made a bulk send read like personal correspondence. The subject line carried a stray leading period, the artifact a template engine leaves when a preceding merge field resolves to nothing: . Missed message for [FirstName].

The display name was the phrase Message Notifications. The visible call to action read "Message in Teams." Everything in the framing pointed at Microsoft Teams. Nothing in the infrastructure did.

The sending domain that thought it was a moving company

The From address was supportselfservice@globalmovermuscatoman[.]com, a domain registered recently through a budget hosting provider. Its name has no relationship to Microsoft, to Teams, or to the brokerage that received it. It reads like a moving-company name, which is to say it reads like a domain bought in bulk and pointed at whatever campaign needed a sender that afternoon.

That is the whole deception at the identity layer, and the reason authentication was never going to help. The attacker was not spoofing Microsoft. They registered a domain, configured its sending infrastructure properly, and let it authenticate on its own terms while the body did the impersonating. MITRE ATT&CK tracks the acquisition step as T1583/001, domain acquisition and the costume as T1656, impersonation. Neither leaves a fingerprint on an SPF record.

Where the authentication story splits

Delivery ran through three hops: SendGrid, at s[.]wrqvtnrb[.]outbound-mail[.]sendgrid[.]net, client IP 149[.]72[.]114[.]91; then a Mimecast security relay at relay[.]mimecast[.]com over STARTTLS; then Microsoft 365.

At the mailbox, the surviving results were mostly green. SPF passed against the bounce subdomain em2838[.]globalmovermuscatoman[.]com, exactly what a correctly configured SendGrid tenant produces. DMARC passed against a policy of p=none, which means the domain owner asked for no enforcement at all. Composite authentication came back compauth=pass reason=100, the strongest result Microsoft issues. Read that trio in isolation and this is a well-behaved sender.

DKIM is where it comes apart. The final Microsoft check recorded a failure for header.d=globalmovermuscatoman[.]com, selector s1, with the reason "body hash did not verify." That does not mean a key was wrong or a selector was missing. It means the content that arrived is not the content that was signed.

Now look one hop earlier. The ARC seal written by the Mimecast relay recorded DKIM as a pass for the same domain and the same selector. Both verifiers were almost certainly correct, and the most likely explanation for the split is that between them the relay did what a link-protection gateway is built to do: rewrite the URLs in the body, wrapping them in its own click-inspection domain. The delivered message carries that wrapper, so the rewriting demonstrably happened, after the relay validated the signature and before Microsoft validated it again. On that reading, the gateway broke the signature it had just approved.

See Your Risk: Calculate how many threats your SEG is missing

This is the part most authentication explainers skip. DKIM is not a property of a message, it is a property of a message at a point in the delivery path. Every rewriting intermediary, every appended disclaimer, every sanitized attachment resets that verdict for everyone downstream. So "DKIM failed" reaches the mailbox carrying two meanings that look identical: someone tampered with this, or a security product touched it. RFC 7489 lets DMARC pass on SPF alignment alone precisely because signature survival through relays is unreliable. Treat a DKIM failure as decisive and you chase gateway artifacts. Treat it as ignorable and you miss real tampering. Neither is a control.

The click that went somewhere real

The "Message in Teams" call to action pointed first at the relay's own protection domain, url[.]us[.]m[.]mimecastprotect[.]com, which follows from the rewriting above. Unwrap it and the real destination was a click-tracking subdomain on the attacker's own domain, hxxp://url1211[.]globalmovermuscatoman[.]com/ls/click?upn= plus a long tokenized string. Plain HTTP, no encryption, a per-recipient token.

Follow that and the chain terminates at hxxps://assets-usa[.]mkt[.]dynamics[.]com/, a legitimate Microsoft Dynamics marketing asset host. Not a credential form. Not a fake sign-in page. A real Microsoft-owned page.

That is the deception, and it is more efficient than a harvest page. The recipient was promised a waiting Teams message and handed a marketing asset, which maps to T1566/002 for the link delivery and T1036/005 for the gap between what the CTA claimed and where it went. Meanwhile the per-recipient token confirmed which mailboxes were live and which humans clicked, with no attacker-controlled landing infrastructure exposed to any scanner. The 2024 Verizon Data Breach Investigations Report puts the median time from receiving a phishing link to clicking it at 21 seconds, roughly how long this reconnaissance needs to pay off, and CISA's phishing guidance treats validated-target lists as fuel for the next, sharper campaign.

What actually caught it

No one reported this message. Detection came from the shape of the send rather than any single verdict: a first-time external sender, four personalized variants of one template landing across one organization within minutes, a brand claim contradicted by every domain in the headers, and a CTA whose visible promise did not match its destination. IRONSCALES Adaptive AI resolved all four copies as phishing automatically, and the mailboxes were remediated as one cluster rather than four separate tickets. Microsoft's own filter had already landed on SCL=5, a spam score, despite issuing that perfect composite authentication pass a few header lines earlier.

Two things are worth keeping. First, a security gateway in your delivery path is also a content-modifying intermediary, and its protective rewriting degrades the authentication evidence available to everything behind it. That argues for putting behavioral analysis downstream of the gateway rather than treating the gateway's verdict as final, the practical case for augmenting a gateway instead of stacking more of the same inspection. Second, this message never lied about its authentication. It authenticated honestly, as itself, from a domain nobody had a reason to trust. The lie lived entirely in the body, and the body is not something SPF, DKIM, or DMARC has ever claimed to evaluate.

Indicators of Compromise

MITRE ATT&CK Mapping

• T1583/001, Acquire Infrastructure: Domains. A freshly registered throwaway domain, configured to authenticate properly on its own name.
• T1566/002, Phishing: Spearphishing Link. The "Message in Teams" CTA was the only payload; no attachments, no QR codes.
• T1036/005, Masquerading: Match Legitimate Name or Location. The link's visible promise of a Teams thread against a tracking hop and a marketing-asset terminus.
• T1656, Impersonation. Microsoft Teams notification framing carried entirely by body content, with zero Microsoft infrastructure in the sending path.