Dialog Insight takes care all of these configurations, click here to see how.

This article presents the following:

  • Email Authentication
  • DMARC Authentication Validation
  • Link Customization

Authentication

Email authentication is what differentiates legitimate emails from any spam that would use your domain. A good configuration proves to your recipients that your emails are legitimate and helps to block emails that are not.

Good authentication also allows you to establish your reputation as a sender, helps increase your delivery rates, reduces the risk of having your emails filtered and reported as spam, and increases your recipients' trust in your electronic communications.

Inversely, not authenticating your emails exposes you to risks. If a receiving server cannot prove that a server is entitled to send emails on your behalf, then the following consequences might arise:

  • It will be more difficult to gain, and maintain, a good sender reputation, and your reputation can be easily damaged by a spam campaign that would aim at the reputation of your domain;
  • Your recipients could be informed that the emails “do not seem to come from your domains”, or that the source of the email cannot be confirmed;
  • Your domains could easily be used for phishing campaigns since it is not possible to distinguish legitimate from illegitimate emails.

There are two ways to authenticate emails:

  • By DKIM signature
  • By SPF protocol (if you use dedicated IP addresses)

You must know that even if the DKIM signature and the SPF protocol help to prove that an email is legitimate, their absence does not however prove that they are not legitimate.

DKIM signature

The DKIM signature (Domain Keys Identified Mail) is an Internet standard that is almost universally supported by major email providers and anti-spam systems.

The DKIM encryption authentication method validates that the email is authorized by the the domain owner of the sending domain by adding a digital signature to the email

This signature is based on an asymmetric cryptography:

  • The signee (in this case, Dialog Insight) has the private part of the key, which is used to sign emails.
  • The public part of the key is indicated in the DNS of the domain for which the emails are signed.

When receiving an email, the mail server that finds a signature will look in the DNS servers to retrieve the public key and use it to validate the signature.

When the signature is validated, it indicates 2 things:

  1. That the email has been signed by a server (Dialog Insight) that has the private key. It is therefore authorized to be signed by the server owner (your company) since the existence of the public key in your DNS indicates that you have accepted that we sign on your behalf;
  2. That the email was not changed while in transit. If it had been changed, the signature would no longer be valid.

The DKIM signature works as follows:

  • A public key of several alphanumeric characters is inserted in the configurations of your domain.
  • Dialog Insight has the private key. The domain that receives the email comes from our servers, but since we have the private key, the email that comes from Dialog Insight is authenticated.

A DKIM public key looks like this:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCA"
"QEAz4XrZ/2W5t98RXqmss6SGdIezyrnUveUx0dY5ooktaYPIsxnj3cnoCh8"
"luPmHw/O1m8P/TEkQhGL8uqbegYiEO68ZeZIhhRhPk2rWGl4Ade9ROilrNK"
"GF+8EQ/pJsVPxAeLUSha3v+tgmgWuTkebVEACGQlCKWpuamcXvR/y2TTxSt"
"gOYi1QN0+VP89FcV7fn6zreI7TWiQ6kXLjCXW91RAml9ZlpL9ibTnvI1vOt"
"zWl0MhVg6E6JXjU8dfQL0jy9i0R75Glf9PgeD9fm6bGz1EY5H+T+3YjeFPm"
"eY/Zr2h3IBKzZ5TtE0n+FyypeiLH8zKtxHPkYuV3dnSdYqh6IwIDAQAB"

For more information on DKIM: http://www.dkim.org/

SPF Protocol

The SPF protocol is automatically used by Dialog Insight, who uses its own domains for this specific purpose and publishes the proper records
for these domains. You therefore have no configuration to perform to comply with the SPF protocol, unless you use a dedicated IP address
when sending emails. In such a case, we will provide you with the required configuration to implement.

SPF (acronym for Sender Policy Framework) is a protocol that determines whether an email comes from a server authorized to use a particular domain name to deliver emails, by comparing its IP address with a list of addresses published in the DNS of the domain of the SMTP envelope of the email.

The following diagram provides a visual overview of how it works.

The SMTP envelope is like the return address on a postal envelope: it is an address that is potentially different from the address indicated in the header of the letter contained in the envelope.

The configuration of the SPF protocol is optional since Dialog Insight supports the default SPF if you send from our shared addresses.

If you use dedicated IP addresses, or if you want the emails sent to our shared addresses to be more directly linked to your domain for reputation management, then our technical team can help you configure the SPF.

As for DKIM, it will then be necessary to send our technical team the list of sending domains you use and DNS entries will be provided to you in return. Once the entries have been made and validated, the configuration will be activated by our team.

DMARC Authentication Validation

The implementation of a DMARC (Domain-based Message Authentication, Reporting and Conformance) policy allows a sender to indicate that his emails are protected by DKIM and/or SPF and tells receiving servers what should be done when receiving an unauthenticated email - for example, reject the email or report it as spam.

DMARC eliminates uncertainty at reception: although the SPF protocol and DKIM signature help to prove that an email is legitimate, their absence or failure does not prove the opposite.

Your DMARC policy addresses this uncertainty by allowing you to explicitly indicate what should be done with an unauthenticated email.

 PrerequisiteTo implement a secure DMARC policy that rejects emails that fail authentication, it is necessary that all emails are authenticated correctly.

How to

The site https://dmarc.org contains all the resources necessary to enable your team to understand DMARC, prepare an appropriate policy, and test it.

Some more technical tools are also listed in this section: https://dmarc.org/resources/deployment-tools/

Link Customization

On the platform, these customized tracking links are also sometimes called "Custom Trackers," but they can be for more then tracking. By default, links interacting with the platform use the platform's domain.

Tracking Clicks

When you use links in a communication and have activated link tracking, Dialog Insight records clicks by replacing your link with a pseudo-link which points to the platform and then redirects to your link. This means that all traffic from a message will first go through the Dialog Insight environment. This pseudo-link uses the custom domain when displayed on hover over the link. 

Other

Tracking clicks is not the only use for custom trackers, functions like email Web Version, forms hosted on Dialog Insight and landing pages also use these Custom Domains to make links.

Why use a custom domain?

Basically, these replacements are done using a domain name associated to the platform (example: app.dialoginsight.com).

However, your contacts may find these links suspicious: why does a link in a communication lead to "app.dialoginsight.com", when they don't know about this site and certainly do not associate it with your company?

To give your recipients confidence and reduce possible phishing complaints, it is important to set up a domain name that will be used to customize tracking links.