We have been alerted by our clients to potential issues with Outlook Web Access and New Outlook following a recent update by Microsoft.
This issue manifests as a long delay with insertion of images when using the client-side add-in to insert a signature containing images.
Support staff at Symprex have reproduced the issue and contacted the responsible product group over this issue.
This issue is under high priority investigation by Microsoft, early analysis indicates the impact extends beyond add-ins to include OWA and New Outlook clients. Initial findings suggest OAuth latency as a potential root cause
We have been alerted by our clients to potential issues with Outlook Web Access and New Outlook following a recent update by Microsoft.
This issue manifests as a long delay with insertion of images when using the client-side add-in to insert a signature containing images.
Support staff at Symprex have reproduced the issue and contacted the responsible product group over this issue.
This issue is under high priority investigation by Microsoft, early analysis indicates the impact extends beyond add-ins to include OWA and New Outlook clients. Initial findings suggest OAuth latency as a potential root cause
We are currently seeing reports from some users of a failure to load the Signature 365 add-in.
This appears to be a result of issues with Azure / Microsoft 365 services, and is not related to the Signature 365 platform.
Server-side mailflow is unaffected by this external issue, and default cached signatures are correctly inserted by the add-in.
Whilst Microsoft resolve this issue, signatures may not be available from the add-in.
Microsoft have released the following details of this issue:
Starting at approximately 16:00 UTC, we began experiencing DNS issues resulting in availability degradation of some services. Customers may experience issues accessing the Azure Portal. We have taken action that is expected to address the portal access issues here shortly. We are actively investigating the underlying issue and additional mitigation actions. More information will be provided within 60 minutes or sooner.
Details can be found on the Azure status page below:
An update has been given from Microsoft as below:
Starting at approximately 16:00 UTC, we began experiencing Azure Front Door issues resulting in a loss of availability of some services. In addition. customers may experience issues accessing the Azure Portal. Customers can attempt to use programmatic methods (PowerShell, CLI, etc.) to access/utilize resources if they are unable to access the portal directly. We have failed the portal away from Azure Front Door (AFD) to attempt to mitigate the portal access issues and are continuing to assess the situation.
We are actively assessing failover options of internal services from our AFD infrastructure. Our investigation into the contributing factors and additional recovery workstreams continues
The current update from Microsoft as of 17:51 UTC:
We are taking several concurrent actions: Firstly where we are blocking all changes to the AFD services, this includes customer configuration changes as well. At the same time, we are rolling back our AFD configuration to our last known good state. As we rollback we want to ensure that the problematic configuration doesn't re-initiate upon recovery.
Customers may have experienced problems accessing the Azure management portal. We have failed the portal away from AFD to mitigate the portal access issues. Customers should be able to access the Azure management portal directly, while all portal extensions are working correctly there may be a small number of endpoints that might have a problem loading (i.e. Marketplace).
We do not have an ETA for when the rollback will be completed, but we will update this communication within 30 minutes or when we have an update.
We are receiving reports of some customer clients recovering from the MS outage, however others are still affected by this outage.
Microsoft have updated the latest information as of 21:12 UTC as follows:
Affected Azure services include, but are not limited to: App Service, Azure Active Directory B2C, Azure Communication Services, Azure Databricks, Azure Healthcare APIs, Azure Maps, Azure Portal, Azure SQL Database, Container Registry, Media Services, Microsoft Defender External Attack Surface Management, Microsoft Entra ID, Microsoft Purview, Microsoft Sentinel, Video Indexer, and Virtual Desktop.
Current status: We initiated the deployment of our ‘last known good’ configuration, which has now successfully completed. We are currently recovering nodes and re-routing traffic through healthy nodes.
As recovery progresses, some requests may still land on unhealthy nodes, resulting in intermittent failures or reduced availability until more nodes are fully restored. This recovery effort involves reloading configurations and rebalancing traffic across a large volume of nodes to restore full operational scale. The process is gradual by design, ensuring stability and preventing overload as dependent services recover. We expect continued improvement across affected regions. This means we expect recovery to happen by 23:20 UTC on 29 October 2025
Customer configuration changes remain temporarily blocked to prevent new deployments that could interfere with recovery. We will notify customers once this block has been lifted. Customers can failover to origins if they decide to.
Microsoft confirmed the issue was resolved at 00:05 UTC 30/10/25. We have received no additonal reports of issues since this point.
Microsoft's RCA is detailed below:
What went wrong and why?
An inadvertent tenant configuration change within Azure Front Door (AFD) triggered a widespread service disruption affecting both Microsoft services and customer applications dependent on AFD for global content delivery. The change introduced an invalid or inconsistent configuration state that caused a significant number of AFD nodes to fail to load properly, leading to increased latencies, timeouts, and connection errors for downstream services.
As unhealthy nodes dropped out of the global pool, traffic distribution across healthy nodes became imbalanced, amplifying the impact and causing intermittent availability even for regions that were partially healthy. We immediately blocked all further configuration changes to prevent additional propagation of the faulty state and began deploying a ‘last known good’ configuration across the global fleet. Recovery required reloading configurations across a large number of nodes and rebalancing traffic gradually to avoid overload conditions as nodes returned to service. This deliberate, phased recovery was necessary to stabilize the system while restoring scale and ensuring no recurrence of the issue.
The trigger was traced to a faulty tenant configuration deployment process. Our protection mechanisms, to validate and block any erroneous deployments, failed due to a software defect which allowed the deployment to bypass safety validations. Safeguards have since been reviewed and additional validation and rollback controls have been immediately implemented to prevent similar issues in the future.
