Monitoring -
We are actively investigating reports of slow image loading when composing a new email. This is only specific to the Xink add-in in Outlook on the web. Initial analysis confirms the issue does not occur in Outlook Classic or the New Outlook preview.
Affected users may experience delayed rendering of signature images, intermittent image load errors, or instances where images fail to load entirely.
Evidence points to a performance degradation in the Microsoft API used by the add-in to retrieve signature assets in Outlook on the web.
Nov 7, 10:56 CET
Resolved -
This incident has been resolved.
Nov 4, 12:58 CET
Monitoring -
Between November 04, 2025, 07:46:33 UTC and November 04, 2025, 08:41:36 UTC, some clients with rerouting enabled experienced Non-Delivery Reports (NDRs) or were unable to send emails due to a Spamhaus (Microsoft’s default spam service provider) block affecting our US IP address.
Our US IP address (US Data Center) was temporarily blocked by Spamhaus, which is used by Microsoft as its default spam filtering service. During this period, one of our rerouting servers became overloaded with requests, resulting in email delivery delays and NDRs for affected clients.
We do not have direct control over this service, however we have been actively working with both Microsoft and Spamhaus to prevent such issues. Despite these ongoing efforts, the block was imposed again.
Our rerouting tester service triggered an alarm, allowing us to quickly identify the issue and request immediate removal from the blocklist. The IP was successfully removed from the Spamhaus blocklist at 08:41:36 UTC, and normal mail flow has since been fully restored.
We recommend that clients resend any affected emails that may not have been delivered during the disruption window.
Recommended Solution: Switch to the Xink 365 Add-in To avoid similar disruptions in the future, we strongly recommend switching to the Xink 365 Add-in, which does not rely on email routing or Spamhaus. With the add-in: ✅ No reliance on email servers – signatures are applied directly in Outlook before sending. ✅ No risk of email filtering issues – no interaction with external spam blacklists. ✅ Instant updates – signatures are applied automatically without waiting for mail flow rules.
Most of our clients have already switched and eliminated email delivery risks altogether. Our team can assist with the transition to ensure a seamless experience.
We strongly encourage you to consider the 365 Add-in for a more reliable and future-proof email signature solution.
Nov 4, 11:02 CET
Resolved -
This incident has been resolved.
Nov 3, 12:32 CET
Monitoring -
Due to SpamHouse (Microsoft's default spam service provider) blocking our US IP, between November 03, 2025 05:56:01 (UTC) and November 03, 2025 08:07:35, some of our clients with rerouting enabled received NDRs or were unable to send emails.
Date Listed: November 03, 2025 05:56:01 (UTC) Date Removed: November 03, 2025 08:07:35 (UTC)
One of our rerouting servers became overwhelmed with requests, resulting in delays for affected clients.
We encourage clients to resend the affected email.
Recommended Solution: Switch to the Xink 365 Add-in To avoid similar disruptions in the future, we strongly recommend switching to the Xink 365 Add-in, which does not rely on email routing or Spamhaus. With the add-in: ✅ No reliance on email servers – signatures are applied directly in Outlook before sending. ✅ No risk of email filtering issues – no interaction with external spam blacklists. ✅ Instant updates – signatures are applied automatically without waiting for mail flow rules.
Most of our clients have already switched and eliminated email delivery risks altogether. Our team can assist with the transition to ensure a seamless experience.
We strongly encourage you to consider the 365 Add-in for a more reliable and future-proof email signature solution.
Nov 3, 10:54 CET
This is our Preliminary PIR to share what we know so far. After our internal retrospective is completed (generally within 14 days) we will publish a Final PIR with additional details.
What happened?
Between 15:45 UTC on 29 October and 00:05 UTC on 30 October 2025, customers and Microsoft services leveraging Azure Front Door (AFD) may have experienced latencies, timeouts, and errors.
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, Azure Virtual Desktop, Container Registry, Media Services, Microsoft Copilot for Security, Microsoft Defender External Attack Surface Management, Microsoft Entra ID (Mobility Management Policy Service, Identity & Access Management, and User Management UX), Microsoft Purview, Microsoft Sentinel (Threat Intelligence), and Video Indexer.
Customer configuration changes to AFD remain temporarily blocked. We will notify customers once this block has been lifted. While error rates and latency are back to pre-incident levels, a small number of customers may still be seeing issues and we are still working to mitigate this long tail. Updates will be provided directly via Azure Service Health.
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.
Oct 30, 01:30 CET
Monitoring -
Some clients have reported that their Xink Outlook add-in is not loading, resulting in email signature not appearing when composing or sending emails. This issue has been identified as being caused by a Microsoft Azure service disruption, specifically related to “Azure Front Door - Connectivity Issues.” This is a Microsoft managed infrastructure problem, and we have no ability to address that.
We are continuously monitoring Microsoft’s incident updates and will notify clients once services stabilize.