- Ya
- 4 Septemba 2026, 17:33 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 723ddcd
GET /api/security/domains/{id}/spf, for the SPF step on /setup/dns. The setup page cannot give one set of SPF instructions to everybody, because the right instruction depends on what the domain already publishes and the wrong one is destructive. A domain with no SPF record needs one created; a domain that already has one — most of them, since Google, Microsoft and every marketing tool publish one — needs that single record edited. "Add this record" given to the second group leaves two v=spf1 records on one name, which is a permerror: receivers ignore BOTH, so the customer's own senders stop being authenticated too. So this resolves the record first and returns the exact string to save, merged with whatever is there. The merge inserts our mechanism immediately before the terminating `all` (or a `redirect=`), because everything after those is never evaluated — appending it would produce a record that looks fixed and does nothing. Everything else about the record is preserved verbatim. It also refuses to answer where no safe answer exists, so the page has something to refuse with rather than improvising: - several SPF records already published -> MANUAL; merging them is a judgement call about senders we know nothing about - the merge would breach RFC 7208's limit of 10 DNS lookups -> flagged, and the page shows no record to paste, because saving it would invalidate the whole record including the customer's own senders Counting those lookups means following include/redirect chains as a receiver does, bounded by depth and a query budget. A record already authorizing us by ip4 or by our corporate domain counts as done — no point spending one of the ten on a mechanism that changes nothing. TXT character-strings are concatenated before parsing (RFC 7208 §3.3): real records from Google and HubSpot arrive split across several, and parsing them separately would miss the record entirely.