Domains & DNS records

Adding a domain asks you to publish some DNS records. This page explains what each one is for, so you can decide which you need and understand what breaks if one is missing.

You do not need a domain to get started. Endpoints work immediately on the platform URL, and every org gets a platform sending identity (no-reply@<org-slug>.<platform-send-domain>) provisioned automatically on first send. You add your own domain when you want the address to be yours rather than ours.

Three kinds of domain

A domain is added as one of three kinds, and they need entirely different records. Only the ownership challenge is common to all of them.

Kind	What it gives you	Records
Webhook (webhook)	Providers post to wh.example.com instead of the platform URL	ownership TXT, a CNAME, an ACME TXT
Email (email)	Send and receive mail as @example.com	ownership TXT, apex MX, three DKIM CNAME, MAIL FROM MX + TXT
Email, send only (email-send)	Send as @example.com — never receives	ownership TXT, three DKIM CNAME, MAIL FROM MX + TXT

Send-only email domains

Use email-send for a domain you send from but do not want receiving anything — notify.example.com, alerts.example.com, a transactional subdomain. No MX is ever issued for it, so mail addressed to that domain keeps going wherever it goes today (or nowhere), and no alias can be created on it — an address that silently receives nothing is worse than no address.

It also verifies differently. A receiving email domain is not active until its MX actually resolves to us — a domain that looks verified while its mail goes nowhere is a lie worth refusing. A send-only domain has no inbound mail to route, so ownership + DKIM verified by SES is the whole gate.

emithook domains add notify.example.com --kind email-send
emithook domains verify dom_...          # once the TXT + DKIM CNAMEs resolve

Then enable Outbound sending on the domain in the console, publish the MAIL FROM MX + TXT it adds, and verify once more. Sending works as soon as sending is enabled; the MAIL FROM pair aligns the bounce-return path (until it resolves, the provider falls back to its own).

Switching between receiving and send-only

An existing email domain converts in place — no re-adding, and nothing you have already published needs republishing. The console has a Receiving card on the domain page; the same change over the API:

emithook domains update dom_01JX9 --kind email-send   # stop receiving
emithook domains update dom_01JX9 --kind email        # start receiving again

Only email ⇄ email-send converts. A webhook domain publishes a CNAME, which cannot coexist with an MX (RFC 1034), so it is refused — remove it and add it as the kind you want.

• To send-only — the MX is dropped from your record set (delete it from your DNS too). It is refused while any alias still receives on the domain: those addresses would keep looking live while receiving nothing. Delete them first. An already-verified domain stays active.
• To receiving — the MX is added back, which redirects the domain's mail to Emithook, so the same acknowledgement as adding a domain applies when it already receives mail elsewhere. The domain returns to pending-dns until that MX resolves.

Ownership, DKIM and MAIL FROM records are untouched either way, and a domain already enabled for sending keeps sending across the conversion.

A hostname can be one or the other, never both

A webhook host publishes a CNAME, and RFC 1034 and RFC 2181 forbid any other record type at a name that has one — MX included. So wh.example.com can never also receive mail. To do both on one parent domain, use sibling hosts: wh.example.com for webhooks and mail.example.com for email. The domain page's Also receive email action sets the sibling up for you.

---

Webhook domains

1. Domain ownership

TXT   _emithook-challenge.wh.example.com   emithook-verify=01KY7T442P8…

A one-off challenge proving you control the hostname — what stops someone else pointing your name at their account. Until it resolves, the domain stays pending-dns.

2. Route traffic to Emithook

CNAME   wh.example.com   wh.emhk.in

Points your hostname at our ingress, so senders can post to your address instead of the platform URL. Your endpoints keep working on the platform URL either way — this changes the address your providers see, not how delivery works.

3. TLS certificate

TXT   _acme-challenge.wh.example.com   6hJeSUGcotcQKNExOJX-…

A domain-control-validation challenge that lets us obtain and renew the certificate for your hostname. Emithook terminates TLS here, so leave this record published — remove it and renewal fails the next time the certificate comes up for expiry.

