SMTP Relay service description

This article intends to provide technical information on the SMTP Relay (formerly "Forward") service, to facilitate the setup and launch. Some functional aspects are mentioned for a better understanding of the flow.

📘
Recipients' data and events logs are stored for no longer than 40 days.

Service set-up

SMTP connection

The Splio customer is identified by username/password, the authorization protocol is AUTH LOGIN

Host: relay.splio.com
Protocol: SMTP with STARTTLS (TLS 1.2)
Port: 587
Username: created on request to your contact at SPLIO
Password: created on request to your contact at SPLIO

📘

The port 587 has the benefit of usually not being blocked or throttled by network operators. The port 25 remains available if necessary. The port 10587 is also available if needed.

Currently, the AUTH LOGIN command does not support appending the username directly, it must be issued on its own.

AUTH PLAIN is not supported.

Once the identifiers are communicated to the customer, the service is open only between the customer and Splio, but the first messages are not relayed until further checks are done by Splio.

The first messages are blocked until checks are ok. Then Splio notifies the customer of the real availability of the service. After this, emails are submitted to the recipients.

DNS Setup

The customer must tell Splio which sending domain(s) he intends to use, so Splio can provide guidelines for the DNS setup to be applied.

It is usually recommended to use a subdomain of the organizational domain of the brand.

This setup includes the creation or update of DNS records such as SPF, MX, tracking domain, DKIM, DMARC, Google Postmaster Tools…

Optional headers

The Splio SMTP Relay behavior and reports can be adjusted through additional message headers.

These headers start with X-Splio-. They must be placed each on a different line, at the beginning of the line.

The first 2 following headers below allow post-campaign report splits: there will be one separate campaign report per day for each channel and for each campaign identified. With no such headers, there will be only one campaign report per day. It means that using the parameter X-splio-ref allows you to aggregate your campaign according to your needs.

Do not use timestamps or unique IDs in those headers, as that would create a separate campaign for each email sent.

X-Splio-ref: campaign identifier

Example: X-Splio-ref: 20191129_blackfriday_FR

X-Splio-canal: channel

Example: X-Splio-canal: Welcome_emails_FR

If not provided, the id of the SMTP Relay account will appear in the campaign reports, in lieu of the channel.

X-Splio-extid: recipient id

Example: X-Splio-extid: 587426

X-Splio-pool: pool name

Example: X-Splio-pool: wp52

The list of available pools must have been defined beforehand, and set by Splio's team.

X-Splio-filteroff: Y

Optional bypass of the blacklist. This option is dedicated to transactional messages such as e-commerce order confirmation, logistic information, etc... It is not supposed to be used in a marketing campaign. Using this option implies a strong integration of Unsubscribes and spam complaint management on the customer side. The option is disabled by default and requires a specific setting on Splio’s side.

X-Splio-notracking: Y

If this header is present, with a value such as Y, yes, true, or 1, the tracking will be entirely disabled for the given message (no link tracking: no click tracking).

Additional headers

These headers are not Splio-specific, but Splio encourages their use.

Expires: date, time, timezone

Example: Expires: Thu, 6 Apr 2023 12:21:57 +0200

As described in the draft https://datatracker.ietf.org/doc/html/draft-billon-expires-09, the value provided indicates when a message is not useful anymore and could be safely deleted. This can help unclutter the recipients' mailbox, and ultimately reduce the carbon footprint of mailbox hosting.

Temporary marketing offers or pieces of news could see a more or less short period, while password reset emails should have a very short one, and invoices or order confirmations should never expire. Except for these last cases, most bulk emails don't need to stay valid for more than 90 days after being delivered.

The somewhat confusing date format is the same as for other existing headers, notably the Date: header.