Look up any customer's email delivery history in one place

Build me an internal support console my customer support team opens every time a customer says they never received an email from us, so nobody on the team has to log into Mailgun and read raw logs. A rep opens it on demand and works a single case at a time. There is no schedule and no trigger.

The main screen is a single search box where a rep types a recipient email address. On submit, fetch that address's full sending history from Mailgun using List Events filtered by recipient, plus Query Logs, and render it as a per-message timeline. Group the raw events by message id and show one row per message with the subject, the sending domain, the timestamp and the current status, expandable into the ordered event trail of accepted, delivered, opened, failed and bounced, including the delivery status text or SMTP response on any failure event. Sort newest first. Mailgun's searchable log retention is capped by plan, roughly one to five days on entry tiers, fifteen on mid tiers and thirty on higher ones, so when a search returns nothing say that explicitly: an empty result means no messages inside the retained window, not proof that nothing was ever sent.

Above the timeline, show a status banner about the address itself. Check its suppression state with Get Bounce, List Complaints and List Unsubscribes (the single-address variants Get Complaint and Get Unsubscribe are fine if you want a faster exact lookup), and use List Domains to enumerate the account's sending domains so the banner covers every domain rather than only one. The banner should state plainly whether the address is currently suppressed, which kind of suppression it is (hard bounce, spam complaint or unsubscribe), which sending domain it applies to, when it happened and the reason recorded alongside it. If the address is clean, say so just as plainly.

Beside the timeline, a context panel that identifies the person so the rep gets one screen instead of three browser tabs. Use HubSpot Search Contacts on the email address to pull the contact's name, company, lifecycle stage and owner. Use Zendesk Search Tickets to list their recent tickets with subject, status and last update, newest first, each linking out to Zendesk. Let the rep select one of those tickets as the linked ticket for the session, since the diagnosis agent posts its reply back to it. If either lookup returns nothing, show a quiet empty state rather than an error, because plenty of recipients are not in the CRM.

Give the timeline rows actions. Resend a failed message with Mailgun Send Message, prefilling the sending domain, from address, recipient and subject from the event record so the rep can review and edit the body before it goes. Lift a suppression with Delete Bounce, Delete Complaint or Delete Unsubscribe, scoped to the domain the suppression actually sits on. Re-check the address with Validate Single Address and show the verdict inline, including the risk assessment and any suggested correction for a typo'd domain.

Resending and lifting a suppression are the only destructive things in this app, so put a confirmation step on both. The confirmation should spell out exactly what is about to happen, naming the address, the domain and the specific message, and require an explicit click to proceed. Record every action in a persisted action log inside the app: what was done, to which address and domain, when, and which rep did it, taken from the signed-in app user. Show that log in a panel beneath the timeline and stamp the rep's name onto the affected row, so the team can always see who lifted a block or resent a message. Nothing else in the app writes anything anywhere.

Add a Diagnose this delivery button on the results screen that kicks off a background agent. The agent reads the assembled event history for that address, pulls the detailed bounce classification with List Bounce Classification Bounce Logs for the sending domain, and checks the sending domain's signing health with List DKIM Keys for a Domain. It then writes two things back into the app. First, a plain-English root cause aimed at the support rep, for example that the recipient's mail server rejected the message as a hard bounce because the mailbox does not exist, or that messages are being accepted but the sending domain's DKIM key is not active so spam filtering is the likely culprit. Second, a customer-ready reply the rep could send as is, written in a calm non-technical support voice that never blames the customer and says clearly what happens next. Store both against the searched address so the results panel renders them the moment the agent finishes, and show a visible running state while it works.

Under the drafted reply, put a one-click button that posts it onto the linked Zendesk ticket as a public comment using Zendesk Update Ticket. Let the rep edit the draft text before posting. If no ticket was linked in the context panel, keep the button visible but disabled with a short explanation of what is missing, rather than hiding it.

Keep the whole thing a fast, dense, single-screen tool: search at the top, status banner under it, the message timeline as the main column, the customer context panel on the right, the action log below. Reps use this under time pressure with a customer waiting, so focus the search box on load, make each row readable without expanding it, and color-code status consistently throughout, with delivered and opened positive, failed and bounced negative, and suppressed as a warning state.