Stop Emailing Like It’s 2013: Microsoft Is Finally Pulling the Plug on @onmicrosoft.com

If you’ve still got mailboxes or services firing off emails from something@yourtenant.onmicrosoft.com, consider this your polite nudge (well, Microsoft’s) to stop.

Because in classic Microsoft fashion, it’s not just a suggestion anymore — they’re throttling it.

Yes, seriously!

The Change

Starting October 15, 2025, Microsoft will start throttling outbound email sent from .onmicrosoft.com addresses to 100 recipients per tenant, per day. It’s a phased rollout, with full enforcement by June 2026.

After that? Every message over the limit gets bounced faster than your expense claim for a “technical lunch” at Gaucho.

🧾 Full details here on TechCommunity


Why the Sudden Crackdown?

To be fair, Microsoft’s letting you down gently. The reasons behind this move are solid:

  • Shared reputation – Your .onmicrosoft.com domain shares an IP rep with every other tenant. That includes legitimate businesses… and also dodgy spam farms.

  • Trust and branding – No one feels good getting an invoice from accounts@widgets-inc.onmicrosoft.com. It just doesn’t inspire confidence.

  • Security – Spoofing an onmicrosoft.com address is relatively easy for attackers. This change makes that harder — and forces orgs to clean up their setup.

 

 


What Actually Breaks?

Here’s the fun bit: it’s per tenant, not per user.

So if multiple users or automated services are still sending from @onmicrosoft.com, you’ll all be queuing for that same 100-email daily allowance. Go over, and Microsoft slaps you with this lovely NDR:

550 5.7.236 – Message rejected due to sending limits.

That means:

  • Support mailboxes stop replying

  • CRM notifications don’t arrive

  • Your legacy scanner in Accounts can’t send its daily scan of someone’s elbow

 


What You Should Be Doing Instead

This really shouldn’t be news. But hey, if your setup still leans on the freebie domain, here’s your to-do list:

✅ Register a Real Domain

Use something official — ideally the same domain your users sign into.
No myrealbusinesssolutions365v2.biz, please.

✅ Add It to Microsoft 365

Go to Admin Centre > Settings > Domains and follow the prompts.
Set up your DNS records — SPF, DKIM, DMARC — all the good stuff.

✅ Set As Default

Make sure new users and services get assigned your real domain automatically — not @onmicrosoft.com.

✅ Fix Existing Mailboxes

Use PowerShell to change addresses:

Set-Mailbox -Identity user@onmicrosoft.com -PrimarySmtpAddress user@yourdomain.com

Don’t forget to double-check login UPNs and app dependencies.
One careless change and suddenly half your staff can’t log into Teams.

✅ Audit Everything Sending Mail

Check for services, apps, Power Automate flows, old scanners, or hybrid mail relays still sending from the wrong domain. Microsoft’s Message Trace or Defender XDR can help.


But… Why Was I Using It Anyway?

Short answer: because it was easy.
Long answer: it was easy 10 years ago.

The .onmicrosoft.com domain was always meant to be a placeholder — for testing, tenant setup, and temporary use. Not for external mail, marketing comms, or service account spam.

Would you send corporate mail from yourbusiness@hotmail.com?
(…don’t answer that if you’re still doing it.)


Bonus Round: Do Some Security While You’re There

While you're cleaning up your domain usage, it’s a great time to:

  • ✅ Set up SPF to say who can send on your behalf

  • ✅ Enable DKIM to sign your mail

  • ✅ Configure DMARC so spoofers get blocked

  • ✅ Add a Transport Rule to stop future sends from .onmicrosoft.com just in case someone tries again

You’ll sleep better at night — promise.


Final Thought

If you haven’t sorted this already, don’t worry — there’s still time. But make no mistake, this change is coming whether you’re ready or not. And while fixing it might feel like a chore, not fixing it is worse.

Avoid outages, broken processes, and embarrassing email bounces.
Use a real domain. Email like a grown-up.

Your support desk will thank you. And so will your customers.


TL;DR

  • Microsoft is throttling .onmicrosoft.com email sends from October 2025

  • The cap is 100 recipients per tenant per day

  • Use your real domain — now

  • Audit your setup and fix anything that sends from the default tenant domain

  • Update SPF/DKIM/DMARC while you’re there


Intune Done Right: Automating App Packaging and Updates with PowerShell and WinGet

Keeping applications up to date is one of the most tedious, time-consuming tasks for any modern endpoint admin. Between version sprawl, vendor updates, and testing cycles, it’s no wonder many organisations either fall behind or burn far too much time keeping things current.

Luckily, with PowerShell, WinGet, and a few clever tools, you can automate the process — without breaking the bank or your sanity.


The Problem with Traditional App Management

Historically, there have been two common approaches to app lifecycle management:

  • Manual packaging: Admins download and repackage every update as a .intunewin file, update detection logic, and redeploy through Intune — an arduous process that often introduces inconsistency.
  • Neglect: Apps go untouched, often falling several versions behind, introducing security risks and compatibility issues.

