How do I integrate an external SMTP with Klaviyo?
Published 24 Jul 2025
Updated 5 Oct 2026
16 min read
Summarize with
Updated on 5 Oct 2026: We updated the Klaviyo integration steps with current API requirements and webhook delivery handling.
Klaviyo does not let you add external SMTP credentials and make Klaviyo campaigns or flows send through your own mail server. Treat Klaviyo as the sending platform when mail is built and sent in Klaviyo. When an outside SMTP path is required, keep message delivery outside Klaviyo and pass events, profile data, or order data between the systems.
That distinction matters because the workaround is not an SMTP relay integration. The workable answer is to choose one of four routes: send the email in Klaviyo, trigger a Klaviyo transactional flow with an event, let a Klaviyo flow webhook call your application so it can send through external SMTP, or send outside Klaviyo and sync the customer and event data back. The right route depends on who owns the message, trigger, delivery retries, and suppression rules.
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 a flow webhook: When a Klaviyo flow should call your application and the application should queue an external SMTP message.
- 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 a Klaviyo integration can do
Klaviyo accepts integrations that bring data into Klaviyo, push events into Klaviyo, or send flow data to an external application through a webhook. 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. Current Klaviyo setup documentation describes branded sending domains and data integrations, but it still does not provide a customer SMTP relay setting.
Klaviyo Integrations screen listing connected apps and data sync integrations.
The confusing part is that people use the word integration for different functions. A data integration syncs orders, profiles, events, consent, catalog data, or flow triggers. A workflow integration uses an event or webhook to tell another application what to do. Mail transport hands a fully formed message to an SMTP server for delivery. Klaviyo supports the first two functions, but it does not expose the third as a customer-configurable relay.
An ecommerce integration with Magento 2 or WooCommerce does not change the store server's SMTP settings. If an extension asks for an SMTP host, port, username, and password, Klaviyo does not supply those relay details. Klaviyo's Magento support answer instead recommends flows triggered by existing metrics such as Placed Order or Fulfilled Order, or by a custom event.
|
|
|
|---|---|---|
Campaign sending | Use Klaviyo sender setup and sending domain authentication. | |
Flow sending | Yes | Trigger flows with native metrics or custom events. |
Flow webhook to app | Yes | POST JSON to your HTTPS endpoint, then let the app queue the SMTP message. |
External SMTP relay | No | Send outside Klaviyo and sync the event back. |
Transactional approval | Yes | Use approved metric-triggered flow emails on a paid account. |
Raw app mail | No | Use a separate SMTP path owned by the app. |
Klaviyo integration paths compared by purpose.
Choose Klaviyo sending or external SMTP
Decide the route 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: Connect the Klaviyo branded 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 metric-triggered flow, and Klaviyo sends the approved transactional message. Transactional status is available on paid accounts and applies to each flow email separately. Editing the message removes that status, so the email must be submitted for approval again. This is still Klaviyo sending the email, not Klaviyo relaying through your SMTP server. Price drop flows are excluded from transactional approval. Requests for eligible list- or segment-triggered messages go through Klaviyo Support. See Klaviyo's transactional eligibility rules for the supported flow types.
Klaviyo and external SMTP routing flowchart for marketing and application email.
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@your-store-domain.com" }}}, "properties": { "invoice_id": "INV-1048", "amount": 129.00, "invoice_url": "https://app.example.com/invoices/INV-1048" }, "unique_id": "9be2b09d-a709-45ad-9f3a-7c7fd54b92e8" } } }
Use a real test profile
Replace the recipient address and URL before testing. An HTTP 202 response confirms acceptance for processing, not that an event was recorded or an email was sent. Events using @example.com or @test.com addresses are silently dropped. Verify the event in the real profile's activity feed. Reuse the same unique_id when retrying one business event, and generate a different ID for each new event. See Klaviyo's Events API overview for event processing and test-address behavior.
Send the event through Klaviyo's API
For a Next.js application or another custom backend, send the invoice payload above through Klaviyo's server-side Create Event API. Keep the private API key on the server and give it the events:write scope. Klaviyo's Create Event reference documents the JSON request and required revision header. Older community instructions that use the legacy Track API and base64-encoded payloads do not describe this API.
Create Event request headers for the JSON payload abovehttp
POST https://a.klaviyo.com/api/events Authorization: Klaviyo-API-Key YOUR_PRIVATE_API_KEY accept: application/vnd.api+json content-type: application/vnd.api+json revision: 2026-07-15
- Send a test event to a real recipient you control, then confirm that Invoice Created appears on the profile. Use the same metric name for subsequent invoice events.
- Create a metric-triggered flow using Invoice Created. Add the email and insert event fields such as {{ event.invoice_id }} and {{ event.invoice_url }} into the template.
- On a paid account, keep the email in Manual mode and apply for transactional status. Keep promotional content out of the message and allow up to one business day for review.
- After approval and a successful test, set the email to Live and disable the equivalent store or application notification so the same invoice is not sent twice.
The event starts a flow; it does not submit a finished SMTP message. Klaviyo's transactional flow setup explains approval and activation. Klaviyo still owns delivery for this route.
Use a flow webhook when Klaviyo owns the trigger
A Klaviyo flow webhook is the closest supported workflow connection to external SMTP. The webhook sends a JSON POST request to your HTTPS endpoint when a profile reaches that flow step. Your application validates the request, puts the message job into a durable queue, and sends through its own SMTP path. Klaviyo never receives or uses the SMTP credentials.
- Choose the trigger: Place the webhook action in a flow started by a supported metric, list, segment, or date trigger. Use a metric-triggered flow for the invoice example so its event fields are available.
- Send a stable identifier: Include an event or message ID that your endpoint stores atomically before it queues the send. Keep the ID identical across retries.
- Queue before success: Return a 2xx response after the job has been accepted into a durable queue, not after the final SMTP delivery.
- Handle retries safely: Klaviyo retries eligible errors such as HTTP 429 and HTTP 500 up to 17 times over 24 hours with exponential backoff. Deduplicate by the stable ID and monitor skipped requests. See Klaviyo's webhook retry rules for response handling.
- Write results back: Send accepted, bounced, or failed custom events into Klaviyo for customer history, and apply required suppression changes separately. Your application owns SMTP retries after the webhook job is accepted.
Invoice webhook body for a metric-triggered flowjson
{ "message_id": "invoice-{{ event.invoice_id }}", "message_type": "invoice_ready", "recipient": "{{ person.email }}", "invoice_id": "{{ event.invoice_id }}" }
Keep SMTP credentials out of the payload
Add an authentication header for your HTTPS endpoint and store SMTP credentials only in the external application. The endpoint needs a trusted TLS certificate and must not redirect. A Manager, Admin, or Owner with two-step authentication can add or edit flow webhooks. These webhooks send one-way JSON POST requests, and list- or segment-triggered flows supply profile properties rather than invoice event data. See Klaviyo's flow webhook setup for endpoint and variable requirements.
Authenticate Klaviyo and external SMTP domains
A common setup mistake is using a Klaviyo-delegated sending subdomain for an unrelated SMTP sender. Configure separate subdomains, such as marketing.example.com for Klaviyo and orders.example.com for the external sender's Return-Path. DMARC passes when SPF or DKIM passes and its authenticated domain matches the visible From domain under the policy's matching mode. Relaxed mode accepts the same organizational domain; strict mode requires an exact match. See the DMARC domain matching rules before relying on sibling subdomains with a root-domain From address.
Klaviyo lets an account configure separate branded sending domains for marketing, transactional, and service traffic, with one active domain for each send type. Marketing campaigns and flows use the marketing domain, approved transactional flow messages can use the transactional domain, and service replies use the service domain. If you are still planning the split, 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 sending ownertext
Klaviyo marketing path marketing.example.com -> publish Klaviyo's generated NS or CNAME records Root domain -> publish the generated TXT ownership verification record External application path orders.example.com -> configure the SMTP sender's Return-Path and SPF DKIM selector hostnames -> publish the SMTP sender's supplied records DMARC policy for a visible From address at example.com _dmarc.example.com -> publish one monitored policy Check for separate subdomain policies when using subdomain From addresses
Klaviyo's branded sending domain setup generates NS or CNAME records for SPF and DKIM authentication, plus a TXT ownership verification record. Publish the supplied records, then verify and activate the domain under Settings > Domains. Do not replace those values with a generic SPF include or use the delegated sending subdomain as a receiving mailbox. A branded sending domain is separate from a dedicated IP and does not provide SMTP credentials. For the external SMTP path, use its supplied hostnames and record values. Follow Klaviyo's branded domain setup, then check the external sender with a domain health check and the SPF checker before traffic moves.
Do not merge SPF records blindly
Publish only one SPF TXT record at each hostname evaluated for SPF, usually the Return-Path domain. Multiple SPF records at that hostname cause permerror. Keep external sender records out of Klaviyo's delegated DNS configuration. If external senders share one SPF hostname, combine their authorizations into one record and stay within the limit of 10 DNS-querying terms per evaluation, including nested includes. The SPF lookup limit applies to those terms, rather than every DNS request used to authenticate an email.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Suped's DMARC monitoring shows which sources are sending for the domain, whether SPF or DKIM has a DMARC 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.
Sync delivery events and suppression rules
If the mail leaves through external SMTP, Klaviyo still needs the data that explains what happened. 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. Custom bounce or complaint events do not automatically suppress a profile. Apply marketing suppression and consent changes separately through Klaviyo's Profiles API and enforce the external sender's rules before each send.
|
|
|
|---|---|---|
Message requested | Application | Klaviyo event timeline |
SMTP submission accepted | SMTP relay response | External logs and Klaviyo custom event |
Bounce | Bounce processing or sender webhook | Suppression workflow in both systems |
Complaint | Mailbox feedback loop or sender webhook | Suppression workflow and risk review |
Data sync choices when the email sends outside Klaviyo.
For external SMTP, 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. SMTP acceptance does not prove inbox delivery. Approved Klaviyo transactional messages can bypass marketing suppression, but addresses suppressed for hard bounces, spam complaints, or seven consecutive soft bounces are skipped. External failures need their own sending exclusions; a manual marketing suppression does not block every approved transactional message. See Klaviyo's transactional suppression rules when deciding which recipients remain eligible.
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.
Test both sending paths before production
Before moving volume, 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, bounce handling, or complaint feedback path. For marketing mail, also confirm the required one-click unsubscribe headers and endpoint.
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 or the sending path has an SPF permerror or broken DKIM configuration.
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: Trigger a live flow or campaign to a controlled test recipient using the final Klaviyo sender address and branded sending domain.
- Send SMTP: Send a controlled test through the external SMTP path without enabling a duplicate production notification.
- Check headers: Confirm DKIM, SPF, DMARC, return-path, and one-click unsubscribe behavior where required for marketing mail.
- 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.
Check DMARC for each sending path
If Klaviyo passes DMARC but the external SMTP path fails with the same visible From domain, inspect each sender's authenticated domains separately. A successful Klaviyo test does not validate the application sender. Passing DMARC also does not guarantee inbox placement or prevent a domain or IP from appearing on a blocklist (blacklist).
Monitor both sending sources with Suped
Suped's product gives teams one DMARC workflow for a split sending setup. It identifies which source sent the mail, shows whether SPF or DKIM produced the required domain match, and keeps the failure tied to the source that needs a DNS or platform change. That evidence is useful before moving a DMARC policy past monitoring.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
When Klaviyo and another SMTP sender share an organizational domain, Suped combines DMARC monitoring, SPF and DKIM source visibility, policy management, alerts, and blocklist monitoring. Hosted SPF and SPF flattening apply only where a sender-managed SPF record needs them. They should not replace the NS or CNAME records generated for a Klaviyo branded sending domain.
|
|
|---|---|
Unknown sender | |
SPF limit risk | Review sender-managed SPF records before using Hosted SPF or SPF flattening. |
Policy rollout | Stage DMARC policy changes after both approved sources pass consistently. |
Authentication drift |
How Suped maps to the Klaviyo plus SMTP problem.
The practical workflow is to authenticate Klaviyo, authenticate the external SMTP path, use DMARC reports to confirm both sources, and tighten policy after the results are stable. Suped keeps the source evidence and fix steps visible to the people who own DNS, lifecycle marketing, and application email.
Views from the trenches
Best practices
Keep Klaviyo and external SMTP on separate subdomains, with DMARC reporting for both.
Give every webhook a stable message ID so retries cannot create duplicate email sends.
Return success only after the application accepts the message into a durable queue.
Common pitfalls
Treating a flow webhook as an SMTP relay hides where message rendering and retries occur.
Reusing a delegated Klaviyo subdomain for another sender causes DNS ownership conflicts.
Logging bounce events without applying suppressions leaves invalid recipients eligible.
Expert tips
Store the Klaviyo event ID with the external message ID for easier troubleshooting.
Use a transactional flow only after each message has the required Klaviyo approval.
Compare both send paths in DMARC reports before moving the domain policy past monitoring.
A Klaviyo Community answer says the platform does not provide SMTP credentials, so a customer cannot use Klaviyo as a generic relay.
2022-04-25 - Klaviyo Community
A Klaviyo Support reply in the Magento community discussion directs store notifications to existing order metrics or custom-event flows instead of an SMTP relay.
2022-03-28 - Klaviyo Community
