Power Pages custom domain not working: incorrect URL mapping and SSL

You try to connect a domain such as www.example.com to your site in the Power Platform admin center, and it stops. The host name step says there's an incorrect URL mapping error. Or domain validation never lets you go on, or the certificate option you expected isn't there. Or the domain connects, and your sign-in providers still point at the old address. Microsoft documents a requirement for each step of the setup, so the fix is to check them in order.

How the setup works

Per Microsoft's documentation, you connect a domain from the site's page in the Power Platform admin center: under Resources, open Power Pages sites, select your site, select Manage, then select Connect Custom Domain in Site Details. A side panel walks you through these steps, in this order:

1. Choose an SSL certificate.
2. Enter the host name.
3. For a site with a content delivery network (CDN) or Web Application Firewall (WAF), validate the domain with a TXT record.
4. Review the host name and certificate, and create the SSL binding.

Your DNS provider needs a CNAME record before step 2, and your identity providers need the new address after step 4.

Check the site first

Two rules come before any DNS work:

• The site must be in production. Microsoft says you can add a custom domain only when the website is in production state. Every site starts as a trial. An admin converts it to production from the admin center, which needs a production or sandbox environment and the right licences. A developer site can't be converted. Our Power Pages licensing guide covers the licences.
• One custom domain per site. To swap the domain, select the pencil icon beside the custom URL in Site Details, delete the current SSL binding, then the certificate, then the host name, and run the setup again with the new domain.

Fix the CNAME record

At your DNS provider, create a CNAME record that points your host name to your site's Power Pages URL, such as contoso.powerappsportals.com. Microsoft lists three ways this goes wrong:

Before you enter the host name, check that the record resolves publicly. On Windows:

nslookup -type=CNAME www.example.com

On macOS or Linux:

dig CNAME www.example.com

If the record doesn't resolve publicly yet, Power Pages can't validate it. Wait, then check again before you go back to the panel.

CDN or WAF: add the TXT record

If your site has a content delivery network or Web Application Firewall turned on, the setup adds a Validate the domain step. Both features run on Azure Front Door, and this step proves you own the domain before Power Pages routes traffic through it.

1. In the panel, copy the Record type (TXT), Record name and Record value. Microsoft's example name is _dnsauth.www.
2. Create a TXT record with those values at your DNS provider.
3. Check it's public, with the command below.
4. Back in the panel, select Refresh. When the record is validated, Next becomes active.

nslookup -type=TXT _dnsauth.www.example.com

If Next doesn't become active, check these:

• The value expired. The record value in the panel has an expiry. If you didn't create the record in time, Power Pages generates a new token, and the old one never validates. Copy the value shown now and update your record.
• An old asuid record is in the way. There must be no TXT record named asuid.<your domain>, such as asuid.www.example.com. Delete it and try the binding again.
• DNS is still catching up. Microsoft says WAF domain validation typically completes within minutes to 48 hours.

Turning on CDN or WAF later, on a site that already has a custom domain, can also trigger this validation: Microsoft says enabling either feature for the first time triggers domain validation for custom domains.

Choose a certificate it accepts

The panel offers three options:

The managed option is missing? It isn't shown when CDN or WAF is turned on. Upload your own certificate instead. Azure Front Door also creates its own certificates for those sites, separate from the one you upload, and you stay responsible for renewing yours.

Using your own .pfx? Microsoft lists what it must have:

• It's signed by a trusted certificate authority.
• It's exported as a password-protected .pfx file, encrypted with TripleDES. AES-256 encryption isn't supported.
• Its private key is at least 2,048 bits long.
• It includes every intermediate certificate in the chain.
• It's SHA2 enabled.
• It has the Extended Key Usage for server authentication (OID 1.3.6.1.5.5.7.3.1).

Microsoft notes that the export steps vary by certificate provider, so follow your provider's instructions and check the encryption before you upload.

When the certificate expires or won't update

Per Microsoft's renewal steps, uploading the renewed certificate is only half the job: you also replace the binding that uses the old one.

1. Get the renewed certificate as a password-protected .pfx, encrypted with TripleDES.
2. In Site Details, select the pencil icon beside your custom domain.
3. In the Edit Custom Domain pane, choose New and upload the renewed .pfx.
4. Delete the existing binding that uses the old certificate.
5. Create a new binding with your host name and the new certificate.

To move between your own certificate and a Microsoft managed one, delete the SSL binding and the certificate, then run the setup again.

Update sign-in reply URLs after the domain connects

Each identity provider sends visitors back to your site at a reply URL. Microsoft says that if you use or add a custom domain name, you must set up your identity provider to use the correct reply URL.

1. In Power Pages design studio, open the site and select Security > Identity providers.
2. Next to each provider you use, select More Commands (…) > Edit configuration. Where its settings have a redirect URL, enter the custom URL. The Local sign in and Microsoft Entra providers can't be changed here; Microsoft says to use site settings for those.
3. In the provider's own app registration, such as one in Microsoft Entra ID, set the redirect URI to the same custom URL. Microsoft asks for the two values to match exactly.
4. Changes can take a few minutes to show. To see them at once, restart the site from the admin center.

Once sign-in works on the new address, our guide to web roles and table permissions covers what they can reach.

Using your own Azure Front Door

If you put your own Azure Front Door in front of the site, rather than the built-in CDN or WAF, Microsoft's order matters. Browsers reject the site's cookies when the Front Door address differs from the site's address, so:

1. Connect the custom domain to the Power Pages site first, with its CNAME pointing at the site.
2. Then change only the CNAME at your DNS provider to point at the Front Door endpoint, and add the same domain to Front Door.
3. Check with nslookup that the CNAME now returns the Front Door endpoint, and that browsing to the domain shows your site.

Sources

• Add a custom domain name — Microsoft Learn
• Power Pages lifecycle — Microsoft Learn
• Use the admin center: Site Details — Microsoft Learn
• Content Delivery Network — Microsoft Learn
• Web Application Firewall (WAF) for Power Pages — Microsoft Learn
• Set up site authentication — Microsoft Learn
• Set up an OpenID Connect provider with Microsoft Entra ID — Microsoft Learn
• Set up the Microsoft provider — Microsoft Learn
• Set up Azure Front Door with Power Pages sites — Microsoft Learn