Using transactional email


How transactional email works
   » Sending via SMTP
   » Sending via our API
How to create a transactional email user (for SMTP)
Creating a transactional email
Usage limits
Managing 'from' addresses and replies
Turning tracking on and off


Our transactional email function enables you to send your administrative and operational-based email (in short, your non-marketing email) to contacts via SMTP, or via our API, allowing you to then manage and track your transactional email using the platform.  

What do you mean by 'transactional email'?

If you're not familiar with the term, it is best described as the email you send to a single contact (hence non-marketing email) as a result of an action triggered by that contact and specific to that contact. For instance, transactional email can be automated notifications such as:

  • welcome emails
  • password reminders/resets
  • order confirmations
  • shipping notifications

Once enabled, 'Transactional email' will be available from the dropdown menu at the very top of the screen (it will probably read Email if you haven't accessed any of the other areas of the application after logging in):


When clicking on Transactional email for the first time, you will be presented with a list of five tasks to complete to get you sending your first transactional email:


Click on each task to complete them one by one.

How transactional email works

Transactional email can be sent via SMTP, or it can be sent via our API.

If you want to send via SMTP you will need to create a transactional email user (more on creating these credentials below).

If you want to send via our API, you will need to create an API user (if you don't have one already). 

Sending via SMTP

To send via SMTP (Simple Mail Transfer Protocol), you need to connect to:

  • if you have an account belonging to region 1 (Europe)
  • if you have an account belonging to region 2 (North America)
  • if you have an account belonging to region 3 (Asia Pacific)

You can either connect to ports 25, 587, or 2525, provided you support secure sending via the STARTTLS command, or you can connect securely to port 465.

Sending via our API

To send via our API, you'll require the REST operation Send transactional email or the SOAP method SendTransactionalEmail.

How to create a transactional email user (for SMTP)

You need to create a separate transactional email user to send via SMTP. This is distinct from an API user.

There are two ways to create a transactional email user:

1. Either click on Transactional email > Settings > Credentials and then click on New user to enter the details. 


2. Select Access from the settings menu that appears when clicking the person-and-cog icon in the bottom left corner of the screen, select the Transactional email users tab and then click on New user to enter the details. 


These will be your credentials for sending transactional email via SMTP.


Creating a transactional email

You can create a transactional email as a triggered campaign in EasyEditor. This allows you to design and brand your transactional email.

The campaign ID can then be given to your developers to either send it via SMTP or via our API using:

Alternatively, you can create your transactional email content elsewhere and pass the HTML to your developers to send it in its entirety via SMTP or via our API using:

Usage limits

If you think your transactional email usage is going to be a non-trivial amount - for instance, more than a few tens of thousands a day - then please contact us directly about your plans, so we can set appropriate limits for your account.

You can add a maximum of 100 contacts to the 'To'/'Cc'/'Bcc' sections of a transactional email, and the send will only be counted as one send despite the numerous recipients. Sending transactional email via the API doesn't count towards your API limit/usage.


Attachments are supported in our SMTP version only and have a limit of 20MB.

Attachments aren't supported, however, if you're using SMTP to send a transactional email as a triggered campaign.

Sending to unsubscribed/suppressed contacts

You can send transactional email to your unsubscribed or non-mandatorily suppressed contacts.

However, you can't send transactional email to any email addresses that are on the GSL (Global Suppression List).  


The dashboard provides both an overview, including a graph, as well as the detail on your sent transactional emails.

The period that the dashboard covers can be changed by clicking on Date range in the top right, with the options ranging from today, yesterday, last seven days, last week, this month, last month, last 30 days, all time, or you can enter a custom date range. 


At the very top of the dashboard, you're provided with the total amount of transactional emails sent in the period, the amount delivered, the total amount of opens, and the total amount of clicks for links within the transactional emails.

The graph provides a visual representation of similar information per day over the period, with the different coloured lines charting emails delivered, opens, clicks and transactional email bounces.

Underneath the graph, you're provided with the detail of each transactional email sent. This covers the date and time it was sent, the email address of the contact it was sent to, the email's subject line, the total opens and clicks the email received, and whether it was successfully delivered or not.

Clicking on the Download icon will download the email to your computer so you can open it and view exactly what was sent. Please note, however, that transactional email is retained for 30 days, after which you will no longer be able to download it.

You can delete the details on sent transactional emails by selecting the records and clicking Delete. This will remove the email addresses you've sent to - but opens and clicks data will be kept.

A note on GDPR compliance

When a contact wants you to remove them from your system, they're exercising their 'right to be forgotten'. This delete action allows you to comply with this request.

You can filter on the report by clicking on Show successes only, which will show delivered emails, or by clicking on Show failures, which will display bounced emails.

You can search the report for a contact's name.

You can export the contents of the report into a downloadable Excel file by clicking on Export, located to the top right.

Click on Display to change the amount of transactional emails that are shown on one page, as well as adding or hiding visible columns in the report.


This is where you can create a transactional email user.

Managing 'from' addresses and replies

You can manage your 'from' addresses in Settings > From addresses.


You will want to set the unknown mail forward for your default 'from' address to cater for replies.

You can use any of your 'from' addresses to send from. However, if you send from a 'from' address that isn't on this list then the system will select the one set as the default. This applies to transactional mail sent from both the API and SMTP.

For further general information on 'from' addresses and reply management, you may be interested to read the following articles:

Turning tracking on and off

By default, we track opens, clicks and bounces for transactional emails automatically. If you wish to disable any of these features however, you can do so in Settings > Tracking

Simply uncheck the 'Active' box for the appropriate type of tracking.


After doing so, this data will no longer be tracked or reported to you.


We wouldn't expect you to receive many complaints at all for transactional email. However, if a contact does click on a 'report spam' button in their email software in response to a transactional email you've sent them, they will be listed under Settings > Complaints. This helps you to know about it and to be able to do something about it, in order to protect your and our reputation and deliverability.

The page provides the email address of the complainer and the date and time of the send.

You can search the report for a contact's name.

Click on Display to change the number of transactional emails that are shown on one page, as well as adding or hiding visible columns in the report.


Note: Contacts who complain are not put on a suppression list at all. Therefore it is your responsibility to regularly check for any complainers here and ensure you deal with any such complaints promptly and appropriately.

Have more questions? Submit a request


  • Avatar


    What does this mean? This error type isn't covered by your error types documentation.

    It sounds like it's saying that dynamic content blocks aren't supported by the tool? That would be quite an omission, considering it's the best bit of the EasyEditor! Is this coming in a later release?

    If I choose an email that doesn't use dynamic content, it sends. One issue though, it ignores default personalisation values, so the received email contains "@SOMETHING@" which obviously doesn't look very good!

  • Avatar

    Hi Matt,

    Thanks for your questions. To clarify, transactional email doesn't make use of contact data at all, and, as dynamic content relies upon the use of contact data, transactional email doesn't therefore support dynamic content, no.

    There are also a few other transactional email restrictions with regards to EasyEditor features, which are outlined in this article -

    Content that changes per sender will need to be sent using transactional email's personalisation placeholders instead - As transactional email doesn't make use of contact data, there's no crossover with EasyEditor's personalisation function as a result and that's why you're not seeing a default contact data field value being retrieved.

    Apologies that you couldn't find ERROR_CAMPAIGN_CONTAINS_UNSUPPORTED_BLOCKS listed in the error response types documentation at the time you were looking for it. This was an oversight and has now been added.

    Furthermore, you may be interested in this article on our developer hub, if you haven't seen it already -

    Anyway, I hope this helps. Please let me know if you have any further questions at all.

  • Avatar

    Would you use transactional e-mail for example sending a confirmation if somebody registered to an event or a whitepaper? Or would you really just use it account related?

  • Avatar

    Hey Wilco!

    Thanks for your question. We would recommend using the transactional email option for non-marketing purposes, so the event registration would fit with our recommendation. As for the whitepaper, this seems like more of a marketing need, and may fit best in a different campaign method, perhaps email? It really is a matter of preference and what works best for you at the end of the day. :-)

    Hope this helps!