SparkPost SMTP test: SMTP_Injection username and API key

SparkPost provides SMTP injection at smtp.sparkpostmail.com on port 587 with STARTTLS (port 2525 as a fallback). The SMTP username is the fixed string SMTP_Injection and the password is a SparkPost API key that has the "Send via SMTP" permission enabled. There is one username for every account and subaccount: your identity is carried entirely by the API key.

Because the credential model is unusual (a constant username plus a long API key), most SparkPost SMTP problems are credential or domain problems, not network problems. Running a live handshake with SMTP Tester shows exactly where the conversation stops: authentication, domain acceptance, or message injection. If you are new to this kind of test, start with what an SMTP test is.

When SMTP injection makes sense (and when the API does not)

SparkPost's primary interface is the Transmissions REST API. The SMTP endpoint exists so existing applications, CMS plugins, and internal MTAs can switch relay without a rewrite. The trade-offs:

If you are building something new, use the API. SMTP injection is the supported path when you cannot modify the sending application deeply, or when you want to point an existing mail system at SparkPost as a relay.

Recommended settings

• Host: smtp.sparkpostmail.com (US) or smtp.eu.sparkpostmail.com (EU)
• Port: 587 (STARTTLS) or 2525 (STARTTLS fallback)
• Username: SMTP_Injection (exact string, case-sensitive)
• Password: a SparkPost API key with "Send via SMTP" permission
• Auth method: Auto, PLAIN, or LOGIN
• From address: must use a verified sending domain
• MAIL FROM (envelope sender): derived from your bounce domain (see below)

How SparkPost SMTP credentials are scoped

SparkPost does not issue separate SMTP usernames or passwords per sending domain. Instead:

1. You create an API key in the dashboard and grant it the "Send via SMTP" permission.
2. That key can relay mail for any sending domain verified on the account (or subaccount) the key belongs to.
3. Per-domain enforcement happens at MAIL FROM time, not at authentication: SparkPost checks the envelope sender and From domain against your verified sending domains after AUTH succeeds.

Subaccounts follow the same model. A key created inside a subaccount sends only with that subaccount's settings and reputation. If you split traffic by subaccount, create one key per subaccount and store each as a separate profile in SMTP Tester.

Creating an API key with sending access only

Keep the key least-privileged. For SMTP sending it needs exactly one permission:

1. Log in to the SparkPost dashboard.
2. Go to Configuration → API Keys.
3. Click "Create API Key."
4. Enable the "Send via SMTP" permission (this is separate from the "Transmissions: Read/Write" REST API permission).
5. Copy the key immediately. SparkPost shows it only once.

If the key does not have "Send via SMTP" enabled, authentication will fail over SMTP even though the key works for the REST API. The reverse also holds: a REST-only key cannot authenticate at the SMTP endpoint at all.

A send-only key cannot read account data, list templates, or query metrics, which makes it suitable for an application's environment config. It is also the key type to paste into SMTP Tester for this test.

Testing with SMTP Tester

1. Host: smtp.sparkpostmail.com, port 587, security STARTTLS.
2. Username: SMTP_Injection. Password: your API key.
3. From: an address on a verified sending domain.
4. To: any recipient you control.
5. Click Run. A 235 2.7.0 Authenticated confirms login.

A 250 OK after DATA means SparkPost accepted the message for delivery.

While the test runs, each transcript stage tells you something specific:

• Connect + TLS: the server banner and the STARTTLS negotiation. The certificate should match *.sparkpostmail.com (or the EU equivalent).
• EHLO: a 250 response listing extensions, including AUTH PLAIN LOGIN.
• AUTH: 235 2.7.0 means the API key was accepted. SMTP Tester redacts the key from the transcript.
• MAIL FROM / RCPT TO: a 250 for each. SparkPost validates your sending domain here, so this is where a bad From domain fails.
• DATA: 354 starts the message, and the final 250 means the message entered SparkPost's delivery pipeline.

If a stage fails, the exact server reply appears in the transcript, which makes the error sections below easy to match against your run.

MAIL FROM, the bounce domain, and why alignment matters

Every SparkPost message has two senders: the From header address, which recipients see, and the envelope MAIL FROM (return-path) address, which receives bounces.

SparkPost derives the MAIL FROM domain from the bounce domain configured on the sending domain. By default this is the sending domain itself, so mail with news@marketing.example.com in the From header gets an envelope sender on example.com. If you configure a custom bounce domain (for example bounces.example.com, CNAME'd to SparkPost's bounce infrastructure), SparkPost uses that domain for the return-path instead.

