Why are Klaviyo test emails not delivering to Outlook after changing the sending domain?
Updated on 12 Oct 2026: We clarified Outlook.com requirements, Klaviyo's domain transition, and the evidence needed to trace missing test emails.
Klaviyo test emails can stop reaching Outlook after a sending domain change when the new branded sending domain is not verified for the selected send type, DKIM records are incorrect, authentication does not satisfy DMARC's domain matching requirements, or Microsoft filters the new identity. A separate possibility is that the Klaviyo account has reached its preview-email limit. The first task is to identify whether Klaviyo submitted the message before changing more DNS records.
Treat the timing as evidence, not proof. If tests work again when the old sending domain is restored, compare the old and new authentication results, Klaviyo send events, and Exchange Online message trace for Microsoft 365 recipients. The content or mailbox can still contribute, but the domain migration is the strongest place to start.
- Old domain works: Compare the old and new domain records, authentication results, and reputation.
- Quarantine is empty: An empty Microsoft quarantine does not prove that Exchange Online accepted the message.
- Preview status matters: A preview limit or alternate preview route can fail before Outlook evaluates the email.
- Authentication must match: A DMARC pass needs a passing SPF or DKIM domain that matches the visible From domain. Outlook.com's bulk sender requirements also require both SPF and DKIM to pass.
- Activation matters: Published records must resolve publicly, and Klaviyo must verify the domain. During a gradual transition, the new domain can send with a Warming status.
Why a new Klaviyo domain changes Outlook delivery
A sending domain change can alter the DKIM signing domain and the domain reputation Microsoft associates with the message. A branded sending domain is also called a dedicated sending domain; Klaviyo manages Return-Path SPF separately, and dedicated click tracking has its own configuration. Microsoft evaluates authentication alongside sending IP reputation, domain history, content, and recipient engagement. A correctly published domain can therefore authenticate and still receive different filtering from a new identity. See Klaviyo's domain explanations.
Klaviyo branded sending domain settings with a DNS record verification error.
The branded sending subdomain and the visible From domain have different jobs. Klaviyo commonly uses a unique subdomain such as send.example.com in the message headers, while the visible From address remains support@example.com. Relaxed DMARC matching accepts related subdomains, while strict matching requires an exact domain match. The visible From address should also be valid, and Reply-To should route replies when it differs from From. Reply-To does not determine a DMARC pass.
Do not add an MX record by default
A Klaviyo marketing branded sending domain does not generally need an MX record. Publish the exact DNS records Klaviyo generates for the selected send type. Klaviyo specifically requires MX for static service-type domains because those domains handle inbound support mail.
- Marketing domain: Use the routing, DKIM, verification, and related records shown by Klaviyo.
- Service domain: Add the generated MX record when Klaviyo uses static service routing.
- Outlook result: Use the SMTP response and, for Microsoft 365, message trace instead of inferring a rejection from missing MX.
Check whether the recipient uses Outlook.com or Microsoft 365
Outlook is an app as well as a consumer email service. An address opened in the Outlook app is not necessarily hosted by Microsoft. Identify the recipient's actual mail provider before choosing a diagnostic.
|
|
|
|---|---|---|
Outlook.com, Hotmail, or Live.com | Klaviyo's SMTP response and mailbox folders | Check Junk Email, blocked senders, and the exact bounce code |
Company mailbox hosted in Microsoft 365 | Exchange Online message trace and tenant policy | Ask the administrator to trace the recipient and timestamp |
Another provider accessed through Outlook | That provider's mail logs and mailbox folders | Use the hosting provider's delivery evidence |
Use the receiving mail service to choose the delivery evidence.
Microsoft began enforcing bulk sender requirements on May 5, 2025. Domains sending at least 5,000 messages per day to its consumer service must pass both SPF and DKIM, publish DMARC, and pass DMARC using at least one matching domain. A p=none policy meets the minimum; quarantine and reject are also valid. A bounce containing 550 5.7.515 identifies an authentication requirement failure, even if the message was a single test. Microsoft's 550 5.7.515 guidance lists the required checks.
If only your company's Microsoft 365 addresses fail, ask the administrator to inspect anti-phishing or impersonation policies and any mail gateway before Exchange Online. External Klaviyo mail using your own From domain can trigger spoofing checks. Compare a consumer Outlook.com test with a company-mailbox test to isolate tenant policy.
Check Klaviyo submission and DNS first
Start with evidence that separates Klaviyo submission, public DNS, and Microsoft filtering. Check whether the test was generated, confirm that the new branded sending domain is verified for the correct send type, then inspect a received diagnostic message. For Microsoft 365 recipients, search Exchange Online message trace for the exact recipient and time; for Outlook.com recipients, request Klaviyo's SMTP response.
- Klaviyo status: Check Settings > Domains for the correct send type and routing. Confirm verification; a new domain can show Warming while the previous domain remains Active.
- Preview status: Check the account's preview limit. Use live-send activity for bounce or skip details; editor previews do not necessarily create the same profile events.
- Public DNS: Run a domain health check for the root domain and the exact Klaviyo subdomain.
- Authentication: Confirm the Return-Path, DKIM signing domain, and DMARC result in raw headers.
- Message trace: For Microsoft 365 recipients, have the administrator search Exchange Online for the recipient and exact test window.
DNS checks for the new sending setupBASH
# Static marketing example: replace hosts with Klaviyo's generated values dig CNAME send.example.com dig CNAME km1._domainkey.example.com dig TXT km1._domainkey.example.com dig CNAME km2._domainkey.example.com dig TXT km2._domainkey.example.com # Visible From domain: DMARC and domain-verification TXT dig TXT _dmarc.example.com dig TXT example.com # Dynamic routing: check the delegated subdomain's NS records dig NS send.example.com
Use the exact hostnames Klaviyo generated because DKIM selectors vary by send type and domain history. With static routing, check each CNAME and its final TXT answer. With dynamic routing, confirm that the delegated nameservers answer authoritatively for the child domain; changes below that delegation belong in Klaviyo's DNS zone. Keep generated records unproxied and check that the DNS interface has not appended your root domain twice. See Klaviyo's DNS troubleshooting.
Klaviyo states that DNS changes can take up to 48 hours to propagate, although many resolve sooner. Check public answers before activation. During a domain transition, retain the old domain's DNS while Klaviyo moves traffic to the new domain.
Header From, Return-Path, and authentication
The biggest troubleshooting mistake is treating every domain in the message as the same identity. SPF checks the envelope sender in Return-Path. DKIM validates the signature and its d= domain. DMARC compares the visible Header From domain with a passing SPF or DKIM domain under the record's matching mode.
Return-Path
This is the bounce address used during SMTP delivery. Klaviyo controls bounce processing for this identity.
- SPF role: SPF checks this envelope domain, not the visible From address.
- Bounce role: Klaviyo records the recipient server's delivery response against the profile or message.
Header From
This is the address recipients see. DMARC uses its domain as the identity that SPF or DKIM must match.
- DMARC role: At least one passing authentication domain must satisfy the DMARC domain match.
- Reply role: Replies use Reply-To when present; otherwise they use the From address.
Illustrative headers with a provider-managed Return-Path
Visible From: support@example.com Reply-To: support@example.com Return-Path (illustrative, inspect the actual header): bounce@provider.example.net DKIM signing domain: example.com or send.example.com Authentication-Results fields to compare: spf=pass smtp.mailfrom=provider.example.net dkim=pass header.d=send.example.com dmarc=pass header.from=example.com
In this example, SPF passes for provider.example.net but does not match example.com for DMARC. DKIM with d=example.com supplies an exact match. DKIM with d=send.example.com matches under the default adkim=r setting, but does not match under adkim=s. DMARC still passes if another passing identity supplies the required match. The aspf tag independently controls SPF matching. A DMARC pass confirms authenticated domain use, but it does not guarantee Outlook inbox placement. See Microsoft's DMARC matching examples.
If SPF fails after the domain change, use the SPF checker on the exact Return-Path domain. Klaviyo normally manages that domain's SPF, so a branded sending domain does not require adding Klaviyo to your root-domain SPF. If the failing domain is provider-managed, ask Klaviyo to investigate its result rather than editing unrelated records.
Separate preview failures from live sending failures
A Klaviyo preview email is not a complete substitute for a live campaign. Previews sent through Email Templates can use a Klaviyo sender, while campaign or flow previews use a different preview path. Live links and unsubscribe behavior also need a live test. Previews have account-level limits, so a missing preview can point to the preview process even when a live campaign delivers. Klaviyo explains these preview-path differences. If the email arrives but clicking a link shows ERR_CONNECTION_REFUSED, check click-tracking DNS and browser or network filtering.
|
|
|---|---|
0-250 contacts | 100 emails |
251-500 contacts | 500 emails |
501+ contacts | One tenth of sending capacity |
Current Klaviyo preview-email limits per billing cycle.
Klaviyo also allows up to 30 recipients in one preview send. Check Billing for the account's plan and preview allowance. If the limit is exhausted, preview inside the editor or create a small preview list and send a live campaign using the saved template. The limits are listed in Klaviyo's preview guidance. A live test requires available normal sending capacity.
- Send one editor preview: Record the recipient, subject, time, and which Klaviyo editor generated it.
- Send one live test: Use a preview list with the same From address, content, and new sending domain.
- Compare results: If only the preview fails, check its limit and compare the Email Templates preview with the campaign or flow editor preview before changing DNS.
- Check recipient activity: For live sends, review bounce, skip, and delivery activity, including Smart Sending or suppression reasons. A delivery status confirms server acceptance, not inbox placement.
Use the result to narrow the incident
A live test that reaches Outlook while the editor preview does not points to Klaviyo's preview path or limit. A live test that bounces provides an SMTP response. For Microsoft 365, a sent live test with no matching trace requires Klaviyo's delivery logs.
Collect headers and Microsoft delivery evidence
A normal inbox test shows only whether the message appeared. A useful diagnostic also captures the visible From address, Reply-To, Return-Path, DKIM signing domain, Authentication-Results, timestamp, and Message-ID. Those fields connect Klaviyo's delivery logs with Exchange Online trace where available. Capture both tests separately because each has its own Message-ID.
Send a Klaviyo test to the email tester and inspect SPF, DKIM, and DMARC for that message. For Microsoft 365, compare a separate Outlook test with its Exchange Online trace. A diagnostic DMARC pass does not prove that Microsoft evaluated the other message the same way, particularly when Klaviyo changes routing. If authentication fails, fix the failing identity; otherwise inspect Microsoft's response, reputation signals, and recipient policy.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Exchange Online message trace can show Delivered, Failed, Pending, Quarantined, or Filtered as spam. The last status means Microsoft rejected or blocked the message without placing it in quarantine. New trace records and final status can take about five to ten minutes to appear. These statuses are defined in Microsoft's message trace documentation.
If trace has no matching message after that delay, search by recipient and time first. The sender filter uses the SMTP envelope sender, which can differ from the visible From address. Then compare the subject, time zone, and that Outlook test's Message-ID. Klaviyo must confirm submission and the SMTP response. A Delivered trace moves the investigation to Junk Email, inbox rules, transport rules, redirects, or mailbox placement. Microsoft's message trace FAQ also notes that IP reputation blocks can be absent from trace.
|
|
|
|
|---|---|---|---|
Klaviyo event | SMTP acceptance confirmed | Skipped or bounced | Read live-send detail or request SMTP log |
SPF | Pass | Fail | Check Return-Path |
DKIM | Pass | Missing key or fail | Verify generated records |
DMARC | Pass | Fail | Compare authentication domains |
Microsoft 365 message trace | Receive and deliver | Missing, failed, or filtered | Inspect trace or sender log |
Compact evidence map for Klaviyo to Outlook test failures.
When to ask Klaviyo support for delivery logs
Ask Klaviyo support to investigate when the domain's verification or transition status conflicts with public DNS, a live test uses an unexpected domain for its send type, or delivery activity has no matching Microsoft 365 trace. A Warming domain can legitimately carry traffic alongside the old Active domain. These facts require account-side logs; a missing trace alone does not establish a Klaviyo setup fault.
If the domain must be rebuilt, follow a clean Klaviyo subdomain setup process. Use a unique, unused sending subdomain, publish the generated records exactly, verify them, then activate the domain for marketing, transactional, or service mail as intended.
What to ask Klaviyo support
- Account state: Confirm verification, send type, and any Active/Warming transition, including which domain handled the specific test.
- Generated records: Provide the expected routing, DKIM, verification, and delegation values.
- Preview state: Confirm remaining preview allowance and whether the request generated and submitted a message.
- Delivery log: Provide the destination host and exact SMTP response for the Outlook recipient.
Support evidence to send
Old domain that works: email.example.com New domain under test: send.example.com Domain status and send type: Active/Warming/Incomplete; marketing/transactional/service Recipient: actual test address Mailbox service: Outlook.com or Microsoft 365 Test timestamp: YYYY-MM-DD HH:MM UTC Message type and editor: template preview, campaign/flow preview, or live test Visible From: support@example.com Return-Path: copy the actual envelope sender Message-ID: copy the ID for this specific test Klaviyo activity: delivery, skip, bounce, or no event SMTP response: exact code and text, including destination host Microsoft 365 message trace: status, no result, or not applicable
This evidence keeps the support request focused on one message. The useful answer identifies whether Klaviyo generated the test, which infrastructure submitted it, and what Microsoft returned during SMTP delivery. A 4xx response is a temporary deferral that calls for retry; a 5xx response is a permanent rejection for that SMTP attempt.
How Suped fits into the workflow
Suped is our DMARC reporting and email authentication product. For a Klaviyo domain migration, Suped's DMARC monitoring groups reports by sending source and distinguishes raw SPF or DKIM results from the domain matches DMARC requires. That provides trend evidence across real sends rather than one preview message. Aggregate reports normally arrive daily from participating receivers and do not identify an individual missing Outlook test.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
The practical workflow is to add the domain before cutover, confirm that known Klaviyo traffic appears under the expected identity, and watch for a sudden change in pass rates during and after the transition. DNS issue alerts can then support the Klaviyo and Microsoft evidence without replacing message trace or sender logs.
- Before migration: Record the old domain's senders and authentication pass rates.
- During testing: As aggregate reports arrive, confirm that Klaviyo appears under the expected sending identity.
- After activation: Watch DMARC pass rates and investigate any new unknown source.
- Reputation context: Review blocklist (blacklist) signals separately from authentication results.
A safe fix sequence
If the old domain still works, keep its DNS available while the new domain is verified and the transition runs. Klaviyo supports adding a second branded sending domain for the same send type under the same root domain, then gradually moves traffic to it. The new domain is Warming while the old one is Active; Klaviyo promotes the new domain and retires the old one when the transition completes. Follow Klaviyo's current setup guidance and use a unique subdomain that does not overlap corporate or support mail.
- Stabilize sending: Retain the working domain's DNS during diagnosis and any gradual transition.
- Verify generated DNS: Publish only the records Klaviyo provides for the selected routing and send type.
- Activate in Klaviyo: Confirm public DNS and verification. During a transition, Warming is expected before the new domain becomes Active.
- Test both paths: Compare an editor preview with a live test campaign to a preview list.
- Trace Outlook: For Microsoft 365, use the exact recipient, time, subject, and Message-ID. For Outlook.com, inspect the SMTP response and mailbox folders.
- Increase volume carefully: For new marketing infrastructure, start with engaged recipients and expand as delivery remains consistent. An existing, established sending domain does not automatically require a full re-warm.
Example DMARC record for monitoringDNS
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
The rua address requests aggregate reports; p=none does not request DMARC-based blocking. This monitoring example is for a new policy, not a reason to replace an existing quarantine or reject policy during a Klaviyo migration. Fix legitimate senders' authentication and domain matching while preserving the existing policy. Keep the aggregate-report destination configured to receive reports.
Views from the trenches
Best practices
Check Klaviyo activation and generated DNS before changing unrelated mail records.
Compare Microsoft 365 trace with the Klaviyo SMTP log for the same recipient and time.
Read the actual Return-Path and DKIM domains because Klaviyo manages SPF independently.
Common pitfalls
Adding MX to a marketing subdomain can distract from failed DKIM or DMARC checks.
Treating quarantine as the only evidence misses rejects, filters, and absent sends.
Using preview delivery alone can hide limits or differences in the live sending path.
Expert tips
Keep both domains' DNS during Klaviyo's transition and confirm live Outlook delivery.
Ask Klaviyo for the exact account state, send event, and remote SMTP response details.
Use Suped alerts to catch authentication and DNS changes during the domain migration.
Marketer view
Marketer from Email Geeks says Klaviyo support should inspect provider-side logs because the platform can see account setup state that public DNS cannot show.
2025-03-25 - Email Geeks
Marketer view
Marketer from Email Geeks says Outlook troubleshooting should start with Microsoft message trace, since quarantine does not prove the message reached the tenant.
2025-03-25 - Email Geeks
