Mailgun SMTP test — domain credentials & common errors

Mailgun provides SMTP relay at smtp.mailgun.org (US region) or smtp.eu.mailgun.org (EU region) on port 587 with STARTTLS. The most common mistake is using the Mailgun private API key as the SMTP password: Mailgun separates REST API credentials from per-domain SMTP credentials.

A second trap is mixing up your Mailgun account login with your SMTP credentials. Your account login only gets you into the dashboard. SMTP authentication uses a username like postmaster@mg.yourdomain.com plus a password generated on that domain's settings page, so testing with SMTP Tester first confirms you have the right pair.

Recommended settings

• Host: smtp.mailgun.org (US) or smtp.eu.mailgun.org (EU)
• Port: 587 (STARTTLS) or 465 (implicit TLS)
• Username: your domain's SMTP user (e.g. postmaster@mg.yourdomain.com)
• Password: the SMTP password for that user (shown once on creation/reset)
• Auth method: Auto, PLAIN, or LOGIN
• From address: must be on a verified domain

If you are unsure which port to choose, start with 587 and STARTTLS. Both ports are fully supported; the difference is how TLS is negotiated. Our guide on SMTP port 587 vs 465 covers the trade-offs.

Mailgun account login vs SMTP credentials

Mailgun has two distinct credential types, and confusing them causes most 535 errors:

Older Mailgun accounts issued private API keys with a key- prefix, and many old tutorials show SMTP examples using that key as the password. That does not work: SMTP submission requires the per-domain SMTP password. If you paste an API key into SMTP Tester, the server answers 535 Authentication failed, which is the transcript telling you the credential type is wrong.

Finding your SMTP credentials

Mailgun issues SMTP credentials per sending domain. Each domain in your account has its own user and password:

1. Log in to the Mailgun control panel.
2. Open the domain list and select the domain you want to send from.
3. Find the SMTP credentials section on that domain's page. You will see the default postmaster@your-domain.com user (or another user you created).
4. Reset the password if you do not have it stored. Mailgun shows the new password only once, so copy it immediately into a password manager.

The username is the full SMTP user address (e.g. postmaster@mg.yourdomain.com), including the domain part. The password is the SMTP-specific password, not your Mailgun account password and not the private API key. If you manage several domains, make sure the credentials you copy belong to the domain in your From address; credentials from one domain will not authenticate for another, which shows up as a relay error rather than a plain auth failure (more on that below).

Sandbox domain vs verified production domain

New Mailgun accounts start with a sandbox domain such as sandbox123abc.mailgun.org. It is meant for exactly the kind of testing SMTP Tester does: verifying credentials, TLS negotiation, and message acceptance before you commit DNS changes.

Sandbox domains come with two restrictions:

• Authorized recipients only. You can send only to addresses you explicitly add under Authorized Recipients in the control panel, and each recipient must confirm via a verification email.
• Shared reputation. Sandbox mail is not suitable for production traffic.

For production, add your own domain (or a subdomain such as mg.yourdomain.com), publish the DNS records Mailgun gives you, and wait for verification. Until every required record shows a green checkmark, Mailgun may reject or queue messages.

Testing with SMTP Tester

1. Host: smtp.mailgun.org (or smtp.eu.mailgun.org for EU domains).
2. Port 587, security STARTTLS.
3. Username: your SMTP user (e.g. postmaster@mg.yourdomain.com).
4. Password: the SMTP password you copied from the control panel.
5. From: an address on the verified domain (e.g. noreply@mg.yourdomain.com).
6. To: any recipient, or an authorized recipient if you are still on the sandbox.
7. Click Run. A 235 Accepted response confirms authentication.

A 250 after DATA means Mailgun accepted the message for delivery.

What each transcript stage means

• Connection established / greeting (220): TCP reached Mailgun and the server is ready. A failure here points at the regional host or a firewall rule.
• STARTTLS and TLS handshake: the channel upgrades to encrypted. Certificate errors here usually mean TLS interception on your network or the wrong security mode for the port.
• AUTH (334 → 235): your credentials were accepted. This is where API-key-as-password mistakes surface as 535.
• MAIL FROM / RCPT TO (250): the envelope was accepted. A rejection usually means the sender domain is not verified or the recipient is not authorized on a sandbox.
• DATA (250): the message was queued, with a queue id you can look up in Logs.

