Resend SMTP test: fixed username, API key, and port 465

Resend provides SMTP relay at smtp.resend.com on port 465 (implicit TLS, recommended) or port 587 (STARTTLS). The SMTP username is the fixed string resend, not your email address, and the password is your Resend API key (the same key used for the REST API).

This guide walks through the credentials, the sandbox restriction that trips up most new accounts, the DNS records Resend requires, and a live test with SMTP Tester so you can see exactly what the server returns at each protocol step.

Recommended settings

Port 25 is not supported. If your network blocks outbound 465, use 587 with STARTTLS. The port-to-security mapping matters: picking TLS on 587 or STARTTLS on 465 fails before authentication even starts. The SMTP port 587 vs 465 guide explains why the two ports negotiate encryption differently.

Why the username is literally "resend"

Most SMTP providers use your email address or account ID as the username. Resend does not. Every customer authenticates with the same username, resend, and the API key alone identifies your account. This design has two practical consequences:

1. Username typos are the most common failure. Developers habitually type their email address, dashboard login, or domain name into the username field. The server responds with 535 Authentication credentials invalid, and the fix is simply the four-letter string resend, lowercase, no quotes.
2. Your API key is the entire credential. Anyone holding your key can send email through both SMTP and the REST API. There is no second factor at the SMTP layer, so key handling (covered below) matters more than with providers that issue scoped SMTP-only passwords.

Getting your API key

1. Log in to the Resend dashboard.
2. Go to API Keys in the sidebar.
3. Click "Create API Key." Choose a name and permission scope (sending access is sufficient).
4. Copy the key (starts with re_). This is both your REST API key and your SMTP password.

Unlike most providers, Resend does not issue separate SMTP credentials. The same API key works for both interfaces, and it is shown once at creation, so store it in a password manager or secret manager immediately.

Sandbox vs production access

New Resend accounts start in sandbox mode. In sandbox you can only send to the email address that owns the Resend account. This is a deliberate anti-abuse measure: it stops unverified domains from sending to arbitrary recipients.

The restriction surfaces after authentication succeeds, when Resend inspects the recipient during the envelope exchange. In a transcript it looks like this:

>>> MAIL FROM:<noreply@yourdomain.com>
<<< 250 2.1.0 OK
>>> RCPT TO:<colleague@example.com>
<<< 550 2.1.1 The requested target mailbox is not available.
    Sandbox sending restrictions apply. Verify your domain
    at resend.com/domains to send to any address.

Two details worth noting:

• Authentication returned 235, so your credentials are fine. The rejection happens at RCPT TO, not at AUTH.
• The message text varies, but it always arrives as a 550 on the recipient command. If you see a 550 immediately after a successful 235, check whether you are still in sandbox before debugging your auth code.

To leave sandbox: verify a domain in the dashboard, then request production access from the Domains page. Approval is typically quick for legitimate use cases, but plan for it in your launch timeline rather than discovering the restriction on release day.

Testing with SMTP Tester

1. Host: smtp.resend.com, port 465, security TLS (or port 587 with STARTTLS).
2. Username: resend. Password: your API key.
3. From: an address on a domain you have verified in Resend (e.g. noreply@yourdomain.com).
4. To: in sandbox, the email address tied to your Resend account. In production, any recipient.
5. Click Run. A 235 response confirms authentication.

A 250 OK after DATA means Resend accepted the message for delivery. If you are new to the tool, what an SMTP test is explains the handshake stages in general terms.

What each transcript stage means

Reading the transcript in order makes diagnosis fast: an error at AUTH is always a credentials problem, and an error at RCPT with valid credentials is almost always sandbox or recipient policy.

Domain verification

Before Resend relays mail for your domain, you must prove ownership by adding DNS records:

• DKIM (required): Resend issues two CNAME records (a selector record and a key record) that delegate DKIM signing to Resend's infrastructure. Because they are CNAMEs rather than long TXT keys, you copy two short values instead of pasting a 2048-bit key.
• SPF (required): a TXT record at your root domain authorizing Resend's sending IPs, typically via an include: mechanism.
• DMARC (recommended): a TXT record at _dmarc defining your alignment policy. Start with p=none and reporting to observe alignment, then tighten to quarantine or reject once you confirm legitimate mail passes.

The Resend dashboard shows the exact hostnames and values for your domain and verifies each record automatically once it detects them. DNS propagation can delay verification; if a record is rejected immediately after you add it, wait and retry before changing values. Do not remove the records after verification, either. Resend signs and authorizes ongoing mail through them, and a stripped DKIM record is a common cause of sudden spam-folder placement.

Common errors

535 "Authentication failed"

• Wrong username: must be the literal string resend, not your email address or account name.
• Wrong password: must be the Resend API key (starts with re_). Do not use your Resend account login password.
• Key lacks sending permission: if the API key was created with restricted scope, ensure it includes sending access.
• Revoked or expired key: check the API Keys page in the dashboard.

The SMTP authentication failed guide covers 535 responses in more depth, including how different auth mechanisms report failures.

550 "Sender address not verified"

