AKMTA interaction with SMTP relays

By default, AKMTA sends messages directly from the sender's IP addresses. If the SMTP relay is enabled for a sender, all of that sender's outbound traffic is handed to an external SMTP relay server.

This page describes what happens when sending through a relay: how the envelope sender (MAIL FROM) is formed, how the sending session is built, and how the platform obtains delivery statuses.

Relay parameters

The following options are configured on the sender's SMTP relay tab:

Parameter	Description
SMTP relay host	The relay server host
Port	The relay server port (separate from the host)
SMTP auth type	Authorization method: Login, Plain, CRAM-MD5, or no authorization
SMTP auth user	Login for authorization
SMTP auth password	Password for authorization
Start TLS	Establish a TLS connection if supported by the relay
Sending strategy	The speed strategy that controls sending through the relay
Use webhook	Integration name and webhook URL for receiving statuses (if the relay delivers them via webhook)

note

If the relay host is empty while the relay is enabled, the AKMTA module will not start: relay parameters are validated at startup.

MAIL FROM formation

The envelope sender (MAIL FROM) determines where bounces (NDR) from recipients are returned and is set by the sender's Mail From type:

Mail From type	Envelope sender when sending through a relay
From Email	The sender's From address is used as-is — the generated return address is not applied
PTR	b-<smid>@<PTR-domain>
Custom	b-<smid>@<SenderDomain>
Aligned	b-<smid>@<subdomain>.<sender-domain>

<smid> is the send identifier of the specific message. Generated b-... addresses let the platform match incoming bounces back to the specific message. The visible From: header always contains the sender address, not the envelope sender.

Events are also matched to a message by the data of the report itself — the envelope identifier and the original message headers returned in a DSN. Notifications are therefore registered for the From Email type as well, when no b-... address is used.

Send sequence

For each session with the relay server, AKMTA performs:

1. Resolves the relay host to an IP address and opens a TCP connection (15-second timeout);
2. Waits for the server's 220 greeting and sends the EHLO command;
3. If Start TLS is enabled and the relay advertises the STARTTLS extension — sends STARTTLS and establishes a secure connection (certificate verification is disabled), then repeats EHLO;
4. Performs authorization with the chosen method, if it is set and the relay advertises the AUTH extension;
5. For each message in the batch:
   • MAIL FROM with the envelope sender (when DSN is supported, parameters are added that define notification conditions and the amount of the original message returned — RET=HDRS and ENVID);
   • RCPT TO for the recipient (when DSN is supported — the NOTIFY=SUCCESS,FAILURE parameter);
   • DATA transfer of the message body (DKIM-signed if a DKIM key is configured);
   • RSET to reset the connection state before the next message.

note

The Start TLS option does not guarantee an encrypted transfer. If the relay does not advertise STARTTLS or the TLS handshake fails, AKMTA opens a new connection and retries without TLS — within the same five attempts. Authorization is then performed over the unencrypted connection, provided the relay advertises the corresponding AUTH mechanism. Implicit TLS (connecting over TLS right away) is not supported — only STARTTLS.

AKMTA forms the message by the same rules as in direct sending — the same headers and platform service identifiers. Any further changes to headers and content depend on the external relay.

Delivery status handling

Delivery statuses when working through a relay are determined by the relay's responses, webhooks, and incoming bounce messages. Responses to the commands that send a specific message (MAIL FROM, RCPT TO, DATA) are handled as follows:

Relay response	What the platform does
Final 250 after the message is transferred in DATA	With the webhook disabled and DSN unsupported, the message is counted as delivered
250 with a webhook enabled or with DSN support	The message is not counted as delivered — the platform expects a delivery result notification via webhook or DSN
4xx codes	Soft failure: the message is retried per the sender's common Retry rules; if a soft-bounce pattern matches the response text, a soft bounce is registered. If neither a retry rule nor a pattern matched, the message is registered as undelivered
5xx codes	Hard failure: the message is registered as undelivered with no re-send; whether the event is a hard bounce or another status is determined by the response pattern