Why alignment matters:

• SPF: the bounce domain carries the SPF evaluation for the envelope sender. Pointing its CNAME at SparkPost means SparkPost's published SPF records vouch for your mail.
• DMARC: DMARC passes if either SPF or DKIM aligns with the From domain. SparkPost DKIM-signs with your sending domain, so DKIM alignment normally carries DMARC even when the bounce domain differs.
• Bounce handling: a misconfigured bounce domain sends bounces nowhere, which degrades list hygiene and reputation.

For the SMTP handshake itself, MAIL FROM alignment rarely changes the result. It changes what happens after acceptance: whether SPF-based checks at recipients pass, and whether out-of-band bounces route back into SparkPost's event data.

Common errors

535 "Authentication failed" / "Invalid credentials"

• Wrong username: must be SMTP_Injection exactly (capital S, capital I). Not your email, not your account name.
• Wrong password: must be a SparkPost API key, not your account login password.
• Key missing SMTP permission: the API key must have "Send via SMTP" enabled in its permissions. Edit the key in Configuration → API Keys if needed.
• Subaccount key: if you are using a subaccount, the API key must be created within that subaccount, not the master account.
• EU vs US endpoint: EU accounts use smtp.eu.sparkpostmail.com. US keys will not authenticate against the EU endpoint and vice versa.

The generic 535 walkthrough lives in fixing SMTP authentication error 535.

554 "Relay denied" / "Relay access denied"

SparkPost returns 554 when the message is not allowed to relay even though authentication succeeded. The usual causes:

• no verified sending domain matching your From or MAIL FROM domain;
• the domain is verified but still pending compliance approval;
• the key belongs to a subaccount and the sending domain is only configured on the master account, or the reverse.

Fix the domain, not the credentials. If AUTH already returned 235, the problem is at the domain level.

550 "MSGID: invalid recipient" / recipient rejected

SparkPost checks recipient syntax at RCPT TO. A malformed address (missing TLD, stray characters, or a placeholder like test@) is rejected with a 550 reply that references the message ID, in the "MSGID: invalid recipient" style. Re-run the test with a valid address.

This is a syntax check, not a mailbox check. SparkPost accepts syntactically valid but nonexistent mailboxes and reports the hard bounce later through message events.

550 "Sender domain not verified"

The From address uses a domain not configured as a sending domain in SparkPost. Go to Configuration → Sending Domains and add + verify your domain (DKIM + bounce domain DNS records).

421 "Try again later" / rate limit

SparkPost is throttling injection. Sending rate depends on your plan and account warm-up status. Retry after a brief pause or reduce injection rate.

Connection timeout on port 587

If port 587 is blocked by your network, try port 2525, which SparkPost supports as an alternative STARTTLS endpoint. If you are comparing ports before switching, see SMTP port 587 vs 465.

US vs EU regions

SparkPost separates infrastructure by region:

API keys and sending domains are region-specific. An API key from the US account will not authenticate against the EU SMTP endpoint.

Sending domain verification (SPF, DKIM, DMARC)

SparkPost requires verified sending domains before relaying mail:

