Email DNS & SPF merge

Connecting a domain points web traffic at your product. Many customers also want email on that domain (Google Workspace, Microsoft 365, Zoho). Email records (MX, TXT for SPF/DKIM/DMARC) can ride the same apply rail as the web records — you include them in the records array of POST /v1/connections/{id}/apply, or the customer adds them by hand in the manual flow.

The one email-specific hazard the engine handles for you is SPF: a domain must have exactly one v=spf1 record, so blindly writing a second one silently breaks mail. That's what the SPFM meta-record is for.

SPF merge (SPFM)

Instead of a raw TXT, apply an SPFM record with the mechanisms you need. At write time the engine reads any SPF TXT already published at that host and merges your mechanisms into it — deduped, with a single terminal all, and the existing record's qualifier preserved (a merge never loosens the policy):

existing:  v=spf1 include:mailgun.org ~all      (already published)
SPFM add:  include:_spf.google.com
→ written: v=spf1 include:mailgun.org include:_spf.google.com ~all

If nothing is published yet, the SPFM record is materialized into a fresh v=spf1 … ~all TXT. This append-never-clobber behavior is applied for both Rail B (API-token apply) and the automatic rails.

Provider records (reference)

DKIM & DMARC

• DKIM keys are generated in the provider's admin console (unique per domain), so they can't be derived — add the provider's selector._domainkey record as given. The widget's DKIM step groups records flagged purpose: "dkim" onto a dedicated screen (enableDkim).
• DMARC should start at p=none (monitor only). After confirming legitimate mail passes DKIM/SPF, tighten to quarantine, then reject.

Pre-flight: POST /v1/domains:check reports spf_override_support and returns any record_conflicts (including spf-merge clashes) it observes in public DNS, so you can warn the customer before writing anything.