Frustrated that the ‘New’ Outlook forces links to open in Edge? A senior DevOps engineer explains why this happens and provides three practical fixes, from a simple toggle to a permanent registry edit that actually sticks.

Is “New” Outlook Just a Fancy Web App? A DevOps Take on Fixing the Edge Problem

Let me tell you, nothing gets my blood pressure rising faster than a P1 alert at 2 AM. A few weeks ago, I got an email notification: `CRITICAL: High CPU on prod-db-01`. I grab my laptop, click the Grafana link in the email to see the dashboard, and… it opens in Microsoft Edge. Not my default browser, Firefox, where I’m logged into everything, with all my tools and extensions ready to go. No, it opened a clean Edge profile, prompting me to log in. In the heat of an incident, those wasted 30 seconds of fumbling with logins and 2FA feel like an eternity. That’s when I decided I had to permanently fix this “New Outlook” behavior, not just for me, but for my whole team.

The “Why”: It’s Not a Bug, It’s a Platform

So, what’s going on under the hood? The chatter is true: the “New” Outlook is essentially a Progressive Web App (PWA). It’s a wrapper for Outlook on the Web (OWA) running in a WebView2 control. WebView2 is Microsoft’s component for embedding web content in native applications, and it’s powered by the same engine as Microsoft Edge. This deep integration is why, by default, Outlook hands off all link clicks directly to its sibling application, Edge, completely ignoring your system’s default browser settings. It’s an attempt to create a seamless “Microsoft ecosystem” experience, but for those of us who live in different toolchains, it’s a major workflow disruption.

How to Fix It: From a Simple Click to a Registry Edit

I’ve seen this issue trip up juniors and seasoned engineers alike. Here are three ways to reclaim control, ranging from the easy-peasy to the “make it stick” enterprise solution.

Solution 1: The Quick Fix (The In-App Setting)

This is your first line of defense. It’s simple, requires no admin rights, and works instantly. However, I’ve personally seen it revert after a major Office update, so consider it a temporary truce rather than a peace treaty.

• Open the new Outlook.
• Click the Settings cog icon in the top-right.
• Go to General > Privacy and data.
• Click on Privacy Settings.
• Scroll down and find a setting about “connected experiences” or link handling. Or, more reliably, go back to the main settings panel.
• The better path is: Settings > Mail > Message handling.
• Scroll down and you should find a “Link handling” section. Change the setting for opening links from Edge to Default Browser.
• If you can’t find it there, Microsoft’s menus change often. Try the legacy path: File > Options > Advanced > File and browser preferences. Change the “Open hyperlinks from Outlook in:” dropdown to Default Browser.

Solution 2: The Permanent Fix (The Registry Edit)

Alright, let’s get our hands dirty. For those of us who prefer a solution that sticks, we need to talk to the Windows Registry. This directly tells the Office suite how you want to handle links, bypassing the application-level setting that can sometimes be overwritten.

Warning: You’re editing the registry here. Back it up first. Don’t fat-finger a key and blame me if your machine starts demanding tribute in the form of cat pictures. Proceed with caution.

You need to create a `DWORD` value. Here’s the path and value:

Key: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Links
Value Name: DefaultBrowser
Value Type: REG_DWORD
Value Data: 1

To make this easy, you can save the following as a `.reg` file and just double-click to import it.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Links]
"DefaultBrowser"=dword:00000001

This has survived multiple Office updates on my machine and is my go-to recommendation.

Solution 3: The “Enterprise Hammer” (Group Policy or Scripting)

Sometimes you need to bring out the big guns, especially if you’re managing a fleet of developer machines where this workflow interruption is a genuine productivity killer. You can enforce the registry setting from Solution 2 via Group Policy (GPO).

In the Group Policy Management Editor, you would navigate to:

User Configuration > Preferences > Windows Settings > Registry

From there, you create a new Registry Item that applies the exact same `DWORD` value from Solution 2. This ensures that even if a user (or an update) changes the in-app setting, the GPO will slap it back into place on the next policy refresh. For non-domain machines, you can achieve the same result by deploying a PowerShell logon script that runs `Set-ItemProperty` to enforce the key. It’s the “set it and forget it” approach for a busy team.

Ultimately, while I understand the push for ecosystem integration, user choice for fundamental tools like a web browser is non-negotiable. Pick your fix, get it implemented, and get back to putting out the real fires.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions