The Email Dependency Test: Map One Service, Find Twenty Problems

Start With the Obvious

Ask anyone in your organization to draw the architecture for email and you'll get roughly the same picture: a user opens Outlook on their laptop, it connects to Exchange or Microsoft 365, messages flow. Three boxes, two arrows. Done.

This is the diagram that ends up in the business continuity plan. It's the diagram that gets presented at the annual review. And it's dangerously wrong — not because it's inaccurate, but because it's incomplete in ways that only matter during an outage.

Here's the exercise: take email — one service that every organization has — and actually map every system it depends on to function. Not "what vendor provides the mailbox." Everything. The authentication layer. The network path. The certificates. The directory services. The DNS resolution. Every component that has to be working for a user to open Outlook and send a message.

What starts as three components becomes fifteen. Then twenty. And somewhere in that map, you'll find at least one single point of failure that nobody in your organization knew about.

Layer by Layer: What Email Actually Depends On

Let's walk through it the way a practitioner would, starting at the user's laptop and working down through every system that has to be functioning.

Layer 1: The Client

The user opens Outlook on their laptop. Already, you have dependencies: the laptop itself (hardware, OS, local disk), the Outlook application (version, configuration, cached credentials), and the user's profile (locally cached or pulled from a domain controller at login). If your organization uses virtual desktops (VDI), add the hypervisor layer, the session broker, and the storage backend.

Layer 2: The Network Path

The laptop needs to reach the mail server. If the user is in the office, that means the local network, switches, and the corporate firewall. If they're remote — and post-2020, most are — that means a VPN connection. The VPN depends on the VPN concentrator, the VPN authentication service (which may be separate from the email authentication), and the user's home internet connection. Every one of these is a dependency. Every one has its own failure mode.

Layer 3: DNS

Before Outlook can connect to anything, it performs a DNS lookup to find the mail server's address. If your internal DNS is down, Outlook can't resolve the server name. If your external DNS is down, inbound mail can't find your MX records. DNS is one of those invisible dependencies that makes everything work and nobody thinks about until it doesn't. Microsoft's own October 2025 DNS outage took down Azure and Microsoft 365 simultaneously — not because the mail servers failed, but because nobody could find them.

Layer 4: Authentication

This is where the dependency chain gets deep. The user needs to authenticate to access their mailbox. In a typical enterprise, that means:

• Active Directory — the source of truth for the user's identity and group memberships
• Microsoft Entra ID (Azure AD) — cloud identity for Microsoft 365 services
• AD Connect / directory synchronization — keeping on-prem and cloud identities in sync
• Single sign-on (SSO) — often through AD FS or a third-party identity provider like Okta
• Multi-factor authentication (MFA) — a phone call, an authenticator app push, or a hardware token, each with its own dependency chain

If any of these fail, the user cannot access email. In October 2024, an MFA outage in Microsoft Entra blocked access to Teams, Exchange Online, and the admin center simultaneously. The mail servers were fine. Authentication was the single chokepoint in the recovery chain.

Layer 5: Certificates and TLS

Every connection in this chain is encrypted with TLS. That means SSL certificates — for the mail server, for the SSO federation service, for the VPN endpoint. Certificates expire. When they do, connections fail silently or throw errors that look like network problems. Microsoft requires TLS 1.2 for all Exchange Online connections. An expired or misconfigured certificate breaks the entire mail flow without a single server going down.

Layer 6: The Mail Platform

Now — finally — we reach the actual email service. Exchange Online or on-premises Exchange servers, with their own dependencies: the database, storage, transport pipeline, anti-spam filtering, data loss prevention rules, and the compliance/archiving layer. In March 2025, a code issue in Microsoft's message transport infrastructure caused a week-long outage where emails returned "554 5.6.0 Corrupt message content" errors. The servers were running. The transport pipeline was broken.

Layer 7: External Dependencies

