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

Email Infrastructure

You can send from your root domain without touching your website

If your website lives at acme.com, you could not send from info@acme.com.

If your website lives at acme.com, you could not send from info@acme.com. Not because of anything to do with DNS - because of us.

What was wrong

A domain had to be verified before you could send from it, and verifying meant pointing the domain at Solstral and waiting for a certificate. That is the right requirement for a domain serving your website or your CRM login. It is the wrong one for email, and at a root domain the record it asks for is your website.

So the customers most likely to want a root-domain address - anyone with a live marketing site - were the ones who could never have one. The product was telling them their DNS could not do something their DNS was perfectly capable of.

What changed

Proving you own a domain and pointing a domain at us are now two separate things. Sending needs the first. Hosting needs both.

Every record email asks for sits on a subdomain - _domainkey, bounce, link, _dmarc. Nothing is added or changed at the root, so the record serving your website is untouched and so is the MX record carrying the mail you already receive. That was always true; the product just would not let you act on it.

Adding a domain now asks one question: is it for sending email, or for hosting a website or the CRM? The answer decides which records you are asked for, and it is not a decision you can get stuck on - attaching a site to an email-only domain adds the hosting records at that point.

One set of records, one sitting

Your DKIM records are themselves proof you control the domain: nobody can publish them on a zone they do not hold. So there is no separate ownership record to publish first and no second trip to your DNS host - you publish the records for sending and the domain verifies on those.

The bounce address is also set up automatically now rather than waiting behind a toggle. Without it your SPF authenticates against Amazon’s domain instead of yours, which leaves DMARC relying on DKIM alone. It has always been available; it now arrives in the same list as everything else, so there is one visit to your DNS panel instead of three.

The DNS screen tells you which record is wrong

It used to be a flat list of name-and-value pairs with no status on it, sitting under a separate panel that reported status per feature. Nine records, one typo, and the only thing on screen was that the domain was still pending.

It is now one list, grouped by what each record actually does for you - Required (nothing sends without it), Recommended (it sends, but lands worse) and Optional - with a light on every row: green when we can see it in your DNS, amber when we cannot yet. Each record opens to show what to paste and says in one line why it is being asked for. Optional extras start collapsed, so a domain that is sending perfectly stops looking like it has six unfinished jobs.

And an address with no mailbox behind it

Adding info@ or hello@ used to send a confirmation link to an inbox that does not exist. There has always been a path for organisation-owned addresses that needs no link - the verified domain is the proof - but it lived in a different card, so nobody found it. Say the address belongs to the organisation rather than to you and it is added straight away, with replies routed into the CRM and threaded onto the right record.

Get the new stuff the day it ships

Every plan runs the same, latest platform.