Verified DNS and an issued certificate are two separate steps. The domain can sit at pending briefly after all records resolve, because the certificate is still being issued. That's expected.

Cloudflare users

If your domain is on Cloudflare and proxying is on (orange cloud), a CNAME pointing at another Cloudflare-hosted zone can fail with "Error 1014: CNAME Cross-User Banned." Set the record to DNS-only (grey cloud) — Emithook issues and terminates TLS for this hostname, so you don't lose HTTPS by doing so.

---

Email domains

1. Domain ownership

TXT   _emithook-challenge.example.com   emithook-verify=01KY7DC85SX0…

Same purpose as above: proof you control the domain. Until it resolves, neither sending nor receiving is enabled — it's what prevents someone adding yourcompany.com to their org and sending as you.

2. Receiving mail

MX (10)   example.com   inbound-smtp.<region>.amazonaws.com

An MX record tells the internet which server accepts mail for a domain. This one points at our inbound host, so anything addressed to @example.com is delivered to Emithook, parsed, and made available to your endpoints and the Inbox.

This replaces your existing mail routing

A domain has one set of MX records and they decide where all its mail goes. If example.com currently receives through Google Workspace or Microsoft 365, adding this record diverts that mail to Emithook. Most people point a subdomain at us instead — inbound.example.com — and leave the apex alone.

Sending does not need this record. A send-only domain has no MX at the apex, and that is fine.

3. DKIM — signing what you send

CNAME   <key1>._domainkey.example.com   <key1>.dkim.amazonses.com
CNAME   <key2>._domainkey.example.com   <key2>.dkim.amazonses.com
CNAME   <key3>._domainkey.example.com   <key3>.dkim.amazonses.com

DKIM attaches a cryptographic signature to every message you send. The receiving server fetches your public key from these records and checks it, proving the message genuinely came from your domain and wasn't altered in transit.

This is the single most important group for deliverability. Unsigned mail from an unfamiliar domain is treated as suspicious by essentially every large provider and lands in spam regardless of content.

All three are required. They exist so keys can rotate without a gap in signing. Publishing only one leaves you unsigned the moment that key rotates — which shows up as mail that delivered fine for weeks and then abruptly started failing.

4. MAIL FROM — bounces and SPF

MX (10)   send.example.com   feedback-smtp.<region>.amazonses.com
TXT       send.example.com   v=spf1 include:amazonses.com ~all

Every message has two "from" addresses: the one the recipient sees (the From: header) and the invisible envelope address bounces are returned to. By default the envelope belongs to Amazon. These records move it to a subdomain of yours, which matters twice over.

Bounce attribution. The MX routes delivery failures and complaint reports back through us, so they can be matched to the message that caused them. That's what populates bounce and complaint status on a message, and what feeds the automatic suppression list.

SPF alignment. SPF checks whether the sending server is authorised by the envelope domain. With the default envelope, SPF passes for amazonses.com — not your domain, so it doesn't align. DMARC requires at least one of SPF or DKIM to both pass and align. DKIM alone satisfies that, so mail still works without this group, but you're running on one leg: any DKIM problem takes you straight to failing DMARC. With MAIL FROM published, both align.

These records sit on the send. subdomain rather than the apex, so they don't disturb an SPF record you already publish for the domain itself.

Enable this at Domains → your domain → Outbound sending → Enable sending. It appends the records to the list and re-runs verification; existing DKIM is untouched.

---

Checking your work

After publishing, press Verify DNS. Each record shows verified, or the value we actually resolved so you can see the delta — a trailing dot, copied-in whitespace, or a provider that appended the domain to a name you'd already made absolute.

Propagation takes minutes, occasionally hours. A failure immediately after publishing usually means "not yet" rather than "wrong" — wait and retry. We re-check automatically too.

To confirm a real send end to end, use Send test email on the Outbound email screen, then open the message in your mail client and view its original/source. You want DKIM=pass and SPF=pass on your domain rather than on amazonses.com.

See also

• Send email — sending identities, the API, suppression list
• Receive webhooks — custom domains for webhook ingress
• Glossary