Skip to content
New: simulate any flow against real records before it goes live. See what's new →

Email Infrastructure

Inbox placement, treated as engineering

Domain authentication ranked by what actually matters, automatic bounce handling, warm-up ramps, link domains that match your sending domain — the unglamorous details that decide whether mail lands.

Sending domains and sender identities with verification status

Verification without tickets

Add the DNS records; Solstral polls and confirms automatically. Status is always current in settings.

Told what matters, in order

DKIM is required, SPF and DMARC are recommended, BIMI is optional — and each one says what it does and what happens if you skip it, rather than presenting four equal-looking chores.

Bounces handled in seconds

Hard bounces and complaints suppress the address platform-wide before your next send can touch it.

Warm-up on rails

New domains ramp gradually on a managed schedule instead of torching their reputation on day one — and while a domain is warming, its first sends go to your most engaged contacts, because those first few hundred messages are the entire evidence base a provider has to judge you on.

What the receiver actually thinks

Google's own rating of your domain and its users' spam-report rate, read straight from Postmaster Tools. Every other number in email software is the sender's view of what happened, and it is blind in one specific place: a message filed into spam is still delivered.

Test where it lands, not whether it sent

Send a campaign to real Gmail, Outlook, Yahoo and Apple mailboxes and see which folder each one filed it in. Everything else on the review screen predicts; this measures.

Your DMARC reports, read for you

Publish one address and the daily XML every mailbox provider sends becomes a plain list: who is sending as you, what is failing, and whether it is safe to tighten your policy yet.

Bad addresses caught at import

Typo'd domains, domains with no mail server, disposable inboxes and obvious test data are flagged in the import preview — a warning, never a block, because a shared sales@ address can be a real subscriber.

Replies come back on your domain

Turn it on and replies route to reply.yourdomain.com instead of a shared address on ours — so the Reply-To matches the address you send from. Reply-To isn't part of SPF, DKIM or DMARC and can't fail authentication, but a reply address on somebody else's domain is the shape phishing takes, and filters and people both notice. One MX record.

Require encryption on mail sent TO you

MTA-STS publishes a policy telling other mail servers that mail for your domain must arrive over an encrypted connection, and only at the mail servers you name. It is the one deliverability setting that governs mail arriving rather than mail you send — so it starts in a testing mode where senders report problems and deliver anyway, it shows you the exact list of mail servers before anything is published, and requiring encryption only unlocks once your TLS reports show a clean run. We host the policy file and issue the certificate; you publish two records.

Nothing invites a reply that bounces

A send-only address has no mailbox behind it, so a reply to one is rejected at the recipient's server — worse than useless, because they think they answered you. Every email the product sends now carries a Reply-To that reaches a real destination: meeting invites, reminders, survey requests, confirmations, test sends. Except one — an address a person actually reads is left alone, because quietly diverting their mail into the CRM would be its own bug.

What's included

  • A page per sending domain — records, authentication, warm-up and footer in one place
  • DKIM verification with auto-refresh status
  • Optional custom bounce domain for SPF alignment (one MX + one TXT)
  • DMARC read and explained, including policy inherited from a parent domain
  • A DMARC record to copy at every stage — none published, inherited, or ready to move to quarantine
  • Optional BIMI with SVG validation at upload, gated on DMARC actually being at enforcement
  • Open, click, bounce and complaint tracking
  • Automatic suppression on hard bounce and complaint
  • Managed warm-up ramp per sending domain, with today's usage shown
  • One warm-up budget covering campaigns, flow marketing and one-to-one mail
  • Per-domain marketing footer — postal address, privacy and terms per brand
  • Email links on your own domain, matching your sending domain
  • One CNAME moves click tracking onto link.yourdomain.com, with the certificate issued automatically
  • DMARC aggregate reports collected, parsed and summarised — including a per-sender list of what is failing
  • A computed answer to “is it safe to enforce DMARC?”, deliberately conservative
  • Google Postmaster Tools reputation and spam rate per sending domain
  • Optional reply domain — replies arrive on reply.yourdomain.com instead of a shared address (one MX)
  • Reply-To carries your brand name, not a bare machine-generated address
  • A reply destination set per sending address: someone reads it, route it into the CRM, or forward it
  • Campaigns are blocked from sending when replies would have nowhere to land
  • Inbox placement testing across real seed mailboxes, per campaign
  • Address quality checks at import — syntax, typo’d domains, missing MX, role accounts, disposable inboxes
  • Dead-link and link-domain-mismatch checks before a campaign sends
  • One-click unsubscribe headers (RFC 8058) on every marketing send, test sends included
  • Optional engagement sunsetting — off by default, asks before it stops, reversible on any open, click or reply
  • MTA-STS policy hosting on mta-sts.yourdomain.com, certificate issued automatically (two records)
  • Mail-server list discovered from your MX and re-checked daily, so a provider migration re-publishes rather than breaking
  • Testing mode first, always — enforcement is gated on a clean TLS-RPT window and is never the default
  • Switching MTA-STS off publishes a withdrawal and waits out the old policy before removing anything
  • TLS reporting (TLS-RPT) collected and summarised per domain
  • Inbound reply threading onto records, routed to the right shared mailbox

Try Deliverability on your own data

Free plan, no card, set up in an afternoon.