In this blog post Azure App Service Email Validation Ends in 2027 What to Do Now we will explain what Microsoft is changing, which certificates are affected, and how to prevent a failed renewal from taking an important website or application offline.
The issue is easy to overlook. Your certificates may be renewing successfully today, so nobody expects a problem. However, if the renewal process still depends on someone clicking an email verification link, that workflow will stop being available during March 2027.
What App Service Certificates actually do
Azure App Service is Microsoft’s cloud platform for hosting websites, customer portals, APIs and business applications without managing the underlying servers. An App Service Certificate protects the connection between the application and its users.
This protection is provided through Transport Layer Security, or TLS. Often still called an SSL certificate, it encrypts information travelling between a user’s browser and the application, while also confirming that the user has reached the correct website.
CPI Consulting helps organisations design, build and secure Azure AI solutions, from Azure OpenAI and Microsoft Foundry to agents, governance and production deployment.
Visit CPI ConsultingWhen an organisation purchases an App Service Certificate through Azure, Microsoft helps manage its lifecycle. This includes arranging certificate issuance, storing it securely in Azure Key Vault, supporting renewal and making it available to connected App Service applications.
Before a certificate can be issued, the certificate provider must confirm that the applicant controls the domain. This process is called domain control validation.
What changes in March 2027
One current validation option is mail verification. A message is sent to an approved address associated with the domain, and someone clicks a link to confirm ownership.
Microsoft has announced that mail verification for App Service Certificates will stop during March 2027. Organisations will instead need to use another supported method, such as a DNS TXT record, App Service verification or domain verification.
A DNS TXT record is a small piece of information published in your domain’s settings. It allows the certificate provider to confirm domain control without depending on a person receiving and responding to an email.
The retirement does not mean every existing certificate will suddenly fail in March. The danger appears when a new certificate, renewal or rekey operation requires domain validation and the selected email method is no longer available.
Why this is a business continuity issue
An expired certificate can cause browsers to display security warnings or block access altogether. Customers may assume the website has been compromised, while staff may be unable to use an internal portal, integration or line-of-business application.
The visible outage may be only part of the cost. IT teams can spend hours locating domain credentials, finding the correct DNS provider, obtaining approvals and making emergency changes under pressure.
Certificate lifecycles are also becoming shorter across the industry. That means weak manual processes will need attention more frequently, increasing the chance that a missed approval or unclear ownership creates an outage.
This is similar to other Microsoft retirement projects. As we discussed in our guide to replacing SMS and voice MFA in Microsoft Entra, the best time to remove a legacy dependency is before it becomes an emergency.
How to tell whether your organisation is affected
Start by identifying paid App Service Certificate resources in every Azure subscription. Do not assume the certificate list inside one web application gives you the complete picture.
For each certificate, record:
- The domain and any included subdomains.
- The Azure subscription and resource group.
- The applications and services using it.
- The expiry date and automatic renewal status.
- The current domain validation method.
- Who controls the domain’s DNS settings.
- Whether the certificate is exported for use outside App Service.
Pay particular attention to older environments, acquired businesses and applications built by external developers. These are common places to find certificates linked to forgotten mailboxes, former employees or DNS accounts that nobody in the current IT team can access.
Also distinguish paid App Service Certificates from free App Service Managed Certificates and certificates imported from another provider. They may appear together in Azure, but their issuance, renewal and validation processes are different.
What to do before March 2027
1. Create a complete certificate inventory
Ask your Azure team or provider for an export of certificate resources across all subscriptions. The inventory should include production, development, disaster recovery and dormant subscriptions that still contain live services.
Connect each certificate to a business owner as well as a technical owner. If an application supports customer orders, payroll or field operations, the person responsible for that function should understand the impact of a certificate failure.
2. Confirm access to your DNS provider
DNS is the service that directs people to your domain and its applications. It may be managed in Azure DNS, through your domain registrar, by a marketing agency or by a separate IT provider.
Confirm that at least two authorised people can access it securely. Use named accounts with multi-factor authentication rather than a password stored in an old spreadsheet or shared mailbox.
3. Select a supported validation method
For many organisations, manual validation through a DNS TXT record is the clearest replacement because it proves control at the domain level. Azure provides the required name and value during certificate configuration.
An illustrative record may look like this, but your team must copy the exact details displayed in Azure:
Record type: TXT
Host or name: @
Value: [Azure-generated verification token]
TTL: 3600Do not overwrite existing TXT records. Domains often use them for Microsoft 365, email protection and other services, so the new record must be added carefully.
App Service verification may be appropriate when the domain is already mapped to the relevant Azure application. Domain verification may also be available in supported configurations. The right choice depends on how the domain, application and certificate are currently managed.
4. Test the process before a production renewal
Do not wait for the most important customer-facing certificate to expire. Test the replacement process on a lower-risk certificate or during a planned rekey operation, with an agreed rollback plan.
Confirm that validation completes, the certificate reaches an issued state, it is stored correctly in Key Vault, and the connected application receives the updated certificate. Automatic renewal should also be checked rather than assumed.
5. Add monitoring and clear ownership
Set alerts well before certificate expiry and route them to a monitored team, not one individual. Your process should cover pending issuance, failed validation, failed renewal and certificates approaching expiry.
This same governance should be applied to other scheduled platform changes. Our article on the Microsoft Sentinel SAP connector retirement explains why named ownership and early testing are essential when Microsoft removes an older workflow.
A common scenario
Picture a 200-person company with a customer portal, a supplier API and several internal web applications. Its Azure certificates renew automatically, so certificate management has not appeared on an IT meeting agenda for years.
A review finds that one certificate still uses mail verification linked to a shared administrative address. Messages to that address are filtered, nobody owns the process, and the external developer who configured the application no longer works with the company.
If the organisation waits until renewal, the certificate could remain stuck in a pending state while staff search for domain access. Moving validation to DNS now turns an emergency change into a controlled task that can be tested and documented.
A practical timeline for Australian organisations
With March 2027 approaching, we recommend the following schedule:
- During October and November 2026 inventory App Service Certificates, confirm validation methods and identify business owners.
- By December 2026 restore access to DNS platforms, remove dependencies on former staff and choose replacement methods.
- During January 2027 test validation, renewal, Key Vault storage and application bindings.
- By February 2027 complete production changes and confirm monitoring across every subscription.
This change is not itself an Essential 8 requirement, referring to the Australian government’s cybersecurity framework. However, clear asset ownership, controlled administrative access and reliable patching and renewal processes all contribute to stronger security and easier compliance reviews.
Do not treat certificates as a set-and-forget service
The March 2027 retirement is manageable, but only if your organisation knows where its certificates are and who controls the associated domains. The immediate outcome is avoiding an application outage. The longer-term benefit is a certificate process that remains reliable as validation rules and certificate lifetimes continue to change.
CloudProInc is a Melbourne-based Microsoft Partner with more than 20 years of enterprise IT experience across Azure, Microsoft 365, Defender, Intune and cloud security. If you are unsure which App Service Certificates rely on email validation, we are happy to review your Azure environment and provide a practical action list with no strings attached.