Skip to main content
Send email through Telnyx over SMTP by configuring an SMTP client to use smtp.telnyx.com. This page lists the connection settings, the limits the relay enforces, and the exact reply the relay sends for each outcome.

Connection settings

The username is always apikey; it is not an account name or email address. The API key is the credential.

Session walkthrough

S: lines are relay replies and C: lines are client commands. The greeting, the first EHLO, and STARTTLS are exchanged before encryption starts; the rest of the session runs over TLS. The relay advertises AUTH only in the EHLO response that follows a completed STARTTLS handshake, so send EHLO again after the handshake.

Command order

Send commands in this order: EHLO, STARTTLS, EHLO again, AUTH, then MAIL FROM, RCPT TO, and DATA for each message. Use EHLO, not HELO: the relay answers HELO with 250 smtp.telnyx.com and advertises no extensions, so a client that sends only HELO can’t start TLS or authenticate. The table lists the reply to a well-formed command sent out of order by a client that greets with EHLO. The TLS handshake resets the session, so “before EHLO” also covers the time between the handshake and the next EHLO. For each command, the first matching row applies. After EHLO, a syntax or parameter error in MAIL FROM or RCPT TO is reported before authentication is checked. A connection is authenticated from the 235 reply until a later AUTH fails with 535, or until the relay replies 421 4.4.2 Session expired, close and retry. A mail transaction starts when MAIL FROM is accepted and ends with the final reply to DATA or with RSET. If DATA ended with 552 Message too large, send RSET before AUTH.

Authentication

  • Authenticate with AUTH PLAIN or AUTH LOGIN after STARTTLS and the second EHLO. Other mechanisms, such as CRAM-MD5, are refused with 504 Unrecognized authentication type.
  • For AUTH PLAIN, send the base64 encoding of \0apikey\0YOUR_API_KEY, either on the AUTH line or after the 334 prompt. For AUTH LOGIN, send the base64-encoded username apikey and then the base64-encoded API key, one after each 334 prompt.
  • A response that is not valid base64, or an AUTH PLAIN response that does not decode to NUL-separated username and password fields, is refused with 501 Authentication line too long / invalid.
  • Before STARTTLS, EHLO does not advertise AUTH, and an AUTH command sent after that EHLO is refused with 538 5.7.11 Encryption required. The connection stays open: issue STARTTLS, send EHLO, and authenticate.
  • Any username other than apikey, or an invalid key, is refused with 535 5.7.8 Authentication credentials invalid. A valid key that is not permitted to send email is refused with 535 5.7.1 Authorization failed: email send capability required. After a 535 reply, the connection stays open and is not authenticated.
  • Repeated failed AUTH attempts can be temporarily refused with 421 4.7.0 Temporary authentication failure, retry later. The relay sends the same reply when authentication is temporarily unavailable, and closes the connection after it. Wait, then reconnect and authenticate with a valid key.

Sender and recipients

  • The domain of the MAIL FROM address must be a verified sending domain on the account that owns the API key. The relay applies the same sender-domain rules as the Send Email API and refuses other senders with a 550 5.7.1 reply that states the reason. See Domains.
  • The message must contain exactly one From: header, and its address must pass the same check. A missing or repeated From: header is refused with 550 5.7.1 Invalid sender address after the message data is sent.
  • An empty sender (MAIL FROM:<>) is refused with 550 5.7.1 Invalid sender address.
  • An address in angle brackets is refused with 501 Bad sender address syntax or 501 Bad recipient address syntax when it is longer than 320 characters after any source route, quoting, and escaping are removed.
  • Delivery status notification (DSN) parameters such as NOTIFY and RET are not supported and are refused with 555 Unsupported option: <parameters>.

Message content

Content is delivered unchanged; Telnyx may re-encode it and add a DKIM signature. Don’t send mail you’ve already signed.
  • Message-ID and Date: The relay keeps the Message-ID header the message carries. If Message-ID or Date is missing, the relay does not add it, so set both headers on every message.
  • Tracking: No open or click tracking is applied to mail sent over SMTP. To track opens and clicks, send through the Send Email API.
  • Line endings: End every line in the message data with CRLF. Message data with bare LF or bare CR line endings can be refused with 451 Bare newline detected.
  • Character encoding: Message data must be valid UTF-8. Send parts in other character sets with Content-Transfer-Encoding: quoted-printable or base64. Message data that is not valid UTF-8 is refused with 554 5.6.0 Message content must be UTF-8; send other character sets as quoted-printable or base64.
  • Telnyx message ID: The UUID in the final 250 2.0.0 Ok: queued as <uuid> reply is the Telnyx message ID. Use it with GET /v2/email_messages/{id}, and to match webhooks and events and Email Detail Records. A 250 reply means Telnyx accepted the message; delivery results arrive as events.
  • Retries after 451 4.3.0: In rare cases, a message that gets 451 4.3.0 Temporary submission failure, try again at the end of DATA has still been accepted, so retrying it can deliver a duplicate.

Session limits

The recipient limit applies to the connection, not to a single message. A 452 4.5.3 Too many recipients reply refuses only that recipient; recipients already accepted in the transaction stay accepted. Open a new connection for each batch of up to 50 recipients, and close each connection with QUIT. After 421 4.4.2 Session expired, close and retry, the connection is not authenticated. Close it and open a new connection. Messages sent over SMTP count against the same rate limits and quotas as messages sent through the API, including sending-domain limits. When any of these limits is reached, the end of DATA is answered with 452 4.5.3 Mail quota exceeded, try again later. Retry later with backoff; a daily quota resets at midnight UTC. Suspensions get different replies depending on their cause:
  • Suspended sending domain: MAIL FROM, and the From: header at the end of DATA, are refused with 550 5.7.1 Domain is suspended.
  • Sending suspended because of the sending domain’s reputation: the end of DATA is answered with 452 4.5.3 Mail quota exceeded, try again later. Retries get the same reply until the suspension is lifted; contact Telnyx support.

Reply codes

Each table lists the exact reply line. <domain>, <n>, <uuid>, <parameters>, and <COMMAND> stand for values from the session.

Connection and TLS replies

Authentication replies

Envelope replies

Message data replies

The sender replies in the envelope table also apply to the From: header at the end of DATA.

Session and timeout replies

Other command replies

Test the connection

openssl s_client

Build the AUTH PLAIN credential:
Open a TLS session. -starttls smtp sends EHLO and STARTTLS for you, -crlf sends CRLF line endings, and -ign_eof stops openssl from treating lines that start with Q or R as its own commands:
After the handshake, enter the session:

swaks

--tls makes swaks require STARTTLS. Without it, swaks doesn’t start TLS, and the relay doesn’t offer AUTH on an unencrypted connection.
Both tests send a real message. A successful run ends with 250 2.0.0 Ok: queued as <uuid>.