Email verification and sending at organisational scale
Dedicated IPs, your own sending domains, role-based team access and a documented data-processing position — for teams where email volume and compliance both matter.
What you get
- Dedicated sending IPs, so your reputation is not shared with other senders
- Custom sending domains with DKIM and SPF provisioned and repaired automatically
- Team accounts with role-based access rather than one shared login
- A Data Processing Agreement and documented retention and deletion behaviour
Dedicated
Sending IPs available
Your volume builds your own reputation instead of inheriting a shared pool.
Per-user
DKIM keys and domains
Each account signs with its own key pair on its own sending subdomain.
Documented
Retention and deletion
Data-subject rights and retention windows are written down, not improvised.
What changes at scale
The mechanics of sending do not change with volume — the consequences do. At a few thousand addresses a bad import is an embarrassing campaign. At several hundred thousand it is a blocklist entry affecting every message your organisation sends, including transactional mail nobody thought of as marketing.
| Small sender | At organisational scale | |
|---|---|---|
| A bad import | One weak campaign | A domain-level reputation hit affecting all mail |
| Sending IP | Shared pool is usually better | Dedicated IP, reputation you own |
| Access | One login | Role-separated: campaigns, billing, administration |
| Compliance | Privacy policy | DPA, documented retention, data-subject request handling |
| Integration | CSV upload | API at the point of capture, webhooks for events |
Infrastructure you control
Dedicated sending IPs
Reputation built by your own traffic. Appropriate for consistent volume — a dedicated IP needs steady sending to establish itself.
Custom sending domains
Send from a domain you control, with DKIM signing and SPF in place, rather than from shared infrastructure that carries other senders' history.
Automatic DNS provisioning and repair
DKIM keys, SPF and A records are created on provisioning, then verified and repaired pre-flight before each send.
Team accounts and roles
Separate permissions for campaigns, billing and administration, so access reflects responsibility instead of one shared password.
Volume controls and scheduling
Daily sending limits, automatic pause and resume, and scheduled or recurring campaigns rather than manual dispatch.
Documented compliance position
A published DPA, defined retention windows and deletion paths for data-subject requests.
Where verification belongs in a larger stack
At scale, cleaning a list once a quarter is not the goal — keeping bad data out of the systems that feed it is. That means verification at the boundary rather than as a periodic cleanup job.
- 1
Verify at the point of capture
Call the API from your signup forms, CRM imports and data-entry paths so an invalid address is rejected before it enters any downstream system.
- 2
Re-verify before large campaigns
Segments that have not been mailed recently decay silently. A pre-send pass turns a would-be bounce into a removal at no reputational cost.
- 3
Separate your sending streams
Keep transactional and marketing traffic distinguishable so a marketing reputation problem does not take password resets down with it.
- 4
Monitor authentication continuously
SPF, DKIM and DMARC records drift as infrastructure changes. A pre-flight check before each send catches drift rather than discovering it through a delivery failure.
- 5
Route events into your own systems
Use webhooks to feed bounces, opens and clicks back into your warehouse or CRM, so suppression is enforced everywhere rather than only inside one tool.
Bring your requirements, not just your volume
Dedicated IP suitability, team structure, DPA review and integration questions are better answered against your actual setup than a feature list.
Talk to usBeing straight about the limits
Procurement goes faster when the gaps are stated up front rather than discovered in a security review.
- No single sign-on. Access is managed through team accounts with role-based permissions.
- No CRM or contact-lifecycle automation — automation here is campaign-triggered follow-up over engagement segments.
- No SMS, WhatsApp or push channels. Email only.
- No per-recipient timezone sending; a campaign fires at one moment for the whole list.
If any of those are hard requirements, it is better to know now. If your problem is deliverability, list quality and sending infrastructure you actually control, the rest of this page is the relevant part.
Frequently asked questions
Yes. Dedicated IPs mean your sending reputation is built by your own traffic rather than shared with other senders. They suit consistent, higher-volume sending — at low or irregular volume a shared pool usually performs better, because a dedicated IP needs steady traffic to establish reputation.
Team accounts support role-based access rather than a single shared login, so campaign, billing and administrative permissions can be separated. Team members are provisioned with their own entitlements rather than sharing one seat.
Yes — a DPA is published, alongside a documented position on retention windows, data-subject rights and deletion behaviour. Verification is a processing activity, so this is worth reviewing with your legal team before procurement rather than after.
Yes. There is a public API with key-based authentication and webhooks for event delivery, so verification can run at the point of capture inside your own signup, CRM or data-quality pipeline.
Retention behaviour is documented rather than left vague. Two separate clocks apply — one governing what remains visible to your account, one governing existence in storage — and deletion paths exist for data-subject requests.
Not currently. Access is managed through team accounts with role-based permissions. If SSO is a procurement requirement, raise it with us directly rather than assuming it is available.
Each account is provisioned a unique sending subdomain with its own DKIM key pair, and the required DNS records are created automatically. A pre-flight check verifies and repairs those records before each send rather than failing silently.
Discuss your volume and requirements
Dedicated IPs, team structure and procurement questions.