The final 250 means the relay accepted responsibility for further delivery; it does not confirm delivery to the final recipient. While the webhook is disabled and DSN is unsupported, the platform registers a delivery event right after the final 250 — such an event reflects the relay accepting the message, not delivery to the recipient.

Authorization (535) and sender (553) errors relate to the relay settings, not the recipient address: the message fails, but this does not prove the recipient address is invalid.

If no confirmation arrives

After the final 250, the message leaves the send queue. If the platform expects a notification via webhook or DSN but none arrives, no event is registered — neither a delivery nor a non-delivery appears in statistics. There is no waiting deadline: a notification is processed when it arrives, including a late one. Duplicate notifications do not create duplicate events: for the Sendsay integration, events with the same message ID, event type, and status code are ignored.

Relay webhooks

If the relay delivers statuses via webhooks, enable the Use webhook option on the SMTP relay tab and select the integration (Sendsay or Altcraft Cloud SMTP). The platform issues a webhook URL of the form /integrations/<integration>?sh=<hash> — specify the full URL, reachable from the relay over the network, in the relay's configuration. To verify that an event was accepted, check that the event appears in the campaign journal after a test send.

Handled events:

Event	Meaning
Delivery (deliv)	A code greater than zero means the message was delivered, less than zero — not delivered; the code -100020 (Sendsay) additionally registers a hard bounce
Email reply	A reply from the subscriber was received
Complaint (unsub)	A spam complaint; for Sendsay, a complaint event is registered only for the fbl and admin subtypes, other unsub subtypes are ignored

note

The set of events depends on the integration. Sendsay sends deliv, emailreply, and unsub events with numeric status codes. Altcraft Cloud SMTP sends typed events: Delivery, Bounce, TransientFailure, Expiration, AdminBounce, Feedback. In Bounce and AdminBounce events, a 5xx code registers a hard bounce, 4xx — a soft bounce.

note

With a webhook enabled, a 250 response from the relay does not confirm delivery to the final recipient: the delivery event is registered only after the webhook is received.

Incoming bounces

With the webhook disabled, the platform parses incoming bounce messages (NDR) arriving at the envelope sender's domain and matches them to messages by the identifiers in the report. With a webhook enabled, incoming bounces are ignored: the webhook remains the only status source.

Failure behavior

Failure	Behavior
Cannot establish a connection	Up to five connection attempts with pauses; after they are exhausted, the messages return to the queue and are retried per the Retry rules
TLS error (STARTTLS)	The retry runs on a new connection without TLS; if the TLS connection could not be established within five attempts, the messages fail without being sent
Authorization error (wrong credentials)	The batch messages fail with no retry attempts — check the relay's login and password

caution

A persistent authorization error is not retried: until the relay credentials are fixed, all sends from this sender will fail.

caution

If the connection drops after a message was transferred in DATA but before the final response, the relay's acceptance result remains unknown: the message either fails or returns to the queue and is sent again. In the latter case, the recipient may receive a duplicate.

Testing relay delivery

1. Send a test message and make sure the relay accepted it: the final 250 response is visible in the AKMTA SMTP responses log.
2. Check that the expected delivery or non-delivery event appeared in the platform.
3. In the received message, check the envelope sender (Return-Path), as well as SPF, DKIM, and DMARC.
4. Send a message to a deliberately nonexistent address and make sure the non-delivery is reflected in the platform — via a notification or webhook.
5. Webhook processing errors are logged in the tracking service logs.

Limitations when working through a relay

• All of the sender's traffic goes through a single relay and is accounted under the system ISP Relay: only common speed, Retry, and Lock rules apply; per-ISP rules for individual providers are not used (a single sending strategy is used instead);
• The LISP (Lock per ISP) blocking mode does not single out individual ISPs: the lock is applied to the system ISP Relay, that is, to all sending through the relay.

For the full AKMTA sender configuration, see the Email senders article; for examples of configuring specific relays — the Sendsay and Altcraft Cloud SMTP articles.