If any stage fails, the transcript shows the exact server response.

Common errors

535 "Authentication failed" / "Invalid login"

The most frequent Mailgun SMTP error. Causes:

• Using the API key as the password: the private API key (starts with key-) is for the REST API only. SMTP requires the per-domain SMTP password.
• Using the wrong domain's SMTP user: if you have multiple domains, each has its own SMTP users. Using the credentials from one domain against another will fail.
• Password was reset and old one is in use: after resetting the SMTP password, update all applications and configs that reference it.
• Region mismatch: US-region domains authenticate against smtp.mailgun.org; EU-region domains use smtp.eu.mailgun.org. Cross-region auth will fail.

For a fuller walkthrough, see the guide on fixing SMTP authentication error 535.

550 "Relay access denied" / relay not permitted

The credentials authenticated fine, but they belong to a different domain than the one in your MAIL FROM or From header. Mailgun only relays mail for domains tied to the credentials you authenticated with, so match the From address domain to the SMTP user's domain.

554 Rejected

A 554 at the end of DATA means Mailgun refused the message itself rather than the connection or authentication: a From address on an unverified domain, a sandbox sending to a non-authorized recipient, or content that tripped a spam filter. The transcript line right before the 554 usually contains the specific reason.

550 "Sandbox subdomains are for test purposes only"

If you are using Mailgun's default sandbox domain (e.g. sandboxXXXX.mailgun.org), you can only send to verified recipients listed in the control panel under "Authorized Recipients." Add the To address there or switch to a custom verified domain.

550 "Domain not found" / "Sender not authorized"

The From address is on a domain not verified in your Mailgun account. Verify the domain by adding the required DNS records (SPF, DKIM, MX) in the Mailgun Sending → Domain settings page.

Connection timeout

Verify you are using the correct regional endpoint, and try port 465 if your network blocks 587. Mailgun does not listen on port 25 for submission.

US vs EU regions

Mailgun separates infrastructure by region for data residency compliance:

Domains created in one region cannot authenticate against the other. The symptom is a 535 auth failure even though the username and password are correct, because the endpoint you dialed does not know that user. Use the matching host for your domain's region; EU data residency requirements often make the EU endpoint mandatory for European senders.

Domain verification and SPF, DKIM, and DMARC

Before Mailgun relays mail for a domain, you must verify ownership by adding DNS records:

• SPF: a TXT record authorizing Mailgun's servers to send on behalf of your domain.
• DKIM: TXT (or CNAME) records for Mailgun's DKIM signing keys.
• MX (optional): only needed if you want Mailgun to receive inbound mail.

Mailgun publishes the exact record values on the domain's settings page. Until DNS verification completes, sends may fail or be queued, and the dashboard shows a checkmark once each record is detected.

Once verified, consider adding DMARC as a separate TXT record on your root domain. DMARC tells receiving servers what to do when SPF or DKIM checks fail and gives you reports for spotting unauthorized sending. If you send from a subdomain, SPF and DKIM live on that subdomain, while DMARC policy belongs on the organizational domain.

Sending limits

Mailgun's limits depend on your plan and change as Mailgun adjusts its offerings, so treat the dashboard as the source of truth rather than any fixed number. In general:

• Entry-level pay-as-you-go plans have no fixed monthly cap, but new accounts start with a low daily allowance that grows as your reputation builds.
• Higher-tier plans set monthly volume allowances per plan.
• Exceeding your throughput allowance results in throttling: Mailgun either queues messages or returns a temporary 4xx error such as 452 Too many recipients.

For testing, none of this matters much: a handful of test messages per day will not approach any limit, even on a fresh account. Check the Logs section of the dashboard for delivery status once volume picks up.

Sending a test message with Node.js and nodemailer

Once SMTP Tester confirms the handshake, wire the same settings into your application. A minimal nodemailer example:

import nodemailer from "nodemailer";