And even if you do get the apps in, there’s still a big gap:

  • No business ownership of applications — meaning there’s often nobody responsible for testing or approving updates
  • No schedule — since updates arrive whenever the vendor feels like it
  • Change process misalignment — most organisations don’t have a change control process built for weekly app updates

Neither approach scales well, especially with remote workforces and short-staffed IT teams.

 


Enter WinGet and PowerShell

WinGet, Microsoft’s native Windows package manager, has become powerful enough to support real-world enterprise deployment. When used with PowerShell and Intune, it can:

  • Identify the latest available app versions
  • Download and install silently with version-specific control
  • Package and deploy via Intune
  • Maintain consistency across a fleet with minimal manual intervention

 


Full Walkthrough: Automating with PowerShell + WinGet + Intune

⚠️ Important Note for Enterprises
While this Winget-based approach is excellent for SMEs and dev-focused environments, I don’t recommend it as a wholesale solution for large enterprises or regulated organisations. It lacks native version control, rollback capability, and structured testing flows.
Use this as a supplement — not a replacement — for enterprise-grade patch management and change control.

 

 

1. Identify Your Application Set

Start by defining which applications you want to manage. You can do this by:

winget export -o baseline-apps.json

This provides a JSON file listing all apps installed via WinGet on a reference machine. Trim this down to only include approved apps.

 

2. Script the Installation with Silent Flags

WinGet supports silent install switches out of the box. Here's an example script to silently install 5 common LOB (line-of-business) apps:

$apps = @(
    "Microsoft.Teams",
    "Microsoft.PowerToys",
    "Notepad++.Notepad++",
    "7zip.7zip",
    "VideoLAN.VLC"
)

foreach ($app in $apps) {
    winget install --id $app --silent --accept-package-agreements --accept-source-agreements
}

Wrap this in a PowerShell script. You can either:

  • Package each app individually — allows granular control, targeted assignments, and version-specific detection logic
  • Use a single core app script — great for Autopilot or shared machines needing a standardised baseline
💡 The benefit of a core app script is that you control the install order, unlike Intune's Required apps, which install in an unpredictable sequence. This ensures critical apps install first, reducing delays for the user.

Choose based on your organisation’s needs. Enterprises may prefer one-per-app for change control, while SMEs benefit from the simplicity of a single script.

 

3. Package as a Win32 App

Use the Win32 Content Prep Tool from Microsoft:

IntuneWinAppUtil.exe -c "source-folder" -s install.ps1 -o "output-folder"

Deploy the resulting .intunewin package via the Intune admin portal.

 

4. Configure Detection Rules

Use detection logic such as:

  • Registry key path & version
  • File version
  • Existence of an installed .exe

Example for PowerToys:

Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\PowerToys" | Select-Object DisplayVersion
⚠️ Note for core install scripts: If you're installing multiple apps from a single script, you’ll likely need to write custom detection logic for one or more of the apps to ensure Intune knows the install was successful. This might include checking registry values, file versions, or installed MSI product codes for each app — and you'll need to pick a representative one for the app’s detection rule.

 


Keeping Apps Updated Automatically

 

Even if you’ve nailed your first-time install process, keeping apps updated is just as important — especially with the frequency of updates in 2025.

To solve this, I came across an excellent open-source script: Winget-AutoUpdate by Romanitho. It’s simple, effective, and gets the job done — use at your own risk, but if you're supporting SMEs or dev teams, it's honestly a lifesaver.

This script:

  • Scans for updates to installed Winget apps
  • Downloads and installs new versions silently
  • Logs to Event Viewer and text logs
  • Gives the user a great little notification to tell them what's going on

Install it using:

winget install Romanitho.Winget-AutoUpdate

💡 Particularly useful for SMEs or kiosk devices that don't require tight update controls. It saves time, avoids packaging repetition, and ensures devices stay current — even after Autopilot provisioning. For enterprises that require version control or pre-release testing, Winget-AutoUpdate may not be suitable as a standalone solution.

 

 

 


When This Approach Works Best

Ideal for:

  • SMEs and startups: Where "latest version" is typically fine and risk is low
  • Developer devices: Where agility and staying current outweigh strict change control
  • Kiosk/field devices: Where rapid, unattended updates are essential

But less suitable for:

  • Regulated environments
  • Apps with tight version dependencies
  • Situations requiring rollback/version testing

In those cases, consider tools like:

  • Patch My PC: For deep version control and compliance
  • Chocolatey for Business: Internal repos and testing workflows
  • Custom WinGet manifests with version locks

 


Bonus Tips

  • Baseline Golden Images with winget export
  • Use Proactive Remediations to check for outdated apps
  • Combine with Delivery Optimisation to reduce bandwidth by enabling peer-to-peer sharing of app content across devices on the same network. This lightens the load on WAN links and accelerates deployments, especially in branch offices. To configure this in Intune:
    1. Go to Devices > Configuration profiles > Create profile
    2. Choose Windows 10 and later > Templates > Delivery Optimization
    3. Set Download Mode to LAN (1) or LAN and Group (2)
    4. Configure peer caching, cache size, and cache age settings
  • Always include robust detection logic to prevent loops or unnecessary reinstalls. A common mistake is triggering reinstallation when the detection method fails due to minor version differences or missing registry entries.Example for MSI-installed apps. Ensure detection is specific, version-aware, and avoids overmatching.

 


