SMTP2GO test tool: mail.smtp2go.com credentials

SMTP2GO is a transactional SMTP relay used by apps, WordPress sites, and small teams that want reliable outbound mail without running their own MTA. If you are configuring SMTP2GO in an app or plugin, use this SMTP2GO test tool workflow to confirm host, port, TLS, and credentials before chasing application-level errors. A two-minute handshake test in the browser beats an hour of guessing whether the problem is your network, your credentials, or your application code.

Recommended settings

• Host: mail.smtp2go.com
• Port: 587 (STARTTLS), recommended for most clients
• Alternatives: 465 (implicit TLS), 2525, 8025, 80, or 25 if your network blocks 587
• Username: an SMTP user username from the SMTP2GO dashboard (not your account login email)
• Password: the matching SMTP user password
• Auth method: Auto, PLAIN, or LOGIN
• From address: a sender you have verified in SMTP2GO

How SMTP2GO SMTP usernames work

The single most common setup mistake with SMTP2GO is using the wrong credential type. SMTP2GO issues per-user SMTP credentials that are completely separate from your web login. Your dashboard login is usually an email address plus a password you chose. The SMTP username, by contrast, is a generated string (it often looks like a short word plus random characters) paired with an SMTP password that is not your account password.

This design exists for a good reason: it lets you create isolated credentials per app, per environment, and per team member, and revoke any one of them without touching your account login. Treat each SMTP user as a scoped key for one sending path.

To create one:

1. Log in to the SMTP2GO dashboard.
2. Go to Settings → Users → SMTP Users (wording may appear as SMTP & API → SMTP Users).
3. Click Add SMTP user (or edit an existing user).
4. Copy the username and password shown; this pair is what your app must use.

You can create multiple SMTP users on the same account. A practical split:

Do not use your SMTP2GO account email and account password in SMTP clients. Forum threads with 535 authentication failed on SMTP2GO almost always mean the account password was pasted instead of an SMTP user password, or the username was truncated.

Verify your sender domain

SMTP2GO lets you send from a shared sending domain (one of theirs) the moment you sign up, which is fine for a first smoke test. For anything real, verify your own domain:

1. In the dashboard, open the sender domain verification page and add your domain.
2. Publish the DKIM DNS records SMTP2GO shows you (typically two CNAME records) at your DNS provider.
3. Wait for DNS propagation, then confirm verification in the dashboard.
4. Once verified, send with a From address on that domain so SPF and DKIM align, which is what inbox providers actually score.

Sending from an unverified domain risks rejection or spam-folder delivery even when the SMTP session itself returns 250 OK. The transcript tells you the relay accepted the message; it cannot tell you where it landed. If you want the underlying concepts, the what is an SMTP test guide covers the handshake from first principles.

Testing with SMTP Tester

1. Host: mail.smtp2go.com, port 587, security STARTTLS.
2. Username: the SMTP user username from the dashboard.
3. Password: the SMTP user password.
4. From: a verified sender address in your SMTP2GO account.
5. To: any recipient you want to test delivery to.
6. Click Run. Look for 235 after AUTH in the transcript.

Reading the transcript as it streams:

• Connect + TLS: a successful STARTTLS upgrade on 587 means your network allows the connection and the certificate checks out.
• EHLO → 250: SMTP2GO lists the extensions it supports, including its AUTH mechanisms.
• AUTH → 235: your SMTP user credentials were accepted. A 535 here means the credential pair is wrong.
• MAIL FROM / RCPT TO → 250: SMTP2GO accepted your sender and recipient.
• DATA → 354, then 250: the message body was accepted and queued for delivery.

A 250 OK after DATA means SMTP2GO accepted the message for delivery. Submission success does not guarantee inbox placement: check SMTP2GO sending logs if the message does not arrive.

Test all three ports before wiring up your app

SMTP2GO publishes several submission ports on the same host, and the differences matter more in real networks than in documentation. Run the test on every port you plan to rely on:

