Choose a Mailgun region and authenticated domain

Mailgun supports region-specific domain configuration. Establish whether the domain belongs to the US or EU service before copying an API example; the same visible domain name does not make regional endpoints interchangeable.

Prepare the connection

1. Select the intended account/region and add the application sending domain.
2. Publish the authentication records shown for that domain. Receiving MX is a separate decision; do not replace a staff-mail domain’s routing unnecessarily.
3. Choose a sending credential appropriate to the domain and application. Keep account API keys, domain sending keys, SMTP credentials, and webhook signing secrets distinct.
4. Store secrets in backend configuration and record the region alongside the domain, not as an undocumented default inside code.

The current Mailgun getting-started documentation is the authority for available regions, domain capabilities, and account requirements.

Confirm before production

Use one controlled recipient and verify the send appears under the expected regional domain. If a domain cannot be found, check endpoint/region/account first; creating more credentials may not fix the mismatch.

Sandbox/testing facilities have restrictions and are not evidence that the production domain is ready. Plan bounce/complaint handling and the inbound route separately.

If MailKite receives replies while Mailgun sends, document the return/reply address and which system owns each domain/subdomain. Sharing a customer-facing brand does not make their keys, webhook signatures, or suppression stores identical.