Email doesn't exist in isolation. It connects to everything: calendar services, Teams integration, file sharing via OneDrive/SharePoint links in messages, third-party email security gateways (Mimecast, Proofpoint), and SMTP relay for application-generated emails. If your email security gateway goes down, inbound mail may stop entirely even though Exchange is healthy.

The Actual Count

Let's tally what we found:

Twenty components. Your BCP document says "email — Microsoft 365 — 1 hour RTO." The diagram has three boxes. The reality is twenty interdependent systems, each with its own team, its own RTO, and its own failure modes.

The Problems This Surfaces

Mapping the email dependency chain doesn't just reveal components. It reveals organizational problems that were invisible before.

Conflicting RTOs across business units. HR accepts one-day email downtime. The trading desk needs one hour. Legal needs it "as fast as possible, depending on what's in flight." All three share the same authentication infrastructure. Whose RTO determines the investment in authentication resilience? This is a budget negotiation disguised as a technical decision, and most organizations avoid it entirely by never drawing the map in the first place.

Single points of failure nobody planned for. Active Directory often serves as the identity provider for email, VPN, file shares, business applications, and building access. If AD goes down, it's not just email — it's everything. But in most BCP documents, AD appears as a dependency of each service individually, never as the shared dependency that creates correlated failure across all of them simultaneously.

RTOs that don't add up. Your email RTO is one hour. But authentication has a four-hour RTO. VPN has a six-hour RTO. DNS... nobody set an RTO for DNS because nobody thought of it as a service. The real recovery time is the longest sequential path through the dependency chain, not the number next to "email" in your BCP document.

Ownership gaps. Who owns the email dependency map? The messaging team owns Exchange. The identity team owns AD and Entra. The network team owns the VPN and firewall. The security team owns the email gateway. Nobody owns the end-to-end chain, which means nobody is accountable when the chain breaks.

Try This With Your Team: The 30-Minute Exercise

You can run this exercise in a single meeting. Here's how.

Step 1 (5 minutes): Pick one critical business service. Email works perfectly because everyone understands it. But you could also use payment processing, customer login, or order fulfillment — whatever your organization cares most about.

Step 2 (15 minutes): Start at the user and work backward. Ask: "What does the user interact with?" Then: "What does that system depend on to function?" Then: "What does that depend on?" Keep going until you hit infrastructure that has no further dependencies (power, internet connectivity, cloud provider availability). Write every component on a whiteboard or shared doc. Don't filter. Don't say "that's too low-level." If it has to be working for the service to function, it goes on the list.

Step 3 (5 minutes): For each component, write down three things: who owns it, what's its RTO (if one exists), and is there a known backup or failover. Most of the cells will be blank. That's the point.

Step 4 (5 minutes): Look at the map and find two things. First, find the single points of failure — components that appear in multiple dependency chains with no redundancy. Second, find the RTO conflicts — places where the downstream service needs faster recovery than the upstream dependency can deliver.

What you'll discover in 30 minutes is what most organizations never discover until an outage forces the conversation: the BCP document says one thing, the infrastructure says another, and the gap between them is where incidents turn into crises.

What Happens After the Exercise

The exercise itself is the easy part. The hard part — and the valuable part — is what you do with what you find.

You'll have a list of single points of failure that need redundancy or at minimum a documented workaround. You'll have RTO conflicts that need resolution, which means budget conversations between teams that don't normally talk to each other. And you'll have documentation gaps that reveal how far the BCP has drifted from reality.

If you ran this exercise for email and found twenty dependencies, imagine running it for your payment pipeline. Or your customer authentication flow. Or your data platform. Each one will surface its own set of hidden dependencies, ownership gaps, and RTO fiction.

The organizations that do this regularly — not once, not annually, but as a continuous practice embedded in how they maintain their continuity plans — are the ones that recover from outages in hours instead of days. Not because their infrastructure is better, but because they know what their infrastructure actually looks like.

Everyone else finds out during the incident.