727-216-8010 / 805 618-1853 info@protekitsolutions.com

PREVENTING EMAIL SPOOFING/PHISHING

by | Oct 3, 2025 | Email, Office 365

PREVENTING EMAIL SPOOFING/PHISHING:

(This topic is centered around Microsoft 365 hosted emails but applies to other mail providers.)

PHISHING/SPOOFING EMAIL DEFINED:

A phishing/spoofing email is a fraudulent email that a cybercriminal has designed to fool end users and employees into thinking the email is legitimately from another employee, vendor, boss or friend. Most examples of phishing emails will be accomplished by a false email address hidden by a fake “display name”, such as “Boss’s Name” will be displayed at the top of the email before a fake email address such as “bosssname446@hotmail.com or bosssname@companydomain.ru – using a different domain extension like “.ru”, instead of .com. Or purchasing a domain name that is very similar to your company’s domain name, such as “acmeconstruction.com” could be spoofed with “acmeconstructoin.com” – you can see that its very slightly misspelled but many employees will miss that.

The above examples are just the tip of the iceberg in the realm of spoofing/phishing emails. Hackers and cybercriminals will do their “due diligence” and research into a company to find out details about employees, executive heirachy, accounting personnel and will also dig into the dark web for information about the company so that they can get a foothold into your network or email system.

In other instances they will devise a new way to get around spam filters and then send out millions of spam emails to their email lists until spam filters get around to figuring out how they are being bypassed.

WHAT BUSINESSES CAN DO TO PREVENT SPOOFING/PHISHING EMAILS:

We have seen that most small business are not properly setup to prevent spoofing emails, they might have one or two of the 8 or so processes implemented, and in some cases have none of them implemented.

Email anti-spam filters have long been lacking in the ability to detect and prevent phishing/spoofing attacks due to the emails themselves containing no actual red-flags that any software algorithm can detect (sketchy links, spam like attributes, malicious files). So while preventing spam/malware can in theory be largely accomplished through licensed advanced filters (either Microsoft or 3rd party like Barracuda, Vipre, Proofpoint, etc.), the question of how to reduce and prevent phishing and spoofing attacks is more complex and requires several layers of defense each of which I will go into below:

 

KEY POINTS SUMMARIZED:

  • Enable SPF Hard Fail
  • Enable DKIM with Quarantine or Reject DMARC Policy
  • Harden your email host server’s email security policies
  • Turn of Microsoft Direct Send
  • Stop using 3rd party filters that rely on Connectors and MX relay, and instead use your email host server’s solution or one that truly integrates and keeps up with  modern detection capabilities OR –
    • Thoroughly configure the 3rd party filter to properly bypass the checks your mail server will do, and ensure that the 3rd party filter’s settings are all enabled to properly reject dmarc/spf fails, and ensure that the mail server has it’s own settings enabled
  • Set up External Sender Banners
  • Conduct User Awareness Training
  • Consider Geo-Fencing Inbound Email

SPF (Sender Policy Framework)

INITIAL NOTES:

SPF is still needed and used but DKIM (mentioned next) is becoming the more modern go to for mail senders to authenticate with as an allowed sender for a domain. Many modern mail send solutions (like SendGrid, Mailchimp, etc) don’t even mention SPF when adding a domain to their system, since DKIM is trusted over SPF and receiving mail hosts will typically accept inbound mail where DKIM passes even if SPF fails. This is true even when hard fail is enabled. That said, there is a difference between what SPF and DKIM are doing, where DKIM is authenticating a sending source server via encrypted keys and SPF is verifying the sending source by IP or Domain.

FUNCTIONS:

  • SPF soft fail tells receiving mail hosts that if the inbound email fails the SPF check to route mail to usually spam or junk
  • SPF hard fail tells receiving mail hosts that if inbound email fails the SPF check to reject the mail completely.

CAVEAT(S):

  • What the receiving mail host actually does with the inbound email when it fails its SPF check (sending IP is not in the sending domain’s SPF record) is not a given. Every mail provider has different settings and makes its own decision.

SPF hard fail could be completely ignored(!) if some or all other checks that the receiving server is doing check out (pass).

As mentioned, for example, if DKIM passes, then this typically overrules SPF. Which makes sense since if DKIM is set up and passing, it’s your trusted source send server.

However, other criteria of the email and its sender may also be evaluated by the receiving server, for example in Microsoft’s case we saw this in action where the sending domain and server was trusted, and the email made it through all of Microsoft’s (albeit basic, unlicensed, unconfigured/lowest strength) spam/phishing/virus checks. The sender utilized a spoofing technique involving sending out from Microsoft’s servers using its Direct Send feature (more on this later).

