Receiving
Accept mail at your own domain and read it over the API or a webhook, with an SPF, DKIM and DMARC verdict on every message.
Updated
Add an address, and mail sent to it arrives in your account: readable in the dashboard, over the API, and pushed to your webhook endpoints as it lands.
Add an address
Open a verified domain under Domains, then Receiving → Add a receiving
address. Pick the mailbox (support) or * to catch everything at the host.
The host is filled in for you. A domain verified with Sendpository already publishes an MX record for its bounce address, so mail to that host reaches us already - an address there works immediately, with no new DNS.
support@sp.yourdomain.com ← works as soon as you add itTo receive at another name - your apex domain, or inbound.yourdomain.com - change
the host. The address stays Pending until you publish its MX record:
| Type | Name | Value | Priority |
|---|---|---|---|
| MX | inbound.yourdomain.com | mail.sendpository.com | 10 |
An MX on your apex takes over all your mail
yourdomain.com can have one set of MX records. Pointing them here sends every
message for that domain to Sendpository, including anything your team reads in
Google Workspace or Microsoft 365. Use a subdomain unless you mean to move the
whole domain.
Press Re-check once the record is live, or wait - we re-check every night.
Read what arrives
In the dashboard: Emails → Receiving.
Over the API, with a full-access key - a sending key cannot read your mail:
curl https://api.sendpository.com/v1/inbound \
-H "Authorization: Bearer $SENDPOSITORY_API_KEY"{
"data": [
{
"id": "9f1c7d4e-2b1a-4f3c-9d55-0a1b2c3d4e5f",
"from": "customer@example.com",
"to": "support@sp.yourdomain.com",
"subject": "Invoice question",
"status": "received",
"size_bytes": 18422,
"received_at": "2026-09-16T09:12:03.000Z"
}
],
"limit": 50,
"offset": 0,
"total": 1
}GET /v1/inbound/{id} returns the whole message, including the text and HTML
bodies. See the API reference.
Get told as it arrives
Subscribe an endpoint to email.received under Webhooks. Each delivery
carries who it is from, which address took it, the subject, the attachment
list and the first 500 characters of the text body - enough to decide what to
do without a second call:
{
"type": "email.received",
"created_at": "2026-09-16T09:12:04.000Z",
"data": {
"inbound_id": "9f1c7d4e-2b1a-4f3c-9d55-0a1b2c3d4e5f",
"to": "support@sp.yourdomain.com",
"from": "customer@example.com",
"subject": "Invoice question",
"spam": false,
"sender_verdict": "verified",
"attachments": [{ "filename": "invoice.pdf", "content_type": "application/pdf", "size": 48122 }],
"text_preview": "Hi - could you resend invoice SENT/2026-27/0184?"
}
}Webhooks are signed exactly like the sending ones - see Webhooks for verifying the signature.
Is the sender real?
Anybody can put any address in a From line. Every arriving message is checked against the sender's own DNS - SPF (was it sent from a server their domain allows?), DKIM (is it signed by their domain?) and DMARC (does their domain's policy say it passes?) - and given one verdict:
sender_verdict | Meaning |
|---|---|
verified | DMARC passed, or DKIM passed for the From domain. The domain vouches for it. |
failed | DMARC failed, or nothing passed and SPF rejected the sending server. Treat it as forged. |
unverified | The domain publishes nothing that proves it either way. Common for small senders; not proof of forgery. |
unchecked | The message arrived without what the checks need. |
The verdict is shown as a badge in the dashboard, and is on the API and on
email.received. Before an automation acts on a message - resetting a
password, paying an invoice, forwarding data - check that it is verified.
Remote images
Images hosted elsewhere are blocked when you open a message, so its sender cannot tell that - or when, or from where - it was read. Show images loads them for that message.
Spam
Messages the mail server marks as spam are stored and shown under Spam
rather than thrown away, so nothing disappears silently. They do not fire
email.received: whether to act on suspected spam is a decision for a person,
not an automation.
What is kept, and for how long
- Bodies - text and HTML, up to 256 KB each. Anything longer is stored truncated.
- Pictures - PNG, JPEG, GIF and WebP images, inline or attached, so the dashboard can show the message the way a mail app does. Up to 3 MB each and 8 MB per message; anything past that is listed like any other attachment.
- Other attachments - filename, type and size. The contents are not stored, the same as for sending. Read them from the message as it arrives if you need the bytes.
- Received mail follows the same retention windows as sent mail: bodies are cleared first, then the record itself. Both are shown on your Billing page and in the Privacy Policy.
Limits
- Your plan sets how many receiving addresses your account can have, across all its domains - see Pricing. The Receiving page shows how many you have used.
- 25 receiving addresses per domain.
- One account may own any given address - the first to add it keeps it, for as long as its domain stays verified. If that domain stops being verified, mail to it is refused and the address can be claimed by whoever verifies the domain next.
- Your plan may set a daily limit on received messages (spam included). Messages past it that day are not stored. The Receiving page shows the limit and how much of it today has used.
- Messages larger than 30 MB are refused by the mail server before they reach your account.