Skip to main content

Bitdefender post incident report - GravityZone Security for Email delivery interruption on 19 Sep 2025

Audience: All customers using Bitdefender GravityZone Security for Email (powered by our technology partner Censornet, recently renamed TrustLayer)

Status: Service restored; mitigations in progress.

Summary

  • Some Bitdefender GravityZone Security for Email customers experienced a service outage. This was due to a third-party outage by our email security technology partner Censornet (recently renamed TrustLayer). Because customer domains’ MX records point to the provider, inbound mail to those domains could not be delivered during the technology partner’s downtime.

  • Impact: Some customers saw blocked or delayed incoming email; most messages were queued by senders and delivered once service was restored.

  • Root cause: Third-party technology partner service outage caused by their recent corporate transition from Censornet to TrustLayer; no breach or attack within Bitdefender infrastructure.

  • Limited workaround options: Fast, safe redirection of mail at Internet scale is complex (DNS MX changes per domain, global propagation delays, MTASTS/TLS/DANE constraints, and the risk of bypassing security controls).

  • What’s changing:

    1. We are building a Bitdefender managed MX Router so we can fail over traffic to backup stacks without requiring customer MX edits during a future technology partner issue.

    2. We encourage all Bitdefender email customers to migrate at no cost to our new, Bitdefender native GravityZone Extended Email Security, built on our July 2025 acquisition of Mesh Security and designed for multilayer resilience.

In-depth analysis

Immediate cause: The MX endpoints went offline due to an automated administrative hold on our technology partner’s public cloud infrastructure. This hold was triggered by unvalidated account information during the corporate transition from Censornet to Trustlayer, and was not caused by a technical system failure. Because customer domains publish these MX records, sending servers on the Internet could not complete SMTP delivery to those domains during the downtime.

A controlled approach was taken instead of a mass MX record change

  1. Security integrity:

    • Bypass of configured controls. Many organizations rely on the secure email gateway for antispam/phishing, malware scanning, impersonation protection, and DMARC enforcement workflows. Directing traffic straight to destination mail servers would circumvent those controls during the incident window.

    • MTASTS/DANE/TLS constraints. If a domain enforces MTASTS or DANE, a sudden switch to an unplanned MX host or certificate set can cause hard delivery failures rather than a quick fix.

    • Allowlists and reputation. Senders often apply IP reputation and allowlists tuned to the existing MX. Flipping to a new ingress without pre-warming reputation can increase false positives/blocks.

  2. Customer experience:

    • Half migration outcomes. In a large fleet, some domains would update early while others lag behind (due to change windows or governance), yielding fragmented delivery and inconsistent support impact.

    • Defer vs. bounce. Most modern MTAs will queue mail and retry for up to 72 hours when the receiving MX is unavailable; instructing risky cut-overs during a transient outage can create more permanent failures than simply allowing retries to succeed after recovery.

Given these trade-offs, our call was to stabilize and restore via the technology partner and accelerate the permanent architectural fix described below.

Messages delivery

Because the MX servers were offline, messages couldn’t have been lost as they were not accepted.

  • In the common case: Nearly all messages were deferred and retried by sending MTAs, then delivered once the partner restored service. This mechanism has been built in the email protocol since the beginning.

  • Edge cases: A minority of senders (e.g., those with strict retry policies or misconfigured senders MTAs) may have generated bounces. The senders received those and will have to send the message again.

Corrective actions and prevention

  1. Migrate at no cost to Bitdefender’s GravityZone Extended Email Security

    Following our July 2025 acquisition of Mesh Security, Bitdefender provides a modern, multilayer email protection stack that combines secure email gateway (perimeter) and mailbox level (API) detection, improving resilience and visibility while reducing third-party dependency. We invite all legacy customers to migrate at no cost.

    Benefit relevant to this incident:

    • Dual layer architecture (SEG + API) increases detection depth and provides operational options if one layer is impaired.

  2. Build and deploy a Bitdefender MX Router (solution under analysis)

    We will be introducing a Bitdefender controlled MX indirection layer so customers will publish Bitdefender MX hostnames. Behind those, we can dynamically route inbound SMTP to healthy filtering stacks (primary, secondary, or a store and forward queue) without asking customers to change DNS during an incident or give up security.

Customer actions (recommended)

  1. Reach out to support via phone or email or chat to schedule a no cost migration to GravityZone Extended Email Security with our team (priority scheduling for impacted tenants).

  2. If you manage your own DNS, document current MX TTLs and ensure your team can update records for future Bitdefender MX Router adoption (we’ll provide exact hostnames and TTL guidance in a KB once the solution is thoroughly tested).

Commitment

We deeply regret any disruption this may have caused. We own the availability experience, and we are changing our architecture and operational posture accordingly. Thank you for your partnership and for holding us to a high standard.

Sincerely, 

The Bitdefender Team