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

Email domain verification is proving to a sending service that you control a domain, by publishing DNS records only somebody with access to the zone could publish. It is the precondition for everything else: a send from a domain that has not passed verification is refused before anything leaves the building.

The proof is not a formality. Once a domain is verified, mail is signed as that domain, and a receiving server that checks the signature will conclude the message really is from you. That is exactly the claim that would be worth forging, which is why the mechanism is a record in a zone only you can write to rather than a checkbox or a confirmation email.

It also has nothing to do with where your mail is read. Verifying a domain for sending does not move your mailboxes, does not change your MX records unless you also turn receiving on, and does not require you to transfer DNS anywhere.

Adding a domain generates its set. These are the DNS records for email that a sending domain needs, with values truncated here the way the dashboard truncates them.

TXT   rasket._domainkey.send.acme.example   "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."MX    send.acme.example                       (the host the dashboard hands you)TXT   send.acme.example                       "v=spf1 include:... ~all"

The private half of the signing key never leaves us and is encrypted at rest. The key is 2048-bit, so the value is long enough that some panels split it into two quoted strings — normal, and it resolves correctly.

1. Add the domain — Add the exact name you want mail to come from. A subdomain such as send.acme.example is the shape to prefer, because everything nests under it and nothing collides with your existing mail.
2. Copy the generated records — Adding the domain generates its record set: a signing key to publish as TXT, and the two records that give the domain its own return path. Copy each row exactly as it is shown.
3. Publish them at your DNS host — Create each record in the zone for that domain. Many panels append the zone to whatever you type, so pasting a fully qualified name produces a record with the domain in it twice.
4. Wait for the change to resolve — Publication is not instant. How long depends on your provider and on the TTL of anything being replaced, so give it minutes rather than seconds before deciding something is wrong.
5. Let verification run — Checks start as soon as the domain is added and repeat on a schedule, so nothing has to poll. Each record carries its own status, and you can ask for an immediate re-check up to once a minute.
6. Send one real message — Once every record reads verified, send a single message to an address you control and look at the headers it arrives with. A signature that verifies at the receiving end is the only proof that matters.

If your DNS is somewhere we can write to, you can connect that account and have the records published for you; the access is used for that one write and not kept. Otherwise it is a few rows pasted into a panel you already have open.

Publishing is not instant, and how long it takes has nothing to do with us. A new record usually resolves within minutes, because there is no cached answer to expire. A record that replaces an existing one can take as long as the old record’s TTL, because resolvers that already have the old value will keep serving it until then.

Two practical consequences. If you know a change is coming, lower the TTL on the record you are about to replace a day beforehand. And check what DNS is actually answering rather than what the panel shows you — the panel shows its own state, not the internet’s.

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

Verification checks start as soon as you add the domain and repeat on a schedule, so nothing has to poll and a record verifies on its own once it resolves. You can also ask for an immediate re-check, up to once a minute per domain.

One cause accounts for most of them.

Name field:  send.acme.examplePanel scope: acme.exampleResult:      send.acme.example.acme.example   <- not a record anybody will find

Many DNS panels append the zone to whatever you type in the name field. Pasting a fully qualified name into a field that is already scoped to the zone produces a record with the domain in it twice, which resolves to nothing and looks, in the panel, entirely correct. Enter the short label, then read back the fully qualified name the panel displays.

• Quotes in the value. Some panels want the TXT value quoted and some add the quotes themselves. A value with quotes inside quotes will not match.
• A truncated DKIM value. The key is long. A field that silently cut it off leaves a record that parses and never verifies.
• Flattening at the root. Providers that flatten records at the apex can interfere with a record you publish there, which is one more reason to use a subdomain.
• A second provider’s SPF record. A domain publishes one SPF record. If the name already has one, merge the new include into it rather than adding a second.
• Somebody else verified the name. A name can be verified on one team at a time, so adding it is refused rather than duplicated.

Adding send.acme.example rather than acme.example is the shape to prefer, for two reasons that both save you trouble later.

Every record nests under the subdomain, so nothing collides with what your mailbox provider already publishes at the root — no merging SPF records, no worrying about flattening at the apex. And reputation is scored per sending domain, so a problem on your product mail never reaches the mail your staff send from their own addresses.

Take it one step further if you send campaigns as well as receipts: a subdomain each means a campaign with a bad list cannot drag down the password resets. The deliverability guide covers why that separation matters more than almost anything else on this page.

Verification is not a one-off. The records are re-checked on a schedule, each with its own status, and one that verified and later stops resolving is reported as drifted rather than quietly ignored — which is the difference between noticing a DNS migration dropped a record and finding out from a customer.

Two habits are worth building. Subscribe a webhook to the domain events so a drift shows up where your team already looks, rather than on a page somebody remembers to open. And treat the records as infrastructure: whatever manages the rest of your DNS should manage these too, so a zone rebuilt from configuration comes back with them.

The domains page shows the record set beside what DNS answered on the last check, the reference documents every field and route, and the quickstart goes from an empty account to a sent message in about five minutes.