While you as an admin are familiar with Zelo, it can be something else to build up trust within your organization when important messages are sent from a-adress@zelo.app. Your colleagues might not recognize the address as they yet have to get a personal relation to this and might discard the email as yet another spam message.

But what if the messages came from your name@your_organization_domain? The same colleagues would by the first glance of the message recognize the sender, and likely trust that whatever the content it would be of relevance.
​

Therefore, Zelo supports domain authentication (DA) to allow for using custom domains when sending emails from the system. DA lets Zelo send messages on behalf of other domains (@your_organization_domain), while in practice the receiver of your messages will only see your chosen domain. This helps build trust within your organization and increases the effectiveness of your communication.

CNAME (Canonical Name Record) is a form of alias used primarily to archive two features:

CNAME is of importance from a display perspective and also a technical perspective. It is required for DA to fully work in Zelo. When successfully set up, it would look like the following:

The table is read from left to right, meaning subdomain.yourdomain.com. is a CNAME, or alias, while zelo.com is the actual domain.
​

DNS (Domain Name System) is the common naming system for domains on the internet. In short, it is what makes it so that we can write google.com instead of an IP address when we want to find answers to our questions.
​

When Zelo mentions DNS, it is in this context meant the name of the domain you want Zelo to send messages on behalf for. Note that a DNS name might be different from the DNS provider’s name. For example, if we look at the Gmail service; The DNS name is Gmail, while the DNS provider’s name is Google.

There is more depth to both of these features, but for the sake of readability, these are kept short. Further reading material for those interested:

To start setting up DA, navigate to the settings menu in the top bar -> Email in the left bar.

By clicking Open within Your Domains, you are provided with the information needed to set up the DA. As Zelo wants to send on behalf of another domain, the information on this page has to be added to the DNS of the custom domain to verify Zelo’s requests later.

Depending on the provider, there will be a bit of approval time. The Status column keeps track of this process, and updates automatically when approved by the provider.
​

You can at any time delete the requested domain, by clicking Delete button in this menu.

You can have as many domains as you please, same for requests.

Depending on the provider, some will add your domain to your new DNS record values automatically, resulting in a CNAME entry containing too much information to fails authentication, e.g: name123.yourdomain.com.yourdomain.com.
​

In the event of failing to validate the requests, make sure to check the CNAME and whether this practice applies to your provider.
​

Below is an example of the CNAME values under the HOST column as they are displayed in Zelo and how you will need to enter them into the DNS management of your provider. Note that entries in the VALUES table do not need to be changed.

In the image below we have attached an example of the information that would be needed for setting up a Sendgrid DA - although values visible would be different in your application.

If you are unsure of the information related to your organization’s domain, Zelo provides an option to send the DA request with all the necessary data by mail to an IT department or technical support person. Simply click the Send to coworker tab, followed by a valid email address to this entity.

When a domain has been successfully set up and authenticated, it can be selected for use. You can at any time switch between the different domains depending on the need. Users receiving messages after the change of domain will see the domain used at the time of sending.