Triage your Amazon SES suppression list with HubSpot context

Build me an app my lifecycle team opens whenever email starts bouncing: a suppression triage desk for our Amazon SES account. It is interactive only. Nothing runs on a schedule and there are no digests or alerts. Everything happens when a person opens the app and clicks.

The main screen is a table of every address on the account suppression list, loaded with the Amazon SES List Suppressed Destinations operation, paging through NextToken until the whole list is in hand. Columns: email address, reason (BOUNCE or COMPLAINT), date added, recipient domain, and a small badge column showing whether our own team has acted on that address before. Give me free text search across the address and domain, a filter by reason, and a filter by date added range. A header strip above the table shows total addresses suppressed, how many were added in the last 7 days, and the split between bounces and complaints.

Next to the table, a rollup grouped by recipient domain: for each domain show the number of suppressed addresses, the bounce versus complaint split, and the most recent date added, sorted by count descending so one broken corporate domain is obvious at a glance. Clicking a domain filters the table down to that domain.

Clicking a row opens a detail panel with three sections. First, the full suppression record from Get Suppressed Destination, including the last update time and any bounce or complaint detail SES stores in the attributes. Second, a live validity check on the address using Get Email Address Insights, rendered as plain badges rather than raw output: syntax valid or not, DNS and MX records found or missing, and mailbox exists, does not exist, or unknown. That check is a POST with the address in the body and costs a call each time, so cache the result per address for the session and give me a refresh button.

Third, who the person actually is in HubSpot. Use Search Contacts with a filter on the email property equal to the suppressed address, requesting firstname, lastname, email, company, lifecyclestage, hubspot_owner_id and the contact id. Show name, company, lifecycle stage and owner. If there is no matching contact, say so plainly instead of rendering an empty card, and still allow the SES actions.

From the detail panel I can take three actions. Reinstate the address with Delete Suppressed Destination. Suppress it with Put Suppressed Destination, choosing BOUNCE or COMPLAINT as the reason. Write the outcome back to the CRM with HubSpot Update Contact against the matched contact id, setting an email status property. Do not hardcode the property: put the property name and the values written for a reinstate versus a suppress in a small settings area so the team can point it at whatever property their portal uses. The main screen also needs a Suppress address button for adding an address by hand, which takes an address plus a reason and calls Put Suppressed Destination.

Every reinstate and suppress is recorded in the app itself. Store a row with the address, the action taken, a short reason, the signed in user, a timestamp, and a snapshot of what the validity check said at that moment. A History view lists this log with search and filters by user, action and date, and the badge on the main table comes from it, so an address that has been reinstated before is visibly flagged when it shows up on the list again.

The important guard rail: if the validity check says the mailbox does not exist, or the log shows this address was reinstated before and is now back on the suppression list, the one click reinstate is disabled. The user has to type a free text justification of at least a sentence into a required field before the button enables, and that justification is stored on the log row. A preset reason picker is fine for ordinary cases (typo at signup, left the company, one off spam complaint), but the dead mailbox path must always require typed text. The whole point is that the same dead address does not quietly get put back into rotation every month.

One nuance to bake in: SES suppression entries are case sensitive. Always call Get Suppressed Destination and Delete Suppressed Destination with the exact address string returned by the list rather than a lowercased version, and when someone types an address by hand, warn them if it differs only by case from an entry already on the list. Handle empty states gracefully, because an empty suppression list is the good outcome, and surface SES and HubSpot errors inline in the panel rather than failing the whole screen.