AI Bounce Diagnosis in InsightForge, Using Your Own Azure OpenAI

A bounce notice tells you that a message failed. It rarely tells you why in words a person can act on. “550 5.1.1” and “recipient address rejected” are accurate, but whoever is paged about a bounce spike still has to translate them into a fix. InsightForge could already show you which messages bounced. It can now also explain a bounce in plain English, using an Azure OpenAI resource that lives in your own subscription.

It is optional, and nothing runs until you connect an Azure OpenAI resource. This post covers what you get, exactly what data leaves InsightForge to produce it, what it costs, and where it falls short.

What you get

Open any bounced message in the dashboard and expand Diagnose this bounce. You get a short explanation, two to four sentences, of what most likely caused the bounce and one or two concrete steps to fix or avoid it. It works for bounces from Postmark, Azure Communication Services, and SendGrid, so you don't need a separate habit for each provider's error format.

Where it runs, and who pays

InsightForge is deployed into your Azure subscription, and the diagnosis request goes from that deployment to an Azure OpenAI resource you own. You create the resource, deploy a chat-completions model to it, and give InsightForge the endpoint, key, and deployment name. The usage is billed to your Azure subscription at whatever your Azure OpenAI deployment costs, not through InsightForge.

Exactly what it sends

The model gets a short, fixed set of fields about the bounce, and nothing else:

• The provider name
• The recipient's email domain, not the full address
• The bounce type and status code
• The reason and details text the provider reported

It does not send the message body, the subject, or the message headers. The recipient's address is not sent as its own field. One caveat is worth knowing: the provider's reason and details text is passed along as the provider wrote it, and some SMTP error responses quote the recipient address back. If that matters for your data-handling rules, review it against what your own providers return before turning the feature on.

Limits and cost control

AI Bounce Diagnosis is included on every plan, with a monthly cap on the number of diagnoses: 10 on Standard and 500 on Pro. Reopening a bounce you have already diagnosed returns the saved explanation. It doesn't call your Azure OpenAI resource again and it doesn't count against the cap, so the number is about distinct bounces you investigate, not page views.

Setting it up

1. In your Azure subscription, create an Azure OpenAI resource (or use an existing one) and deploy a chat-completions model to it.
2. In the InsightForge dashboard, go to Setup and open the Connect Azure OpenAI card.
3. Enter a display name, the endpoint, the API key, and the deployment name, then connect.

Only one Azure OpenAI connection can be active at a time. To change it, disconnect and reconnect with the new values.

Where it falls short

• It is only as good as the provider's fields. When a provider returns a bare category with no detail, the explanation is told to say so rather than guess, and you will get a general answer instead of a specific one.
• It can be wrong. It is a language model reading a few fields. Check anything you plan to act on, such as a DNS change or a suppression-list edit, against your provider's own documentation.
• It explains, it doesn't fix. InsightForge doesn't change your sending settings, suppression lists, or DNS based on a diagnosis.
• It works one bounce at a time. It is for understanding a specific failure, not for triaging thousands of bounces. For the overall picture, the bounce and complaint trends are still the place to look.