Domains

You can only send from a domain you have proved you control. Adding one gives you DNS records to publish; publishing them is what proves it.

The records

What you get depends on which engine the domain sends through. Both cases give you the same three things under different names.

Purpose	Why it matters
DKIM (`TXT`)	Signs every message. Without it, mail is unsigned and most providers treat it as suspicious.
SPF / return path	Says which servers may send as you, and where bounces go.
DMARC (`TXT`, recommended)	Tells receivers what to do when a message fails the two above. Optional to add, and increasingly not optional in practice.

DMARC is marked recommended rather than required because a domain verifies without it. Gmail and Yahoo both require it for bulk senders, so treat it as required if you send to consumers at any volume.

Letting mailstein publish them

If your domain's DNS is on Cloudflare, you do not have to copy anything. On the domain page, Publish these records for me → Connect Cloudflare, and paste an API token scoped to that one zone:

Cloudflare → My Profile → API Tokens → Create Token → Edit zone DNS template → Zone Resources: Include → Specific zone → yourdomain.com

mailstein then writes the DKIM, SPF, MX and DMARC records itself and nothing else. Publishing again is safe — records already correct are reported as unchanged, so it doubles as a repair button if one gets edited by hand.

The token is encrypted at rest and never shown again; the interface displays only its last four characters. Scope it to the single zone: a token that can edit DNS for a domain can repoint its website and read its mail, and there is no reason to grant more than the one zone.

Other providers are not automated yet, so those records go in by hand. The domain page names your provider so at least you know where to go.

Verifying

curl -X PUT https://app.mailstein.com/api/v1/domains/1/verify \
  -H "Authorization: Bearer $MAILSTEIN_API_KEY"

Verification is also re-checked on a schedule, so a domain fixes itself shortly after you correct a record. The manual call just skips the wait.

A domain that will not verify is almost always one of four things: the record was added to the wrong zone; the provider silently appended the domain name to a record that already ended in it; the record is proxied when it must not be; or DNS has not propagated yet. The status column tells you which record is missing.

Settings

curl -X PATCH https://app.mailstein.com/api/v1/domains/1 \
  -H "Authorization: Bearer $MAILSTEIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"clickTracking":true,"trackingDomain":"links","tlsPolicy":"ENFORCED"}'

trackingDomain — a subdomain of this domain used for tracked links. See tracking; it is worth reading before you turn tracking on.

tlsPolicy — OPPORTUNISTIC uses TLS when the receiving server offers it and sends unencrypted when it does not. ENFORCED refuses to deliver unencrypted at all. Enforced is what a BAA or a similar contract normally requires, and it will cost you delivery to the small number of servers that still do not support TLS. Currently applies to domains sending through Amazon SES.

Sending from a subdomain

Sending from mail.yourdomain.com rather than yourdomain.com keeps your marketing reputation separate from the domain your staff email from. If a campaign goes badly, the damage is contained to the subdomain.

The trade-off is recognition: yourdomain.com in the From line is more trusted by humans than anything with a prefix. Most senders use the root domain for transactional mail and a subdomain for bulk.

Something here wrong or missing? It is generated from the running API — tell us and we will fix the source.