Email authentication and encryption

Online abuse may occur in many ways, this includes spoofing of sender domains or email content and the sending of spam messages on behalf of someone else. In order to prevent this from happening, Episerver applies a number of email authentication and encryption techniques.

Email authentication

A major aspect of the email delivery is the email authentication. ISPsStands for "internet service provider" and most email servers, in general, decide the credibility and authenticity of your email based on the email security policies that you have in place. Furthermore, email authentication is a technical method for identifying spam and verifying that an email is actually sent by the sender, which refers to technical standards. ISPs and organisations use these technical standards to block harmful emails such as phishing and spam.

IP-based authentication

Episerver adheres to email technical standards to ensure we provide the utmost delivery of emails, this includes the authentication of our sending IP infrastructure. Our authentication standards are intended to improve security and trust when sending emails using the Simple Mail Transfer Protocol (SMTP).

Reverse DNS (rDNS or PTR)

The Reverse DNS record, also called PTR record, resolves an IP address to a host name. It adds tracing to the origin of an email and thus, credibility to an outbound email server. If the Reverse DNS lookup returns a ‘no domain associated’, the email will likely be filtered, bounced or deleted by the receiving ISP.

Domain-based authentication

To help keep deliverability at its best, Episerver requires that each sending domain is configured to enable Episerver to send verified messages on behalf of your chosen domain. Records are added to your DNS managed by your IT administrator.

Sender Policy Framework (SPF)

The SPF record prevents email spam by recognising email spoofing. The domain published in the “include” record contains all Episerver sending IP ranges. Confirming the sender's IP addresses, SPF enables the domains administrators to determine which hosts are permitted to send emails on behalf of the given domain.

The SPF record is created as a TXT record on the technical return path domain like t.example.com.

Mandatory Episerver SPF record

Type: TXT
Value: v=spf1 include:spf.srv2.de -all

DomainKeys Identified Mail (DKIM)

DKIM utilises the information published by the domain proprietor. The information permits the accepting server to check if the email message was sent by the proprietor of the domain. Using a digital signature, the receiver also verifies that the message was not changed during transmission.

For digitally signing a message, two keys are necessary. A private key that is stored in our infrastructure and signs outgoing messages, and a public key that is published in the DNS settings of a sender domain to be used. The domain of the Episerver DKIM record contains this public key.

The DKIM record is set up as a CNAME record on both your technical return path like t.example.com and visible sender domain example.com.

Mandatory Episerver DKIM record:

Type: CNAME
Value: dkim.srv2.de

Domain-Based Authentication Reporting and Conformance (DMARC)

The DMARC record tells the receiving server which email authentication methods were used by the sender, and what an ISP should do with a message if it fails those authentication methods.

Possible DMARC policies:

• p=reject tells the receiver to reject an email that cannot authenticate with SPF and DKIM (Recommended)
• p=quarantine tells the receiver to quarantine an email that cannot authenticate with SPF and DKIM
• p=none tells the receiver to apply no special policy to an email that cannot authenticate with SPF and DKIM

Using the reject policy, emails that an unauthorized third party tries to send on your behalf as part of a spam attack would simply be blocked by the ISP. Furthermore, DMARC allows a sender to set up a reporting mechanism. Like that you will be notified each time an authentication failure and potential abuse of your domain is taking place.

The DMARC record is stored as TXT record in a sub domain of your visible sender domain named _dmarc.

Example domain: _dmarc.example.com

Example DMARC record: v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected]

Brand Indicators for Message Identification (BIMI)

BIMI uses a text record which is stored on your DNS server and works together with DMARC to indicate to participating email clients that you are the true sender. The difference between BIMI and other authentication methods is that it uses front end visualisation by having the email provider show your branded logo within the users inbox. When a message is sent, the recipients ISP will look for the BIMI text file. When the ISP has successfully located the file for verification, your company’s logo is shown in the recipient’s inbox. Currently participating mailbox providers include Gmail, Comcast, and Verizon (Yahoo, AOL, etc.).

A BIMI setup currently has the following requirements:

• DMARC record with either reject or quarantine policy
• Logo to be displayed as .svg file (Scalable Vector Graphic)

The BIMI record is stored as TXT record in a sub domain named _bimi. Furthermore, the domain starts with the BIMI selector, for now this is limited to the value default.

Example domain: default._bimi.example.com

Example BIMI record: v=BIMI1; l=https//www.example.com/logo.svg; a=;

Email encryption

Encryption is a security mechanism for converting information into code in order to prevent access to this information through unauthorized third parties. It is also used to protect data in transit. To protect it, the information itself and/or the transport of it are converted into a ciphertext and only authorized parties will be able to translate it back into plain, readable information. This is also how email encryption works.

Transport Layer Security (TLS)

Transport Layer Security (TLS) is the upgrade of Secure Sockets Layer (SSL), a protocol that used to communicate securely over computer networks. TLS Record Protocol secures a connection security, then using TLS Handshake, the protocol authenticates both sending and receiving servers. This prevents snooping during message transmission, protecting the content from being read by unauthorized third parties.

Based on the TLS protocol, there is the STARTTLS email protocol command, that tells the receiving server that for the transmission of the email an existing insecure connection shall be turned into a secure one.

With the opportunistic TLS mechanism that Episerver is using, the recipient server is asked during transmission if it is able to process TLS encrypted messages and if the answer is yes, then the email gets sent using TLS encryption. If it’s not possible, the email is sent without encryption. Episerver uses TLS version 1.2 by default as it offers the strongest encryption, unless it is necessary to use a lower version in specific cases.

Digital signature

Using DKIM, you already have one digital signature mechanism in place. DKIM signatures are applied by Episerver’s sending server and verified by the receiving server of the ISPs. They guarantee the authenticity of your sending domain.

Additionally, it is possible to also sign emails in order to verify the actual sender and not only the domain. To do this, you can set up an S/MIME certificate that will then be visible to and verified by your recipients.

Secure/Multipurpose Internet Mail Extensions (S/MIME)

Secure multipurpose internet mail extension is an email signing protocol used to improve email signing, by enabling you to prove the actual sender of an email through a timestamped digital signature and to encrypt and decrypt the content of their emails. S/MIME helps ensure that files stay authentic and protected when sending between networks.

Remark: Digital signatures only ensure data integrity and do not apply to confidentiality. Emails protected with a digital signature are still sent as plain text. Message encryption of the S/MIME standard is not supported.

See Sending S/MIME-signed emails.