550 Error in Mailgun

A 550 from Mailgun is a permanent SMTP rejection per RFC 5321 §4.2.1 — the message was refused outright, not temporarily deferred (that would be a 4xx). Mailgun reuses the code for several distinct situations, so the fix depends entirely on the enhanced status code (the 5.x.x per RFC 3463) and the text that follows it. Find the full line in your Mailgun Logs before changing anything.

What causes a 550 error in Mailgun?

The common variants:

• 550 ... Sandbox subdomains are for test purposes only. — You are sending from a sandboxXXXX.mailgun.org domain to an address that is not an Authorized Recipient. Per Mailgun's sandbox docs, sandbox domains can only deliver to up to 5 verified authorized recipients.
• 550 ... Relaying denied — Mailgun returns this when the SMTP session was not authenticated (a RCPT TO was issued before the session authenticated) or, for inbound, when no route is configured to catch the recipient address. It is an authentication/routing problem, not a DNS-record problem, and it commonly surfaces as 550 5.7.1. See Mailgun's Relaying Denied article.
• 550 ... Sender Verify Failed — The receiving server did an MX lookup on your envelope mail-from (your sending domain/subdomain) and could not resolve it, so it refused the message. Per Mailgun's Sender Verify Failed article, the fix is to publish MX records for your sending subdomain (pointing to Mailgun) so the lookup succeeds.
• 550 5.1.1 (bad destination mailbox address) — The recipient mailbox does not exist at the receiving server. This is a recipient-side reject; the address is wrong or has been deactivated.
• 550 5.7.1 — Per RFC 3463, this is "delivery not authorized" — the sender is not authorized to send to the destination. In practice this covers both Mailgun's own relaying denied (above) and receiver-side policy/reputation/spam blocks (low sending-domain reputation, missing alignment, content filters). Read the accompanying text to tell which.

Note: older guidance sometimes blamed a missing MX record on the sender's domain for every Mailgun 550. That is only the cause of the Sender Verify Failed variant above, where the recipient server's MX lookup on your sending domain fails — it is not the cause of sandbox, 5.1.1, or relaying-denied rejections. Add MX records for your sending subdomain only when a Sender Verify Failed (or 498 No MX) message names your sending domain; do not add them as a blanket fix.

How do I fix a 550 error in Mailgun?

1. Read the exact line. In the Mailgun dashboard open Send → Reporting → Logs, click the failed event, and copy the full 550 … string including the 5.x.x code. (Debugging with Mailgun logs.)

2. Sandbox reject → add the recipient as an Authorized Recipient: select the sandbox domain, open its Setup/settings tab, add the address, and have the recipient click the activation link so they become Verified. For production, add and verify your own sending domain instead of the sandbox (Authorized Recipients).

3. Relaying denied → make sure your client authenticates the SMTP session with your Mailgun SMTP credentials (or use the API) before issuing RCPT TO — all outbound mail must be authenticated. If the rejection is for inbound mail, check that a Route is configured to catch the recipient address.

4. Sender Verify Failed → publish MX records for your sending subdomain pointing to Mailgun so recipient-side MX lookups on your envelope mail-from succeed, and verify the domain in Mailgun (publish the SPF TXT, DKIM TXT, and tracking CNAME records Mailgun gives you). Allow up to 24–48 hours for propagation. Only point MX records to Mailgun if the subdomain is not already receiving mail elsewhere.

5. 5.1.1 → the recipient address is invalid. Correct the address, suppress hard bounces, and stop re-sending to it — repeated sends to dead addresses hurt reputation.

6. 5.7.1 (policy/reputation) → if it is not relaying denied, treat it as an authorization/reputation block. Ensure SPF, DKIM, and DMARC are aligned for your domain, warm up new sending domains gradually, and review content. If a specific receiver (e.g. Gmail) blocks you, check its postmaster guidance.

If you send through Courier, Mailgun's 550 and its bounce reason surface in your Courier message logs — use that detail to route the fix to the right cause above rather than retrying blindly (a 550 is permanent and will fail again unchanged).