SMTP Relay service description
This document intends to provide technical information on SMTP Relay (formerly "Forward") service, in order to facilitate the set up 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 to usually not be 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 reports splits: there will be one separated 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. Do not use timestamp 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
The recipient IDs would appear in campaign data.
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 suppression list. 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
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 uncluttering 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 time span, while password reset emails should have a very short one, and invoices or order confirmations should never expire. Excepted for these last cases, most bulk emails don't need to stay valid more than 90 days after being delivered.
The somewhat confusing date format is the same as for other existing headers, notably the Date: header.