CamelMailer
DocsAPISDKsTemplatesHow-to

Verify a sending domain

You can only send from domains you have proven you control. The dance: add the domain, publish the records it shows you, verify.

1. Add the domain

Dashboard: Server → Domains → Add. Or via API:

terminal
curl -X POST …/api/v2/admin/organizations/acme/servers/production/domains \
  -H "X-Admin-API-Key: $ADMIN_KEY" -d '{ "name": "acme.com" }'

2. Publish the records

The domain view shows the exact values. They boil down to:

DNS zone
; SPF — allow your instance to send for the domain
acme.com.          TXT  "v=spf1 a:mail.yourdomain.com -all"

; DKIM — the public key of the installation signing key
camelmailer._domainkey.acme.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBg…"
  • The DKIM selector is the installation's dns.dkim_identifier (default camelmailer).
  • Add DMARC once SPF/DKIM are live; a sane rollout starts with p=none.

3. Verify

terminal
curl -X POST …/domains/acme.com/verify -H "X-Admin-API-Key: $ADMIN_KEY"

Sending to unverified domains is rejected with a ValidationError whose message names the domain.

When it doesn't verify

  • Propagation: dig TXT acme.com and dig TXT camelmailer._domainkey.acme.com from the machine running CamelMailer, since caches can lag minutes to hours.
  • Quoting: some DNS UIs split long DKIM keys into multiple quoted strings, which is fine. A truncated paste is the real problem.
  • CNAME shadowing: the TXT must live on the exact name; a CNAME on the same label swallows it.
  • Multiple SPF records: a domain may have only one v=spf1, so merge mechanisms into a single record.
Subdomains (e.g. mail.acme.com for product mail) are their own sending domains with their own records, and they isolate reputation from your root domain. Recommended.