# How to use a Righthand with Mailgun

Prepare a Mailgun delivery investigation with domain and message context, event IDs, event times, and carefully qualified retry proposals.

By Righthand Team · 2026-10-09

Source: https://www.righthand.ai/blog/how-to-use-righthand-with-mailgun

## Investigate a particular message, not an entire inbox

Righthand can help prepare a Mailgun delivery investigation for selected transactional messages. The useful output shows the observed event sequence and unresolved questions. An accepted send request, a delivered event, and evidence of a person reading a message are different states and should remain distinct.

Mailgun's [event structure guide](https://documentation.mailgun.com/docs/mailgun/user-manual/events/event-structure) describes event type, timestamp, and event ID. The documented event ID is unique within a day, so preserve date and domain context when reconciling overlapping event windows. Avoid a global deduplication key based on the ID alone.

## Collect the exact delivery tuple

Give the sending domain, provider message reference, approved recipient, intended template, and relevant interval. For an illustrative password-reset investigation, include the application's source receipt and the provider events the operator permits the assistant to inspect.

Check Mailgun's tools through [integrations](/integrations). If event reads are unavailable, use an approved event export or browser review. Do not obtain a wider event archive when selected records answer the question, and do not infer resend authority from read access.

## A complete worked brief

> At 10 AM America/Los_Angeles, review the supplied application receipt and approved Mailgun events for the selected transactional message in the named domain. Produce a private timeline with message reference, verified recipient, event type, event time, retrieval time, and available failure detail. Deduplicate overlapping event extracts using the documented identity context. Do not resend, change suppression, or alter the domain. Deliver to me for messaging-operator review and reconcile the message and recipient across all sources.

This example is illustrative. The investigation should not expose reset tokens or other sensitive message contents in a wider report.

## Define the expected timeline

An example entry could say: “Application reports request accepted; provider event extract contains a later failure; operator must inspect the reported reason before deciding next action.” The assistant should not label the message delivered based only on the application's successful request.

If the event extract contains a delivered state, report its provider meaning and retain the source. It does not prove inbox placement, reading, or the user's successful completion of the intended workflow. Missing downstream evidence should remain unresolved.

## Reconcile before proposing a retry

A delayed event can arrive after the first investigation. Refresh the exact message before recommending another send, and compare timestamps. A retry without reconciliation can duplicate a message whose delivery was already accepted.

Permission loss, an incorrect domain, and a narrow reporting window can hide events. State the coverage limit rather than declaring permanent failure. Any retry needs explicit operator authority, recipient eligibility, and a check for an existing successful effect.

Use [Righthand's connection guide](https://docs.righthand.ai/guides/add-a-connection) for narrow read access. Check [plans](/pricing) for recurring delivery monitoring and retain the operator as the owner of retries and suppression changes.