Same WeSendit Notice, Opposite Verdicts a Year Apart

This organization had already seen this exact email. Same platform, same template, same noreply sender, same subject line: "Files are waiting for you." In October 2025 it was a real transfer from an existing equipment supplier, and the tenant released it. In October 2026 it was a phish, and a human analyst resolved it as malicious.

Nothing a mail filter can measure changed between the two. The verdict flipped on one question: is the person named inside the notice real, and did they say they were sending this?

The control case the tenant already had

The target was a senior regional trading executive at the trading division of a multinational building-materials group. The tenant's history with the platform's sender domain held exactly two incidents. Both came from noreply@wesendit[.]com. Both carried the subject "Files are waiting for you."

The first, in October 2025, went into review and came out as a False Positive. The release request gave the reason "Known sender," and the comment explained that the supplier had separately emailed to say he had sent a link via WeSendit. Out-of-band confirmation from a known person. That was the deciding evidence.

The second arrived on 21 October 2026 at 14:53 UTC. A second copy followed about five minutes later. This time the H1 of the notice read "You have received files from" an address at southeastexhlbit[.]com, a lookalike of a real US trade-show exhibits company. The domain had been registered at 08:17 UTC that same morning.

Put the two side by side and the only column that differs is the uploader.

Everything a scanner scores is a constant

Here is what the receiving Microsoft hop recorded for the malicious copy: spf=pass for ses.wesendit[.]com, dkim=pass for both wesendit[.]com and amazonses[.]com, dmarc=pass, compauth=pass reason=100. SCL 1. No forwarding, no ARC chain, no signature appliance in the path. The platform domain publishes a p=reject DMARC policy.

All genuine. WeSendit really sent it, through its own Amazon SES pipeline in eu-central-1.

Every link pointed at wesendit[.]com or its help-center subdomains, wrapped in SES click tracking. The download link scanned clean. There was no attachment. The 92 KB PDF lived on the platform behind the download link.

The legitimate 2025 transfer would have produced the same authentication results, the same sender reputation, the same link reputation and the same template. On a transfer platform those values are fixed by the platform, not by whoever uploads. The 2026 Verizon Data Breach Investigations Report puts the human element in 62% of breaches. This is what that looks like at the inbox: the only signal left is a human one.

What the uploader controls

The attacker wrote very little. Inside the platform template, the fields the uploader fills in carried the entire deception:

• an uploader address on the same-day lookalike domain
• a "Subject line" reading "[exhibits firm] Document Handler"
• one file named "[exhibits firm] scanner #498r678364.pdf"

The platform's own text even contained a grammar slip ("The link is and available until 6 days"), which a reader would blame on the vendor, not the sender.

The lookalike itself swaps an "i" for an "l" in "exhibit" and drops the plural. The real company has held its domain since 2010. That character swap is a supporting fact here, not the story.

The managed security analyst who reviewed the incident classified it as a Microsoft credential-harvesting lure. The transfer was not retrieved for this analysis, so the landing page is not described here.

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

MITRE mapping

The automated verdict listed the right cautions and still said SAFE

The automated triage pass labelled the message SAFE. Its reasoning: authentication passed, the platform is legitimate, the links are clean. It also noted the misspelled sender domain shown in the body and the awkward grammar, and then did not weigh them against the platform's reputation.

That is the trap in miniature. On this platform, reputation is identical for good and bad transfers, so it cannot outvote anything. The cautions it listed were the only variables in the message. Agentic analysts earn their keep when they are allowed to treat a constant as a constant.

The recipient reported the message. The managed security analyst reviewed it and resolved it as malicious, and both copies in the original mailbox were quarantined.

Then the verdict kept working. The same notice reached a second mailbox at an affiliated brand on later days. Each copy was quarantined on arrival, because a human had already decided. One report from one inbox protected the rest of the group, which is the point of crowdsourced human intelligence.

Indicators

Do not block wesendit[.]com or the SES range. You will block real suppliers along with the attacker.

Make the uploader the thing you verify

The fix is procedural, and it is the same one the tenant used correctly a year earlier.

1. Treat the platform as a constant. A pass on SPF, DKIM and DMARC for a transfer service tells you the service sent it. Policy that scores it as trusted is scoring the wrong field.
2. Check the uploader's domain against the real one. Compare it to the domain you already correspond with, and look up its registration date.
3. Require out-of-band confirmation. The 2025 release was right because the supplier said, separately, that he had sent a link. No confirmation, no click. CISA phishing guidance makes the same point about verifying through a known channel.
4. Make reporting fast and visible. A single report here protected an affiliated brand's mailbox for two more days.

The financial stakes are not abstract. The FBI IC3 2024 report tracks phishing among the most reported cybercrime complaints every year, and the Microsoft Digital Defense Report 2024 is a useful baseline for how identity attacks begin in the inbox. NIST defines phishing as an attempt to acquire sensitive data by masquerading as a trustworthy entity. Here, the trustworthy entity was real. Only the person inside it was not.