- Shipped
- September 4, 2026 at 5:31 PM UTC
- Author
- kamo
- Commit
- d022313
/setup/dns walked a customer through ownership, subdomains and SSL and then said nothing about the record that decides whether the mail we send for them is believed. Without it, a password reset we send as NoReply@their-domain is unauthenticated mail claiming to be from a domain we do not send for, so it is filtered to spam — the workspace looks finished while its e-mail quietly is not. Generic instructions could not be written for this, because the correct one is different per customer and the wrong one is destructive. A domain with no SPF record needs one created. A domain that already has one — which is most, since Google, Microsoft and every marketing tool publish one — needs that single record edited. Telling the second group to "add this record" leaves two v=spf1 records on the same name, which is a permerror: receivers ignore BOTH, so the customer's own senders stop being authenticated too. The page would have caused the outage it was trying to prevent. So the card reads the domain's live record first and then shows one outcome, with only the steps that apply to it: - no record -> "Add one new record", with the full value - record exists -> "Edit the record you already have", the current value to match by eye, the merged value to replace it with, and a red callout that a second record must never be created - already listed -> nothing to do - Kamo-hosted -> nothing to do; we manage it Two cases deliberately show no record to paste at all, because there is no value we could offer that is safe: a domain already publishing several SPF records (already broken, and merging them is a judgement call about senders we do not know), and a merge that would breach SPF's limit of 10 DNS lookups — saving that would invalidate the whole record, the customer's own senders included. Both ask them to talk to us instead. The step is last and never gates Enter Workspace: the workspace genuinely does work without it.