const transporter = nodemailer.createTransport({
  host: "smtp.mailgun.org", // or smtp.eu.mailgun.org for EU domains
  port: 587,
  secure: false, // STARTTLS on 587; set true only for port 465
  auth: {
    user: "postmaster@mg.yourdomain.com",
    pass: process.env.MAILGUN_SMTP_PASSWORD,
  },
});

await transporter.verify(); // handshake + auth only, no message sent

const info = await transporter.sendMail({
  from: "Hello <hello@mg.yourdomain.com>",
  to: "recipient@example.com",
  subject: "SMTP check",
  text: "If you can read this, Mailgun relay works.",
});

console.log(info.messageId);

Two details worth noting: secure: false with port 587 means nodemailer upgrades with STARTTLS after connecting (secure: true is for implicit TLS on 465), and transporter.verify() performs the same check SMTP Tester does, connect plus TLS plus AUTH without sending a message. Load the SMTP password from an environment variable or a secrets manager rather than hardcoding it.

Using Mailgun SMTP with WordPress (WP Mail SMTP)

WordPress sends email through PHP's mail() function by default, which often lands in spam or fails silently on shared hosting. The WP Mail SMTP plugin routes WordPress mail through Mailgun instead:

1. Install and activate the WP Mail SMTP plugin, then open its Settings page.
2. Choose SMTP as the mailer (not the native Mailgun API option, which uses REST credentials).
3. Enter smtp.mailgun.org (or smtp.eu.mailgun.org) as the host, port 587, encryption TLS (STARTTLS), authentication on.
4. Enter the SMTP username (postmaster@mg.yourdomain.com) and the SMTP password from the domain's credentials page.
5. Set the From email to an address on your verified domain, save, then use the plugin's built-in email test.

If the test email fails, run the same credentials through SMTP Tester. The transcript tells you whether the problem is authentication (535), the sender domain (550), or the message itself (554), which narrows a WordPress configuration issue down to a specific SMTP stage.

Multiple SMTP users

You can create additional SMTP users for a domain beyond the default postmaster@:

1. Open your domain's page in the Mailgun control panel and go to SMTP credentials.
2. Create a new SMTP user and set a password.
3. Store the password immediately; it is shown once.

Each user authenticates for that domain only, so you can give different applications different credentials and revoke them independently. Related: the Brevo SMTP test and SendGrid SMTP test guides cover other transactional relays, and what is an SMTP test explains how handshake testing works across providers.

Security notes

• Never use the private API key (key-...) as an SMTP password. It will not work, and pasting it in unexpected places risks exposure.
• Rotate SMTP passwords if you suspect compromise: reset them on the domain's SMTP credentials page and update your applications.
• SMTP Tester redacts credentials from the live transcript.
• Enable webhooks for bounces and complaints in Mailgun to protect your sender reputation.
• Use a subdomain for sending (e.g. mg.yourdomain.com) to isolate mail reputation from your root domain.

Frequently asked questions

Does each Mailgun domain have its own SMTP credentials?

Yes. SMTP credentials are issued per sending domain, not per account. Each domain's SMTP user (e.g. postmaster@yourdomain.com) has its own password managed on that domain's page. Credentials from one domain will not authenticate against another.

Can I send to any recipient with a sandbox domain?

No. Sandbox domains only deliver to addresses listed as Authorized Recipients in your Mailgun account, each of which must confirm via a verification email first. To send to arbitrary recipients, verify a custom domain and use it instead of the sandbox.

What happens if I use the wrong region's SMTP host?

Authentication fails with a 535 error even though your username and password are correct, because the user exists only in the other region's infrastructure. US domains use smtp.mailgun.org and EU domains use smtp.eu.mailgun.org.

Why does Mailgun reject my API key as an SMTP password?

The API key authenticates calls to Mailgun's REST API, a different protocol and credential store than SMTP submission. SMTP servers only accept the per-domain SMTP password, so any config that uses an API key over SMTP needs updating.

Does testing with SMTP Tester count against my Mailgun sending limits?

A handshake-only test sends no message at all. A full test sends one message through your plan's normal allowance, far below any meaningful limit even on accounts with fresh, low daily caps.

Should I send from my root domain or a subdomain?

A subdomain such as mg.yourdomain.com isolates sending reputation from mail your root domain might send directly. Either works as long as the domain is verified in Mailgun and the From address matches it.