Duties of Cooperation

Introduction

Retarus is Certified Senders Alliance (“CSA”) certified. The cooperation duties described herein reflect the current CSA requirements. The CSA reserves the right to adapt their requirements at any time, in which case Retarus will notify Customer accordingly. Customer agrees to comply with any such changes.

Email design

Each email sent must contain easily identifiable legal details that comply with the applicable statutory requirements. Additionally, the following applies to emails with advertising/promotional/marketing content:

• The initiator of such emails must be clearly recognizable;

• Neither the sender nor the commercial nature of the email may be disguised or concealed in the header and/or subject line of the email. An email is considered disguised or concealed if the header and subject line are intentionally designed in such a way that the recipient receives no or merely misleading information as to the sender's actual identity or the commercial nature of the message before reading the content.

Network

• The delivery of emails to the Retarus Transactional Email service must take place via Security Layer (SSL/TLS (Transport Layer Security) – opportunistic/enforced) from the Customer. Retarus uses for sending emails to the addressee Transport Layer Security (TLS) while using CSA IP-addresses;

• For the connection between Customer infrastructure and Retarus infrastructure, Retarus recommends setting a connection timeout value of 30 seconds. This value suits well in infrastructures where there are several hops, such as a public Internet connection for Software as a Service (SaaS) services. Of course, this value can be re-evaluated according to the Customer’s context;

• Sender addresses must be registered and be included in the service administration. The sender address must be able to receive emails (valid DNS MX record). The sender domain must also have a valid DNS A-Record. Role-based sender addresses (e.g. abuse@ or postmaster@) are not permitted;

Email authentication

SPF

• The Sender Policy Framework is a means of sender verification designed to make sender address forgery or impersonation more difficult. This allows the receiving server to verify if the system sending on behalf of a domain is in fact authorized to send messages with the sender domain in question. To authorize the Retarus relays to send messages on your behalf, add the following SPF record to your DNS:

v=spf1 include:_spf.general.transactional-mail-a.com ~all 

• For the 'MAIL FROM' address specified in the SMTP communication between email servers, an SPF-From Record must be entered, thereby allowing an SPF test to be carried out on the recipient side. The SPF Record must end in "-all" or "∼all". In case the necessary entries are not made on the Customer's side within ten (10) business days, the re-verification efforts and expenses will be charged in accordance with Retarus’ agreed hourly rates.

DKIM

The use of the DKIM (DomainKeys Identified Mail) method is mandatory. For each sender domain registered with Retarus on behalf of the Customer, the Customer must store a corresponding DKIM key in their DNS (generated and provided by Retarus). If the Customer fails to make the necessary entries within ten (10) business days, the reverification will be billed in accordance with Retarus’ agreed hourly rates.

DMARC

DMARC lets Customer tell receiving servers what to do with messages from the Customer's domain that don’t pass SPF or DKIM. The authenticating domain must be the same domain that's in the message From: header. It is the responsibility of the Customer to publish a DMARC record within the DNS zone for each sender domain. If there is no DMARC record, create one with a “none” tag policy as below:

v=DMARC1; p=none; rua=mailto:rua@example.com; ruf=mailto:ruf@example.com; fo=1

List management

• The Customer must immediately delete email addresses from the respective mailing lists if non-existence of the address is discovered upon transmission, and at the latest if three hard bounces have occurred. The total hard bounce rate per ISP shall generally not exceed 1.0%. Role-based recipient addresses (e.g. postmaster@, abuse@) will be rejected/discarded.

• The Customer must delete email addresses from the respective mailing lists if the recipient categorizes an email as spam and reports this (complaint) or revokes consent to receiving emails.

• The Customer must set up an abuse email address for the reporting of the abuse of email addresses for the addresses of the emails and monitor it. The abuse email address can be configured for example as abuse@domain.

Promotional emails

• For promotional emails (such as newsletter, announcements, products updates, so mainly list-based mailings), the recipient must be made aware of the option to unsubscribe or opt out from receiving emails at any time. In general, opting out/unsubscribing from emails must be easily doable for the recipient, i.e. without entering access data (e.g. login or password).

• The 'List unsubscribe' header is required for list-based mailings, and has to be inserted with a 'POST HTTPS'-link including a 'One-click unsubscribe' feature (RFC 8058). The link provided must trigger a direct one-click unsubscription at least at list level. The sender may send unsubscribe confirmation emails.

• Using the „list-unsubscribe-Post“-Header requires a valid URL address which can receive and process such POST requests.

List-Unsubscribe:   <mailto:listrequest@example.com?subject=unsubscribe>,
                    <https://example.com/unsubscribe.html?opaque=123456789>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

• Exceptions to these obligations may apply if it is not required or possible to unsubscribe as described above due to the configuration of the Service and the associated transmission of automated emails.

Transactional emails

In non-list-based mailings (such as order confirmation, shipping follow up, password reset email,...), the 'List-help' header shall be set as an alternative to the 'List-unsubscribe' header. The 'List help' header (RFC 2369) shall include at least one 'mail-to' address or a HTTP/S link. HTTP links (without Security Layer) are not permitted. Both the use of the "mailto" address and the HTTP/S link must enable the recipient to receive information about the reason why the email was sent to them and why unsubscribing at the list level is not possible.