Provider guide · Mailgun
Mailgun's credentials belong to a domain, not to your account, and its servers come in two regions. Both facts are invisible in the signup flow and both produce authentication errors that look like a wrong password. Here is the map.
1 · Credentials
Your Mailgun sign-in email and password authenticate you, the human. WordPress authenticates as a domain, with credentials managed under that domain.
A brand-new account only has a sandbox domain, sandbox….mailgun.org, which sends to a handful of addresses you authorise and to nothing else. Real sending starts with your own domain, a paid-plan feature:
Under Sending, Domains, choose Add new domain. Mailgun’s own recommendation is a subdomain such as mail.yourdomain.com, which leaves the DNS of your root domain untouched.
Mailgun hands you two TXT records for that subdomain, SPF and DKIM. Add them at your DNS provider, click Verify DNS settings, and Mailgun emails you once verification passes.
In Domain settings, pick the domain, then the SMTP credentials tab. The default login has the form postmaster@yourdomain.com.
The credentials tab lets you set or reset it; do so and copy the result, because an existing password cannot be read back later, only reset.
2 · In the plugin
Selecting the Mailgun preset fills the port (587), the encryption (TLS) and the US host. If your domain lives in Mailgun’s EU region, that host is wrong for you.
smtp.mailgun.org for a US-region domain, smtp.eu.mailgun.org for an EU-region one. The region was chosen when the domain was added, and it is shown in the domain list.
The SMTP login from the credentials tab, postmaster@yourdomain.com unless you created another.
The password you set for that login.
An address on the sending domain, so the DNS you configured vouches for it.
Save, then use Send Test Email. On a sandbox domain, send it to an address you authorised first, or Mailgun will decline it by design.
3 · Pitfalls
Two of these three produce the same symptom, a refused sign-in, which is why Mailgun problems get misdiagnosed as password typos.
Credentials belong to a domain, and the domain belongs to a region. A domain created in the EU region authenticates only against smtp.eu.mailgun.org; the preset’s US host will refuse it every time, with an error indistinguishable from a bad password. If authentication fails and you are in Europe, check the region before anything else.
The sandbox domain that comes with a new account sends only to addresses you explicitly authorise, five at most, each of which has to accept an invitation first. It exists to prove your integration works. Real traffic, to customers who never signed up for anything, requires your own verified domain, and custom domains are a paid-plan feature.
Signing in to the dashboard with your email does not make that email an SMTP username. If the username field holds your account email instead of postmaster@yourdomain.com, or the password field holds your dashboard password, Mailgun refuses the connection. Both values come from the SMTP credentials tab of the domain, nowhere else.
The email log keeps the exact error message the server returned, which is the fastest route to the cause. The documentation walks through the common ones.
There is a guide like this one for each of the twelve presets, from Gmail to Amazon SES, and the plugin takes any other SMTP server too.