Inbound email API
Receive email on your domain - through an API
In short
Sendpository receives email for addresses on your own domain - support@, replies@, or a catch-all - and delivers each message to your inbox, the API and an email.received webhook. Every message arrives with an SPF, DKIM and DMARC verdict so your automations can refuse forged senders.Addresses in seconds
A verified domain already routes its sp. subdomain to us, so support@sp.yourdomain.com works with no new DNS. Other hosts need one MX record.
Sender verdicts
SPF, DKIM and DMARC are checked on arrival and summarised as verified, failed, unverified or unchecked.
Spam filtered
Every message is scored before delivery; spam is kept and labelled, never silently dropped.
Webhook or pull
Get an email.received webhook the moment mail lands, or list and fetch messages over the API.
Example
const { data } = await sendpository.inbound.list({ status: "received" });
const message = await sendpository.inbound.get(data[0].id);
if (message.sender_verdict === "verified") {
await createTicket(message.from, message.subject, message.text);
}What arrives, and in what shape
Mail sent to an address on your verified domain is accepted, parsed and posted to your webhook as JSON: sender, recipients, subject, headers, the text and HTML bodies, and the name, type and size of every attachment. You get the parsed message rather than a raw MIME blob, so there is no multipart decoding to write.
Every inbound message carries an SPF, DKIM and DMARC verdict computed at receipt. That is the part worth building on: a reply-by-email feature that trusts the `From` header without checking alignment is a feature that accepts forged replies, and the verdict is how you decide whether to act on one.
Designing around it
Treat the webhook as at-least-once. Network failures and retries mean the same message can arrive twice, so key your handling on the message id and make the second delivery a no-op rather than a duplicate ticket.
Reply-threading works best on a token in the address itself - `support+a1b2c3@` - rather than on parsing quoted text out of the body. The token survives every mail client; quoted text does not.
What it does not do
- Attachment contents are not stored. You get the filename, type and size on the webhook payload, and the body of the message - if you need the file itself, fetch it during the webhook call.
- Inbound is per-domain, not per-address: once the domain receives, any address on it can be routed. There is no per-mailbox provisioning step.
Questions
How do I receive email with an API?
Add a receiving address on a verified domain, point its MX record at the mail server if it isn't already, and read messages from the inbound API or an email.received webhook.
Can I trust the From address on received mail?
Not on its own - anyone can write any From line. Check sender_verdict: 'verified' means the sender's domain vouched for the message through DMARC or aligned DKIM.
Are attachments stored?
Attachment names, types and sizes are recorded; the file contents are not stored. Receiving is built for mail your application processes - replies, tickets, commands - rather than as a full mailbox.
Other features
Transactional email API
Sendpository sends password resets, receipts, sign-in links and notifications with one HTTPS request.
Email webhooks
Sendpository posts a signed JSON webhook when an email is sent, delivered, delayed, bounced, complained about, opened, clicked or received.
Domain authentication (DKIM, SPF, DMARC)
Sendpository generates a 2048-bit DKIM key for every domain, signed as your own domain so it passes strict DMARC alignment, and puts its SPF and bounce records on a dedicated subdomain so your existing company email is never touched.
Scheduled email
Add scheduled_at with an ISO 8601 time to any send and Sendpository delivers it then.
Send your first email in minutes
6,000 emails a month (up to 200 a day), free forever. No card needed.