Relay Service

Overview

The Relay Service feature allows you to define a custom target mail server (or relay) instead of sending the email to the recipient domain. This feature is particularly useful in case you need to re-route messages into the infrastructure of your choice for further processing or compliance reason, like applying a digital signature managed by your own internal servers or route emails to a specific cloud service.

The Transactional Email default outbound route is to send emails to the Internet querying DNS MX record. Therefore, our Mail Transfer Agents (MTAs) send a DNS query to identify the mail servers of the recipient and establish an SMTP connection with those mail servers. With the Relay Service feature, you define a custom target mail server (or relay) instead of using the MX Record set into the recipient domain DNS.

Requirements

• Feature configured for at least one Transactional Email Account and one sender domain;

• Only one target relay can be defined by sender domain;

• This relay must be a Full Qualified Domain Name (FQDN);

• The Relay Service feature can’t be configured when the Message Signing feature is enabled for a specific sender domain.

Optional: in case you want to implement authentication via Source IP between Transactional Email MTAs (Mail Transfer Agents) and your target relay, Retarus highly recommends to set up a dedicated IP to ease the authentication process.

How to set up and use this feature?

This feature is configured at the Sender Domain L3-level, and can’t be controlled at the JobRequest level (REST APIs or SMTP adapter) at the moment. By default, a JobRequest:

• sent to the configured Account;

• and using the sender domain that has been configured;

• (optional) and using one of the configured sender address(es);

will trigger the Relay Service feature and therefore route these messages to the target relay.

When no sender address has been configured, then all JobRequests sent to the Account and using the configured sender domain are routed to the target relay.

To set up this Relay Service feature, please open a Service Request and provide:

• the Account name for which you want to set up this feature;

• the sender domain for which you want to implement this feature;

• the FQDN to which Transactional Email must route messages;

• (optional) the sender address(es) (up to 10 addresses can be configured);

• (optional) if you want Source-IP authentication, you must request a dedicated IP for that Account as well.

Tracking Points

When messages are routed to your target relay using the Relay Service feature, this server is considered by Transactional Email as the final processing step. Therefore, you can rely on the final “FINISHED” tracking point to get the information if emails have been successfully relayed and accepted by your internal server.

We can’t provide visibility about the actual delivery to the end recipient as this is the role and responsibility of your target relay.

myEAS Live Search

The information about the custom target host can be found into Live Search under the section name SMTP relay.

In case your target host is down, Transactional Email service will receive a bounce:

• in case of temporary error, there is a retry mechanism;

• in case of a permanent error, the job is considered as hard bounced

Possible values are:

• For "Delivered" cases, there will be a specific value;

• For "Hard bounced" (for example, the mailbox does not exist), you will get a "none";

• For "Soft bounced", both could be possible, "none" or a specific value (it depends on the reason why you got the soft bounce);

• For "Dropped" cases, the complete SMPT stack is not available and the value will be “n/a”

Delivered case:

Hardbounced case:

Dropped case:

Push Notifications

The information about the custom target relay can be found into the push notifications under the metadata smtp.relay.

In case your target relay is down, Transactional Email service will receive a bounce:

• in case of temporary error, there is a retry mechanism for a maximum of 48 hours;

• in case of a permanent error, the job is considered as hard bounced;

Example, below the message has been routed to “your.target.relay“ :

{
   "meta":{
      "account":"m4a_test_user",
      "customerNo":"99999",
      "tenant":"Test User", //optional
      "receivedTs":"2020-10-16T05:54:11.043Z",
      "jobId":"7e5251d9-8661-43c3-bb00-0c1caf168c3f",
      "version":"1"
   },
   "notifications":[
      {
         "meta":{
            "tag":"a813f47bca9ded6b0305885e235c073e886168b8b63eb5e99d02d00bcc7a6371",
            "mail":{
               "id":"6393ae2f-7c…-862b-880754463a38",
               "email":"recipient@sample.com",
               "from":"sender@sample.com",
               "mimeFrom":"sender@sample.com" //optional
            },
            "event":{
               "type":"DELIVERED",
               "phase":"DELIVER",   //optional
               "state":"FINISHED",  //optional
               "subType":"OK",      //optional
               "ts":"2020-10-16T05:54:18.000Z",
               "description":"mail delivered" //optional
            }
         },
         "content":{  //optional
            "mime":{  //optional
               "messageId":"<20201016-…54463a38@retarus.com>",  //optional
               "size":"884" //optional
            },
            "smtp":{  //optional
               "responseCode":"250",
               "reason":"sent (250 2.0.0 Ok: queued as 3yFnZW2mNlzPk9y)", //optional
               "relay":"your.target.relay",  //optional
               "dsn":"2.0.0",
               "transportEncryption":{  //optional
                  "requested":true,     //optional
                  "established":true,   //optional
                  "properties":{        //optional
                     "protocol":"TLS1.2", //optional
                     "cipherSuite":"“example-cipher-suite" //optional
                  }
               }
            }
         }
      }
   ]
}