Exclaimer Status

After continued monitoring, we have confirmed the issue is no longer occurring. Servers that were displaying errors have been removed and replaced within our UK region to prevent the issue from reoccurring. If you are still seeing issues with mail flow when using Exclaimer at this time, please reach out to our support team directly, who will be happy to help.

The Azure SQL database in EU2 has been fully restored by Microsoft. EU2 endpoints have been re-enabled and mailflow is balanced. All services are confirmed healthy with no further impact to customers.

Issue:  Client side signature fails to apply and the message 'Failed to acquire auth token' is displayed. Incident Length: 10 Day\(s\) and 3 hour\(s\)  Incident Date: 18/05/2026, 11:00 UTC - 28/05/2026, 14:05 UTC   Incident Status: Resolved   **Summary**   When composing a new email, the Exclaimer add-in was unable to acquire an authentication token, resulting in signatures not being inserted and an error message being displayed for customers using Outlook for iOS.   All other platforms, including Windows desktop, New Outlook, Mac, Web, and Android, were unaffected.   Server-side signatures continued to apply normally for customers with that configuration.  **Root Cause**   The Exclaimer Outlook Add-in uses a Microsoft authentication flow designed for Office add-ins, which is intended to authenticate users silently in the background without any user interaction. Around 18 May, this silent authentication flow stopped working on Outlook for iOS.   Following an investigation, Microsoft confirmed that a change on their side had caused the silent authentication failure, and that this change was subsequently rolled back.  **Mitigation**   On identifying where the authentication flow was failing, Exclaimer Engineers updated the Outlook Add-in \(v1.29.200\) to introduce a fallback path for when silent authentication cannot complete.   Rather than surfacing an error, the add-in now prompts the user to sign in interactively, allowing authentication to complete and the signature to be applied, improving authentication flow resilience.   This was deployed on 28 May and has been retained permanently as a resilience improvement.    **Incident Timeline**  18/05, ~11:00 UTC - Silent authentication begins failing on Outlook for iOS. Customers start experiencing signature failures on this platform   18/05, 12:51 – Exclaimer releases a new version of the Exclaimer Add-in \(v1.27.200\)   21/05, 19:01 - First report of errors from the Add-in reaches Exclaimer Engineering. Investigation begins.   22/05, 07:26 Engineering confirmed a review of the latest Add-in release had been completed; no active indicators of the issue are present based on the changes made.  10:14 – Active theory was composed on the cause of the issue; code changes are then prepared by Engineering to be released the following week to prevent potential issues over the weekend.     26/05, 10:01 UTC - First code change deployed to improve logging and extend authentication timeouts.    12:10 – Add-in v.1.28.0 is released to the production channel of the Add-in. Review of impacted systems indicates no improvement.   27/05, 13:25 UTC - v.1.29.0 is deployed to both channels to surface more detail from the authentication failure on iOS.    28/05, 07:44 UTC - Severity escalated given customer impact and duration.   10:42 – Issue confirmed to only impact iOS, with other errors likely being unrelated.    11:03 – Internal investigation is prioritized to identify the cause.   11:30 - Internal reproduction of the issue achieved for the first time, enabling rapid iteration on a fix.   13:02 - The point of failure in the authentication flow fully identified, Exclaimer Engineers also identify development of a Fix and begin prioritizing a full release.   13:50 – Add-in version \(v1.29.200\) is prepared for release, awaiting confirmation of the resolution within the preview channel before being released to the production channel.   14:05 - Updated add-in \(v1.29.200\) verified in preview and released out to production channel.   14:31 - Customer confirmation of resolution is received   29/05, 08:10 UTC - Microsoft confirms that a change on their side caused the authentication failure and that it has been rolled back. Exclaimer Engineers agree to keep the changes applied based on this information at this time.

