Send email from your own domain

By default, emails your agents and lifecycle messages send come from support@subcontext.com. With a sending domain, they come from an address on your own domain instead, signed so that inboxes trust them.

Subcontext sends email through Amazon SES (Simple Email Service). You add a domain in the dashboard, publish the records it gives you at your DNS provider, and Subcontext checks for them until the domain is verified.

Before you start#

• Your plan. Sending domains is a plan feature. If Sending domains isn't in your dashboard's settings, it isn't on your plan.
• Who. An owner or manager adds the domain. Whoever runs your DNS publishes the records.
• Choose the domain carefully. Emails can only come from an address on exactly the domain you verify. If you verify example.com, you can send from support@example.com but not from support@mail.example.com, and the other way round. Verify the domain your From address will use, which is usually your main domain rather than a mail. subdomain. The dashboard warns you if you add one.
• Check the bounce subdomain is free. Subcontext uses a subdomain of your domain for bounces, mail. unless you choose another (see the records). If mail.example.com already exists as a CNAME (for webmail, say), the new records can't sit beside it. Choose another subdomain, such as bounce, under Bounce subdomain when you add the domain.

Adding the domain#

In the dashboard, open Sending domains, enter the domain (for example example.com) and press Add. To use a bounce subdomain other than mail., open Bounce subdomain first and enter it. If the page says your email sending workspace is still being set up, check back shortly. This is a one-off step for your organisation.

You can add a domain again after removing it.

The domain's page then shows a DNS setup table with a Host, Type and Value for each record. Copy them from there, because the values are unique to your domain.

The records#

There are six. For the domain example.com they look like this (the three DKIM tokens, shown here as TOKEN1 to TOKEN3, are long random strings that are different for every domain):

All six go on the domain you added. If you chose another bounce subdomain, such as bounce, the MX and TXT records are on bounce.example.com instead of mail.example.com. If you added a subdomain such as notify.example.com, the hosts are ..._domainkey.notify.example.com, mail.notify.example.com and _dmarc.notify.example.com.

You can change the bounce subdomain on the domain's page until the domain is verified. The page then shows the new MX and TXT records to publish.

What these change, and what they don't#

• Your existing email keeps working. None of these records touch your domain's own MX or SPF records. The MX and SPF go on the bounce subdomain, which only handles bounces from Subcontext's emails.
• DMARC is optional. It isn't checked for verification. If your domain already has a DMARC record, keep it and don't add a second one. A domain can have only one. Emails from Subcontext pass DMARC through DKIM, so a stricter existing policy (p=quarantine or p=reject) is fine once the domain is verified. If you do add the suggested one, change the rua= address to a mailbox someone reads, or remove rua= altogether.

Verification#

Subcontext checks your domain with Amazon SES automatically every 30 minutes. It counts as verified only when all of these pass: the three DKIM records, and the bounce subdomain's MX and SPF records. Most domains verify within a few hours of the records being published.

The domain shows one of these:

• Check verification status on the domain's page runs a check straight away. Refresh the page after a moment to see the result.
• A failed domain can recover. Amazon SES stops looking 72 hours after checking starts. Fix the records, then press Check verification status. Checking starts again for another 72 hours.
• Owners and managers can be told when a domain is verified or fails, with the Domain status changes notification.

Once it's verified#

• Choose the From address. Nothing is sent from your domain until you choose its From address on the domain's page, for example hello@example.com. You can choose it before the domain is verified, and change it at any time. Until then, emails keep coming from support@subcontext.com. Use a real mailbox, or one that forwards somewhere. Replies to an agent's emails normally go back to the agent (its emails carry the agent's own address as the Reply-To), but some people write to the From address directly.
• A product can have its own address. Set Sending email address in Settings, under Channels, to any address on a verified domain.
• An agent's email channel sends from its Forwarding address when that address is on a verified domain (see Receive email into an agent).
• Anything not on a verified domain falls back. An address on a domain that isn't verified (or stops being verified) isn't used. Emails go from support@subcontext.com instead, so they don't land in spam.

To stop sending from a domain, press Remove next to it in Sending domains. That also removes it from Amazon SES, so you can add it again later. You can then delete the DNS records.

Common DNS mistakes#

• The domain added twice. Many DNS providers add your domain to the end of every host name. If yours does, enter TOKEN1._domainkey (not TOKEN1._domainkey.example.com), mail and _dmarc. To check, look up the record afterwards (see below). If it shows example.com.example.com, the domain was added twice.
• The MX priority in the wrong place. The MX value is 10 (the priority) followed by the mail server. If your provider has a separate priority box, put 10 there and feedback-smtp.eu-west-1.amazonses.com in the value.
• Proxied CNAMEs. On Cloudflare, set the three DKIM records to DNS only (grey cloud). A proxied record hides the CNAME and DKIM fails.
• Quotes around TXT values. Some providers add them for you, some want you to type them. Either way, the published value must be exactly the text in the table.
• A trailing dot. Some providers show dkim.amazonses.com. with a final dot. The dot doesn't change the name.

Checking your records#

These commands show the records as published (replace the names with yours):

dig +short CNAME TOKEN1._domainkey.example.com
dig +short MX mail.example.com
dig +short TXT mail.example.com
dig +short TXT _dmarc.example.com

On Windows, use nslookup -type=CNAME TOKEN1._domainkey.example.com and so on. A record that shows nothing hasn't been published yet, or is under the wrong name.