The email was five words long: "Has this invoice been paid?"
No attachment.
No invoice number.
No payment amount.
Just a question from andy@linkedinreceivables-mail[.]com sitting in an accounts payable inbox, waiting for someone to reply.
SPF passed. DKIM passed. DMARC passed. Every authentication check that a Secure Email Gateway (SEG) relies on gave this message a green light. And that's exactly what the attacker was counting on.
The message arrived on a Sunday morning, sent from a domain registered just 17 days earlier. The sender, "Andy Murray," addressed it to accountspayable@ at a mid-size development firm. The display name was unremarkable. The subject line was routine. The body was a single sentence.
This is Business Email Compromise (BEC) at its most disciplined. No urgency. No threats. No attachments to scan. Just a conversational opener designed to start a thread that could eventually redirect a real payment to an attacker-controlled account. According to the FBI's IC3 2024 Internet Crime Report, BEC remains the costliest cybercrime category, with adjusted losses exceeding $2.9 billion annually.
The genius of the approach is restraint. A one-line email triggers almost no content-based detection. There's nothing to flag: no malicious URLs, no suspicious attachments, no impersonation of a known executive. The attacker's bet is that an AP clerk will reply, and once they do, the conversation moves toward payment instructions.
Here's where it gets interesting. The attacker didn't spoof LinkedIn. They registered their own domain, linkedinreceivables-mail[.]com, on February 12, 2026, through NameSilo with WHOIS privacy protection. Then they did something that most people assume only legitimate senders do: they configured proper email authentication.
The domain's SPF record authorized the sending IP (83[.]166[.]78[.]5, a UK-based relay at smtp007-fr4.self-mail-messaging[.]com). DKIM was properly signed with a valid key. DMARC was published and aligned. The result? Microsoft's Exchange Online Protection (EOP) saw a fully authenticated message from a domain that, on paper, checked every box.
This is the fundamental gap in email authentication that security teams need to internalize. SPF, DKIM, and DMARC answer one question: "Was this email sent from infrastructure authorized by the sending domain?" They do not answer: "Is the sending domain trustworthy?" An attacker who registers their own domain and configures authentication correctly will pass every check, every time.
The attacker didn't stop at email authentication. The entire campaign infrastructure ran on subdomains of the lookalike domain:
| Type | Indicator | Context |
|---|---|---|
| Domain | linkedinreceivables-mail[.]com |
Lookalike domain (registered 2026-02-12) |
| Subdomain | tracking.ib59382.linkedinreceivables-mail[.]com |
Click/open tracking infrastructure |
| Subdomain | ib59382.linkedinreceivables-mail[.]com |
SPF envelope domain |
andy@linkedinreceivables-mail[.]com |
Sender address | |
| IP | 83[.]166[.]78[.]5 |
Sending relay (UK) |
The tracking subdomain is particularly telling. The unsubscribe and engagement tracking URLs all pointed back to attacker-controlled infrastructure on the same domain. This isn't a commodity phishing kit. It's an end-to-end campaign infrastructure, purpose-built for brand impersonation at scale.
See Your Risk: Calculate how many threats your SEG is missing
Microsoft's EOP assigned the message an SCL (Spam Confidence Level) of 5, which routes it to junk. That's better than nothing. But the detection wasn't based on authentication failure (everything passed) or content analysis (a five-word email has almost no analyzable content). It was Microsoft's anti-spam heuristics flagging the newly registered domain and the message structure.
The problem? Many organizations configure their mail flow to trust authenticated messages, especially when SPF, DKIM, and DMARC all pass. In those environments, this message would have landed in the inbox.
IRONSCALES Adaptive AI flagged the message through a combination of signals that authentication alone can't provide: the sender was flagged for a newly registered return path domain, community-based reputation signals matched previously reported phishing activity, and behavioral analysis identified suspicious inconsistencies in sender patterns. Within the IRONSCALES community of over 35,000 security professionals, this exact domain pattern had already been reported, turning one organization's detection into protection for thousands.
This attack follows a well-documented BEC pattern that Verizon's 2024 DBIR identifies as increasingly common: low-content initial outreach followed by relationship building. The attacker's calculus is straightforward:
The five-word email is step one. It costs the attacker nothing, reveals nothing about the scam, and creates a conversational anchor that makes subsequent requests feel like a continuation rather than a cold contact.
Treat authentication as necessary but insufficient. SPF, DKIM, and DMARC stop domain spoofing. They do nothing against attacker-owned lookalike domains. Layer behavioral detection on top of authentication.
Monitor for newly registered domains. This domain was 17 days old when it was used. Domain age is one of the strongest signals for brand impersonation campaigns. Solutions that incorporate community-driven threat intelligence can flag these domains before they reach your users.
Train AP teams on conversational BEC. The most dangerous BEC emails aren't the ones with urgent wire transfer requests. They're the five-word questions that start a thread. AP staff should verify invoice inquiries through existing vendor contacts, never through reply-to addresses in unsolicited emails.
Don't trust "pass" as a verdict. When your security team sees SPF/DKIM/DMARC all passing, that means the sending domain authorized the message. It does not mean the sender is who they claim to be. That distinction is the difference between detecting this attack and losing money to it.
Try It Free: Start your free trial of IRONSCALES