You will need to add certain records to your DNS provider to allow Customer.io to send emails using your domain.
Creating great copy means nothing if your messages don’t make it to the People you’re trying to reach. Although it’s just one piece of the deliverability puzzle (along with your copy and overall reputation), authenticating the domains you use for sending email from Customer.io will help your messages reach your users. Check out our post on Email Deliverability to know more about how it works.
In addition to improving email deliverability, authenticating your sending domains in Customer.io will also let you control the appearance of your tracked links. How about Universal Links? If you need to enable them for your mobile app, HTTPS domain authentication is required as well.
In order to verify and authenticate your domain for sending in Customer.io, you will place our required DNS records in your account-specific subdomain (like:
krs._domainkey.cio#####.yourdomain.com) rather than the root domain.
Because our authentication records are stored in a subdomain, there won’t be any conflict with your existing email configurations that are already setup in your DNS host. By using a subdomain for authentication, we can ensure that:
- our SPF record is valid, will pass DMARC alignment, and will not count towards the lookup limit of your existing SPF record
- our MX record will not disrupt incoming email to your domain’s email server
- our DKIM record has the correct public-key need in order to sign the emails that you send from our servers
A Sending Domain defines who and where your emails are from. You must set up at least one sending domain before you can send emails from your workspace.
If you’re setting up a new workspace, you can configure your domain during the set up process. We show you how that works in the Domain Authentication section below.
If you did not configure your email messaging channel when you set up your workspace, or you just want to add new sending domains, you can:
- Go to Settings > Workspace Settings.
- Click Email Settings and then click Add Sending Domain.
- Enter the Domain, Display Name, and Email Address that you want to send messages from, and click Add Domain.
Unless you use a custom SMTP server, you must authenticate your sending domain before you can use your new sender.
To set up authentication for sending, you’ll need to add three DNS records to your DNS hosting provider for each domain you need to send from using your Customer.io account:
- MX Record: One MX record with two hostnames are required for delivering email from your domain. MX (Mail Exchange) records, in this case, have a specialized purpose which is to create a custom return-path using your subdomain. This is specifically for receiving bounce and spam feedback. This not only helps improve deliverability, but also allows your Customer.io emails to pass DMARC alignment.
- SPF Record: One TXT record that allows Customer.io to sign your emails as an authorized sender. SPF (Sender Policy Framework) records are used to identify which IP addresses are allowed to send email using your domain.
- DKIM Record: One TXT record that allows Customer.io to create an encrypted signature on emails sent on your behalf. DKIM (Domain Keys Identified Mail) signatures ensure that the message that arrives at the inbox provider is identical to the message that you sent.
Each domain you choose to authenticate must first be used in one or more of the From Addresses that are configured in your account. Once added, each domain will be assigned its own values for the DNS records that need to be added at your DNS host.
To see these values, follow the Workspace Settings link in the left-hand menu in your Customer.io account, choose Email from the list of message types and then select the Sending Domains tab:
Next, click the Verify domain button for the domain you would like to authenticate. This is where you will see the MX, SPF, and DKIMs records you need to add to your domain’s DNS records in order to authenticate your domain:
After you have added these records to your DNS host, and they have had time to propagate, you will need to come back to the Deliverability page and click the Verify domain button. We will then check that the records and values are correctly in place. If all three records are verified by green checkmarks, then your domain is verified and you’re all set to start sending from that domain.
If any of three required records aren’t able to be verified, then we weren’t able to find a value that matches the required value and therefore aren’t able to verify the domain for sending. We recommend double-checking your DNS configuration for typos, spaces, etc. before attempting to verify again. If you aren’t sure how to proceed, you are always welcome to reach out to us at firstname.lastname@example.org for support and we can take a look with you.
A note about DMARC and Customer.io…
If your domain is utilizing a DMARC policy and you plan to send your emails through Customer.io’s built-in delivery servers, you will need to ensure that your DMARC policy is using “r” (or relaxed) values for the aspf and adkim tags in order to have passing alignment. If your policy doesn’t specify aspf or adkim tags, then they are already relaxed by default and no changes to your policy are necessary.
The reason for this requirement is because Customer.io uses an account-specific subdomain of your verified domain (ex.
cio#####.yourdomain.com) for signing the return-path, SPF, and DKIM headers in the emails our servers send from of your verified domain.
Under the default relaxed policy, the emails you send from Customer.io will pass DMARC alignment because of the parent/child match of the mail-from domain (from address) you’re sending from and header-from subdomain (return-path) we sign to your emails.
For context, a strict policy for these tags would require an identical match of the domains in these headers, which would result in your Customer.io emails failing to pass alignment. Failing DMARC alignment could then cause your emails to either bounce back (p=reject) or filter to spam (p=quarantine), depending on your DMARC policy.
Customer.io provides link tracking by default, and we also support the option to use your own subdomain for this if you’d like. You can set this up for tracking using HTTP or HTTPS, which we’ll get into below.
To use a custom subdomain for tracked links in Customer.io, the default setup is to add a CNAME record to your DNS host that alias our tracking subdomains, which are
e-eu.customeriomail.com depending on your Customer.io account region. This allows HTTP traffic to flow to our servers from your custom subdomain. We also support HTTPS tracked links, however this requires additional setup outside of Customer.io, such as setting up a reverse-proxy server. We have a guide on setting up HTTPS Link Tracking here.
- CNAME Record: The CNAME record enables your tracked links will use your domain instead of our default link tracking subdomain. CNAME (Canonical Name) records alias another domain behind your subdomain.
To edit your link tracking settings, click the Manage Domain button and navigate to the Link Tracking tab for the domain you’d like to set up custom link tracking for. This is where you will enter your subdomain and see the CNAME record you need to add to your domain’s DNS host:
After you have added this record at your DNS host and it has had time to propagate, you will need to come back to the Deliverability page and click the Verify domain button. We will verify that the record is in place and you’ll see the results of our check.
- CNAME: A green checkmark means we have verified that your CNAME record is configured. The domain must also be verified for sending before your tracking links can use this domain.
- HTTP link status: A green HTTP link status (shown bottom left) means we are able to connect to your CNAME domain without error over HTTP. Unless you have successfully configured HTTPS Link Tracking, we’ll generate HTTP links whenever link tracking is enabled in your messages.
A red HTTP link status (shown below middle) indicates that our check found a HSTS (HTTP Strict Transport Security) policy on your domain. This means that you must set up HTTPS Link Tracking in order for your custom subdomain to resolve your tracked links correctly.
- HTTPS link status: A green HTTPS link status (shown below right) means you have successfully configured HTTPS Link Tracking and we’ll generate HTTPS links in messages sent from this domain that have link tracking is enabled. The domain must also be verified before your tracking links can use this domain.
For your convenience, here is a list of links to the instructions for adding DNS records at commonly used hosts:
- 123 Reg - MX | TXT | CNAME
- bluehost - MX | TXT and CNAME
- DNS Made Easy - MX | TXT | CNAME
- DNSimple - TXT | CNAME
- Dreamhost - MX | TXT | CNAME
- DYN - MX, TXT, and CNAME
- GoDaddy* - MX | TXT | CNAME
- Hostgator - MX | TXT and CNAME
- Hover - MX, TXT, and CNAME
- Media Temple - MX, TXT, and CNAME
- Namecheap - MX | TXT and CNAME
- Network Solutions - MX | TXT and CNAME
- Register.com - MX | TXT | CNAME
*Instead of entering the full hostname (ie cio12345.yourdomain.com), these providers automatically append your domain to the record. Enter just the front portion of the hostname (ie cio12345) when adding records to these providers. See FAQ below for screenshot examples.
For verifying HTTPS for regular links please visit our documentation on Setting Up HTTPS Link Tracking. If you also need to support links to iOS or Android apps, our documentation on setting up Setting Up Universal Links would be more appropriate.
When using custom SMTP, you do not need to authenticate your domain in Customer.io. However, you should check your custom SMTP provider’s documentation to see if you still need to add DNS records (such as SPF and DKIM) to your domain to use their services successfully.
Branded link tracking with custom SMTP
If you want to use branded custom link tracking in Customer.io (using your domain instead of “customeriomail.com” when generating tracked links), you must verify the domain by adding the CNAME record shown in the Domain Settings section of your workspace.
The CNAME record will not validate your domain for branded link tracking if your domain has a HSTS policy, but does not currently have SSL coverage. Please see our HTTPS Link Tracking documentation for more information on getting this set up.
On the Email Deliverability page, we’ll show you the verification status of any domains you’ve added.
Domains will have one of the following statuses:
- Verified: The domain’s DNS records have been verified and the domain can be used to send signed emails.
- Unverified: The domain’s DNS records have not been verified and the domain cannot be used to send emails.
- Undetermined: The domain’s status cannot be determined because the From Address uses liquid code.
Note: We will not be able to send your emails until you verify your domain.
The domain list is made up of domains used in the From Addresses that are configured in your account. If you want to add another domain, follow the Message Settings link in the left-hand menu in your Customer.io account, choose Email from the list of message types, then select the From Addresses tab, and then click the “Add From Address” button at the top of the domain list.
If you are setting up a new domain for sending through our built-in delivery server, you must add all three required DNS authentication records. This not only verifies the domain’s ownership, but also authorizes Customer.io to send from the domain. If you do not add the DNS records and verify the domain, you will not be able to send from it.
If you have already verified a domain but the DNS records are removed at a later point, this can result in your emails bouncing back or being filtered to spam due to lack of authorization.
Yes. Our email server requires that both SPF and DKIM are verified in order for us to send email from your domain. If either record is missing, you may see your deliveries fail to send due to the domain no longer being verified.
Make sure you’re using a TXT record as indicated in our instructions, and not a SPF type record.
It’s also required that your SPF record is placed inside of the Customer.io-specific subdomain, rather than your existing SPF record in your root domain. If the record is still not verified, get in touch and we’ll troubleshoot the issue with you!
Cloudflare CNAME records won’t be verified if their DNS proxy feature is enabled. Disable this setting in Cloudflare first, and then you can verify your tracking domain in Customer.io.
GoDaddy already adds your domain when creating DNS records, so it’s likely that your domain is being posted twice to the records. Simply update the record to be only the subdomain value (as shown below) and re-verify after a few minutes.
You can confirm this by checking your DNS using a free online tool like viewDNS.info and testing the full hostname URL listed in your Customer.io email settings (ie cio12345.yourdomain.com). If the DNS records don’t appear, then double check that your records are set up correctly.
Underscores: Some hosts do not support underscores (
_) in DNS records, and adding the DKIM record can cause an error. The underscore is required and you’ll want to contact your host to see if they disallow underscores entirely or if they can manually add the record for you.
Semicolons: Some hosts require that you escape semicolons in records. If you’re getting an error try replacing
No. The records are written specifically to allow our servers to send for you but not to disallow other servers.
Some DNS hosts won’t allow you to add records yourself, but will add them for you. As a first step we recommend you talk to your hosting company to see if they can help.
If you aren’t able to add our DNS records for authentication, you may need to consider moving your DNS hosting to a separate provider (i.e. DNSimple, DigitalOcean, Cloudflare, etc). This would allow you to set up custom records while likely still being able to point your domain to the website hosting provider you’re using. If you do consider this, make sure your current website hosting provider supports this.
Wix doesn’t allow you to add a sub-domain in an MX record, preventing you from verifying your domain. If you use Wix, you might consider setting up a custom SMTP server.
AWS doesn’t allow you to set multiple MX records per hostname. To get around this issue, add a single record that has both MX values on separate lines. For example:
10 mxa.mailgun.org. 10 mxb.mailgun.org.