The Teams Invite That Came From the Wrong Domain: Display-Name Impersonation With All-Legitimate Links

An employee at a regional banking institution received a Microsoft Teams notification: "You have been added to a team in Microsoft Teams." The display name matched an internal contact exactly. Every link in the message pointed to teams[.]microsoft[.]com, go[.]microsoft[.]com, or aka[.]ms. SafeLinks rewrites decoded to the same legitimate Microsoft domains. The sender address, however, belonged to usafederal[.]us, an external domain with no prior relationship to the recipient organization.

Technical Breakdown

The email replicated a standard Microsoft Teams invitation. The "Open Microsoft Teams" button, footer layout, and notification structure all matched legitimate Teams emails. Some branding assets were hosted on wixstatic[.]com rather than Microsoft CDN, a minor anomaly but not one most recipients would notice.

At the initial authentication hop, SPF and DKIM both passed for usafederal[.]onmicrosoft[.]com. The sending tenant was a real Microsoft 365 environment. The message then transited through a Votiro Content Disarm and Reconstruction (CDR) relay at votiro-relay2[.]prod[.]votiro[.]com (44[.]206[.]222[.]91). Votiro modified the message body during sanitization, which broke DKIM body-hash alignment. The relay IP was not in the sender domain SPF record, so SPF also failed at the downstream hop.

The result: the final authentication record showed SPF fail and DKIM fail, but the original cryptographic validation was clean. Organizations running CDR in their mail flow see this pattern routinely with legitimate messages, which trains security teams and automated systems to discount authentication failures from known relay infrastructure.

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

Why This Attack Is Invisible to Authentication and Content Scanning

There is nothing malicious in this message by any conventional definition. No credential harvesting forms. No urgency language. No suspicious attachments. Every URL resolves to a Microsoft-owned domain. A secure email gateway scanning links and attachments would find zero indicators to act on.

SPF, DKIM, and DMARC validate the sending domain, not the display name. An attacker can set any display name they choose while sending from a fully authenticated external tenant. The recipient sees a familiar name and a familiar notification format. The domain mismatch is buried in headers that most email clients hide by default.

The attack surface here is not technical. It is relational. The goal is to establish the sender as a trusted internal contact so the recipient engages with a follow-up message or simply normalizes the external sender in their inbox. This is reconnaissance for a future social engineering attempt, delivered through a notification the recipient was trained to trust.

What Behavioral Detection Sees That Authentication Cannot

The signals that discriminate this message from a legitimate Teams notification are behavioral. The sender address belongs to an external domain with zero prior communication history. The display name matches an internal contact exactly, consistent with targeted impersonation. The sending domain operates in a different industry and geography than the recipient. These are the signals that behavioral detection models evaluate, invisible to authentication-layer defenses.

Across the IRONSCALES community-driven threat intelligence network, display-name impersonation using legitimate platform notifications represents a growing pattern. The absence of any malicious payload makes these messages particularly difficult for traditional tools. Detection depends on understanding who is writing to whom, not what the message contains.

Indicators of Compromise