Email delivery problems belong in your risk register

At Kopexa, we use Google Workspace and are currently experiencing email delivery problems. They affect a service we rely on in our daily work. That puts this case firmly within risk management for me.

For many businesses, email is how they reach their customers. Quotes, questions and meeting arrangements depend on it. When a message bounces or arrives late, someone needs to be able to respond. Even with a paid mailbox from a large provider, we need our own process for that.

Other senders' spam can affect your delivery

Google describes the connection explicitly. A message can leave through a sending IP address that was previously blocked because someone else used it to send spam. Your own message can then bounce. Recipient domains decide which blocklist services they use. Google on blocked sending IP addresses

This creates a dependency on other senders' behaviour. Your organisation controls its sending practices, accounts and domain. The provider manages a shared IP range. The recipient's mail service may make the blocking decision.

Microsoft documents the same underlying risk. One customer's spam can damage the service's reputation and affect delivery for other customers. The provider separates suspicious outbound traffic into its own IP pool, monitors blocklists and restricts accounts that send suspicious volumes of mail. We need to account for those safeguards in our assessment. Delivery still depends on several parties. Microsoft on outbound spam protection

The documented mechanism explains a possible disruption scenario. To establish the cause of a particular rejected message, we need the sending logs and the receiving system's response.

A message needs a traceable delivery path

During an incident, I would first preserve an affected message's timestamp, recipient, Message-ID and complete error response. The administrator then checks how far it travelled and who rejected it. Google provides Email Log Search for this work. In Exchange Online, Message Trace reports stages such as acceptance, rejection, deferral and delivery. These details also help when raising a support case with the provider. Google Email Log Search · Microsoft Message Trace

The investigation should cover our own sender authentication through SPF, DKIM and DMARC, along with unusual activity in our outbound mail. We can then give the provider a more specific request. Which sending route was affected? What does the rejection say? What action can the provider take?

Meanwhile, someone on the business side needs to identify open conversations that require a response. A technical investigation can take time. An urgent customer quote needs an owner and a contact the team can reach during that investigation.

Assess the work that depends on email

The impact depends on the business process. A delayed general announcement and a missing approval for a production date have different consequences. I would agree with the business owner how long a response can wait and how a disruption will be detected. A business impact analysis helps assess that dependency through the consequences of interruption.

A fictional entry for a small sales team could look like this.

The assessment needs your own deadlines and consequences. Assigning a generic risk score would skip that work. Use your existing risk register. If you need one, the risk register and Excel template can help you get started.

People must be able to use the fallback

For urgent work, a telephone contact agreed in advance may be enough. An approved customer portal might provide a way to exchange documents. Owners and recipients need to know when to use that route and how to verify the other person's identity.

Check its dependencies too. A portal that sends a login code over the same disrupted email connection may also fail when needed. The test should therefore include actual access and a response from the intended recipient.

If you are considering another sending service, assess the effort and the new dependencies. These include domain configuration, data protection, administration and the new route's reputation. Your own bulk sending also needs clear operating rules. Microsoft recommends measures such as dedicated subdomains for that purpose. The choice needs to fit the sending volume and the business processes involved.

The remaining risk needs a decision

We have limited influence over a provider's shared sending infrastructure. Within our own business, we can decide who handles bounced messages, when to contact support and how important contacts can be reached.

The responsible role needs to decide whether that treatment is sufficient. Repeated delivery problems, a failed fallback or a new time-sensitive process are reasons for a risk review. The decision to accept residual risk belongs with its reasoning.

In Kopexa, the mail service can be connected to affected processes, the risk, measures and evidence. The tested fallback and the decision about continued operation stay with the same assessment. When the next disruption happens, the team can refer to the existing assessment and the agreed process.