The pattern worth knowing: cloud platforms and VPS providers rarely block 2525, while consumer ISPs and corporate firewalls often do block 587. If your app will run inside a firewalled environment (an on-prem server, a customer's VPC, a locked-down CI runner), test 2525 and 465 from that exact network before committing to a port. A port that works from your laptop tells you nothing about the deployment target.

If 587 times out, try 2525 with STARTTLS before assuming credentials are wrong. For a deeper comparison, see SMTP port 587 vs 465.

Open and click tracking toggles

SMTP2GO can rewrite links and add a tracking pixel to report opens and clicks. For a plain connectivity test this does not matter, but it matters when you are validating real email templates:

• If you are testing whether a link lands on the correct URL, click tracking rewrites the destination to an SMTP2GO redirect domain first. Disable click tracking in the dashboard or expect the rewritten URL in the delivered message.
• Open tracking pixels are harmless in a plain-text test, but if you are comparing HTML rendering across clients, keep the tracking settings identical between runs so results are comparable.
• Some spam filters weight tracking pixels and redirect links. If you are diagnosing deliverability, run one test with tracking off and one with tracking on.

The toggles live in your SMTP2GO dashboard settings rather than in the SMTP session, so the handshake transcript looks identical either way. Check the dashboard if delivered messages behave differently from your source HTML.

Common errors

535 authentication failed

• Wrong username/password pair (account login instead of SMTP user).
• Extra whitespace when pasting the password.
• SMTP user disabled or deleted in the dashboard.
• Try AUTH PLAIN or LOGIN explicitly if Auto fails.

Connection timeout on 587

• Outbound 587 blocked on your network: try port 2525, 8025, or 465.
• Corporate firewall filtering SMTP: test from another network or ask IT to allow mail.smtp2go.com.

550 / 553 relay or sender rejected

• From address not verified in SMTP2GO.
• Domain DNS (SPF/DKIM) not set up: SMTP2GO may still accept the session but policy can reject later; check their sender verification UI.

TLS or certificate errors

• Match security to port: 465 needs TLS, 587 and 2525 need STARTTLS.
• For lab debugging only, you can disable Reject invalid TLS certificates in Advanced settings, never in production.

For a full walkthrough of the 535 case, see fixing SMTP authentication failures.

SMTP2GO vs API

SMTP2GO also offers an HTTP API for sending. The SMTP interface uses the SMTP user credentials above. API keys and SMTP user passwords are not interchangeable: if REST works but SMTP returns 535, you almost certainly have the wrong credential type in the password field.

Testing with nodemailer

Before touching your production code path, replicate the same connection in a short Node.js script. This is the same engine SMTP Tester uses, so a transcript that passes here should behave the same way in your app:

import nodemailer from "nodemailer";

const transport = nodemailer.createTransport({
  host: "mail.smtp2go.com",
  port: 587,
  secure: false, // 587 uses STARTTLS; set true only for port 465
  auth: {
    user: process.env.SMTP2GO_USER, // SMTP user username, not your login email
    pass: process.env.SMTP2GO_PASS,
  },
});

await transport.verify(); // handshake-only: connect, STARTTLS, AUTH
console.log("SMTP2GO connection OK");

await transport.sendMail({
  from: "you@your-verified-domain.com",
  to: "you@your-inbox.com",
  subject: "SMTP2GO smoke test",
  text: "Sent via nodemailer on port 587.",
});

Call transport.verify() from your app's health check if delivery is mission critical. It performs the same handshake as a full send without consuming a message.

Integrating with WordPress

WordPress sends through wp_mail(), which by default uses PHP mail and rarely works on shared hosting. The standard fix is the WP Mail SMTP plugin:

1. Install and activate WP Mail SMTP, then open its settings.
2. Choose Other SMTP (or the native SMTP2GO integration if your plugin version offers one).
3. Enter mail.smtp2go.com, port 587, encryption STARTTLS (or port 465 with SSL).
4. Enter the SMTP user username and password. The From address must be a verified sender in SMTP2GO.
5. Send the plugin's built-in test email, confirm receipt, and check the SMTP2GO activity log.

One caveat: some plugin versions store the SMTP password in the WordPress database. On a shared host, check whether your plugin variant supports defining the credentials as constants in wp-config.php instead.

Moving from shared sending domain to a verified domain

Many teams start on SMTP2GO's shared sending domain and switch to their own later. Sequence the cutover so a mistake stays small:

1. Verify your domain's DKIM records first and wait for the dashboard to confirm.
2. Update one low-traffic sender (a staging app or an internal form) to use the new From address, then test it with SMTP Tester.
3. Watch the first sends in the activity log for rejections or spam complaints.
4. Cut over the remaining apps one SMTP user at a time, so a problem is easy to isolate.

The order matters because reputation attaches to the domain. A verified domain sends with aligned SPF and DKIM and no longer shares reputation with other SMTP2GO customers, but a switch with a missing DNS record will bounce mail from every app at once.

After a successful test

• Lock in the same host, port, security, and SMTP user in your app config.
• Store credentials in environment variables or a secrets manager, not in git.
• Rotate the SMTP user password in SMTP2GO if you pasted it into a third-party support ticket.
• SMTP Tester redacts credentials from the live transcript, safe to share the output for debugging.

Where to go next

• Fix 535 authentication errors
• SMTP port 587 vs 465
• SendGrid SMTP test: another transactional relay with similar port options
• Gmail SMTP test: testing a mailbox provider instead of a dedicated relay

Frequently asked questions

Can I use my SMTP2GO account email and password for SMTP?

No. SMTP authentication requires the username and password of an SMTP user created on the SMTP Users page in your dashboard. Account login credentials only work in the web app. If your transcript shows 535 after AUTH, this mismatch is the most likely cause.

Can I create multiple SMTP users on one account?

Yes. Each SMTP user shares your account's sending limits and domain verification but has its own username and password. Create one per app or environment so you can disable a single credential without breaking everything else, and so the activity log shows which app sent each message.

Why is my SMTP username not my email address?

Because SMTP2GO separates dashboard identity from sending identity. The generated SMTP username is bound to nothing but the relay session; your account email is the identity for billing, support, and dashboard access. Keeping them apart means a leaked SMTP password never exposes your account.

Which port should I use: 2525, 8025, or 465?

Default to 587 with STARTTLS. Move to 2525 or 8025 when your network or hosting provider blocks outbound 587, which is common on residential ISPs and in corporate environments. Use 465 when your client library expects implicit TLS. All three reach the same relay, and the same SMTP user credentials work on each.

Does a passing handshake test prove my email reaches the inbox?

No. A 250 OK after DATA confirms SMTP2GO accepted and queued the message. Inbox placement depends on your domain reputation, SPF/DKIM alignment, and content. Check the SMTP2GO activity log and the recipient's spam folder for the full picture.

How do I stop SMTP2GO from rewriting my links for click tracking?

Click and open tracking are account-level settings in the SMTP2GO dashboard, not per-connection SMTP options. Disable them there if rewritten URLs interfere with your tests, then re-run a send to confirm the delivered message contains your original links.