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.

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.