How do I integrate an external SMTP with Klaviyo?
Matthew Whittaker
Co-founder & CTO, Suped
Published 24 Jul 2025
Updated 25 May 2026
7 min read
Summarize with
The direct answer is no: Klaviyo does not give you a setting where you paste external SMTP credentials and make Klaviyo campaigns or flows send through your own mail server. I treat Klaviyo as the sending platform when mail is built and sent in Klaviyo. If I need an outside SMTP path, I keep that outside Klaviyo and pass events, profile data, or order data between the systems.
That distinction matters because the workaround is not an SMTP integration. The workable answer is to choose one of three routes: send the email in Klaviyo, trigger Klaviyo transactional flows with events, or send the message through an external SMTP provider while syncing the customer and event data back into Klaviyo. The right route depends on whether the message is marketing, transactional, operational, or a platform notification.
Short answer
Klaviyo can send mail for Klaviyo campaigns and flows, including approved transactional flow emails. It does not act like a generic SMTP relay and it does not let you swap in your own SMTP server for Klaviyo sending.
- Use Klaviyo: For campaigns, browse abandonment, post-purchase flows, winback flows, and approved transactional flows.
- Use outside SMTP: For app-generated mail that needs a raw SMTP handoff, custom headers, or application-level retry control.
- Sync data: Send events and profile updates into Klaviyo so segmentation and reporting stay useful.
What Klaviyo accepts
Klaviyo accepts integrations that bring data into Klaviyo, push events into Klaviyo, and connect ecommerce or customer systems. That is different from allowing Klaviyo to hand off message delivery to an external SMTP host. A Klaviyo community answer says SMTP credentials are not offered, which matches the practical behavior I see in account setup.
Klaviyo integrations screen showing app and data connections rather than SMTP settings.
The confusing part is that people use the word integration for two different things. One integration means data sync: orders, profiles, events, consent, catalog data, and flow triggers. The other means mail transport: a system hands a fully formed message to an SMTP server for delivery. Klaviyo supports the first category. It does not expose the second category as a customer-configurable setting.
|
|
|
|---|---|---|
Campaign sending |  Yes | Use Klaviyo sender setup and sending domain authentication. |
Flow sending | Yes | Trigger flows with native metrics or custom events. |
External SMTP relay | No | Send outside Klaviyo and sync the event back. |
Transactional approval | Yes | Use approved metric-triggered flow emails. |
Raw app mail | No | Use a separate SMTP path owned by the app. |
Klaviyo integration paths compared by purpose.
The practical ways to build it
I usually decide this by asking who owns the final message body and who needs delivery control. If marketing owns the message and the audience logic lives in Klaviyo, send from Klaviyo. If the application owns the message and needs SMTP-level control, send outside Klaviyo and send the activity into Klaviyo as data.
Send inside Klaviyo
Use this when Klaviyo is the system that builds, schedules, and personalizes the email.
- Best for: Campaigns, lifecycle flows, ecommerce automations, and approved transactional flow emails.
- Control point: Klaviyo controls message generation, suppression logic, and delivery handling.
- DNS work: Authenticate the Klaviyo sending domain and monitor DMARC domain match.
Send outside Klaviyo
Use this when an application already produces a finished message and must hand it to an SMTP server.
- Best for: Password resets, receipts, account alerts, invoices, and system notifications.
- Control point: Your app controls headers, retries, logs, and SMTP responses.
- DNS work: Authenticate the SMTP sender separately and keep its DMARC reporting visible.
For Klaviyo transactional email, the clean pattern is event-driven. The application sends an event to Klaviyo, the event triggers a flow, and Klaviyo sends the approved transactional message. That is still Klaviyo sending the email, not Klaviyo relaying through your SMTP server.
Flowchart splitting marketing email to Klaviyo and app email to external SMTP.
Event payload for a Klaviyo-triggered flowjson
{ "data": { "type": "event", "attributes": { "metric": { "data": { "type": "metric", "attributes": { "name": "Invoice Created" }}}, "profile": { "data": { "type": "profile", "attributes": { "email": "customer@example.com" }}}, "properties": { "invoice_id": "INV-1048", "amount": "129.00", "invoice_url": "https://app.example.com/invoices/INV-1048" } } } }
DNS and authentication setup
The most common technical mistake is trying to make one sending domain cover two unrelated mail paths without checking the DMARC identifier match. Klaviyo and your external SMTP sender both need authentication that matches the domain strategy. If you use marketing.example.com for Klaviyo and orders.example.com for app mail, authenticate both and monitor both.
If you are still planning the domain split, a separate Klaviyo subdomain is usually cleaner than sharing one sender across multiple platforms. The deeper setup question is covered in Klaviyo subdomain setup, and the same principle applies when you decide whether to share a sending domain across platforms.
Example split by subdomaindns
marketing.example.com. 3600 IN TXT "v=spf1 include:esp.example -all" orders.example.com. 3600 IN TXT "v=spf1 include:smtp.example -all" _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:d@example.com"
Those records are illustrative, not copy-paste records. In production, use the exact hostnames and record values given by each sending platform. Then confirm the domain with a domain health check and inspect the SPF path with the SPF checker before traffic moves.
Do not merge SPF records blindly
A domain gets one active SPF TXT record at a hostname. Adding one record for Klaviyo and another record for the external SMTP sender at the same hostname creates SPF permerror risk. If both paths must use the same hostname, combine the authorized senders into one record and keep the lookup count under the DNS limit.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
This is where Suped is useful in a concrete way. Suped's DMARC monitoring shows which sources are sending for the domain, whether SPF or DKIM has a domain match, and which source needs a DNS or platform fix. That matters when Klaviyo and an outside SMTP path both send under the same organizational domain.
How to keep the systems in sync
If the mail leaves through external SMTP, Klaviyo still needs the data that explains what happened. I keep the message send event, delivery event, bounce event, and relevant customer state available in Klaviyo or the reporting system. Without that feedback loop, marketers see incomplete customer timelines and build segments from stale data.
|
|
|
|---|---|---|
Message requested | Application | Klaviyo event timeline |
Message sent | SMTP logs | Customer record |
Bounce | SMTP webhook | Suppression logic |
Complaint | Mailbox report | Risk review |
Data sync choices when the email sends outside Klaviyo.
For external SMTP, I also keep the unsubscribe and suppression rules explicit. Marketing consent in Klaviyo does not automatically control every operational email your app sends. Transactional mail follows different rules, but complaints and hard bounces still need to affect risk decisions.
Clean handoff
- One owner: Each message type has one system responsible for sending.
- Shared events: The receiving system stores the event that matters for segmentation.
- Separate domains: Marketing and app mail use clear subdomains when possible.
- Visible failures: Bounces, complaints, and authentication failures reach the right owners.
Messy handoff
- Mixed owners: Two systems can send the same customer notification.
- Missing events: Klaviyo does not know that the outside SMTP message happened.
- Shared DNS: SPF records get duplicated or DKIM domain matching is assumed.
- Hidden failures: SMTP bounces stay in app logs and never reach deliverability review.
Testing before production traffic
Before I move volume, I send real messages through the final path and inspect the full headers. A UI preview does not prove that the delivered email has the right DKIM domain, SPF domain match, return-path, unsubscribe headers, or complaint feedback path.
Readiness checks before traffic moves
Treat these as gates before sending meaningful Klaviyo or external SMTP volume.
Ready
Pass
DMARC passes with SPF or DKIM domain match, and bounces are visible.
Needs work
Mixed
Authentication passes inconsistently or only one mail path is visible.
Stop
Fail
DMARC fails, SPF has a permerror, or DKIM is unsigned.
The quickest practical check is to send one Klaviyo message and one external SMTP message to a mailbox you control, then inspect both with the email tester. You want both paths to authenticate cleanly and show the source you expect.
- Send Klaviyo: Send from the final Klaviyo sender address and sending domain.
- Send SMTP: Send the same message type through the external SMTP path.
- Check headers: Confirm DKIM, SPF, DMARC, return-path, and List-Unsubscribe behavior.
- Check reports: Confirm both sources appear in DMARC data within the expected reporting window.
- Check reputation: Watch IP and domain blocklist (blacklist) signals after the first sends.
The failure I look for first
The dangerous version of this setup is when Klaviyo passes DMARC, the external SMTP path fails DMARC, and both use the same visible From domain. That creates confusing inbox behavior and makes it harder to know which system damaged trust.
Where Suped fits
For most teams, Suped is the best overall DMARC platform for this type of setup because it turns the mail-source split into a manageable workflow. The point is not just seeing pass or fail counts. The point is knowing which system sent the mail, which authentication mechanism passed, and what to fix before enforcing a stricter DMARC policy.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped's product fits when you run Klaviyo plus another sender because it combines DMARC monitoring, SPF and DKIM visibility, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, real-time alerts, blocklist monitoring, and MSP multi-tenant reporting in one place. Hosted SPF is especially useful when a marketing team needs to add or remove approved senders without waiting on repeated DNS edits.
|
|
|---|---|
Unknown sender |  Identify Klaviyo, app SMTP, and unapproved sources. |
SPF limit risk | Use Hosted SPF and SPF flattening to reduce lookup issues. |
Policy rollout | Stage DMARC policy changes from monitoring to enforcement. |
Agency reporting | Manage client domains from one MSP dashboard. |
How Suped maps to the Klaviyo plus SMTP problem.
The practical workflow is simple: authenticate Klaviyo, authenticate the external SMTP path, use DMARC reports to confirm both sources, then tighten policy only after the data is stable. Suped keeps that workflow visible for the people who own DNS, lifecycle marketing, and application email.
Views from the trenches
Best practices
Keep Klaviyo and SMTP mail on separate subdomains until both have stable DMARC data.
Confirm support answers against account behavior before building around a hidden setting.
Sync external send events back to Klaviyo so customer timelines do not lose context.
Common pitfalls
Pasting SMTP credentials into a Klaviyo workflow plan wastes time because there is no field.
Sharing one sender domain across systems without DMARC review creates unclear failures.
Leaving bounces in external SMTP logs prevents marketing teams from seeing delivery risk.
Expert tips
Use one DMARC reporting view to compare sources before tightening policy past monitoring.
Treat transactional flow approval as a Klaviyo sending path, not as an SMTP workaround.
Name each custom event for the business action so flow logic stays readable later.
Marketer from Email Geeks says Klaviyo should not be treated as a generic SMTP relay because the product does not expose that handoff.
2024-02-02 - Email Geeks
Marketer from Email Geeks says the practical fallback is to use an external SMTP path for app mail and keep Klaviyo for Klaviyo-owned sends.
2024-02-02 - Email Geeks
The clean answer
You do not integrate an external SMTP with Klaviyo in the sense of making Klaviyo deliver through your SMTP server. You either send through Klaviyo with Klaviyo's domain authentication, trigger a Klaviyo flow with an event, or send outside Klaviyo and sync the result back as customer data.
The safest setup is usually separate subdomains, separate authentication, shared event data, and one DMARC monitoring workflow. That gives each system a clear job and gives you enough evidence to fix SPF, DKIM, DMARC, bounce, and blocklist (blacklist) issues before they affect more mail.
