One place to add a domain - and email authentication that tells you what actually matters

Domains could be added in two places: Settings → Domains, and again inside Settings → Email. They were separate lists that knew nothing about each other, so the same domain could exist in both, in different states, with two sets of DNS records and two Check buttons. There is now one front door. You add a domain once, in Settings → Domains, and prove you own it once. Everything else borrows it: turn on sending in Email, attach it to a website in Sites, or make it the address the CRM itself is served from. You are also no longer asked what a domain is for while you're adding it - a question that came before the domain was even verified, and which you had to answer before you could know. Adding a domain proves ownership and nothing else; what it's used for is a consequence of using it, and the row now states that in plain words rather than in badges. A fix that had been quietly infuriating: a domain waiting on DNS couldn't be removed. If you added one, marked it for the CRM app and mistyped it, it was stuck in your list permanently - it was serving nothing, but being intended for the app counted as being in use. Remove now works unless something would genuinely break, and when it won't, it tells you exactly what to undo first: the website publishing on it, the sending addresses using it, or the CRM being served from it. Email authentication is now ranked rather than listed. DKIM, SPF, DMARC and BIMI used to look like four equally mandatory chores. Each now says what it does, how much it matters and what happens if you skip it - DKIM required, SPF and DMARC recommended, BIMI optional. Two are new. An optional bounce address puts SPF on a subdomain you own instead of Amazon's, so your mail passes on either SPF or DKIM rather than DKIM alone; it only ever touches a dedicated subdomain, so it can't disturb the SPF record covering your everyday business email. And DMARC is now read and explained - including the trap where a sending subdomain inherits its policy from the root domain, or has it overridden by an sp= tag, which is how people end up at p=reject on paper and unprotected in practice. We never publish or change your DMARC record: it governs every system that sends as your domain, not just us. Where you have none, we offer a monitoring-only value to copy. BIMI - your logo beside your emails - is there too, deliberately labelled optional and gated on DMARC actually being at enforcement across all your mail, which is the usual reason a BIMI setup silently never shows up. And who owns a domain is now decided by DNS, not by who typed it first. Adding a domain used to claim it globally: if any other workspace had already added acme.com - verified or not, in use or not - you simply couldn't, and there was no way through except contacting us. Registering a domain now claims nothing. Several workspaces can be part-way through setting up the same one, and the first to publish the DNS record keeps it; the others are told plainly that it's gone rather than being left with a domain that never turns green. If a verified domain later loses its DNS record, it releases the name for whoever proves it next. Finally, one-click DNS setup is live for providers that support the open Domain Connect standard: you approve the records at your own DNS provider and they're created there, with no credentials ever reaching us.