Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Choose the email route before changing DNS
Klaviyo documents separate branded sending domains for marketing, transactional and service email. Identify which route the change covers before collecting DNS records. A marketing campaign does not prove that a transactional flow or Helpdesk reply uses the same domain. Record the account, business owner, visible From address, sending workflow and current active domain. Klaviyo branded domain setup.
Choose an unused sending subdomain and check whether another application already uses it. The current setup requires distinct subdomains for different send types in one account, with the same root domain across its branded sending domains. Preserve current DNS records and scheduled sends in a change record. Assign a DNS owner and an operator who can pause the affected workflow. Treat a service-domain change as a customer-support change too: service traffic includes incoming replies, so recovery must protect that function as well as outbound authentication.
Generate and publish the account records
Open Settings > Domains > Add domain, select the email type, confirm the root domain and specify the subdomain. Choose Dynamic or Static routing and obtain the records generated for that configuration. Dynamic routing uses NS delegation; Static uses CNAME records. The setup also supplies a TXT ownership-verification record. Publish the account-issued set rather than a selector copied from another account or an older guide. Generate DNS records in Klaviyo.
Prepare a worksheet with the full DNS owner name, record type, value, existing answer and responsible person. Check whether the DNS interface automatically appends the zone name. For a delegated subdomain, confirm exactly which namespace is being delegated and who will maintain it. Do not replace the root domain's nameservers as a substitute for the requested subdomain records. Review automatic DNS setup permissions before authorizing any third-party configuration service.
Return to Klaviyo, verify the domain and activate it for the intended email type. Keep the DNS answers and resulting account status together. Activation is a configuration milestone, not proof that every live workflow now produces aligned mail. For migrations, follow the current domain-transition instructions rather than deleting working records to make the new setup screen look clean. Deactivating a service domain stops incoming customer email; deactivating a domain with associated dedicated click tracking also removes that tracking domain. Plan those dependencies before changing static/dynamic routing. Existing legacy kl1/kl2 selectors continue to work and need not be replaced merely because new configurations use send-type-specific pairs.
Separate authentication from alignment
Klaviyo says its generated NS or CNAME configuration enables SPF and DKIM. It does not require adding a Klaviyo include to the root domain's SPF record. The actual Return-Path can use a shared Klaviyo domain, the branded domain or a subdomain of it. Branded mail can have both a customer-domain and a shared-domain DKIM signature. Inspect all signatures rather than stopping at the first passing result. Klaviyo domain identities.
SPF authenticates the SMTP envelope identity. DKIM validates a signature associated with its d= domain. DMARC compares successful authentication identities with the visible From domain and needs at least one aligned passing path. Relaxed and strict alignment require different domain relationships; strict alignment needs an exact match. A passing shared-domain signature alone does not establish alignment for a customer's From address. SPF, DKIM and DMARC.
Review any existing DMARC record before adding one. Klaviyo's optional initial policy does not justify replacing an established policy or publishing a second record. A domain-wide change can affect employee mail and other providers. Agree policy ownership and reporting destinations separately from this service setup. Klaviyo authentication guidance.
Verify a received message from every covered type
Original acceptance worksheet, not an executed test: use controlled recipients and harmless content to send through each changed production-equivalent workflow. Record the account, email type, message identifier, time and intended From address. Preserve the original message source and create a received-message identity table containing the actual From domain, Return-Path, receiver SPF identity and result, every DKIM d= and s= pair, and the trusted receiving system's DMARC result.
Compare the observed domains with the intended policy and record which successful path aligns. For service mail, separately verify that a controlled reply reaches the correct support destination. For a transactional route, use the actual designated flow rather than treating a campaign preview as equivalent. Keep the evidence in a restricted location because message content and addresses can identify customers or staff.
Accept only the workflows whose identity table supports the intended outcome. If verification fails, compare the full record names, routing choice, active email type and From domain before changing policy. Pause the affected transition when necessary and restore only the changes covered by the recovery plan. Authentication success does not guarantee inbox placement, so investigate delivery and reputation separately.
No live Klaviyo tenant, authoritative DNS record or received message was tested here. Current tenant instructions, published-record evidence and the original received-message identity table from each exact route remain mandatory evidence gates, followed by independent technical and human SME review before publication or production approval.