SendGrid 535 authentication failed bad username password

SendGrid returns 535 Authentication failed: Bad username / password from smtp.sendgrid.net when the credentials sent in the SMTP AUTH exchange are rejected. The 535 reply with enhanced status 5.7.8 ("Authentication credentials invalid") is defined directly in RFC 4954 §6 — it is the server telling you the supplied credentials are wrong or insufficient, not a network or TLS-handshake failure.

What causes the SendGrid 535 "bad username / password" error?

In order of how often they're the real culprit on SendGrid specifically:

• Wrong username. This is the number-one cause. SendGrid SMTP does not accept your account email address or dashboard login. The username must be the exact literal string apikey (Twilio SendGrid SMTP docs).
• Wrong password. The password must be a SendGrid API key, not your account password. Per SendGrid's 535 troubleshooting article, it should be the full ~69-character API key, used raw (non-base64-encoded by you — the SMTP library does the encoding).
• API key lacks permission. The key needs at least Mail Send permission. A "Restricted Access" key without Mail permissions will authenticate as invalid for sending.
• Revoked / deleted / mistyped key. API keys are shown only once at creation. If the key was rotated, deleted, or copied with a missing character, you'll get 535.
• Legacy Basic Authentication + 2FA. If your account has two-factor authentication enabled (mandatory since Q4 2020) and your SMTP credentials are still an account email/password pair rather than an API key, SendGrid rejects the connection with 535 Authentication failed: Basic authentication is not allowed with 2FA enabled. Fix: switch to apikey
  • API key as described below.
• Stray whitespace or newline in the credential. SMTP is line-oriented; a copied key that wrapped across lines and picked up a linefeed or trailing space will fail base64 auth (SendGrid SMTP docs).
• Account suspended or under review. A disabled account (billing, compliance, or sender-reputation hold) rejects auth even with correct credentials.

Note: a genuinely wrong host or TLS version usually surfaces as a connection/handshake failure rather than 535, but SendGrid requires TLS 1.2+ and 535 has been observed when a legacy client negotiates down — see the fix below.

How do I fix the SendGrid 535 error?

1. Create a fresh API key with Mail Send permission. In the SendGrid dashboard: Settings → API Keys → Create API Key → choose Full Access or Restricted Access with "Mail Send" enabled. Copy the key immediately.
2. Set the credentials exactly:
   • Host: smtp.sendgrid.net
   • Username: apikey (the literal word — not your email, not the key)
   • Password: the full API key you just generated
3. Pick a valid port. Per the SendGrid docs, use 587 or 2525 (STARTTLS), 25, or 465 (implicit TLS/SSL). Port 587 is recommended. All of these are valid — 465 is not deprecated.
4. Store the key as an environment variable, not hardcoded, so you rotate it in one place and avoid copy-paste truncation.
5. Strip whitespace. Ensure no trailing space or newline was captured when pasting the key.
6. Confirm TLS 1.2+. Make sure your SMTP client/runtime negotiates TLS 1.2 or higher; older .NET/Java/OpenSSL stacks defaulting to TLS 1.0/1.1 can fail auth.

Example (Nodemailer):

const transporter = nodemailer.createTransport({
  host: "smtp.sendgrid.net",
  port: 587,
  secure: false, // STARTTLS on 587
  auth: {
    user: "apikey",                  // literal string
    pass: process.env.SENDGRID_API_KEY, // full API key
  },
});

Verify outside your app with a raw test before blaming code. SendGrid recommends testing the connection with Telnet/OpenSSL to isolate credential vs. network issues:

openssl s_client -connect smtp.sendgrid.net:587 -starttls smtp
# then issue AUTH LOGIN and supply base64(apikey) / base64(API key)

If a correct, Mail-enabled key still returns 535, check whether your account is suspended or under compliance review in the SendGrid dashboard, or contact SendGrid support.