Your sending reputation should be yours alone
Reputation attaches to the domain, not to your account. Bring your own domain and it sends for you and nobody else. You publish three DNS records; SpiderMail only reads them back.
What you get
Your domain, your pool
A verified domain joins your sending pool and nobody else's. Reputation does not transfer across domains, so another tenant's outreach cannot reach your inbox placement, and yours cannot reach theirs.
Your own provider key
Sending credentials are stored encrypted per tenant and used only for your mail. Your sending runs on your account, not on a shared one.
We read, we never write
Verification is an ordinary public DNS lookup. SpiderMail holds no credential to your zone, so changing your DNS is something only you can do.
Three answers, not two
Every record check returns matched, did not match, or could not be read. An unreadable zone is reported as unknown rather than as a failure, and a domain is verified only when every check passes.
Deliverability per source
Bounce and complaint rates are reported for each sending domain rather than blended into one number, so when something drifts you can see which domain drifted.
It stops itself
A source that crosses 0.3% complaints pauses and raises an alert. The mail already queued behind it is held rather than dropped, so nothing is lost while you look at it.
Why a shared pool is the problem
Most platforms that send on your behalf do it from a pool of their own domains. It is the obvious design, and it means your inbox placement depends on the behaviour of customers you have never met. One of them runs an aggressive campaign against a stale list, complaints climb, and the receiving providers score the domain rather than the tenant. Everyone sending from it starts landing in Promotions.
You cannot fix that by being careful, because being careful is not the variable. The fix is a boundary: if the domain is the unit receivers score, it is also the unit of isolation.
What setup actually involves
You publish SPF, a DKIM key and a CNAME for click tracking in your own zone. SpiderMail reads them back over a public resolver and reports each record separately, so a failed check names the exact record to fix rather than telling you the domain is wrong. Once every check passes, you choose which mailbox the domain sends through and supply your provider key.
A newly enrolled domain starts in a warming state and ramps up rather than sending at full volume immediately. A domain with no sending history that suddenly sends thousands of messages is the exact pattern spam filters exist to catch.
The step-by-step version is in the setup guide, and every route, parameter and error code is in the send tier API reference.
Available without the dashboard
The whole tier is reachable from the command line and from an agent. The SpiderMail skill teaches an agent the send tier, including the trap that matters most: a queued broadcast is not a sent one.
Put your own domain in the pool
Three DNS records and about ten minutes, plus however long your DNS takes to propagate. You can run the check as often as you like before committing to anything.
Read the setup guide