Authentication succeeded but the From address uses a domain not verified in your Resend account. Go to Domains in the dashboard and verify the sending domain by adding the required DNS records (SPF, DKIM, DMARC).

550 "Sandbox mode"

New Resend accounts start in a sandbox that restricts sending to the account owner's email only. Verify a domain and request production access to send to arbitrary recipients. See the transcript example above for how this appears mid-handshake.

Connection timeout

Resend recommends port 465 with implicit TLS. If 465 is blocked on your network, try port 587 with STARTTLS. Port 25 is not supported. Corporate networks frequently block both 25 and 465 outbound; if 587 also times out, the block is at your firewall, not at Resend.

Testing with nodemailer

For an application-level check before wiring Resend into your code, the same credentials work in nodemailer. Port 465 uses implicit TLS, so the connection is encrypted before the SMTP banner arrives:

const nodemailer = require("nodemailer");

const transport = nodemailer.createTransport({
  host: "smtp.resend.com",
  port: 465,
  secure: true, // implicit TLS on 465
  auth: {
    user: "resend",
    pass: process.env.RESEND_API_KEY,
  },
});

await transport.sendMail({
  from: "noreply@yourdomain.com",
  to: "you@yourdomain.com",
  subject: "Resend SMTP check",
  text: "Sent over port 465.",
});

Port 587 differs in one line only, and getting it wrong is the classic mistake:

const transport = nodemailer.createTransport({
  host: "smtp.resend.com",
  port: 587,
  secure: false, // STARTTLS: plaintext first, then upgraded
  auth: { user: "resend", pass: process.env.RESEND_API_KEY },
});

Setting secure: true on port 587 makes nodemailer attempt implicit TLS and fail with a socket error before any SMTP exchange. Setting secure: false on 465 produces the mirror-image failure. Match the flag to the port, and prefer 465 when you have the choice because encryption is established before your credentials are transmitted.

Resend SMTP vs REST API

Resend uses the same API key for both SMTP and the REST API (POST /emails). Choose based on what the sending system can support:

• Use SMTP for WordPress, plugins, legacy stacks, and appliances. Anything that already speaks SMTP (wp_mail, postfix relay, MTA forwarding, printers, scanners) works without code changes. Point it at smtp.resend.com:465 and you are done.
• Use the REST API for modern applications. The API returns structured errors instead of SMTP codes, supports batch sending and scheduling, and pairs with React Email templates. Latency is lower because there is no protocol handshake per message.

If your app already has an HTTP client and you are writing new code, the API is the better long-term choice. If you are configuring a system you cannot modify, SMTP is the only option, and Resend supports it fully. Some teams use both: SMTP for WordPress and internal tools, the API for the product. The same domain and DNS setup serves either interface.

Sending limits

Resend's free tier allows 100 emails per day and 3,000 per month. Paid plans scale to higher volumes. Rate limiting returns a 421 temporary error, so retry after a brief pause. For a comparison of testing tools themselves, see SMTP Tester vs smtper.net. For a comparable API-key credential model at another provider, see the SparkPost SMTP test guide. The Mailgun SMTP test guide covers another relay that pairs API keys with SMTP auth.

Key rotation and security

• The Resend API key grants both SMTP and API access. Treat it as a sensitive secret.
• Store keys in environment variables or a secret manager, not in source code or config files committed to git.
• Rotate keys on a schedule and immediately after any suspected exposure. In the dashboard, create the new key, update every consumer (both SMTP configurations and API calls), confirm a test send, then revoke the old one. Revoke first only if you know the key leaked; otherwise update-then-revoke avoids downtime for systems still using the old key.
• Name keys by purpose (e.g. production-smtp, staging) so a rotation does not take down unrelated systems.
• SMTP Tester redacts your password from the live transcript and never persists credentials server-side, so testing with a production key is safe. That said, a dedicated low-scope key for testing keeps the blast radius small.

Never share keys over chat or email, and never paste them into third-party tools that offer to "validate" them without redaction guarantees.

Frequently asked questions

What is the SMTP username for Resend?

The literal lowercase string resend. It is the same for every Resend account. Your email address, account name, and domain all fail with a 535 error.

Why does my test fail with 550 when authentication succeeds?

Most likely sandbox mode, which limits sending to your own account email until you verify a domain and request production access. The failure appears at RCPT TO with a 550, not at AUTH. A 550 on MAIL FROM instead points to an unverified sending domain.

Which port should I use, 465 or 587?

Either works. Port 465 uses implicit TLS and is Resend's recommendation; port 587 uses STARTTLS. Set secure: true for 465 and secure: false for 587 in nodemailer-style clients. Port 25 is not supported.

Do I need a separate password for SMTP?

No. Resend uses your API key for both SMTP and the REST API. There are no separate SMTP credentials to create or rotate.

Can I use Resend SMTP without verifying a domain?

Only in sandbox, and only to your own account email address. Any other recipient returns a 550. Domain verification is required for production sending.

How do I rotate my API key without breaking email?

Create a new key, update all SMTP and API configurations to use it, confirm a test message sends, then revoke the old key in the dashboard. If you suspect the key leaked, revoke immediately and accept the brief outage.