Domain authentication (DKIM, SPF, DMARC)
DKIM, SPF and DMARC set up correctly - by default
In short
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. It re-checks every domain daily.2048-bit DKIM
A key per domain, twice the size of the 1024-bit keys still common, with the private half never leaving our servers.
Aligned for strict DMARC
Signatures use d=yourdomain.com, so even adkim=s passes.
Your apex untouched
SPF and the bounce MX go on sp.yourdomain.com - no merging with your Google Workspace or Microsoft 365 SPF record.
Checked daily
If a required record disappears, you're told before mail starts failing, and sending pauses rather than signing for a domain you no longer control.
What each record is actually doing
SPF lists who may send for a name. It authenticates the envelope sender - the address bounces return to - not the `From:` header your recipient sees, which is why SPF alone has never been enough to stop spoofing.
DKIM signs the message with a private key and publishes the public half in DNS. A recipient recomputes the signature and knows the content was not altered in transit and that whoever sent it held the key.
DMARC ties the two to the domain in the `From:` header, which is the one a human reads. It passes when SPF or DKIM authenticates a domain that *aligns* with that header - and alignment is the whole point, because an unaligned pass proves only that somebody somewhere was authorised to send something.
Why the records go where they go
SPF and the bounce MX sit on an `sp.` subdomain of yours rather than on the apex. An apex SPF record would collide with the one you already publish for Google Workspace or Microsoft 365, and two SPF records on one name invalidate both.
DKIM goes on your apex under its own selector, so the signature aligns with your `From:` domain even under DMARC's strict setting. Providers that host DKIM under a sending subdomain can only ever align in relaxed mode.
The bounce record is an MX rather than a CNAME because a CNAME may not coexist with any other record at the same name, and the SPF TXT already lives there.
What it does not do
- DNS is re-checked daily. After 72 hours of continuous failure, sending from that domain is suspended - a provider that verifies once will keep signing mail for a domain long after its owner has lost control of it.
- If you already publish DMARC, leave it alone. Verification accepts any valid record, and adding a second one at the same name invalidates both.
Questions
Do I need DMARC to send with Sendpository?
No, SPF and DKIM are required; DMARC is recommended. Gmail and Yahoo require a DMARC record for bulk senders, so publish at least p=none.
Will adding Sendpository break my existing email?
No. Only the DKIM record goes on your apex, under its own selector. SPF and the bounce record live on a subdomain you use for nothing else.
Other features
Transactional email API
Sendpository sends password resets, receipts, sign-in links and notifications with one HTTPS request.
Inbound email API
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.
Email webhooks
Sendpository posts a signed JSON webhook when an email is sent, delivered, delayed, bounced, complained about, opened, clicked or received.
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.