Domain verification

Four records stand between adding a domain and sending from it. Each answers a different question, and a receiver that cannot answer all four will treat your mail with suspicion regardless of how good the message is.

What each record is for

SPF — may this server send for you?

name:  yourdomain.com
type:  TXT
value: v=spf1 include:<our-host> ~all

A list of servers allowed to send on behalf of the domain. The ~all means "anything not listed should be treated as suspicious" rather than "rejected", which is the safer starting point.

DKIM — was this message altered?

name:  <selector>._domainkey.yourdomain.com
type:  TXT
value: v=DKIM1; k=rsa; p=<public key>

Every message is signed with a private key; this record publishes the matching public key so a receiver can verify it. The selector is part of the name, which is what makes key rotation possible without downtime.

DMARC — what if the first two fail?

name:  _dmarc.yourdomain.com
type:  TXT
value: v=DMARC1; p=none;

Tells receivers what to do with mail that fails both checks, and where to send reports. p=none asks for reports without asking anyone to quarantine your mail — the right starting point for a domain with no sending history.

Move to quarantine, then reject, once the reports look clean. Tightening early is how a domain ends up quarantining its own legitimate mail. If you already publish something stricter than none, the dashboard will not suggest this record at all.

Return-path MX — where do bounces go?

MX   <subdomain>  ->  10 <our-mx-host>
TXT  <subdomain>  ->  v=spf1 include:<our-host> ~all

Bounces are delivered to the envelope sender, not the From address, and that lives on a subdomain. The MX routes those messages back to us so bounces are recorded and the address suppressed; without it they bounce again, to nobody.

The TXT is needed as well, because SPF does not inherit from a parent domain. This MX is what the return-path check verifies, and the API marks it required_for_verification: true for that reason.

Adding them

Every DNS provider has the same three fields, whatever it calls them: a name or host, a type, and a value. Two things trip people up:

• Names are relative. Many providers append the zone automatically, so _dmarc is correct where the dashboard says _dmarc.yourdomain.com. Typing the full name gives you _dmarc.yourdomain.com.yourdomain.com, which silently never resolves.
• Quotes are added for you. Paste the value without surrounding quotes unless your provider strips them — a literal " in a TXT record is part of the value.

Add the Return-path records on the subdomain, not the root. They are the ones most often dropped, because they are four lines below the three that look like "the real ones".

Verifying

Click Verify once the records are saved. If it fails, the useful question is whether the value is wrong or merely too early, and they look identical from the dashboard. Ask DNS directly:

dig +short TXT yourdomain.com
dig +short TXT _dmarc.yourdomain.com
dig +short TXT <selector>._domainkey.yourdomain.com
dig +short MX  <subdomain>

If dig returns what the dashboard asked for, the record is right and you are waiting on propagation — try again in a few minutes. If it returns something else, or nothing, the record is wrong or was saved somewhere that is not live.

Keeping it working

Verification is not permanent. Records get removed in a DNS migration, a provider flattens a CNAME, someone tidies up "unused" TXT records — and mail starts landing in spam without anything on your side changing. The dashboard warns when a verified domain drifts, and domain.updated fires when settings change, so a webhook subscriber finds out rather than noticing a drop in engagement weeks later.