Final Thoughts

App management in 2025 doesn’t need to be painful.

For SMEs and agile orgs, tools like Winget and Winget-AutoUpdate can replace traditional packaging entirely. For enterprises, they offer a complementary approach that handles the 80% of apps that don’t require slow UAT and change boards.

In short:

  • Automate where you can
  • Control where you must
  • And stop babysitting update downloads manually

The future of app deployment is scripted, scheduled, and silent.

 


 

Stay tuned for our next post: "Stop Building On-Prem Group Policy Castles in the Cloud."


Intune Autopilot – Part 2 – Moving in the right direction!

Cont.

So if you've read part one, then you're looking for a way to set up an Intune managed Autopilot device to be shared among multiple users.

The chances are that you're already using autopilot for your single-user devices. Which means that you already have an Azure AD Dynamic Group, probably using a dynamic query such as:

(device.devicePhysicalIDs -any (_ -contains "[ZTDId]"))

The problem with this approach is that it's going to lump all of our autopilot devices into one AAD Dynamic group, which is no good if we need multiple deployment profiles (User Driven + Self-Deploying profiles). So we need a way to separate these devices. Enter the OrderID field...

The OrderID field, also referred to as GroupTag will allow us to create different groups of Autopilot devices, so that we can deploy Single User laptops, Shared PCs, and Kiosk devices all with different profiles and policy sets. However, if we are using the ZTDId tag, the chances are that none of our existing computers has the order IT field populated.

 

Therefore we need to populate the OrderID value for all existing devices and change our Dynamic AD groups to match the OrderID, not all autopilot devices.

Thankfully, Nicola Suter has come to the rescue here. He has written a PowerShell script that will connect to Graph API, and allow us to change the OrderID field in bulk. https://tech.nicolonsky.ch/bulk-update-windows-autopilot/ In this example. I'm going to use a group tag of "autopilot" to signify a standard user-driven deployed device, therefore we will use Nicola's scripts to change the group tag to "Autopilot" on all existing devices.

 

In conjunction, with this, we also need to change the Dynamic group query in Azure AD from targeting ZTDid to something like this:

(device.devicePhysicalIds -any _ -eq “[OrderID]:Value”)

Where "Value" is the value, you want to put in the OrderID field.

Once we have done this, we can start building a new policy and profile set for our other devices. In part 3, we will explore a multi-user desktop and kiosk mode deployment alongside traditional user-driven deployments.


Intune Autopilot - Sharing the love - Part 1

Over the last 18 months, I've had great success deploying modern-managed devices for clients, using a mix of Azure Active Directory, Intune and Autopilot. Autopilot has always worked great in scenarios where one user = one workstation, but what about a replacement for that traditional domain-joined PC which you would deploy for shift workers or in multi-user situations where one computer = 5 users?

There are a few ways that I have found a multi-user device can be set-up, but these all have drawbacks.

 

Build a PC then AAD join it:

On the face of it, this seems like the most straightforward option. The PC can be AAD joined and added into AAD Device groups to receive policies. However, the drawback with this approach is that the machine will be listed in AAD as a device under the user that AAD joined it. This can lead to admin accounts with tens of devices listed under them and a potential requirement to lift the "per user device limit" within AAD.

It's also a royal pain in the backside to have to assign group memberships manually, and policy application appears to be a little spotty the moment you transition to a standard user.

 

SharedPC CSP

Microsoft has thought of this and created a SharedPC CSP policy. SharedPC CSP comes with several advantages such as Guest account Management, Local Storage Policies, Power Policies, Fast first sign-in and Education Policies, all of which make management and sign-in much easier. But for me, this CSP has one critical flaw - it disables the OneDrive client completely!!

If like me, you've been encouraging people to take advantage included 1TB OneDrive space per user in Office 365, then you've probably migrated users' documents to OneDrive and are using policies such as KFM (known folder move). OneDrive client is critical to a Shared PC; otherwise, users will are forced to use OneDrive online to access their documents. It also gives no easy way to roam documents between shared PCs, for example at a reception desk with two seats.

 

 

So, how do we deploy an Intune Autopilot device for multiple users with all of our usual Line of Business apps?

 

The answer is Intune Self-Deploying Mode but without SharedPC CSP!!

 

What, I hear you cry, that sounds counter-intuitive, but it works. We'll let the self-deploying mode take care of our AAD join and then layer some custom Policies on top to cover the other bits.

The self-deploying mode requires adding another Autopilot deployment profile, which means you must make some changes to your existing autopilot configuration. In Part 2, I'll go into the changes that you need to make to prepare your environment for multiple deployment profiles.


Privacy Preference Center