Domains

A domain has to be verified before you can send from it. Verification means two separate things, and the API treats them separately: that the domain is yours, and that the DNS records which make your mail deliverable are published.

Adding a domain returns it along with the DNS records it needs. Those records are generated server-side — DKIM keys are created per domain — so read them from this response rather than copying values from anywhere else.

The records

Each record in the response has the same shape: record (a human name), name, type, value, a status, and — for some — purpose and required_for_verification.

SPF

A TXT record on the domain itself, authorising our servers to send on your behalf.

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

DKIM

A TXT record at a selector-scoped name, holding the public half of the key that signs your mail. This is what lets a recipient prove a message was not altered in transit, and it is what makes DMARC alignment possible.

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

Rotating the key adds a second DKIM record marked "record": "DKIM (add alongside the one above)" with required_for_verification: false. Publish it alongside the existing one, not instead of it — the old key keeps signing until the new record is confirmed, so replacing it early breaks signing for every message in flight.

DMARC

A TXT record at _dmarc.yourdomain.com telling receivers what to do when SPF and DKIM both fail.

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

p=none is a deliberate starting point for a new domain: it asks for reports without instructing anyone to quarantine your mail while you have no sending history. Move to quarantine and then reject once the reports are clean.

If you already publish a stricter policy, this record is not suggested at all. Advice is only worth showing when it is an improvement, and offering p=none to a domain already at p=reject would be advice that weakens your setup.

Return-path (MX and SPF)

Only present when a custom return path is configured. These are on a subdomain, not the domain — the envelope sender lives there so bounces come back to us rather than to your inbox.

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

SPF does not inherit from a parent domain, so the subdomain needs its own TXT record in addition to the MX. The MX is the one verify_return_path checks, and it is marked required_for_verification: true for that reason.

Verification

Checks the published records and moves the domain to verified if they hold. DNS propagation is not instant, so a failure immediately after publishing usually means the records have not propagated yet rather than that they are wrong — re-check before changing anything.

Managing domains

• GET /domains — every domain in the organization, with status.
• GET /domains/:id — one domain, including its DNS records.
• PATCH /domains/:id — update settings, including whether tracking is enabled for mail sent from this domain.
• DELETE /domains/:id — remove the domain. Mail sent from it is refused afterwards; the DNS records are yours and are left alone.