Transactional Emails, like order confirmations, delivery updates and utility bills can benefit from enhanced delivery rates, personalisation and tracking tools within the platform. They are recorded within your configured Customer Space.
Transactional Emails can be sent by delivering your complete email through our Transactional SMTP server, or by sending the component parts of your email using the Transactional API.
Platform Configuration
- The Transactional Email feature needs to be enabled for your Customer Space. Please contact your account manager to request this feature.
- A customer-level user must be set up for your website or application; it cannot be an agency-level user. The user must have the Authoriser role.
- Supply the From Address(es) that will be used for Transactional Emails.
IP assignment
It may be beneficial to use separate IP address/mail queue for Transactional Email delivery, to keep it segregated from Marketing Email delivery.
Tracking & Delivery Options
By default, Transactional Emails will have open tracking and click-through tracking, and will not send to recipients listed on the Global Bounce List. Recipients listed on the Global Unsubscribe List will be eligible to receive emails (as Transactional Emails are typically not marketing messages).
This default configuration can be adjusted for all Transactional Emails, or for a specific from address. It's also possible to override the default configuration per email for SMTP sends using an email header, or for API sends using the options.
Suppress opt-outs
If sending marketing messages using the Transactional Email service, you must specify the option to exclude recipients on the Global Unsubscribe List.
Reporting
Aggregate reporting on Transactional Emails can be filtered by send date and from address, and optionally by tags.
Tags
Tags can be added to SMTP sends using an email header, or to API sends using the options.
Multiple tags can be added, allowing filtering of reports by one or more tags. For example, adding the tags order, confirmation, guest would allow a user to report on emails that were to guests; or all order emails; or all order confirmation emails; or any other combination.
Unique Identifier
Individual per-send reports available through the interface, Data Export Quick Transactional API and Webhooks all have an associated unique send identifier. This identifier is returned from every Transactional SMTP and Transactional API request.
It is also possible to provide your own identifier in the email's Message-Id. This MUST be fewer than 120 characters, and follow the format requirements described in RFC 5322 §3.6.4.
Attachments
Transactional Emails sent via SMTP can be configured to support attachments. This may be used to send, for example, PDF statements to customers.
One email credit in Maxemail allows a message up to 100KB in size, so if the attachment(s) increase the size of the email beyond this, further credits will be used when the email is sent. For example, an email totalling 150KB would use 2 credits.
Attachment best practice
For best practice, it's better to avoid sending attachments:
- When encoded into an email, attachments will use roughly 125% of their true size
- Maxemail may use more credits to send emails with attachments
- Attachments slows the delivery of your email, as the additional size needs to be delivered to the ISP
- Having attachments on your messages forces the recipient to download them, which can be a poor experience when the majority of opens are on mobile devices and potentially using mobile data plans
- Inline images (as attachments) are better served from a URL which is then only accessed when the recipient opens the email, rather than having to be downloaded to their mailbox
- Attached documents are better served from a URL (for public information) or a secure account area for confidential data, rather than sending by email, which is inherently insecure