# SMTP API integration
___

To integrate with the **SMTP API**, you need the applicable SMTP server information. The following table shows the available endpoints for the SMTP servers and port numbers, dependent on each region.

| Region         | SMTP server                   | Ports     |
|----------------|-------------------------------|-----------|
| Europe         | smtp-api.infobip.com          | 587, 465  |
| Great Britain  | smtp-api-gb1.infobip.com      | 587, 465 |
| India (Mumbai) | smtp-api-mum.infobip.com      | 587, 465|
| Indonesia      | smtp-api-id.infobip.com       | 587, 465|
| MENA           | smtp-api-ae2.infobip.com      | 587     |
| Pakistan       | smtp-api-pk2.infobip.com      | 587     |
| Qatar          | smtp-api-qa1.infobip.com      | 587     |
| Saudi Arabia   | smtp-api-sa3.infobip.com      | 587     |
| Türkiye        | smtp-api-tr1.infobip.com      | 587     |
| US             | smtp-api-us.infobip.com       | 587, 465|

For [Schrems II](https://www.infobip.com/glossary/schrems-ii) compliance, use **smtp-api-eu.infobip.com** with one of the standard available ports: **587** or **465**.

When using port 587, an explicit STARTTLS command is required, while a connection over port 465 implies that the TLS handshake has already been completed. TLS communication is **mandatory** on any port.

Note
SMTP API endpoint white-labeling is also supported. Contact [Support](mailto:support@infobip.com) or your dedicated account manager to enable this option.

___

## SMTP authentication

**SMTP authentication** (SMTP AUTH) ensures that only authorized users can send emails through the Infobip SMTP API. By enforcing valid credentials before permitting message transmission, SMTP AUTH helps prevent unauthorized access or server abuse.

Infobip SMTP supports the **PLAIN** and **LOGIN** authentication mechanisms:

- **PLAIN** - transmits the username and password in a single Base64-encoded string
- **LOGIN** - transmits the username and password individually, each encoded as Base64 string

Your authentication credentials can be submitted in two ways:

1. **Basic authentication** - use your Infobip account username and password.
2. **API key authentication** - username is always App, and the password is the API key created on your Infobip account.

In both cases, the username and password must be submitted as **Base64-encoded** strings.

Note
Some libraries, such as OpenSSL, may terminate the connection if the letter Q is inserted as the first character in a line. This may cause problems when using a base64-encoded username such as App, which encodes to QXBw in base64 and therefore begins with Q. To avoid this issue, use the -quiet option in OpenSSL or start the line with one or more blank spaces before entering the username.

See [API authentication](https://www.infobip.com/docs/essentials/api-essentials/api-authentication) for more information on using API keys.

___

## Supported SMTP commands

The Infobip SMTP server supports the following commands:

| SMTP command | Description |
|--------------|-------------|
| HELP | Returns information about supported SMTP commands and their usage. |
| HELO | Initiates a new SMTP session. Identifies the client to the SMTP server using the client’s domain name or hostname. Used in standard SMTP. |
| EHLO | Initiates an Extended SMTP (ESMTP) session. Identifies the client to the server and requests a list of ESMTP extensions supported by the server. |
| STARTTLS | Upgrades the existing SMTP connection to use TLS (Transport Layer Security) for secure communication. |
| AUTH | Authenticates the client to the server, using a username and password. PLAIN and LOGIN authentication mechanisms supported. |
| MAIL | Specifies the sender’s email address, also known as Envelope From. In addition to the FROM parameter, SIZE parameter is also used to announce the size of the email. Begins the process of sending a new email transaction. |
| RCPT | Specifies a recipient’s email address, also known as Envelope To. Used for each recipient of the message (To, Cc, Bcc). For multiple recipients, the command is repeated for each address. |
| DATA | Signals the beginning of the email content (headers and body). The server replies with a 354 response, prompting the client to send the message data. The data ends with a single line containing <crlf>.<crlf>. |
| RSET | Resets the current mail transaction, clearing any senders or recipients specified, but keeps the SMTP connection open. |
| QUIT | Terminates the SMTP session and closes the connection. |
| NOOP | Health check. |

Note
It is recommended, but not strictly required by RFC, that all email addresses listed in the **To** and **Cc** headers within the DATA section are also specified as recipients using the RCPT command during the SMTP transaction. Only addresses provided via RCPT will actually receive the message, but addresses in headers alone will not.

___

## RFC-compliant headers

The Infobip platform supports **RFC-compliant headers** for outgoing SMTP emails.

Commonly used headers include:

- In-Reply-To - supports message threading
- References - provides context for message threads
- List-Unsubscribe - enables recipients to unsubscribe from mailing lists
- List-Unsubscribe-Post - extends unsubscribe functionality for automated handling

___

## Optional custom headers

Custom headers allow you to include additional information in outgoing SMTP emails. The following table provides a list of custom header names used in email communication.

| Header name | Description |
|-------------|-------------|
| X-IB-Bulk-Id | The ID that uniquely identifies the sent bulk. This filter enables the client to query delivery reports for all the messages using just one request. |
| X-IB-Callback-Data | Additional client data that will be sent on the X-IB-Notify-Url. |
| X-IB-Intermediate-Report | The real-time intermediate delivery report that will be sent on the client's callback server. |
| X-IB-Notify-Content-Type | Preferred delivery report content type. Can be application/json or application/xml. |
| X-IB-Notify-Url | The URL on the client's callback server on which the delivery report will be sent. |
| X-IB-Tracking-Url | The URL on the client's callback server on which the open and click notifications will be sent. See [Tracking notifications](https://www.infobip.com/docs/email/send-email-over-api#tracking-notifications) for details. |
| X-IB-Track | Enables or disables open and click tracking. When enabled, tracking statistics are collected and displayed in the web interface. Can be overridden by X-IB-Track-Clicks and X-IB-Track-Opens parameters.  |
| X-IB-Track-Clicks | Enables or disables click tracking for the email. |
| X-IB-Track-Opens | Enables or disables open tracking for the email.  |
| X-IB-Client-Priority | Sets the priority of the email. Allowed values: HIGH, STANDARD, LOW. If not specified, the default is STANDARD. Higher priority messages are sent before lower priority ones from your account. |
| X-IB-Application-Id | Used to specify the application in outbound send requests. The same value is also returned in notification events. |
| X-IB-Entity-Id | Used to specify an entity in outbound send requests. The same value is also included in notification events. |
| X-IB-Skip-Passive-Storage | Set to true to skip [passive email storage](https://www.infobip.com/docs/email/email-storage-and-retrieval/passive-email-storage) (long-term storage used for compliance, legal, or audit purposes). If false or not set, the account-level setting is used. |
| X-IB-Skip-Active-Storage | Set to true to skip [active email storage](https://www.infobip.com/docs/email/email-storage-and-retrieval/active-email-storage) (short-term storage used for troubleshooting or support). If false or not set, the account-level setting is used. |

___

<crlf><crlf>