As phishing through legitimate services grows, employee training faces new pressure

As phishing through legitimate services grows, employee training faces new pressure

In June 2026, staff at several hotels began receiving Calendly notifications about guest complaints and room problems. Because the messages came from Calendly’s real systems, they passed the authentication checks email providers use (SPF, DKIM, and DMARC) to confirm a sender is who it claims to be. Google redirects then led recipients to malicious downloads. 

Some experts have called this phishing technique “authentication laundering.” The filters worked as designed. The only check left was the employee reading it, and the request looked like the rest of their shift.

The pattern isn’t isolated. Phishing attacks are only increasing, and malicious actors are increasingly sending phishing through platforms employees already trust. One analysis of lures that slipped past email filters found that the proportion of phishing emails sent through Salesforce’s own mailing service tripled over six months.

Essentially, attackers are exploiting two kinds of trust. Trusted delivery slips a message past the filters. Trusted context convinces the reader to act. Employee training has to address both, because a genuine sender is no longer proof of a safe message, and even a request that looks like routine work warrants a second look.

How trusted services carry phishing

Attackers don’t need to spoof a sender when they can use the real one. Automated security checks can confirm where an email came from, but they can’t reliably establish that its contents are safe.

Docusign has seen the same problem on its own platform. In an August 2026 alert, the company warned that attackers were using registered accounts to send real electronic-signature envelopes. Recipients were directed to download software to view documents that were initially blurred. 

The malicious instruction sat inside a genuine service workflow, so the envelope itself told the recipient nothing about whether the request was safe.

That leaves the recipient as the last check. The usual advice to check the sender and inspect the domain stops helping when the sender and domain are real.

The lure that fits the workday

An electronic signature notice, shared file, or calendar invitation is a normal part of many employees’ day. Some attacks abuse real accounts or notification features. Others imitate the service. From the email alone, the two can be hard to tell apart, especially when an employee already expects a document. For the employee, the distinction matters little. The safe move is the same either way: verify the request, not the envelope.

Payroll staff receive more requests around payday. An accounts payable clerk reviewing vendor invoices has little reason to question a message that appears to belong in the same batch. The hotel lures worked the same way. Front-desk staff handle guest complaints and room issues every day.

Researchers at the National Institute of Standards and Technology call this “premise alignment.” As NIST’s Phish Scale points out, a message is harder to recognize as phishing when it closely matches the recipient’s work context. A hotel employee usually takes a booking concern seriously. A payroll specialist already works within an established payment calendar. Neither has to be careless to find an expected request convincing.

Some attackers build that context over time. An attacker posing as a supplier might start with a routine question, exchange several emails, and only later ask for updated bank details. By then, the name is familiar. If the conversation moves to chat or even a phone call, the employee may treat it as part of the same exchange.

One employee may not even be the final target. Consider a multi-step scheme in which a fraudulent vendor update is approved by a department contact and forwarded to accounts payable. The second employee sees that the request was already handled internally. Because the first employee was misled, the approval makes the request look legitimate to their coworker.

Training should follow the workflow and context

In many organizations, phishing training amounts to completing a course and passing a short test. That may satisfy a compliance requirement. But the exercise often ends before employees practice the harder decision: what to do with a request that sits close to their real work.

That is where phishing training for employees should evolve. A conversation might begin in the inbox and continue over a messaging app or a phone call. An employee trained to inspect links in email may still accept instructions delivered in a follow-up chat. Exercises can follow the whole exchange across channels, rather than a single suspicious message.

Most programs can’t capture that, because they measure the wrong things. Management often sees how many people finished the training and how many clicked in a simulation. Both have their uses. But a click rate means little on its own. NIST’s Phish Scale rates how hard a simulated phish is to spot, and a test that mirrors someone’s real work is far harder than one that doesn’t.

What counts as a successful response

A report filed before colleagues click can matter more than a clean click rate. IT can check who else received the message, remove copies where possible, and send a warning. Reporting catches a problem while other employees can still avoid it.

Employees do not have to prove a message is malicious before flagging it. A request that seems slightly off is enough. Some reports will turn out to be legitimate, and that’s fine. The reports also show IT where employees struggle to assess risk.

Culture decides whether any of this works. Employees should feel safe speaking up. Someone who clicked a link or approved a request might stay quiet if they expect blame. They should be able to report the mistake quickly and get help. Mocking or punishing people for false alarms sends the wrong message. Training needs to make the reporting route clear.

Over time, exercises can test what employees actually do. Do they use a known contact to verify a payment change? Do they report a questionable request? Do their warnings reach colleagues in time? Those results say more about readiness than a completion figure.

In the hotel campaign, the messages carried no technical warning signs. They came from Calendly’s real systems and passed standard authentication checks. That left recipients with one practical defense: noticing that a request seemed unusual and reporting it. Building that habit is the job of training, and it takes practice with requests that look like real work, not a once-a-year course.