Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Choose the sending identity before changing DNS
Kit's current verified-sending-domain guide supports both an apex domain and a subdomain. It describes customer-domain SPF and DKIM authentication and a changed Return-Path after verification. Use the actual account-generated records and received identities rather than assuming a particular selector, alias count or exact envelope address from a public example. Kit verified sending domains.
Record the account, intended From address, DNS owner and active broadcasts or automations. Inventory the domains used by each flow and preserve existing DNS before adding anything. A domain used for a newsletter website or landing-page URL has a different job from an email authentication domain. Do not change website records simply because the same brand appears in the sending address.
Choose whether the existing domain or an approved subdomain fits the mail program. Document how the From address, reply mailbox and subscriber expectations will remain consistent. A separate sending subdomain is an operational choice, not an excuse to avoid testing alignment or to disregard the parent domain's policy.
Add the account-issued records and validate
Open Settings > Email > Verified Sending Domains, add the chosen domain and obtain its DNS instructions. Kit offers an Entri-assisted setup and a manual route. In manual setup, copy the supplied records into authoritative DNS and select Validate. Confirm whether the DNS editor expects relative or fully qualified owners. Kit setup procedure.
Choose the setup method with the domain administrator. Review any access or changes requested by an assisted configuration flow before granting them. Manual publication is useful when organizational controls require an explicit record-by-record change. In either case, save a before-and-after record worksheet and query the published values independently of the application badge.
Do not overwrite a CNAME owner belonging to another integration. Resolve the conflict with the relevant service owners and Kit support, then validate again. Keep authentication aliases under change control during later DNS migrations. A record that disappears after a website move can break sending even though the campaign settings did not change.
Preserve DMARC and verify alignment separately
Kit provides a default monitoring DMARC record when it does not detect an existing one; its guide permits a different policy and instructs users to validate after publication. Check the actual authoritative DNS before creating anything and retain the domain's approved policy. Kit DMARC setup.
Publish one valid DMARC policy at the applicable owner. Do not replace enforcement with the setup wizard's permissive default without a separate decision from the domain owner. Monitoring policy is not equivalent to blocking impersonation. Review reporting destinations and other legitimate senders before making enforcement changes. DMARC specification.
Inspect both authentication paths on received messages. SPF evaluates the SMTP envelope domain; DKIM supplies the d= signing domain and s= selector. Each passing domain must be assessed against the visible From domain under the actual alignment mode. A provider statement that verification supports DMARC is useful setup evidence, but it cannot substitute for the specific account's message. SPF and DKIM.
If the account shows a domain as verified but a broadcast uses a different From address, investigate that sender choice before repeatedly editing DNS. Similarly, retain every signature in the evidence rather than assuming the first DKIM header is the one that establishes alignment.
Roll out with a controlled audience and original evidence
Kit recommends beginning with engaged subscribers, temporarily suppressing cold subscribers and avoiding other major sending changes during the transition. Treat that as a reputation-management plan rather than a guarantee about opens or inbox placement. Kit preparation guidance.
First complete technical tests with controlled recipients. This original acceptance plan has not been executed: create a received-message identity table with separate rows for a broadcast, a representative sequence or automation, and any additional From domain. Record account, workflow, timestamp, expected and actual From, Return-Path, trusted SPF identity/result, all DKIM d=/s= pairs/results, trusted DMARC result and restricted original-message location.
Add checks for reply delivery, intended subscriber selection and the expected automation trigger. Do not send a production sequence to a broad list merely to obtain authentication evidence. Once controlled rows pass, expand volume deliberately under the campaign owner's plan and watch delivery errors and complaints alongside engagement. A change in open rate alone does not identify a DNS or alignment fault.
On a failed row, pause the affected rollout and compare current authoritative records with the saved account instructions. Check the exact From selection, observed selector and signing domain before altering policy. Use a provider-supported recovery plan and avoid removing a verified sending domain or DMARC record while active mail still depends on it. Kit retention warning.
No Kit tenant, live DNS answer or received message was tested here. Account-specific records, the completed original identity table, controlled business-flow tests and human SME approval remain open production gates.