mailgun emails not delivered

What does "Mailgun emails not delivered" mean?

This is not a single SMTP reply code — it's a symptom. Your API call or SMTP submission to Mailgun succeeded, but the message never reached the recipient's inbox. Mailgun records the real reason as a message event in its logs, and that event (not your app log) is where the answer lives. The most common reasons are a sandbox/free-plan restriction, a suppressed recipient address, an unverified sending domain, or an outright rejection by the recipient's server.

Note on the older advice for this page: checking an IP "Sender Score" and asking Mailgun support to assign you a higher-reputation IP is not how Mailgun works. Sender Score (Validity) is a third-party metric, not a Mailgun feature, and shared/free senders cannot request a custom IP via ticket. The steps below reflect Mailgun's actual delivery model.

How do I find why my Mailgun email wasn't delivered?

Open the Mailgun dashboard and go to Send → Reporting → Logs. Filter the event metrics to Delivered, Bounced (all), Failed (all) (which splits into Temporary failed and Permanent failed), and Rejected. Find the specific message and read its event detail — Mailgun shows the recipient SMTP response and reason. The event type tells you what to fix:

• Accepted but no Delivered — Mailgun queued it but the recipient server hasn't accepted it yet (greylisting/retry), or it was suppressed.
• Rejected — Mailgun refused to send (sandbox limit, suppression, or invalid request).
• Failed (Permanent) — a hard bounce; Mailgun stops retrying.
• Failed (Temporary) — a soft bounce; Mailgun retries, then gives up.

Source: Mailgun — Debugging Email Issues with Logs.

How do I fix the most common causes?

1. Sandbox / free-plan domain (the #1 surprise). A sandbox*.mailgun.org domain — and a Free plan without a card on file — can only send to Authorized Recipients, up to 5, each of whom must click an activation link to become "Verified." Mail to anyone else is rejected. Fix: add and verify the recipient under your sandbox domain's settings, or add a payment method and send from a verified custom domain. Source: Mailgun — Sandbox Domain and Authorized Recipients.

2. The address is on a suppression list. Mailgun automatically suppresses addresses that previously bounced, complained (marked spam), or unsubscribed, and silently won't resend to them. Check Suppressions in the dashboard or via the API; you'll see the original recipient SMTP error that caused it. If the suppression was a one-off (e.g., a temporary mailbox-full), remove the entry and resend; if it was a hard bounce, the address is likely invalid. Source: Mailgun — Suppressions.

3. Unverified domain / broken authentication. If your custom domain's SPF and DKIM TXT records aren't published correctly, Mailgun can't authenticate on your behalf and receivers will reject or junk the mail. Confirm the domain shows Verified (DNS changes can take 24–48h to propagate), keep a single SPF record under 10 lookups, and make sure the DKIM public key matches exactly with no stray characters. Source: Mailgun — DNS FAQ.

4. The recipient server rejected it. Read the SMTP response in the failed event. A 550 reply with enhanced status code 5.1.1 (no such mailbox) means remove the address; a 452 reply is temporary — its bare meaning is "insufficient system storage," and with the enhanced code 452 4.2.2 it specifically means the recipient mailbox is full, so it may succeed on retry; a 554 reply with enhanced code 5.7.1 (delivery not authorized / policy block) points to reputation or authentication problems — fix SPF/DKIM/DMARC, warm up volume, and check blocklists. (Basic reply codes such as 550/452/554 are defined by RFC 5321; the dotted 5.x.x enhanced status codes are defined by RFC 3463.)

Why does Mailgun say "delivered" but the email still isn't in the inbox?

A Delivered event means the recipient's mail server accepted the message — it does not guarantee inbox placement. The receiver may have filed it in Spam/Junk based on content or sender reputation, or applied a server-side rule. Check the recipient's spam folder, verify SPF/DKIM/DMARC alignment, and review content/links that trigger filters. Note that Mailgun only sees delayed bounces (post-acceptance NDRs) if your domain's MX records point to Mailgun. Source: Mailgun — Tracking Failures.