Issue: Authentication tokens not received via email for users accessing Exclaimer Portal  Incident Length: 7 hour\(s\) and 17 minutes  Incident Date: 25/05/2026, UTC 03:12– 10:29 UTC  Incident Status: Resolved  **Summary**  Customers logging into the Exclaimer Portal using the Username and Password option were unable to receive authentication tokens for a period of time, preventing them from being able to access the portal.   The exception did not trigger alerting that engaged our key engineering team, resulting in an extended impact time.  **Root Cause**  A process-level exception had occurred and not been successfully restarted. This resulted in token codes being generated but not emailed to users when required.  **Mitigation**  A rollback of the key service that included this process resolved the issue and allowed for a backlog of token code messages that had been generated to be cleared and distributed, which then restored standard service.      Further improvements to internal escalation and alerting processes have been put into place to reduce the delay in acknowledging the issue and beginning resolution steps over public holidays.  **Incident Timeline**  03:12 - Exclaimer Engineers identify a possible issue with customers being unable to log in to the portal when using a Username and Password.    03:36 – Further testing confirms the issue is impacting the authentication code stage, where the email is never received. Other forms of authentication are working as expected.   03:18 – Status page is updated to ensure customers are aware of the issue and to advise alternative login methods.   07:37 – Exclaimer Engineering is alerted and begins to investigate the scope of the issue. Additional engineering resources are called in to investigate the cause.   08:51 – A rollback of the last set of changes made to the service is performed. Testing begins to see if the issue continues   09:04 – Exclaimer Engineers identify the issue is still ongoing despite the rollback work   09:26 - Engineers confirm that the token codes are being generated as expected, indicating the service runs as anticipated to ensure accounts are secure.   09:40 – Consistent replication of the issue is confirmed, expediting testing and remediation processes.   09:59 – Exclaimer Engineers complete further system rollbacks to address the issue.   10:19 – Engineering note that a group of token code messages are confirmed to have been sent as expected and are also received within the mailboxes of accounts.   10:29 – Log review indicates that all submitted codes are processed as expected and new requests for token codes are received by users as expected.

Exclaimer Customers using Exclaimer Cloud for Microsoft 365 would have encountered an error when attempting to run the connector setup wizard from the 'Manage Mail Flow' page, causing the wizard to fail to run. This issue would have no impact on customers who have not previously run the Connector Setup wizard for Microsoft 365

This incident has been resolved.

