Domain Authentication

You will need to add certain records to your DNS provider to allow to send emails using your domain.

Why we require domain authentication

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 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 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.

We will not take over your root domain

In order to verify and authenticate your domain for sending in, you will place our required DNS records in your account-specific subdomain (like: and 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

Add a sending domain

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:

  1. Go to Settings > Workspace Settings.
  2. Click Email Settings and then click Add Sending Domain.
  3. 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.

Setting up domain authentication

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 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 emails to pass DMARC alignment.
  • SPF Record: One TXT record that allows 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 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 account, choose Email from the list of message types and then select the Sending Domains tab:

Sending domains
Sending domains

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:

Unverified domain
Unverified 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 for support and we can take a look with you.

Verified domain
Verified domain

 A note about DMARC and…

If your domain is utilizing a DMARC policy and you plan to send your emails through’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 uses an account-specific subdomain of your verified domain (ex. 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 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 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. 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, the default setup is to add a CNAME record to your DNS host that alias our tracking subdomains, which are or depending on your 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, 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.
HTTP, HTTP with HSTS errors, and HTTPS status for tracked links.
HTTP, HTTP with HSTS errors, and HTTPS status for tracked links.


For your convenience, here is a list of links to the instructions for adding DNS records at commonly used hosts:

*Instead of entering the full hostname (ie, 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.

HTTPS Authentication

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.


Do I need to authenticate my domain if I’m using a custom SMTP?

When using custom SMTP, you do not need to authenticate your domain in 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 (using your domain instead of “” when generating tracked links), you must verify the domain and add 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.

How do I verify my records are there?

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.

How do I add another “From Address”?

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 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.

What if I don’t add the DNS records? What happens?

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 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.

Do I need to add both SPF and DKIM?

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.

The SPF record is correct, but it’s not verifying.

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 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!

I’m hosting my DNS with Cloudflare. The CNAME record is correct, yet remains unverified.

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

I’m using GoDaddy and my DNS records are still not verifying.

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.

GoDaddy MX Record example


GoDaddy SPF example


GoDaddy DKIM example


You can confirm this by checking your DNS using a free online tool like and testing the full hostname URL listed in your email settings (ie If the DNS records don’t appear, then double check that your records are set up correctly.

I’m getting an error in my DNS panel when trying to add the records, what can I do?

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 ; with \;.

Will adding authentication affect my regular email?

No. The records are written specifically to allow our servers to send for you but not to disallow other servers.

My host doesn’t support TXT records. What do I do?

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.

Why can’t I verify my domain with Wix?

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.

How do I add multiple MX records for my AWS-hosted domain?

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:

Copied to clipboard!