If you’ve been on the Internet this week, you probably noticed a bunch of spammers sending emails from random onmicrosoft.com email addresses, and most annoyingly, these SPAM messages are getting through basically every SPAM filter out there. The reason for this is that the email domains are all “legit” domains that have been set up as free trials in Office 365. This means the emails will go out until they hit the limit of emails they can send out. And because the domains have valid SPF settings, the emails won’t get flagged as SPAM.
So, how do we block these domains in Office 365? By blocking everything coming from an onmicrosoft.com domain name. This may feed a little heavy-handed, and it might be, but basically, no legitimate company uses the onmicrosoft.com domain name when sending emails.
Blocking
First, let’s block these emails, and then we’ll look at why these emails are making it through.
To block the emails, first log into admin.microsoft.com (if you have Just In Time Access setup, you’ll need to use the Privileged Identity Manager to give yourself Global Admin or Exchange Admin rights). After you are logged into the admin.microsoft.com website, click on the “Show all” menu option on the left.
Then click on the “Exchange” option shown under the Admin Centers menu. This will bring up the Exchange Admin center in another browser tab.
On the Exchange admin tool (at admin.exchange.microsoft.com), open the “Mail Flow” menu option and select Rules from the menu. This will give you a set of rules you created on the Office 365 server. Because these rules are executed on the server, that means these rules are handed before the mail gets to your clients.
Click on the “Add a rule” option above the rules, and select the “Restrict message by sender or recipient” menu option. This will let us create the rule to block emails based on the domain name we enter.
After you select the rule type, give the rule a name. After you give the rule a name, change the “Apply this rule if” menu to “The sender” and change the second drop-down to “address includes any of these words”. This will open a blade to the right. On this blade, put “onmicrosoft.com” and click “add” then “save”.
Under the do the following, you can select either “block the message” or “Notify the sender with a Policy Tip” (or one of the other options if you prefer). Personally, I have the “Block the message” option selected. This will let people who are sending legitimate messages from an onmicrosoft.com domain know that their message didn’t get through, as they will be sent a bounceback.
As I selected the “lock the message” option, I then had to enter a policy tip that basically says that DCAC doesn’t access emails from the onmicrosoft.com domain and to resend the email through another domain name.
Once done, this page should look similar to the example shown here.
After this part of the rule is completed, click next, which will bring you to a page allowing you to enforce the rule, test the rule, select the severity, dates, and times for which the rule should be active, etc. You can change settings here or click next, depending on your familiarity with Office 365.
After you save the rule, it will be disabled (at least it was for me). Click on the rule, and you can flip the active flag on.
Why do I get these emails?
There may be questions about why these emails are getting through. So, let’s examine one of these messages. (I have plenty to use as an example). The email message itself is simply a graphic. So the anti-SPAM filters can’t read the email’s text. And the subject line isn’t SPAMmy sounding enough to trigger an alert.
The email I’m looking at as an example is from the hgvhjgvfhjghvf8.onmicrosoft.com domain.
If I look at this domain, I can see that the correct SPF record was set (as per the default for Office 365). The spammers haven’t bothered to set up DMARC or DKIM (as of this post), but the SPF record will be enough in most cases to let the email through.
Since the email is a graphic only, and the SPF record is correct, it will come through by default unless you have some anti-spam software (or hardware) that can detect that there’s only a graphic or two (some of the ones that I’m getting have several graphics in them), a wholesale blocking of the onmicrosoft.com domain is going to be your easiest route.
Personally, at this point, I’d recommend just creating the rule (if you are using Office 365) and being done with it.
If you want to move to Office 365, contact our sales team for assistance with your licensing purchase and with consulting services to help you move.
Denny
8 Responses
My IT group uses agiliantinc.onmicrosoft.com
Your IT group will never be able to email me.
There are two potential issues with this approach:
1) Third-party IT admins – e.g. Managed IT Service Providers – may have their admin accounts set up in the tenant under tenantname.onmicrosoft.com instead of the tenant’s email domain.
2) Exchange Online Postmaster NDRs are usually sent from an *.onmicrosoft.com address.
The first issue is easily fixed, the second isn’t. I don’t know if it’s a deal breaker if you start rejecting NDRs… it may be in some cases.
UPDATE: This issue can be fixed by changing the default external Postmaster address per this MS KB / mail flow best practices: https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/configure-external-postmaster-address
No, Exchange Online Postmaster NDRs are usually NOT sent from an *.onmicrosoft.com address. They’re sent from the actual domain of the recipient in 365 (e.g., WidgetCompany.com)
UPDATE: The second issue can also be fixed by changing default external Postmaster address per MS best practices.
Yes, I’m getting spam emails from this domain name everyday. I’m supposed to some how set this up to disable this BS ?
Why don’t you sue these people Microsoft ?
Is it you people ?
What luck. I don’t use outlook.
It’s prevalent. How many times will this happen? It’s everyday. Maybe you’re not holding your mouth right….
Another issue is that Microsoft Bookings seems to use an address in the tenant’s onmicrosoft.com domain for reminders sent to external users, and it’s not easy to change. My solution was to add a third exception to my Exchange Rule that allows those Bookings emails through. So my rule includes three exceptions:
* Sender contains “postmaster”
* Sender domain is my own tenant’s onmicrosoft.com domain (because it’s used for various legit system-generated messages)
* Email attributes identifies it as coming from the sending domain’s Bookings feature (the header “Content-ID: ” exists)