Mailgun shows how to send email alerts to Discord

Your team’s Discord channel can double as an email operations feed—with a little plumbing. Sinch Mailgun has published a walkthrough showing how to turn email delivery events into Discord notifications using a small Python application.

This is a build-it-yourself workflow, not a direct connection between the two services. The catch is message format: Mailgun sends event data that Discord cannot consume as-is. A script sits between them, checks the incoming request and repackages the information into a channel message.

What happened

The Mailgun tutorial uses Flask, a lightweight Python web framework, to receive events and forward alerts. Its example includes routes for bounced and delivered messages, plus a test route that checks the Discord connection without involving Mailgun.

A webhook is an event-triggered HTTP request: one service sends data to a configured address when something happens. Here, there are two handoffs. Mailgun contacts the hosted Python application, and that application sends a separately formatted request to Discord’s webhook address.

The distinction matters during configuration. Mailgun does not let users change or control the payload it sends to a webhook, while Discord expects a particular structure. Pasting a Discord webhook address directly into Mailgun therefore does not replace the translation step described in the guide.

The application divides that work into named functions. extract_mailgun_data(request) separates signature information from event information. verify_mailgun_signature(token, timestamp, signature) authenticates incoming data using the webhook signing key. send_discord_alert(...) builds and sends the Discord message, with a configurable color and optional fields.

The example can live in a single file, flask_app.py. That keeps the demonstration compact, but it does not remove the hosting requirement: Mailgun needs an internet-accessible endpoint to contact when an event occurs. A script sitting only on an inaccessible laptop will not complete that chain.

The background

The prerequisites begin with a Mailgun account and a configured domain. The walkthrough uses the sandbox domain supplied on Mailgun’s free tier; it also describes setting up and verifying a custom domain. Mailgun says the free tier should be sufficient to implement the example, rather than presenting a paid plan as a starting requirement.

On Discord, setup happens through Server Settings, then Integrations, then Create Webhook. The user gives the webhook a name and copies its URL into the Python configuration. Anyone without an existing Discord server must create one before that destination can be set up.

The hosting options are deliberately modest. The tutorial suggests running the script locally with ngrok providing internet access, or hosting it online with PythonAnywhere. Its worked example uses PythonAnywhere, which supports Flask out of the box and offers a free tier suitable for testing, according to Mailgun.

There is a hosting constraint worth checking before debugging the code: PythonAnywhere restricts outgoing connections on its free tier. Mailgun says Discord appears on the allowed-domain list, so the example’s outbound notification request should be permitted. That is a dependency of the selected host, not a setting inside Mailgun.

The guide assumes readers already know how to create, run and host Python applications. It does not explain virtual environments or deployment in detail. For teams evaluating email service providers and tools, that makes this an integration recipe rather than a complete beginner’s hosting course.

Security also sits at the application boundary. The webhook signing key is available on Mailgun’s webhook page and goes into a dedicated variable in the script. Its purpose is to distinguish Mailgun’s requests from potentially malicious submissions, not to format the resulting Discord message.

That application check is a different layer from the issues in our coverage of Cisco email gateway security and phishing infrastructure takedowns. The practical consequence here is specific: the newly exposed event receiver needs its own request authentication, even though its job is only to report email activity.

What people are saying

Mailgun frames the workflow around putting operational information where teams already communicate, rather than requiring repeated dashboard checks. Its engineering examples include permanent delivery failures and delayed deliveries, which could prompt investigation of system problems or mail-server configuration.

The vendor also describes different audiences for the same event stream. Support teams need visibility into customer communications that are not reaching their destination, while marketing teams need feedback on campaign deliverability. Those are proposed uses of the setup, not evidence that every event warrants a company-wide notification.

For the demonstration itself, Mailgun favors a successful delivery as the first end-to-end test. A delivered event is easier to generate than a bounce or other unsuccessful outcome. That makes the /delivered route a diagnostic convenience, even when failed messages are the reason a team wants alerts.

Mailgun presents the script as a starting point that users can modify. It specifically suggests adding handling for messages reported as spam and unsubscribe-link clicks. Those additions require corresponding webhook configuration in Mailgun as well as code changes; expanding only one side leaves the workflow incomplete.

The guide also suggests a web application firewall as an additional protective layer for the exposed endpoint. It does not provide a detailed firewall deployment plan. Teams should therefore treat that suggestion as further implementation work, not as a protection automatically supplied by running the sample application.

What happens next

The first check is local to the application: opening its root route, /, should show that the handler is running. Next, visiting /test should produce a Discord message without sending an email. These checks separate basic application availability from the outbound Discord connection before Mailgun enters the picture.

Once those checks pass, the Mailgun configuration sits under Sending, then Webhooks. The tutorial starts with a Delivered Messages webhook pointing to the application’s /delivered endpoint. Other event types need their own matching routes, such as /bounced, so the receiver knows how to process them.

The final test uses Mailgun’s application programming interface, or API, to send an email to a mailbox the tester controls. That requires an API key, separate from the webhook signing key. Mailgun warns that the API key is displayed only once when created; a missed key must be deleted and recreated.

A successful sending request returns a response confirming that the call went through. The delivery-triggered Discord alert follows a later step in the workflow. Keeping those checks separate helps avoid mistaking a successful API request for proof that the entire notification chain works.

Before turning the example into routine monitoring, senders still need to decide which events belong in the channel and who will respond. The tutorial supplies the transport and test points; extending it to permanent failures, delays or spam reports means explicitly configuring the events the team intends to act on.