Domains
Why verification exists, what each DNS record does, and how to fix a domain that won't verify.
Updated
Nothing sends until a domain is verified, so this is the first thing to do. This page covers why that is, what each record does, and what to check when a domain will not verify.
Why verification exists
Anyone can put any address in an email's From field. Nothing in the mail
protocol stops it - that's why phishing works. So mailbox providers ignore the
From field on its own and check the DNS of the domain it claims to be from.
Verification is you publishing records that say: this service may send on my behalf, and here's how to check its signature.
Without it, your mail goes to spam or is rejected outright.
Domains you can use
Use a domain you own, or a subdomain of it: yourdomain.com, mail.yourdomain.com.
Addresses on shared hosting - yourapp.vercel.app, yourapp.netlify.app,
you.github.io, you.duckdns.org and the like - can't be added: you don't
control their DNS, and mail from them is too easy to forge for a shared
sending platform to accept.
The records
When you add a domain we generate four records. Three are required; DMARC is recommended.
Everything we ask you to publish sits on a sp. subdomain you use for
nothing else, except the DKIM key. Your apex domain is left alone, so adding
Sendpository cannot disturb the mail your company already sends through Google
Workspace or Microsoft 365.
Names are the label, not the whole thing
DNS panels add your domain to whatever you type in the Name box, so each record below shows the part you actually enter, with the full name beside it. The dashboard does the same - it prints the label in black and the rest in grey, and Copy gives you the black part. On the rare panel that wants the whole name, use both together.
TTL is a caching hint, not part of the record. An hour is a safe default and whatever your panel pre-fills is just as fine.
SPF - who may send
Type TXT
Name sp (becomes sp.yourdomain.com)
Value v=spf1 include:spf.sendpository.com -all
TTL 3600Lists the servers allowed to send from sp.yourdomain.com.
Note the -all. That is a hard fail: anything else claiming to send from
this name is rejected outright, not merely flagged. Most providers ship ~all,
a soft fail, because their SPF record sits on your apex where a hard fail would
reject your own staff email. Ours can be strict because the name is exclusively
ours - nothing of yours sends from it.
No merging needed
Because this record is on its own subdomain, there is nothing to merge. If you have an existing SPF record on your apex for Google Workspace or Microsoft 365, leave it exactly as it is.
DKIM - the signature key
Type TXT
Name sxxxxxxx._domainkey (becomes sxxxxxxx._domainkey.yourdomain.com)
Value v=DKIM1; k=rsa; p=MIIBIjANBgkq...
TTL 3600We sign every message with a private key; this publishes the public half so recipients can verify the signature. The key is 2048-bit, generated per domain, and never leaves our servers.
This one record is on your apex rather than the sp. subdomain, deliberately.
It makes the signature's domain match your From domain exactly, so it
satisfies DMARC alignment even under the strict setting (adkim=s). Providers
that host DKIM under the sending subdomain only ever align in relaxed mode.
Long values get split
DKIM values exceed the 255-character limit for a single DNS string, so most providers split them into chunks automatically. That's normal - paste the whole value and let the provider handle it.
Return-Path - where bounces go
Type MX
Name sp (becomes sp.yourdomain.com)
Value mail.sendpository.com
Priority 10
TTL 3600Bounces come back to us instead of to your From address, so we can process
them and add dead addresses to your suppression list.
This is an MX record rather than a CNAME for a structural reason: a CNAME may not coexist with any other record at the same name (RFC 1034), and the SPF TXT above already lives there.
It is required, not optional, and that is the point of the whole layout. The envelope sender of your mail becomes a name inside your own domain, which is what lets SPF align for DMARC. Without it, SPF authenticates our domain rather than yours and DMARC has to rest on DKIM alone.
DMARC - the policy
Type TXT
Name _dmarc (becomes _dmarc.yourdomain.com)
Value v=DMARC1; p=none; rua=mailto:dmarc@sendpository.com
TTL 3600Tells providers what to do when a message fails SPF and DKIM. We start at
p=none - monitor, don't reject - which is the right setting while you're
establishing a sending history.
Already publish DMARC? Change nothing
This is the one record in the set your domain may already use, and it is the
only one that can conflict. Two DMARC records on a name are invalid and both
are ignored - so adding ours beside an existing p=reject would quietly
switch that policy off.
Verification accepts any valid DMARC record, so if you already have one this shows as satisfied and there is nothing to do. Ours is a starting point for domains that have none.
Verifying
Press Verify after publishing. We do a live DNS lookup - nothing is simulated, and a domain only turns green when the records actually resolve.
SPF, DKIM and the Return-Path MX are required. DMARC affects reporting rather than whether mail authenticates, so it doesn't block verification.
When it stays pending
| Cause | What to do |
|---|---|
| DNS hasn't propagated | Wait a few minutes and press Verify again. |
| Provider appended your domain | Enter the label only - sp, _dmarc, sxxxxxxx._domainkey - which is what the dashboard shows in black. Pasting the full name makes some panels store sp.yourdomain.com.yourdomain.com; others (Hostinger among them) strip the extra and are fine either way. Some warn you and offer to fix it; accept. |
| MX entered without a priority | Some panels need the priority (10) in its own field. |
| Value was truncated on paste | Re-copy the DKIM value in full. |
Check what's actually published from your terminal:
dig +short TXT sp.yourdomain.com
dig +short MX sp.yourdomain.com
dig +short TXT sxxxxxxx._domainkey.yourdomain.comIf those return nothing, the records aren't live yet - the problem is at your DNS provider, not here.
Sending addresses
Once verified, you can send from any address on that domain - the apex, not the sp. subdomain. None of them
need to be a real inbox:
noreply@yourdomain.com
receipts@yourdomain.com
alerts@yourdomain.comSet reply_to if you want replies to reach a mailbox you actually read.
Managing domains through the API
See the Domains API for adding, listing, re-checking and deleting domains programmatically.