Open Zendesk tickets when a receipt or invoice email bounces

Poll Mailgun for new email events and tell me when a customer has stopped receiving critical transactional mail. Run this whenever Mailgun records a new message event for my sending domain.

Look only at permanent failures. Ignore deliveries, opens, clicks, and unsubscribes, and ignore temporary or soft failures that are likely to succeed on a retry, such as a full mailbox or a receiving server that is briefly unavailable. A permanent failure is one where the receiving server rejected the address outright, for example an unknown mailbox or a domain that does not resolve.

When a permanent failure comes through, use the Mailgun List Events operation to pull the surrounding context for that recipient. Gather the failure reason, the SMTP response code and message returned by the receiving server, the subject of the failed message, any tags on it, the timestamp, and any other recent events for the same recipient so I can tell whether this is a one-off or a repeated problem.

Then decide whether the failed message was transactional or marketing, judging from the subject line and the tags. Treat receipts, invoices, payment confirmations, password resets, account security notices, order confirmations, and shipping updates as transactional and customer-impacting. Treat newsletters, promotions, campaign blasts, and product announcements as marketing and skip them entirely, because a bounced newsletter is not worth a ticket. If a message is genuinely ambiguous, err on the side of treating it as transactional.

Before opening anything, use the Zendesk Search Tickets operation to check whether there is already an open ticket for the same recipient and the same delivery problem. If there is, leave it alone rather than filing a duplicate, so one customer with a broken address does not flood the queue.

For each genuinely customer-impacting failure that is not already ticketed, create a Zendesk ticket with the Create Ticket operation. The ticket should name the recipient's email address, identify the message that failed by subject and time, translate the bounce reason and SMTP response code into plain English that a support agent with no email expertise can act on, and suggest a concrete next step such as calling the customer, asking them for an alternate address, or checking whether the address has an obvious typo. Set the priority based on how critical the message was, with password resets and payment receipts ranking highest.

Once the ticket exists, post a short heads-up to our #support Slack channel using the Slack Bot Send a Message operation. Keep it to a couple of lines: who is affected, what they did not receive, and a reference to the Zendesk ticket. If nothing customer-impacting was found, do not post anything at all.