• DKIM: add the TXT record SparkPost provides for DKIM signing. This signature is what typically satisfies DMARC alignment, since SparkPost signs with your sending domain.
• Bounce domain: CNAME record for bounce handling (improves deliverability and keeps SPF evaluation on SparkPost's sending infrastructure).
• SPF: follow SparkPost's DNS guidance for the sending domain. If you use a custom bounce domain, the CNAME handles the envelope-side records.
• Compliance review: SparkPost may review new domains before enabling sending.

Until the domain is verified and compliance-approved, sends will fail after AUTH with a domain error (typically the 554 relay denial described above), even though authentication and RCPT TO look clean.

X-MSYS-API and X-MSYS-SUBACCOUNT headers

SparkPost accepts a JSON header inside the message itself to control per-message options:

X-MSYS-API: {
  "options": {
    "open_tracking": true,
    "click_tracking": true,
    "transactional": true
  },
  "campaign_id": "welcome-email",
  "metadata": { "source": "smtp-test" },
  "ip_pool": "transactional-pool"
}

In a real message the JSON must be a single header line (wrapped here for readability). Options cover tracking toggles, transactional classification, campaign ID, IP pool selection, and custom metadata that flows into SparkPost's message events.

For subaccount routing over SMTP, use the separate X-MSYS-SUBACCOUNT header with the subaccount name. Without either header, SparkPost applies account-level defaults, which is fine for a handshake test: SMTP Tester's test message carries no X-MSYS-API headers, and SparkPost accepts it with defaults.

Sending limits

Limits depend on your plan:

• Free tier: 500 emails per month (15K first month for testing).
• Paid plans: volume-based, up to billions per month.
• Burst rate varies by account reputation and warm-up stage.

Check your plan's current numbers in the dashboard before load testing. Exceeding the injection rate produces the 421 response described above rather than a hard failure.

Testing with nodemailer

The nodemailer configuration mirrors the settings above:

const nodemailer = require("nodemailer");

const transporter = nodemailer.createTransport({
  host: "smtp.sparkpostmail.com", // smtp.eu.sparkpostmail.com for EU accounts
  port: 587,
  secure: false,     // STARTTLS, not implicit TLS
  requireTLS: true,  // refuse to send if the session is not upgraded
  auth: {
    user: "SMTP_Injection",
    pass: process.env.SPARKPOST_API_KEY, // key with "Send via SMTP"
  },
});

// Handshake-only check: connect, EHLO, AUTH (and MAIL FROM)
await transporter.verify();

// Full send test
await transporter.sendMail({
  from: "news@marketing.example.com", // verified sending domain
  to: "you@example.com",
  subject: "SparkPost SMTP check",
  text: "Handshake and delivery test via nodemailer.",
});

transporter.verify() performs roughly the same connect, EHLO, and AUTH sequence that SMTP Tester shows in its transcript. If verify() succeeds but sendMail() fails with a 554 or 550, the credentials are fine and the problem is the sending domain or recipient. That separation is the fastest diagnostic step in application code.

Recipient validation

SMTP injection performs syntax-level recipient checks only. If you are migrating a list to SparkPost, validate addresses before injection:

• SparkPost offers a Recipient Validation service, available through the dashboard and API, that flags invalid syntax, disposable domains, and other high-risk addresses. Check its availability and pricing on your plan before relying on it at volume.
• Watch message events for hard bounces after the first send and suppress those addresses. High bounce rates damage reputation and can trigger another compliance review.

Never treat an accepted 250 after DATA as proof the mailbox exists. Use a recipient you control for test runs so the test email is accounted for.

Security notes

• API keys with SMTP permission can send email through your account. Store them in environment variables or a secrets manager, never in source control, and rotate if compromised.
• Create send-only keys for anything that relays over SMTP, and revoke unused keys in Configuration → API Keys.
• SMTP Tester redacts credentials from the live transcript and never persists them server-side.
• Use a dedicated sending subdomain to isolate mail reputation from your corporate domain.

Frequently asked questions

Is my API key the SMTP password?

Yes. Over SMTP, the password field is the API key value itself. Your dashboard login password plays no role in the SMTP conversation.

Can one API key work for both the REST API and SMTP?

Only if it has both permissions. A key with "Send via SMTP" alone authenticates over SMTP but cannot call the Transmissions API, and a REST-only key cannot authenticate at the SMTP endpoint. A send-only key for SMTP is the safer default.

Do I need a different credential per sending domain?

No. One key with "Send via SMTP" can relay for every verified sending domain on its account or subaccount. Domain enforcement happens per message at MAIL FROM time, not per credential.

Should I use the US or EU endpoint?

Use the endpoint that matches your account region. US keys authenticate only against smtp.sparkpostmail.com, and EU keys only against smtp.eu.sparkpostmail.com. Keys and sending domains do not cross regions, so choose the region for your data-residency needs at account creation.

Why did my test pass but the email never arrived?

A 250 after DATA only means SparkPost accepted the message into its pipeline. Check message events in the dashboard for the delivery, bounce, or spam-block event that followed. Also confirm the recipient was not suppressed and that the address passed SparkPost's syntax check at RCPT TO.

Does SMTP Tester store my API key?

No. The key is used for the live test, redacted from the transcript, and never persisted server-side. If you save a browser profile with "remember password" checked, the key stays in your browser's local storage.

Related guides

• Mailgun SMTP test: a similar API-key-as-password model with per-domain SMTP credentials.
• Resend SMTP test: another provider that uses an API key as the SMTP password.
• What is an SMTP test: the stages of a handshake test and what each reply code means.