Customer.io SMTP Settings and Configuration (2026)

If you came for credentials to paste into WP Mail SMTP, Laravel or Django, Customer.io cannot serve that job. What it gives you instead is a full sending-domain authentication flow, a transactional API, and a setting that relays through a provider you already pay for. For a behavioural-messaging platform that also exposes a real relay, look at Brevo or SendGrid; the closest peers without one are Klaviyo and ActiveCampaign. Below: what you can actually configure, and how to wire a relay alongside it without wrecking DMARC alignment.

Quick reference

Values below come from Customer.io’s own documentation as of August 19, 2026. Anything unpublished is marked as such rather than guessed.

Why Customer.io has no SMTP relay

Customer.io is a behavioural messaging and customer-data platform, not email infrastructure. Its unit is not a message but a profile: attributes, events, objects, segment membership, frequency caps, suppression state and a Liquid template resolving against all of it at send time. An SMTP envelope carries none of that. Accepting anonymous submissions would mean accepting messages the platform cannot attribute, suppress, frequency-cap or report on in the Deliveries view — which is most of the product.

So the send surface is an API call carrying a transactional_message_id, an identifiers object and a message_data payload, not a rendered MIME body. Even the transactional product, marketed separately from Journeys automations, runs on the same App API host and the same soft ceiling of 3000 requests per 3 seconds as the rest of the ingress. Any system that can only speak SMTP therefore needs a relay in front of it, and Customer.io is not that relay.

What you actually need instead

Sending transactional email from your application

Use the App API. Create a scoped App API key in Account Settings › API Credentials, build a transactional message in the UI to get its transactional_message_id, then POST to /v1/send/email. Official clients wrap it: customerio (Python), customerio-node, go-customerio, customerio-ruby, each taking a region argument. A successful call returns a delivery_id and queued_at for reconciling against the Deliveries view.

Connecting a CMS, framework or appliance that only speaks SMTP

Point it at a dedicated relay. For WordPress, Laravel, Django or any stock mailer: Postmark for transactional-only traffic where speed and support matter, Amazon SES when cost per thousand dominates and you can own the deliverability work, SendGrid or Brevo for a relay plus a marketing surface in one account. Keep Customer.io for behavioural journeys and let both share one authenticated sending domain.

Routing internal notifications and alerts

If the goal is a Slack ping or an ops alert rather than an inbox, skip email. Customer.io ships a native Slack destination that posts to a chosen channel when journey criteria are met, and a Custom Webhook destination that sends any event or profile payload to an HTTPS endpoint you control. Reporting Webhooks stream lifecycle events — sent, delivered, opened, clicked, bounced, spammed, unsubscribed, failed — into your own systems.

Sending domain authentication

This is what most SMTP-settings searchers actually need: the only place in Customer.io where you configure email at the infrastructure level. In Workspace Settings › Email › Sending domains, enter the domain you want to send From; Customer.io mints a subdomain cio#####.yourdomain.com (the digits are your workspace id) and generates four record sets behind a Show Records button.

SPF and DKIM setup

Customer.io publishes no global SPF include. The include value, DKIM public key, the two return-path MX hostnames and the link-tracking CNAME target are generated per workspace and revealed only in the app, so the template below shows shape and placement, not copyable values. The one documented constant is the DKIM selector: always krs.

; Generated per workspace — Settings › Email › Sending domains › Show Records

; 1. SPF — authorises Customer.io on the sending subdomain
cio12345.yourdomain.com.                 IN  TXT    "v=spf1 include:<value shown in app> ~all"

; 2. DKIM — selector is always "krs"
krs._domainkey.cio12345.yourdomain.com.  IN  TXT    "k=rsa; p=<public key shown in app>"

; 3. Custom return-path — one MX record, two hostnames
cio12345.yourdomain.com.                 IN  MX 10  <mx host 1 shown in app>
cio12345.yourdomain.com.                 IN  MX 20  <mx host 2 shown in app>

; 4. Optional — HTTPS link tracking on your own host
links.yourdomain.com.                    IN  CNAME  <target shown in app>

; 5. DMARC — on the ROOT domain, never on the cio##### subdomain
_dmarc.yourdomain.com.                   IN  TXT    "v=DMARC1; p=none; adkim=r; aspf=r"

Two edge cases bite. If a custom SMTP server is already configured, Customer.io cannot verify the domain automatically and the docs tell you to contact support for manual authentication — so verify before switching custom SMTP on. And record values are workspace-scoped: a US and an EU workspace on the same brand domain need two separate sets. Otherwise verification is automatic once DNS propagates.

DMARC alignment

Customer.io states the minimum acceptable record is v=DMARC1; p=none, published at _dmarc.yourdomain.com on the organisational domain, not on the cio##### subdomain. Relaxed alignment is what makes it work: with aspf=r and adkim=r the sending subdomain aligns with the organisational domain in your visible From header, so DMARC passes even though the return-path sits on a subdomain. Tighten to adkim=s and the DKIM d= on the subdomain no longer aligns with the root From domain, and mail fails.

Since the 2024 Google and Yahoo bulk-sender rules a DMARC record is effectively mandatory at volume. Treat p=none as a starting position: publish it with an rua address, read reports until every legitimate stream passes, then move to p=quarantine and eventually p=reject.

Sending limits

There is no per-hour email throttle, because there is no relay to throttle. Customer.io meters monthly email volume per plan and applies request-rate limits per API instead. It calls these limits not strictly enforced, while warning that consistently exceeding them may lead to throttling or dropped data, and that they are subject to change.

Two 2026 workspace controls sit on top: channel frequency caps with windows up to 31 days and automation rate limiting by channel. Throttles you configure, not platform ceilings — but they silently hold messages if you forget them.

Common mistakes

Pairing Customer.io with an SMTP provider

The recommended setup

Run one dedicated relay for machine SMTP traffic, then point Customer.io’s custom SMTP setting at that same provider. Both streams then share one reputation, one authenticated domain and one DNS record set, and bounce handling lives in one place. Order matters: authenticate the domain in Customer.io and let verification finish, configure the relay’s own SPF and DKIM on the same organisational domain, then switch to custom SMTP and ask support to re-authenticate manually.

There is one real financial argument for it: Customer.io documents that emails sent through your custom SMTP server do not count against your plan’s allotted email volume. On a plan starting at $100 per month for 5k profiles and 1 million emails, that only pays off at genuine scale, and the price is lost delivery reporting.

Keeping the two systems from colliding

Two failure modes are worth designing against. The first is double-sending: an order-confirmation event that fires both a Customer.io journey and your application’s own relay call produces two near-identical emails. Pick one owner per message type and write it down. Usual split: Customer.io owns anything triggered by behaviour or segment membership, the application owns anything triggered by a database state change.

The second is DMARC drift. If the relay signs with DKIM on the root domain while Customer.io signs on cio#####.yourdomain.com, both pass under relaxed alignment — but only if your record actually specifies adkim=r and aspf=r. Tighten to strict alignment for the relay’s benefit and you break Customer.io in the same edit. Keep one relaxed DMARC record on the organisational domain, read aggregate reports for both sources before changing policy, and if the two systems share a suppression list sync it in one direction only.

Frequently asked questions