Verified sending domains with DKIM, SPF and DMARC
Add a domain and we generate the exact records it needs. Publish them, and verification runs on its own until every one resolves and the domain can send.
| Type | Name | Value | Status |
|---|---|---|---|
| TXT | rasket._domainkey | p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A… | verified |
| MX | send | feedback-smtp.… (10) | verified |
| TXT | send | v=spf1 include:… ~all | pending |
Re-checked on a schedule until every row resolves.
What a verified sending domain gives you
A domain is the identity your mail is signed with. Adding one is a form or a single call, and everything after it is generated for you.
Verification that runs on its own
We check the records you publish as soon as you add the domain and keep re-checking on a schedule, so nothing has to poll. Each record has its own status, and one that verified and later stops resolving is reported as drifted rather than quietly ignored.
A 2048-bit signing key per domain
The DKIM keypair is made when you add the domain and the private half is encrypted at rest. You publish the public half as a TXT record under the rasket._domainkey selector.
A return path of your own
The MAIL FROM records under send.yourdomain mean bounces and complaints come back to us and land on the message's timeline, instead of arriving at your own mail server.
Ownership proved in DNS
A name can be verified on one team at a time. Taking one over means publishing a TXT record at its root, and that is the only route: no support ticket and no override.
The same records in the dashboard and the API
The record set is on the domain page and in the API response, each row beside what DNS answered for it on the last check.
How domain verification works
Three steps, and the only work that is yours is pasting records into your DNS provider.
- 1
Add the domain
One call or one form. A subdomain such as send.acme.example keeps your transactional reputation separate from everything else the root domain does.
- 2
Publish the records we generate
A DKIM record and the two return-path records, exactly as given, at your DNS provider. If your DNS is on Cloudflare, connect your account and we write them for you.
- 3
Verify, then send
Checking starts by itself, and you can ask for one now instead of waiting. Once the domain is verified every message from it is signed, and sending is allowed.
Add a domain and read back its records
curl -X POST https://api.rasket.com/domains \ -H "Authorization: Bearer rk_..." \ -d '{ "name": "send.acme.example" }'
{ "name": "send.acme.example", "status": "not_started", "records": [ { "type": "TXT", "name": "rasket._domainkey", … }, { "type": "MX", "name": "send", "priority": 10, … }, { "type": "TXT", "name": "send", … } ]}Values are shortened here. The response carries each one in full, beside the status of every record.
DKIM, SPF and DMARC, and what each record does
Three records get a domain sending. Here is what each one is actually for, and the fourth one nobody generates for you.
DKIM signs the message
A receiving server uses the public key at rasket._domainkey to check that the message it is holding is the one we sent and that nothing was changed on the way. The key is 2048-bit, so the value is published as two quoted strings, which nearly every provider handles for you.
SPF and the return path go together
The two records at send.yourdomain set the envelope sender for your mail. They are what makes a receiver's SPF check pass, and what makes a bounce come back to us so it can be recorded and the address suppressed.
DMARC is yours to choose
DMARC is not required to verify a domain and we do not publish one for you. It is worth adding at your own pace, starting at p=none. Publish our records and verify first: a domain already on p=reject can have mail rejected until alignment is in place.
Open and click tracking add one more record, and a domain verifies for sending without it. The tracking guide covers that on its own.
Subdomains, regions and claiming a name
The three decisions people ask about before they add their first domain.
Sending from a subdomain
Adding send.acme.example rather than acme.example is the shape we recommend. Every record nests under the subdomain, so nothing collides with what your mailbox provider already publishes at the root, and a reputation problem on one stream never reaches the other.
Choosing a region
Each domain has a region, picked when you create it and fixed after that. It selects where your mail is signed and relayed from, which is a deliverability and latency choice. It does not decide where your data is stored.
Claiming a name another team verified
Adding a domain another team has already verified is refused, and a claim is how you take it over. We give you a TXT record to publish at the root of the domain; when it resolves, the domain moves to your team and the other copy is switched off. The transfer waits while the current owner is still active on the name, and a claim expires after seven days.
Related features and domain documentation
The features a verified domain unlocks, and the reference pages behind every claim on this page.
- Email API: what a verified domain lets you send
- Receiving: turn the same domain into an inbox
- Webhooks: domain events posted to your endpoint
- Domains reference: every field and every route
- Quickstart: add a domain and send in five steps
- Tracking: the one extra record opens and clicks need
How many domains a team may verify is part of its plan. See what each plan includes.
Questions about sending domains
Do I need to move my DNS?
No. Your DNS stays exactly where it is and you add three records to it. If your DNS is on Cloudflare you can connect your account and we publish them for you. We use that access for that one write and do not keep it.
Can I send from a subdomain?
Yes, and it is what we recommend. Adding send.acme.example rather than acme.example keeps your transactional reputation separate from the rest of your mail, and our records never collide with the ones your mailbox provider already publishes at the root.
How long does verification take?
That depends on how quickly your DNS provider publishes the change. We check as soon as you add the domain and keep re-checking on a schedule, so a record verifies on its own once it resolves and you never have to poll. You can also ask for a check now, up to once a minute per domain.
Do I need a DMARC record?
Not to verify a domain, and we do not publish one for you. It is worth adding, starting at p=none and tightening once the reports look right. If your domain already publishes p=reject, publish our records and verify before you send, or mail may be rejected until alignment is in place.
What if another team already verified my domain?
Adding it is refused, and claiming it is the only way to take it over. Publish the TXT record the claim gives you at the root of the domain, and when it resolves the domain moves to your team with fresh DKIM records of its own. A claim expires after seven days.
How many domains can I add?
The number of sending domains is part of your plan, and every plan includes some. Each domain gets its own signing key, its own record set and its own status. The pricing page lists what each plan allows.
Verify a domain this morning
Add a domain, paste three records into your DNS, and send from it as soon as they resolve.