So even though SPF hard fail was on, the email did not pass the SPF check, and DKIM was not configured, the email still arrived.

TAKEAWAY:

SPF Hard fail is not doing all it may appear to be and is not enough to stop spoofing attacks, but can and should still be used in conjunction with DKIM and other prevention methods.

DKIM & DMARC

INITIAL NOTES: Now the standard for email authentication, it’s simple public/private key authentication. DKIM is a must as it ensures that your trusted send servers are in fact the ones sending from your domain, and makes it much harder for spoofers to spoof you.

DKIM without a DMARC policy or a DMARC policy that is set to none is like installing an antivirus but then not activating it – it’s doing zilch.

DMARC is the pairing record that tells the receiving server (your recipient) what to do with the message.

FUNCTIONS:

  • DKIM private key is configured on the source server (your trusted sender)
  • DKIM Public Key is added to your Domain’s records which is checked by receiving servers to verify that it passes checks against your private key signature.
  • DMARC is a record which tells receiving servers what they should do if the DKIM check does not pass.

CAVEATS:

  • DKIM does not verify the legitimacy of the sender it simply proves that the message was signed by someone in control of the private key for the sending domain. For example, Microsoft’s Direct Send feature could be leveraged by a bad actor to send out from a trusted smtp server therefore passing DKIM but failing SPF checks.
  • Just like SPF hard fail, once again the DMARC policy which tells the receiving server what to do if checks fail is only a suggestion. Microsoft for example has a (turned off by default) setting which says whether to follow the DMARC policy or not – and even then it has a stipulation for “if the message is detected as a spoof, AND the DMARC policy is X, THEN…”

Who knows what other mail providers’ defaults and available options are.

TAKEAWAY:

DKIM with DMARC policy set to quarantine or reject should be paired with SPF hard fail. Combined they serve two different functions and go far toward protecting your domain from being spoofed but sadly, where loopholes still exist, such as with Microsoft’s blatant hole (Direct Send), or with weakly configured receiving mail servers, it is still not perfect

SIDE NOTE: SPOOFING TO OR FROM OTHER DOMAINS, NOT INTERNAL

This has all been so far discussed as far as attackers spoofing YOUR domain and sending to YOU (“Hi, this is your boss, please wire money to XXX-XXX”) and how to prevent/lower that risk, as well as detecting and lowering the risk of receiving inbound mail seemingly from people you know (trusted vendors or clients and friends being spoofed and emailing you).

Keep in mind that while you can fortify your own mail server for inbound handling by adjusting how it responds to SPF fails and DKIM fails (covered more later), there’s nothing you can do about the senders themselves not protecting their own domains from spoofing – meaning, if they don’t have DKIM or SPF set up correctly, their spoofed emails could still slip through your defenses.

As well and as already covered, a bad actor could yet take your domain and attempt to spoof it to someone other than you – for example if they get a hold of a client list and want to send spoofed emails from your domain to them requesting money, it is up to the client’s ( in this example) receiving mail servers to be correctly configured to detect and reject or quarantine such emails. If the receiving mail server on the client side has no mail filter and doesn’t care that the SPF and DKIM checks did not pass, this is how your domain could yet be spoofed despite anything else covered in this article.

MICROSOFT’s DIRECT SEND FEATURE

INITIAL NOTES: A long-standing vulnerability that we noticed in 2023 and which others already knew about:

The Call Is Coming From Inside the House: Microsoft Direct Send and Why You Need to Mitigate Now – Wolf & Company, P.C. (wolfandco.com)

Spoofing Microsoft 365 Like It’s 1995 – Black Hills Information Security (blackhillsinfosec.com)

And also something which Microsoft only now (2025) realized they needed to fix due to an onslaught of internal spoofing attacks.

No matter how many filters or advanced email defender licenses, spf or dkim or dmarc settings you enable these can all still be easily bypassed for spoofing and phishing activity  if you’re using Microsoft 365 and still have the Direct Send function turned on.

FUNCTIONS:

Open power shell right now and run this command, replacing the bolded parts with your domain and recipient (if you are using Microsoft 365):

Send-MailMessage -SMTPServer yourdomain-com.mail.protection.outlook.com -To luffy@yourdomain.com -From literallyanyone@yourdomainORanydomainthatmicrosofttrusts(!!).com -Subject “Please Reset Your Password” -Body “This is a test, Direct Send in 365 exploit….testing a simple spoof with direct send… Give me your passwords right now”

