Quickstart
Send your first email in about two minutes — or run your first API call right now, with no domain at all.
1. Add a domain
You can only send from a domain you own. Go to Domains → Add a domain and type it in.
What happens next depends on where the domain’s DNS lives, and this is the part that is different here:
| Your situation | What you do |
|---|---|
| The domain is registered with us | Nothing. We publish every record it needs. There is no table to copy and nothing to mistype. |
| You have a domain used only for sending | Point its nameservers at us at your registrar. After that it behaves like the first row — forever. Key rotation, tracking domains and DMARC policy will never need anything from you again. |
| You want to use your main domain | Copy three DKIM records by hand — plus one MX if you switch on receiving — the way every other provider works. |
If you point a domain’s nameservers at us, we take over all of its DNS. Use a domain that is not used for anything else — one with a website or mail on it will break the moment the change propagates. We check before you switch and tell you if the domain looks like it is in use, but the check is not infallible.
A separate sending domain is the recommended practice anyway: it keeps transactional reputation off the domain your team emails from, so a bad bounce week does not touch their inbox placement.
Wait for the domain to show verified. Press Check now if you are impatient.
2. Get an API key
You already have one. The first time you open the dashboard, Get started
shows a curl with a key named Default already in it — sending access, not
tied to any domain. Copy it from there.
To make another — for a second application, or because you did not copy the first — go to API keys → Create a key and give it a name you will recognise in six months.
Two permissions:
- Sending access — can send, nothing else. Use this in your application. You can also tie it to one domain.
- Full access — can also read the message log and manage contacts.
Neither can add a domain or a key: those live in the dashboard, behind a signed-in session. See the API.
The key is shown once. We store a hash, so there is no way to show it again. Copy it now; if you lose it, create another and revoke the old one.
3. Send
Pick the one you are actually using:
- HTTP —
curl, and any language, since the API is plain JSON over HTTPS - SMTP — if your framework already speaks it, there is nothing to install
In a hurry, with no DNS access?
You can send before step 1. Every new account can send from an address we own, to four test addresses that reach Amazon’s mailbox simulator, with no domain and no DNS — see the sandbox sender. It exists precisely because “verify a domain” is a dependency that often belongs to another department.
4. Watch it arrive
Open Emails. Every message is there with its full delivery timeline — accepted, delivered, opened, bounced — including the receiving server’s own diagnostic text. That log is the thing you will actually use, because it is what answers “why did this not arrive”.
What to do next
Add a webhook so your application learns about bounces without polling. Every delivery is signed; verify it rather than trusting the source address.
Import your suppression list if you are moving from another provider. Do this before your first send — see migrating. It is the single most important step and the easiest one to skip.
Set an idempotency key on anything you might retry:
Idempotency-Key: order-4821
A repeat with the same key returns the original message instead of sending twice. Without one, a timeout leaves you unable to tell “not sent” from “sent, response lost” — and both retrying and not retrying are wrong.