# Open Zendesk tickets when a receipt or invoice email bounces

> When a customer permanently stops receiving your receipts, invoices, or password resets, we open a support ticket and ping your team in Slack.

- Workflow type: agent
- Services: Mailgun, Zendesk, Slack Bot
- Categories: Customer Support, Operations
- Published: 2026-08-07

## What it does

- Watches your outgoing email for permanent delivery failures, the kind where the message will never arrive no matter how many times it is retried.
- Ignores marketing blasts and newsletters, so you only hear about the mail that actually matters: receipts, invoices, password resets, and order confirmations.
- Opens a support ticket naming the customer, the message that failed, what the failure actually means in plain English, and a suggested next step.
- Posts a short heads-up in your support channel so someone can reach out before the customer notices they never got their receipt.

## What you'll need

- A Mailgun account that sends your transactional email
- A Zendesk account where the support tickets should be created
- A Slack workspace with a channel for support alerts, such as #support

## Prompt

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.

## How to customize

- Change which messages count as transactional by adjusting the subjects and tags to watch for, so you can add things like shipping updates or appointment reminders.
- Point the heads-up at a different Slack channel, or route billing failures to the finance team instead of support.
- Adjust the ticket priority and the suggested next step, for example asking for an alternate address rather than calling the customer.

## FAQ

### What counts as a permanent failure?

A permanent failure is when the receiving mail server says the address will never accept your message, for example the mailbox does not exist or the domain is wrong. Temporary problems, like a full inbox or a server that is briefly down, are skipped because those usually sort themselves out on a retry.

### Will this create tickets every time a newsletter bounces?

No. Marketing sends are deliberately ignored. The workflow reads the subject line and any tags on the failed message to decide whether it was a receipt, invoice, password reset, or order confirmation, and only those become tickets.

### Do I need to understand bounce codes to use this?

No. The technical reason and the response code from the receiving server are translated into a plain sentence on the ticket, along with a suggested next step your agent can act on without any email expertise.

### How quickly will we hear about a failed message?

The workflow checks for new email activity continuously, so the ticket and the Slack heads-up usually appear within minutes of the delivery failing.

### Will it open a new ticket every time the same customer bounces?

No. Before creating anything it checks whether you already have an open ticket for that recipient, so a customer with a broken address does not flood your queue with duplicates.

Use this prompt in General Input: https://www.generalinput.com/prompts/open-zendesk-tickets-when-a-receipt-or-invoice-email-bounces