Issue: Microsoft Azure East US outage causing imprinting, mail flow and portal issues in the US region  Incident Length: 5 hour\(s\) and 23 minutes   Incident Date: 24/04/2026, UTC 12:21– 17:44UTC  Incident Status: Resolved      **Summary**   Exclaimer services within the US were impacted by an Azure service issue, causing the Kubernetes cluster to become unable to function effectively and unable to communicate the issues it was experiencing automatically, resulting in a manual failover needing to be undertaken to remove the unhealthy environment.       **Root Cause**   An issue within the Microsoft Azure Datacenter in East US caused a problem with the communication service that allows servers and services within the DC to communicate with one another. Impact progressively spread across AZ-02 and AZ-03 as Microsoft attempted to roll back the affected components, causing intermittent control plane loss across all three zones at different points throughout the day.      Full details are available on the Azure status history page: [https://azure.status.microsoft/en-us/status/history/](https://azure.status.microsoft/en-us/status/history/)        **Mitigation**   Exclaimer Engineers were able to initiate a manual failover of all traffic to our secondary servers and increased the server capacity within US2 to handle the increased load. The issue was then raised with Microsoft , which was able to confirm the issue was identified as part of the incident they were currently experiencing within the East US Azure region.   Once resolved, the changes to our secondary service were then undone, and both services returned to normal operating capacity.      **Incident Timeline**    24/04, 11:30 – Microsoft Azure East US incident begins. Customers begin experiencing failures provisioning, scaling, and updating resources in East US. Automatic Failovers do not occur.   11:59 – Exclaimer monitoring systems alert as unable to scale to desired replica counts.   12:21 – Multiple other services report issues and enter a crashloop as they are unable to scale.   12:24 – A full Engineering investigation begins. Initial logging indicates connection issues and timeouts occurring between local resources, indicating an issue within the region.   12:35 – US2 forced failover begins manually by Engineering teams   12:45 – US2 Failover is completed, and resources are scaled to accommodate increased traffic.   13:12 – Additional work is done by Engineering to try to alleviate symptoms on services within US1   13:38 – A high-level support case is opened with Microsoft as services are still unable to connect outside the cluster.   14:12 – Microsoft Engineers join Exclaimer Engineers on a call to identify and confirm the issue as related to a recently deployed update within the East US region. Microsoft confirms they have begun remediation work.   15:28 – On Microsoft’s recommendation, Exclaimer’s US1 cluster is stopped for 15 minutes. Microsoft also advises that the issue looks to likely be impacting other regions, but they are still confirming.   15:55 – Exclaimer's US2 cluster within the West US region begins to show similar connectivity issues. Microsoft advises that US1 should remain shut down at this time whilst they resolve the issue in East US.   16:10 – US2 begins to alert as unable to scale or communicate, as was seen within US1.   16:12 – In order to prevent a full failure of US2, the decision is made to pause the imprinting of email signatures, allowing mail to flow through US2 without signatures being applied.   16:28 – Additional Scaling is applied to US2, beginning to stabilize the services within this region.   16:50 – Access to Exclaimer services is confirmed to be stable.   17:44 – Signature imprinting is resumed within the US2 region, and no service instability is detected.   19:01 – Microsoft advises that US1 can be enabled. Exclaimer Engineers restore the US1 cluster and confirm all services are running as expected.   19:13 – All services are maintained through US2 until confirmation from Microsoft of the Incident resolution   25/04, ~01:00 – Azure incident confirmed as resolved by Microsoft.   Failover is reverted, and US1 is brought back into service. Manually scaled resources within US2 are removed to restore both services to expected levels.

An unexpected bad release of the Exclaimer Cloud Portal was able to be deployed to regions, preventing the Portal from being accessible to allow users to configure signatures or complete the Exclaimer onboarding. Automated rollbacks detected the error and reverted to the previous healthy version. An internal investigation was able to identify the cause of the bad release being able to be deployed to our systems, and further checks have been implemented to prevent future occurrences.

Exclaimer Engineers have been able to release a change to the Add-in at the start of this week, alongside a fix that was released by Microsoft, and the issue no longer looks to be occurring frequently within messages. If you are still seeing duplicate email signatures being applied. Please reach out to our support team, who will be happy to help.

Issue: Possible Routing issues within MEA & US region for Microsoft Customers  Incident Length: ~70 hour\(s\)  Incident Date: 4/4/2026, UTC 9:37– 8:07 7/4/2026   Incident Status: Investigating **Summary**   Mail flow for customers in the Middle East and Africa \(MEA\) region would encounter issues routing messages to Exclaimer, with Exchange servers reporting that the exclaimer smtp hosts rejected or did not respond to the request.  We are still awaiting a full Post Incident Review from Microsoft and will update this Postmortem with additional information once it is available.  **Root Cause**   The issue is believed to be a configuration issue within Exchange in the region, preventing the connection to Exclaimer servers within the UAE or US region. All impacted messages appear to have been deferred, resulting in them being delivered at a later time, further confirming the expected mail flow between Exclaimer and Exchange Online.  **Mitigation**   Some Exchange servers which were consistently noted to be failing to provide the email to Exclaimer relays when requested, were passed over to Microsoft for review. Shortly afterwards these instances stopped appearing to submit traffic to Exclaimer, suggesting they have been had been taken out of service.  Exclaimer Engineers have internally made changes to how message logs are stored between our servers, helping to improve and identify potential issues and errors within the STARTTLS process

We will be undergoing scheduled maintenance during this time.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The work required for this maintenance window is now complete.

The scheduled maintenance has been completed.

Exclaimer staffing has now returned to normal levels.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed

The scheduled maintenance has been completed.