Quickstart
Start with a domain you control and an address where you can receive a test message.
1. Verify a sending domain
Add your domain under Domains in the dashboard. Publish the records the domain page shows, including ownership verification when requested. New domains require SPF, DKIM, DMARC and the two MX records. Older domains may show a different set of required records.
Use the exact hosts and values shown for your domain. You do not need to configure reverse DNS yourself.
Domain verification covers the setup. DNS records explains each record and how to enter it at your provider.
DNS changes can take time to become visible. If verification fails, check the value reported under each record before retrying.
2. Create credentials
For an SDK or HTTP integration, create an API key with the sending scope under API Keys & SMTP. Save it in your application's server environment.
For an existing SMTP mailer, create a separate SMTP credential. API keys and SMTP passwords are not interchangeable.
Sending a campaign entirely from the dashboard does not require an API key. Follow the campaign guide after verifying your domain.
3. Choose your integration
Each SDK quickstart includes installation, a complete send example and how to read the result.
| Integration | Start here |
|---|---|
| Node.js / TypeScript | Send with the JavaScript SDK |
| Next.js | Send from server-side code |
| Python | Use the sync or async client |
| Go | Send with a context |
| PHP | Send with the PHP SDK |
| Laravel | Configure the SDK or SMTP |
| WordPress | Configure an SMTP plugin |
| HTTP | Make a cURL request |
Replace the example sender with an address at your verified domain and send to yourself. A verified mail.example.com authorizes hello@mail.example.com, not hello@example.com.
For a simulation, use a test API key or a sandbox recipient. Domain verification still applies. SMTP sends are live.
4. Check the result
The API returns an email ID when the request is accepted. Find it in Activity and open its timeline.
Delivered means the receiving server accepted the message. Delivery can be delayed, and the message can still land in spam. Use webhooks when your application needs to record the outcome.
If something fails
| Symptom | Check |
|---|---|
| Domain stays unverified | Publish every required record, including ownership proof if shown; inspect the reported DNS result |
authentication_failed | The server environment contains the right API key, without an extra Bearer prefix passed to the SDK |
insufficient_scope | The key has sending permission |
domain_not_found or domain_not_verified | The from address uses a domain verified in the key's workspace |
| Repeated runs return the same ID | The example reuses an idempotency key; use a new key for a new logical send |
| Accepted but not delivered | Read the timeline for deferrals or failures |
| Delivered but not visible | Check the recipient address, spam folder and mailbox rules |
After the first send
- Verify webhook signatures before acting on events.
- Keep retries safe across worker restarts.
- Understand bounces before sending to a larger list.
- Choose tracking settings for each stream.