Fixing Outlook's wrong MAPI address (SCP vs Autodiscover)

I was recently migrating our Exchange Server when user reports started coming in that Outlook was throwing certificate errors. Here’s a quick write-up on how to fix Outlook using the wrong MAPI address.

The problem

You've added your new Exchange Server to the domain. But now, Outlook clients – especially the domain-joined ones – are connecting to the wrong address, like:

https://exchange-server.domain.local/autodiscover/autodiscover.xml

(You can see the current MAPI address in Outlook by holding Ctrl + right-clicking the Outlook icon in the system tray and selecting Connection Status.)

Instead of using your public Autodiscover URL, Outlook is going rogue and pulling in the server adress directly, which doesn’t match your SSL certificate — leading to those classic certificate trust pop-ups.

The cause: SCP (Service Connection Point)

Outlook is clever... maybe too clever. When it’s running on a domain-joined computer, it doesn’t just go out to the internet to find your Autodiscover service. First, it checks Active Directory for something called the SCP – Service Connection Point. When you install Exchange, this SCP gets set automatically and usually points to the internal FQDN of the Exchange server. In a fresh setup, that’s probably something like exchange-server.domain.local, which is fine, if you don't use a reverse-proxy or some other external domain, but if you do, your public SSL certificate will likely not match, which results in the certificate error.

The solution

Verify Your Autodiscover URL

Let’s start by making sure the Autodiscover URL is actually set correctly on the server. Run this in the Exchange Management Shell:

Get-ClientAccessService | Format-Table Name, AutoDiscoverServiceInternalUri

If that points to a proper FQDN (e.g. https://mail.domain.com/autodiscover/autodiscover.xml) – great! That’s what you want Outlook to use.

Now that we know the Autodiscover URL is good, we just need to stop Outlook from using the SCP entry. You’ve got two ways to do this.

Solution 1: Disable SCP Lookup on Clients

This is a client-side fix. You tell Outlook to ignore the SCP and use the normal Autodiscover flow instead. Run this PowerShell command (per user):

Set-ItemProperty -Path "HKCU:\Software\Microsoft\Office\16.0\Outlook\AutoDiscover" -Name "ExcludeScpLookup" -Value 1 -Type DWord

Change 16.0 to match your Outlook version – e.g., 15.0 for 2013, 14.0 for 2010, etc.

If you're managing a bunch of users, you can deploy this via Group Policy Preferences or a login script to set the same registry key for all users.

Solution 2: Remove the SCP Entry from Active Directory

This one’s a bit more direct – and probably the quickest fix most admins go for when they just need Outlook to behave now.

Open ADSIEdit (adsiedit.msc)
Connect to the Configuration partition
Navigate through the following path CN=Servers,CN=Exchange Administrative Group,CN=Administrative Groups,CN=<Exchange Org,CN>=Microsoft Exchange,CN=Services,CN=Configuration,DC=<Domain,DC>=<com>
1. Tip: In ADSIEdit, it’s usually easier to work backwards. Start by expanding CN=Configuration, then work your way into Services , Microsoft Exchange, and so on
Find the Exchange server that’s causing trouble
Expand Protocols > Autodiscover
Inside, you should see a CN=<Servername> object with the class serviceConnectionPoint
Right-click it and select Delete

That SCP is gone. Outlook won’t find it anymore and will fall back to using your proper Autodiscover URL. If you have multiple Exchange servers, you might need / want to repeat this for each server that’s causing issues.

Conclusion

Both methods work – it's really a matter of whether you want to fix it at the client level or the directory level. If you have a lot of users, the active directory fix is probably the better option. But if you’re just dealing with a few users, the client-side fix is quick and easy. Both methods will stop Outlook from using the SCP entry and instead use the Autodiscover URL you’ve set up.

Once you’ve done either fix, restart Outlook and check that it connects to the correct FQDN. No more certificate pop-ups! Hope this helped you out!