And the email will come through if Direct Send is enabled and your device’s network firewall isn’t otherwise blocking port 25 for some reason.

WHAT TO DO:

Turn off Direct Send ASAP.

This feature only became available in August 2025 , previously there was no way to fix Microsoft’s little loophole.

Here is a whole bunch of info from Microsoft: Introducing more control over Direct Send in Exchange Online | Microsoft Community Hub

Here is what to do and what to consider:

CONSIDER FIRST:

  1. If you are using a 3rd party mail filter or other service such as Barracuda, Proofpoint, Vipre, etc. chances are they are passing on email to your MX record in 365 rather than directly authenticating or integrating, and turning on the direct send Reject policy could break this. You need to create a Connector in 365 that whitelists that service’s IPs and rejects everything else. See more on this in the next section.
  2. Same goes if you really want to keep sending out from a printer or scanner in the office using Microsoft (go get a free SMTP service!!)

STEPS TO CREATE A CONNECTOR:

Follow Microsoft’s article:

STEPS TO TURN OFF DIRECT SEND:

Run Powershell

Commands:

Connect-ExchangeOnline (enter credentials)

Set-OrganizationConfig -RejectDirectSend $true

That’s it.

NOTE:

The change should propagate out to our entire service within 30 minutes. With the feature enabled, any received Direct Send messages from YOUR DOMAIN or using YOUR MX POINT will see the following message:

550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources

Unless Direct Send is re-enabled again, any messages that hit this error will need a partner connector created to authenticate their source as an approved sender.

NOTE ON MICROSOFT’s DIRECT SEND VULNERABILITY:

They thought they fixed it but they haven’t fully. Turning off direct send will stop the spoofing of your domain as Microsoft will reject these (tested and verified), however:

Even if you have turned of direct send for YOUR tenant – the rest of the world will likely take years to catch on to this need, or decide to ignore it out of ignorance.

In the meantime, Direct Send can be used not only to send from anyone else’s  MX point to your tenant, from any other domain that Microsoft trusts.

MEANING: Even with direct send off on your tenant, bad actors can still leverage tenants that haven’t yet and bypass your 3rd party filters by sending emails from trusted 365 domains directly to you.

3rd PARTY EMAIL FILTERS,  CONNECTORS IN 365 AND HOW THESE ALL PLAY TOGETHER

When you utilize a 3rd party email filter, let’s take Fusemail (by VIPRE) as an example, you are pointing your MX records to the filter first. The filter then does all the checks that it can, and pass the email along to Microsoft. When it passes the mail to Microsoft, it is important to understand a few things (read in order, each builds on the next):

  • The sender IP that shows up in Microsoft’s side is Fusemail’s, not the actual sender.
  • The original sender is highly unlikely to have Fusemail set up in their SPF record
  • Therefore, from Microsoft’s perspective, the SPF check will fail.
  • If the sender has DKIM set up for their domain for the host they are sending from, the DKIM signature will survive.
  • Microsoft does not immediately reject all emails just because SPF fails (as already covered earlier, even if hard fail is turned on in the senders SPF record)
  • Not everyone is up to date with DKIM – a lot of senders won’t have this.
  • So, when SPF fails (since Fusemail’s IP is looked at, and is not in the sender’s SPF) AND if DKIM is not setup or set up incorrectly, now we have two red flags for Microsoft to consider..
  • Microsoft will not immediately reject inbound emails just because SPF and DKIM both fail (again, previously covered).
  • Microsoft will also look at things like sender reputation, , sender trust, email content/attributes, etc.
  • What Microsoft does with the email is influenced by the email security policies you have set within Microsoft itself.
  • So, Microsoft could decide to route such an email to quarantine, junk, or reject it if it sees any other reason besides SPF failing that makes it weary – or if it’s just in a bad mood and doesn’t like that SPF failed on a hard fail.
  • That said, it is safe to say that with a 3rd party email filter in play which results in SPF ALWAYS FAILING (!!), coupled with Microsoft’s own checks/policies/filter, this could result in more (possibly valid) emails getting routed to spam or junk on Microsoft’s side.

Three points to consider when asking yourself if that is the solution:

  1. Is my 3rd party filter really that good, doing all the checks that it should be, keeping up with advancing technologies and detection abilities?
  1. Microsoft emails sent from one Microsoft tenant to another will never go through your inbound connector or third-party filters. So if you want to turn off all the Microsoft built-in policies to avoid having multiple quarantines to check, just know that bad actors can use Microsoft too. So can spam / marketing agencies.
  1. REMEMBER: Even if you have turned of direct send for YOUR tenant – the rest of the world will likely take years to catch on to this need, or decide to ignore it out of ignorance. And Direct Send can be used not only to send from your MX point to your tenant, but from anyone else’s MX point to your tenant, from any other domain that Microsoft trusts.

