Domains

Adding a domain generates its record set at once; GET /domains/{domain_id} returns the same rows the dashboard shows. Send from a subdomain such as mail.example.com rather than the apex: it keeps this product's sending reputation separate from your other mail, and a Receiving MX published there cannot take mail away from the mailboxes your apex already has.

Adding a domain walks the same four steps wherever you start it — the name, where mail should arrive, connecting, and watching the records go live — and the first three ways below are three routes through the third one. Leave at any point with Skip for now: the domain stays in your list and we keep checking in the background.

• Cloudflare. One button. You sign in to Cloudflare, tick the account that holds the zone, and the records are written for you.
• GoDaddy, IONOS, Squarespace and others. Many registrars support a shared standard for this. Where yours does, the connect step offers a Connect card with your registrar's name on it: you approve the change on their own screen and come straight back, and we start checking the records immediately. Nothing of yours is stored, and we never ask you for a password or an API key. If the domain uses a name of its own for the return path, or a renamed tracking hostname, the page says which rows one click cannot cover.
• Any other registrar. The domain page recognises where the domain is hosted from its nameservers and shows that registrar's own instructions: where to click, the fields in the order that panel lists them and under the names it gives them, a copy button beside every value, and the panel's known traps.
• Software. POST /domains returns the records; publish them with whatever manages your zone, then POST /domains/{domain_id}/verify asks for a check now. The MCP server exposes the same two operations.

Open the domain in the dashboard and follow the panel headed Add these at …. It is written for the registrar the nameservers point at; a domain hosted somewhere the page does not recognise gets the generic version, which is true for any record editor.

1. Open your registrar's record editor for the domain.
2. Add each row in the table. Copy every field from the page — the name is already spelled the way that registrar wants it.
3. Leave TTL at the registrar's default.
4. On Cloudflare, set every CNAME to DNS only (grey cloud). A proxied record answers with Cloudflare's addresses instead of ours and never verifies.
5. Come back to the page. It checks every 30 seconds by itself; Check now looks straight away if you would rather not wait.

The most common mistake is pasting the full name into a field that adds the domain for you, which publishes rasket._domainkey.example.com.example.com. The page's Name column already shows what to type; when a panel wants the whole name, it shows that instead.

The sending records live at one name under your domain, the return path: bounces are handled there. Another email service may already use a name like send for its own records, and a name can only point one way, so we pick one nobody uses when you add the domain — rasket, or the next free one of rasketmail, rk, rasket1 and rasket2. The other service keeps working as it does today.

• Choose your own. Open Advanced options when you add the domain, or send custom_return_path to POST /domains. A name that already holds another service's records is refused, with a free one suggested.
• Change it later. The domain's Configuration tab has a Return path row, and PATCH /domains/{domain_id} takes the same field. The sending records move to the new name; publish them there and keep the old ones until the new ones verify. The domain keeps sending in the meantime.
• In use elsewhere. If a check finds another service's record at your return path, the row says so and links to Change return path.

The domain page runs the same check the background schedule runs, every 30 seconds while it is open and for up to an hour, and each row says what the last check saw: Not found yet, Wrong value with what we saw instead, In use elsewhere when another email service holds the return path, or Found, confirming while the mail servers catch up. DNS changes can take up to an hour to show up; the background check carries on after the page stops watching, and a reload starts it again.

Under that, the row says whose turn it is. Action needed means the record is not published, or not published with this value, and nothing will change until you fix it at your registrar — the sentence beside the value says what we saw. Waiting on usmeans the record is where it should be and something on our side has not finished: our mail servers confirming it, or the certificate for a tracking hostname, which takes a few minutes. Pressing Check now looks again, but only publishing or waiting changes the answer.

• A domain is verified for sending once DKIM and the Sending records verify; the Tracking record never holds that up.
• A record that has not verified after 72 hours is marked failed. Fix the value and the page picks it up on its next check.
• DMARC is not one of the records and never holds verification up. The domain page offers a guided DMARC record under the DNS records, with reports going to an address of yours; publish one once sending verifies.
• A domain another team already verified cannot be verified by yours; see the claim flow on the domain page.