August 15, 2025
Author: Kat Calejo

So, you fixed the Direct Send phishing risk, but now your printers won’t email scanned documents, your security cameras have stopped sending alerts, and that custom-built tool in accounting is suddenly silent.

If you read our last post, When Internal Isn’t Safe: The Quiet Threat of Direct Send Phishing, you know that attackers have been abusing the feature to send spoofed internal emails that bypass normal defenses, putting companies at serious risk. Disabling it is the right move for security, but for many businesses, it can also be a workflow killer if the shutdown isn’t done correctly.

The good news is, this isn’t the end of your internal email functionality. In this post, we’ll break down why Direct Send became such a problem, where it’s probably hiding in your environment, and how to replace it with something safer without grinding your operations to a halt.

Why Direct Send became a problem

In our last blog, we talked about how attackers have been exploiting Microsoft 365’s Direct Send feature to make phishing emails look like they came from inside your own organization. 

The result? Employees trust them more, making credential theft and data breaches far more likely. Microsoft’s recent changes to tighten control over Direct Send aren’t a glitch or an overcorrection. 

They’re a deliberate safeguard to stop these attacks before they land in your users’ inboxes. For many companies, that means it’s time to rethink how internal apps and devices send email because leaving Direct Send wide open is no longer worth the risk.

Common Places Direct Send Is Hiding in Your Environment

Direct Send has a way of quietly embedding itself into everyday workflows. It was probably set up once, years ago, and then forgotten. Multifunction printers and scanners are common culprits, relying on Direct Send to email scanned documents directly to staff. Legacy line-of-business applications may be quietly pushing reports or notifications through it. 

Your security system could be set up to deliver alerts this way, and older ERP or CRM platforms might still depend on it to share updates internally. 

Even homegrown scripts and internal tools  (the kind a developer set up ages ago and nobody’s touched since) can be sending email via Direct Send without anyone realizing it.

The tricky part is that these connections often run in the background. They’re not flagged on IT project lists, they don’t show up in obvious reports, and they may not even be documented. 

That’s exactly why turning off Direct Send without a plan can cause unexpected downtime or lost functionality. 

Before you flip the switch, it’s worth running a complete audit to pinpoint every device, app, or script that’s using it. The earlier you find them, the easier it will be to replace those workflows with something more secure, without breaking business operations in the process.

Why “Just Leaving It On” Isn’t Worth the Risk

It’s tempting to keep Direct Send running “just for now” to avoid the hassle of reconfiguring devices and applications. But the security trade-off just isn’t worth it. Leaving it on is like keeping a back door unlocked because the delivery driver uses it. Convenient, yes, but also wide open for anyone who knows it’s there. 

The recent spike in phishing campaigns exploiting Direct Send proves how dangerous that access point can be. Attackers can send emails that look like they came from inside your organization, tricking employees into clicking malicious links, entering credentials, or approving fraudulent transactions.

The most dangerous part? These spoofed emails don’t raise the same red flags as messages from an unfamiliar sender. Your team is more likely to trust them, and that’s exactly why attackers are using this method. 

The good news is you don’t have to choose between security and functionality. With the right configuration changes, you can keep every workflow intact while eliminating the risks that come with leaving Direct Send active.

How to Replace Direct Send Without Breaking Your Apps

Turning off Direct Send doesn’t have to mean breaking your scanners, alerts, or legacy apps. The key is replacing it with something more secure and better suited for modern email standards. 

For most businesses, that means moving to an authenticated SMTP relay or a cloud-based service like SMTP2GO. With SMTP2GO, you get the authentication that keeps attackers out, plus detailed logging so you can see exactly what’s being sent and from where. You also gain control over deliverability and can filter out spam or phishing attempts before they ever reach an inbox.

If your apps can’t use SMTP2GO directly, Microsoft Graph API is another option, offering secure, authenticated sending straight through Microsoft 365. 

The right solution depends on your environment, but the outcome is the same: you maintain all the functionality your systems need, without the open door that Direct Send leaves behind. 

At NTS, we help clients make this transition seamlessly by mapping every dependency, configuring replacements, and testing before we turn anything off, so there’s no downtime and no surprises.

Let’s talk about mapping your Direct Send dependencies and moving you to a safer, more reliable setup without disrupting your day-to-day.

Leave a comment

Your email address will not be published. Required fields are marked *