MEANING: Even with direct send off on your tenant, bad actors can still leverage tenants that haven’t yet and bypass your 3rd party filters by sending emails from trusted 365 domains directly to you.

Considering leaving all of the 365 filters on and STRENGTHENING THEM:

  1. How do we feel about having users need to look out for quarantine reports from both Microsoft AND a 3rd party solution?
  2. How do we feel as IT admins about managing two separate solutions?
  3. Microsoft’s free built in security measures don’t offer much to write home about- even on the strongest settings – is the free version even enough to catch emails sent from its own servers as phishing/spoofing attempts, or do we need to now also think about paying for their Advanced Defender plans which have better impersonation protection..?
  4. And then, how do we feel about paying for TWO different spam services?
  5. And are we certain that this double layer won’t conflict anywhere?
  6. What about the fact that all emails inbound from the spam filter will fail SPF, what will increasing Microsoft’s email security do with that when it does its checks?

Consider licensing Microsoft’s Defender Plan 1 or 2.

Also to consider, there are some (untested) solutions out there like Avanan (by Check Point) or Cortex Advanced Email Security (by Palo Alto Networks) which leverage authentication via API so that you are directly integrated with Microsoft forgoing the need for connectors and MX record hops/redirects.

OR ELSE – customize an inbound connector that whitelists the 3rd party’s IPs, and use 3 tools in 365 to ensure that the emails that are ONLY coming from these IPs are not double filtered so to speak:

  1. Inbound connector with Vipre Enhanced Filtering for Connectors –

Create the inbound connector for partner org, allow listing by the filter’s IPS then enable Enhanced filtering also known as “skip listing,” which is a feature in Exchange Online that helps maintain accurate sender information and message integrity when using third-party spam filtering services like Vipre Email Security. It’s particularly useful in complex routing scenarios, like hybrid environments or when your MX record doesn’t point directly to Microsoft 365. This feature allows you to configure Office 365 to look beyond the last hop (e.g., Vipre’s IP) and identify the original sending IP address of an email, improving the accuracy of security features like anti-spoofing and anti-phishing.

  1. Connection filter in Anti-Spam Policy

Allow list all the 3rd party filter’s IPs

  1. Anti-Phishing Policy spoofed Sender Allow-List

Allow list all the 3rd party filter’s IPs with wild card *

  1. Mail-flow rule to bypass spam filtering

Bypass spam filtering for all the 3rd party filter’s IPs

  1. Strengthen all other Microsoft policies which will apply to internal; or tenant-to-tenant only. (does not solve direct send loophole or tenant-to-tenant phishing without enhanced licensing. Still considerations regarding the double solution issue and needing more licenses.)

OTHER LINES OF DEFENSE:

 

EXTERNAL SENDER BANNERS

Remember that even with all the previous protections, spoofing a domain can still be done in the most basic sense, where the attacker is not truly sending from your domain but instead masking their domain on the email to make it look like it came   from your domain. These types of emails may still get through all lines of defense  since the sender may have all its ducks in a row and pass all checks and their email  may not seem harmful to the various filters.

To help with this you can set up an automatic message to prepend the body of any email that originates from outside your tenant (from a different domain), such as “WARNING – THIS SENDER IS EXTERNAL”

This can help draw attention to the fact that even though an email seems to come from your boss, something about it phishy.

(Microsoft’s how-to is not covered here.)

GEO-FENCING INBOUND EMAIL

Not always workable for everyone since some companies will need to be able to receive emails internationally. But something to look into case by case as an optional strengthening measure. If you know you don’t work with anyone from Russia, why not go block a whole country from trying to phish or spoof you.

Microsoft Article: https://learn.microsoft.com/en-us/defender-office-365/anti-spam-policies-configure?source=recommendations&view=o365-worldwide#use-the-microsoft-365-defender-portal-to-create-anti-spam-policies

USER AWARENESS TRAINING

Put last only because it’s not the main topic of this article, but user awareness training really is the first line of defense. Unaware end users clicking on phishing emails or falling for requests for money or information is the root problem. If everyone knew what to look for and what to send straight to trash, we wouldn’t need all the extra layers of protection as much.

So whether using a paid service like KnowBe4 or conducting manual training, it goes without saying this is a must.