Adding a verified domain to your Agillic instance boosts the reputation and deliverability of the emails you send from the domain. It is not required to use a verified domain for your Agillic sendouts, but it is recommended as it can help secure the deliverability of your emails as well as the brand value of the sender domain.
Please note that if you use the transactional email channel you must enable domain validation but is recommended in all cases.
- Introduction to the Domain Setup in Agillic
- Setting up a Verified Domain
- Brands
- Domain Based Unsubscribe
- Best Practice on Domain Based Unsubscribe
- Getting Started
- Things to Consider Before Enabling Domain-Based Unsubscribe:
- What Happens After Enabling Domain-Based Unsubscribe?
- Examples
- How to Set Up Domain-Based Unsubscribe
- The EMAIL_STATUS One-To-Many Table vs. Standard Unsubscribe
- Creating Conditions Based on Domain Based
Introduction to the Domain Setup in Agillic
In order to have the most flexibility as well as control over your deliverability and brand value of your sender domains, Agillic allows you to setup custom domains in the interface. Here, you can create as many domains as you would like to use to send from in Agillic. Each domain consists of two domain fields. The from domain will be the sender domain for the emails you set up in Agillic and the link domain will be the corresponding web domain if you link to an Agillic landing page or resource from Agillic.
When you use the verified domain setup in Agillic, the only requirement is that Agillic can take "ownership" of the domains by having you set up two CNAME records and a TXT records on your DNS. This means that if there's already an A record set on the domain, you're not able to use the domain in Agillic as you then cannot successfully point to our CNAME records.
Setting up a Verified Domain
Setting up a verified domain in Agillic is a multi-step process, as outlined below:
- Select your domain.
- Set up your domain in Agillic.
- Verify your domain by making DNS changes.
- Acquire and send the domain certificate and private key to Agillic Support or Contact Agillic Support to have 'Let's Encrypt' enabled.
- Verify that all your emails use the new validated domain.
How to Select your Domain
The first step is to select one or more domains that you want to set up. We recommend choosing a subdomain under an existing domain you have. We also recommend using a new subdomain which you're not using for something else.
Part of setting up a verified domain in Agillic requires all web and email traffic to point to Agillic. For this reason, you should not use any active subdomains as this will shut down any current email or website system you may have enabled. You should also avoid having subdomains that contain the word 'agillic'.
If your main domain is agillicandy.com, valid subdomains could be:
- web.agilliccandy.com
- dialogue.agilliccandy.com
- marketing.agilliccandy.com
- contact.agilliccandy.com
Please note, if you intended to use a verified domain for sending transactional emails, it mustn't have been used before for non-transactional emails.
In special cases, it's possible to use a domain you also use for other purposes. This could, for example, be the main domain or a domain used to send other communications not sent from Agillic. However, validating and using this type of domain isn't recommended as the reputation of the domain will be shared across multiple systems.
Agillic doesn't recommend selecting a campaign domain either. That is when you use a standalone domain created with the sole purpose of Agillic communications such as agillicnews.com. From a reputation point of view, it detaches your general mail reputation from your campaign domain, meaning that all email service providers like Gmail have to get to know your domain from scratch. It also makes it easier for spammers and the like to abuse your customers as it will be easy for spammers to buy similar domains. As an example, they could buy agilliccommunications.com to spoof your customers with.
How to Set up your Domain(s)
When setting up your domains, you will need to:
- Log in to the Staging or Production environment.
- Open the Administration module.
- Open the 'Domains' subsection under the 'System Settings' section.
- Fill in your subdomain in both the 'From: domain name' field and the 'Link domain name' field.
- Click the plus icon next to the entry.
- Repeat steps 3-4 for each subdomain you want to set up.
Now, you've added your domains and should see a red 'Failed' label next to the entry. This indicates that the domain name is not yet verified.
The Candy instance where two subdomains have been fully verified and one is still missing to have DNS records and certificate set
How to Verify your Domain
Once the domain is set up, you will need to make some DNS changes for the domain to point correctly to Agillic.
- Click the 'i' icon for your domain entry.
- A pop-up will appear. Note the DNS records which have a red cross next to them. These are the DNS records you need to set up (CNAME, DKIM, and TXT records.)
If there are no DNS records shown, you may already have DNS records for the selected domain. In this case, you should check if the subdomain is being used. In case of an old DNS record for the subdomain, you will need to remove the old DNS records, before you can see the records to be set from Agillic.
Once you've set up these DNS records in your own domain management system and are waiting for the caching period to pass, you should see a green checkmark for these records. The verification label for the domain name will still show 'Failed' since the SSL certificate still needs to be set up.
A domain name where the domain still needs to have the three listed DNS records set
How to Apply the SSL Certificate
Agillic requires an SSL Certificate for the selected subdomain before the verification label will show 'Verified'. Contact Agillic Support and provide the certificate and private key for the subdomain. You must send both the certificate and private key in PEM format (X.509). Once delivered, Agillic Support will contact you when the certificate is set up and the domain has been verified.
Alternatively, it's also possible to use Agillic's 'Let's Encrypt' feature where we can generate an SSL Certificate for you. This is a free service. If it's something you're interested in, simply contact Agillic Support.
Verify Current Emails
Before you enable the 'Enable domain name validation' checkbox, you should make sure any current email is using one of the valid domain names.
For example, if Agillic Candy has set up 'marketing.agilliccandy.com' as a verified subdomain, all emails must send from a '@marketing.agilliccandy.com' address.
If you set up an email to send from a '@agilliccandy.com' address, sending the email will fail once you check the 'domain name validation' checkbox.
Please note, however, that, if you have domain name validation enabled, we do not enforce a validated domain on staging when you want to merge data into that field from the recipient's data.
Enable Domain Name Validation
Once you've corrected all current emails to use one of your verified subdomains, you can enable the 'Enable domain name validation' checkbox.
Now that the requirement of 'Domain Name Validation' has been met, you're ready to enable transactional email sending for a verified domain.
Getting ready to mark the domain 'candy.agilliclabs.com' to be used for sending transactional emails
How to Use a Verified Domain in an Email
- Create an email.
- Go into the Properties panel in the right sidebar.
- Select one of your verified domains from the 'From Email address domain name' drop-down.
- Fill out the first part of the from email address in the 'From Email address' field. For example 'marketing'. The information from step 3-4 will combine to make up the full from address, such as 'marketing@demo.agilliccandy.com'.
Selecting a verified domain name to use as the 'from email address domain name'
Brands
The brands feature enables you to assign brands to individual verified domains. When working with several brands on an Agillic instance with a shared recipient base, this feature adds a layer of protection against accidental send-outs across brands.
Brands are defined by using the familiar Target Group feature. You simply create a Target Group which identifies recipients belonging to a certain brand and then select it in the brand section, found under Settings.
Associating the brand 'Nordic_Candy' with the verified domain 'candy.agilliclabs.com'
When emails are sent from the domain '@candy.agilliclabs.com', an additional check is now in place. Before sending the email, we will make sure that the recipient is included in the Target Group 'Brand_Nordic_Candy' at the time of send-out.
Domain Based Unsubscribe (List-Unsubscribe)
Best Practice on Domain Based Unsubscribe
If you wish to allow your recipients to unsubscribe from communication on per-domain basis, 'Domain Based Unsubscribe' is for you. Without it, a List-Unsubscribe will fully unsubscribe a recipient from all non-transactional email content.
Please note that as the 'Domain-Based Unsubscribe' is triggered by the email client List-Unsubscribe feature, we recommend that you continue controlling permissions either via a Person Data field per domain or via a dedicated One-to-Many table.
We don't recommend relying solely on the Domain Based Unsubscribe statuses (held in the One-to-Many table 'EMAIL_STATUS') for handling permissions. Instead, think of Domain-Based Unsubscribe as an extension to the List-Unsubscribe feature, allowing a higher degree of compatibility with multi-domain setups.
Getting Started
When enabling 'Domain-based Unsubscribe' the system will automatically create the One-to-Many table EMAIL_STATUS. You don't need to create it yourself.
Enabling 'Domain-Based Unsubscribe' will initially prompt you to transfer the current fixed Person Data 'UNSUBSCRIBED' and 'COMPLAINT' to a brand or verified domain. The system will then create a One-to-Many table named 'EMAIL_STATUS' to store this in.
Triggering a 'List-Unsubscribe' from the email client will now create or update a row in a system-generated One-to-Many table named 'EMAIL_STATUS'.
Please note, any unsubscribe footer-links you may have will continue to work independently of the List-Unsubscribe functionality.
The EMAIL_STATUS has the following structure:
| FROM | DATE | ID | TYPE |
| {Name of Brand} | {Date} | {Name of Brand}_{Unsubscribe/Complaint} | {Unsubscribe/Complaint} |
Example - Email Status One-to-Many Table
| FROM | DATE | ID | TYPE |
| Nordic_Candy | 05.10.2019 | Nordic_Candy_Unsubscribe | Unsubscribe |
| US_Candy | 09.11.2018 | US_Candy_Complaint | Complaint |
Things to Consider Before Enabling Domain-Based Unsubscribe:
- If recipients with 'UNSUBSCRIBED = true' exist on your domain and you intend to keep these recipients, switching to Domain-Based Unsubscribe opens these recipients up to receiving communication from all other domains, besides the domain you initially chose to transfer statuses to.
- Consider a way to exclude these recipients and prevent send-outs to them.
- Domain Based Unsubscribe is triggered by the List-Unsubscribe functionality in email clients.
- Provide alternative fallback methods for the recipient to unsubscribe or withdraw permissions through.
What Happens After Enabling Domain-Based Unsubscribe?
When enabling 'Domain-based Unsubscribe' the system will automatically create the One-to-Many table EMAIL_STATUS. Therefore, you don't need to create it yourself.
When a recipient triggers 'List-Unsubscribe', their status is updated in the EMAIL_STATUS One-to-Many table for the corresponding Brand or Domain.
You will likely want List-Unsubscribe to not only update the EMAIL_STATUS table but also update your custom Permission fields (Person Data or One-to-Many).
In order to do so, you can attach a unique event per verified domain in the 'List-Unsubscribe' section of the Settings module. Now, in addition to updating the EMAIL_STATUS table, a List-Unsubscribe will trigger any Event attached to the relevant domain. Events can be configured to update Person Data and One-to-Many data fields. This allows you to make sure that a List-Unsubscribe change is also reflected in your permission setup.
Attaching unique Events which trigger when list-unsubscribe is activated for the connected domain
Examples
Example - Recipient is subscribed to multiple brand newsletters.
Recipient A is subscribed to newsletters from Chocolate News (news@chocolate.agilliccandy.com) and Candy Digest (news@digest.agilliccandy.com).
- Recipient A receives an email from news@chocolate.agilliccandy.com.
- Recipient A triggers the List-Unsubscribe functionality in their email client.
- Recipient A is now prevented from receiving future communication from news@chocolate.agilliccandy.com, but will continue receiving emails from news@digest.agilliccandy.com
Example - Recipient B is subscribed to multiple types of communication.
Recipient B is receiving service status emails from a website hosting provider (service@service.agilliccandy.com).
Recipient B is also receiving marketing information about new products and unique offers from the same website hosting provider (contact@marketing.agilliccandy.com).
- Recipient B receives an email containing a seasonal offer from contact@marketing.agilliccandy.com.
- Recipient B chooses to not receive these in the future and triggers the 'List-Unsubscribe' functionality in their email client.
- Recipient B is now prevented from receiving future communication from contact@marketing.agilliccandy.com, but will continue receiving emails from service@service.agilliccandy.com.
How to Set Up Domain-Based Unsubscribe
You start by enabling domain-based unsubscribe in the Settings module.
- Under the Settings module, select 'System Settings' from the left sidebar and click on 'Domains'.
- Check the box 'Enable domain-based unsubscribe'. When you enable the feature for the first time, you'll be prompted to transfer all current fixed Person Data UNSUBSCRIBED and COMPLAINT statuses to a Verified Domain or Brand.
Enabling domain-based unsubscribe
The EMAIL_STATUS One-To-Many Table vs. Standard Unsubscribe
Once you enable domain-based unsubscribe, the UNSUBSCRIBE and COMPLAINT statuses will be stored in a One-to-Many Data table tilted EMAIL_STATUS. Therefore, when you create Target Groups and build Conditions, they'll need to follow the principles of One-To-Many Condition building, rather than Person Data Conditions.
The EMAIL_STATUS table will only be updated once a recipient unsubscribed or when they complain. This means you can't use the table for general permissions but only for brand-specific unsubscribes.
| METHOD | STANDARD UNSUBSCRIBE | DOMAIN-BASED UNSUBSCRIBE |
| Data used | Fixed Person Data: UNSUBSCRIBE (boolean) UNSUBSCRIBE_DATE COMPLAINT (boolean) COMPLAINT_DATE |
Fixed One to Many table: EMAIL_STATUS: FROM (list of domains or brands) TYPE (Unsubscribe or Complaint) DATE ID |
| Target Group Example |
Unsubscribed population size last 2 weeks: Condition: |
Unsubscribed population size last 2 weeks: Condition: One-to-Many: EMAIL_STATUS exist, where TYPE equals Unsubscribe & where DATE is less than 14 days in the past |
Creating Conditions Based on Domain Based
The EMAIL_STATUS table can be used as part of building Conditions. The table can contain the following fields:
| FROM | DATE | ID | TYPE |
| {NAME_OF_BRAND} | {DATE_FOR_ACTION} | {NAME_OF_BRAND}_ [underscore]{Unsubscribe}/{Complaint} |
{Unsubscribe}/Blank {Complaint}/Blank |
The table for a recipient who has complained and unsubscribed from the ChocolateWeekly brand would then look like this:
| FROM | DATE | ID | TYPE |
| ChocolateWeekly | 01.09.2019 | ChocolateWeekly_Unsubscribe | Unsubscribe |
| ChocolateWeekly | 01.09.2019 | ChocolateWeekly_Complaint | Complaint |
You can refer to these One-To-Many fields when configuring Conditions.
Creating a Target Group, locating all who are currently unsubscribed