Email domain verification: the records to publish and the traps to avoid

Decide this first, because the domain you add is the one after the @. If you add send.acme.example, customers see orders@send.acme.example in the From line, under the display name (“Acme”) that most inboxes show first. Set a Reply-To on an address you read, such as help@acme.example, and replies go there. If you need orders@acme.example itself, add the root. Both work.

For order confirmations, receipts and other mail your product sends, a subdomain is the better default. Its records cannot collide with the ones your mailbox provider publishes at the root, and a problem with product mail is less likely to reach your staff’s mail, though providers also weigh the parent domain. The subdomain guide covers campaigns.

DNS is the public directory for your domain, and your DNS host is the company where you edit it, often the one you bought the domain from. Two records are required there.

• The DKIM key. We sign every message, and receivers use this public key to check the mail came from your domain and was not changed on the way.
• The return path. This is where bounces go. With it on your domain, the SPF check, which asks whether a server may send for a domain, passes for your domain instead of ours, so the pass counts for your name.

Adding send.acme.example generates this set. Copy the values from the domain page rather than typing them.

; Signing key (always)
rasket._domainkey.send.acme.example.  TXT    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

; Return path
rasket.send.acme.example.              CNAME  (the host the domain page shows)

The return path sits at a label of its own, rasket for new domains or the next free label if something else already uses that one, so it never touches the records already at send.acme.example. Some domains show the same job as an MX and a TXT record instead of the CNAME; either verifies. The return path article explains how the label is chosen.

1. Add the name your mail will come from — Add the exact domain that will appear after the @ in your From address, such as send.acme.example, and open it on the domain page.
2. See where the domain's DNS is managed — Open the domain in Rasket. It reads your nameservers and heads its instructions with your DNS host by name, as in Add these at GoDaddy, with where to click in that panel. If it only says your DNS provider, it is usually where you bought the domain.
3. Publish the records — Use one-click connect if your DNS host offers it. Otherwise create each record from the domain page, typing the name exactly as the page's Name column shows it, such as rasket._domainkey.send: most panels add your domain to it themselves.
4. Watch the rows on the domain page — Each row says what the last check saw, such as Not found yet or Found, confirming, and whether the next move is yours or ours. The status table in this article says what to do for each.
5. Let verification run, or ask for a check — Checks repeat on their own, including after you close the page. Press Check now on the domain page when you want an immediate look.
6. Send one test message to yourself — Send from the new domain to a mailbox you control. In Gmail, open it, choose More, then Show original, and look for SPF and DKIM reading PASS with your domain; once the DMARC record below is published, DMARC reads PASS too. The DKIM, SPF and DMARC article explains each result.

For step 3, on Cloudflare one button writes the records after you sign in there. Hosts that support the Domain Connect standard, such as GoDaddy and IONOS, can show a Connect card: you approve the change on their screen and never share a password or key with us. Everything else is copy and paste, one row at a time.

If someone else manages your DNS, press Copy all and send them the rows, or ask them to approve the Connect card with their own login.

Zone:        acme.example
Name typed:  rasket._domainkey.send.acme.example
Published:   rasket._domainkey.send.acme.example.acme.example   <- nobody looks here
Should type: rasket._domainkey.send

Normally under an hour once the records are right. While the domain page is open it says “Checking every 30 seconds. DNS changes can take up to an hour to show up.”, and checks carry on in the background after you close it. When the domain verifies, your team’s admins get an email saying so.

Each record row says what the last check saw, and whose move it is:

$ dig +short TXT rasket._domainkey.send.acme.example
"p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

$ dig +short CNAME rasket.send.acme.example
us1.rasket.net.

$ dig +noall +answer SOA acme.example
acme.example.  3600  IN  SOA  ns1.dns-host.example. hostmaster.acme.example. 2026101601 7200 3600 1209600 300

• The name is doubled. Read back the full name the panel displays and compare it with the domain page.
• The value is quoted twice or cut short. Some panels add quotes themselves; some silently truncate long TXT values. A truncated DKIM key never verifies. If the panel rejects the long key, paste the split form the domain page also shows: the same key as several quoted strings. Only if that fails too, ask the page for a 1024-bit key: weaker, but the smallest size RFC 8301 still allows.
• Something else lives at the return-path name. A CNAME cannot share its name with any other record (RFC 1034 §3.6.2). Delete the old record at that label, or pick another label.
• Cloudflare is proxying the CNAME. A proxied record answers with Cloudflare’s addresses, not a CNAME. Set it to DNS only (grey cloud); the domain page reports this case by name.
• Another team verified the name first. Adding it is refused. The domain page offers a claim instead: you publish one TXT record at the root of the domain, and when it resolves the domain moves to your team, unless the current owner verified or sent from it very recently. The domains guide has the rules.

Verification does not require DMARC. When your domain has no policy yet, the domain page offers a starter record at _dmarc.acme.example, which also covers send.acme.example: v=DMARC1; p=none; rua=mailto:dmarc-reports@acme.example. If a record already exists at that name, keep it; two DMARC records count as none.

p=none blocks nothing. The rua= address asks receivers to send you reports, so you can see who sends as your domain before you tell them to reject the rest. It is still worth having now: Gmail requires a DMARC record, p=none included, from bulk senders, which it defines as close to 5,000 or more messages a day to Gmail addresses, counted across your whole domain. The return path counts toward DMARC for send.acme.example because DMARC’s default alignment is relaxed: both names end in acme.example. The DMARC guide tightens it when the reports look clean.

A verified domain keeps being re-checked. A record that disappears, typically when someone moves DNS to a new host and rebuilds the zone without it, shows up on the domain page rather than in a customer’s complaint. Keep the records wherever the rest of your DNS is managed, so a move brings them along.

Verified means receivers can check the mail is yours; it does not put the mail in the inbox by itself. A new domain has no sending history, so start with the people most likely to open, such as order confirmations, and add volume over a few weeks. The warm-up guide has the schedule.

{
  "name": "send.acme.example",
  "status": "pending",
  "records": [
    { "record": "DKIM", "name": "rasket._domainkey.send", "type": "TXT", "status": "verified" },
    { "record": "SPF", "name": "rasket.send", "type": "CNAME", "status": "pending" }
  ]
}