Does Customer.io require both SPF and DKIM?

Yes. For Customer.io built-in delivery, Customer.io requires both SPF and DKIM to verify the sending domain. If you use custom SMTP, authenticate with the SMTP provider instead and use Customer.io only for the parts it still needs, such as branded link tracking.

Should I add Customer.io SPF to my root SPF record?

No, not in the normal Customer.io setup. Customer.io places SPF on its generated subdomain, such as a cio subdomain, so it can control the return-path and keep the root SPF record under the DNS lookup limit.

Which email platform uses SPF records or includes on cio subdomains?

Customer.io uses account-specific cio subdomains for authentication records. If you see SPF, MX, or DKIM records on a hostname like cio12345 under your domain, treat Customer.io as the likely sending source, but only publish the values shown inside your own Customer.io workspace.

Can Customer.io work with p=reject?

Yes. Customer.io can work with p=reject after SPF, DKIM, and DMARC pass on real Customer.io mail. Move there only after reports show Customer.io and your other legitimate senders are clean, then keep monitoring because one changed DNS record can cause rejected mail.

Learn

DMARC

How to set up DMARC/DKIM/SPF for Customer.io

Matthew Whittaker

Co-founder & CTO, Suped

Published 3 Jul 2026

Updated 3 Jul 2026

9 min read

Summarize with

Customer.io email authentication setup for SPF, DKIM, and DMARC.

Customer.io authentication needs a sending domain in Customer.io, the account-specific DNS records Customer.io shows, and a DMARC record on the root domain. I use the Customer.io record screen as the source of truth because the hostnames are generated per workspace.

Customer.io supports a custom return-path through the MX records it gives you, so SPF can pass DMARC domain matching when the Customer.io SPF and MX records are published on the generated subdomain. The Customer.io authentication docs confirm that Customer.io uses account-specific subdomains for SPF, DKIM, and return-path signing.

What must pass

Customer.io domain: The sending domain must show verified in Customer.io before built-in delivery can send from it.
SPF and DKIM: Customer.io requires both records for its built-in delivery servers.
DMARC: The root domain needs a DMARC TXT record, and relaxed domain matching should stay in place for Customer.io.

Add your domain

Add the domain you will use in the visible From address, then open the DNS records Customer.io generates for that domain. Do not guess SPF includes or DKIM selectors from another account.

Customer.io Sending Domains screen with an unverified domain and record actions.

Open settings: In Customer.io, go to Settings, Workspace Settings, then Email.
Add sender: Click Add Sending Domain and enter the domain, display name, and From address you plan to send from.
Open records: Click Show Records for the domain and keep that screen open while you edit DNS.
Keep root mail: Add Customer.io records only at the hostnames Customer.io gives you. Do not remove existing MX or TXT records that handle your normal inbox mail.

Record	Host	Purpose
MX	cio subdomain	Return-path
TXT	cio subdomain	SPF
TXT or CNAME	domainkey	DKIM
TXT	root	DMARC

Customer.io records to expect

Automatic setup

Best fit: Use it when Customer.io can connect to your DNS host and you are comfortable approving record changes.
Check anyway: Review each applied record after setup, especially MX priority and CNAME proxy status.

Manual setup

Best fit: Use it when DNS changes need approval or your DNS host is not supported by automatic setup.
Copy exactly: Paste the host, type, priority, and value from Customer.io without converting record types.

Set up SPF

Customer.io SPF belongs on the Customer.io-specific subdomain, not in your root SPF record. This keeps Customer.io out of your root SPF lookup budget and gives Customer.io a return-path domain that matches your From domain under relaxed DMARC matching.

Customer.io authentication screen showing SPF and return-path records.

Copy host: Copy the SPF hostname exactly, usually a Customer.io-generated subdomain such as cio12345.
Use TXT: Create a TXT record. Do not use the old DNS SPF record type.
Keep separate: Do not merge the Customer.io SPF value into your root SPF record unless Customer.io explicitly shows the root hostname, which is not the normal setup.
Add MX too: Publish the Customer.io MX return-path records because SPF matching depends on the envelope domain, not the visible From address.
Wait for DNS: DNS propagation often finishes quickly, but Customer.io says verification can take up to 72 hours.

SPF checker

Find SPF syntax issues, lookup limits, and weak records.

?/16tests passed

Common SPF mistake

Most Customer.io SPF failures I see come from adding the full hostname twice. If your DNS host appends the domain automatically, enter only the left side that Customer.io shows before your root domain.

Set up DKIM

DKIM is the most important Customer.io authentication signal because it signs the message itself. Publish the DKIM record exactly as Customer.io shows it, including the selector, hostname, and value.

Customer.io DKIM record row with selector, host, value, and pending status.

Copy type: Use the record type shown by Customer.io. Current accounts can show either TXT-style or CNAME-style DKIM values.
Copy selector: Keep the full _domainkey hostname unless your DNS host appends the root domain for you.
Disable proxy: If Customer.io gives a CNAME, keep it DNS-only. Proxied CNAME records break mail authentication.
Preserve value: Do not wrap, trim, or edit the DKIM value. For TXT values, keep all quoted chunks as one logical DNS value.
Verify later: Save the DNS record, then return to Customer.io and run Verify domain after the TTL has passed.

Do not switch DKIM type

If Customer.io shows TXT, publish TXT. If Customer.io shows CNAME, publish CNAME. Converting a DKIM record because another guide shows a different type is a reliable way to fail verification.

Set up DMARC

DMARC goes on the root domain, not on the Customer.io-generated subdomain. If your domain has no DMARC record, start with p=none and reporting. If your domain already has p=quarantine or p=reject, keep that policy and fix Customer.io until it passes.

Starter DMARC recorddns

Host: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com

Check existing: Look for an existing TXT record at _dmarc before adding a new one.
Use one record: A domain must have one DMARC TXT record. Multiple records cause a DMARC permerror.
Keep relaxed: Do not add aspf=s or adkim=s for Customer.io unless you have tested every sending path.
Add reporting: Replace dmarc@example.com with the reporting address you actually monitor.
Generate safely: Use the DMARC record generator if you need a clean record with reporting and policy tags.

DMARC checker

Look up a domain's DMARC record and catch policy issues.

?/7tests passed

Strict matching breaks Customer.io

Customer.io signs through an account-specific subdomain. Default relaxed DMARC matching accepts that parent and child domain relationship. Strict matching requires identical domains and can make valid Customer.io mail fail DMARC.

Verify and troubleshoot

Verification has two layers. Customer.io must verify the DNS records before sending, and a real delivered email must show SPF, DKIM, and DMARC passing in the message headers.

Customer.io verified sending domain with green checks for authentication records.

Click verify: In Customer.io, click Verify domain after saving DNS records.
Wait sensibly: If the status stays pending, wait for the DNS TTL and retry. Customer.io says verification can take up to 72 hours.
Send real mail: Send a Customer.io test email from the authenticated From address and inspect the received headers.
Check results: The delivered message should show SPF pass, DKIM pass, and DMARC pass.
Repeat per domain: Every From domain you add to Customer.io needs its own authentication records and verification.

Email tester

Send a real email to this address. Suped opens the report when the test is ready.

?/43tests passed

Preparing test address...

Customer.io check

Purpose: Confirms Customer.io can find the expected DNS records.
Limit: It does not continuously check records after you click Verify domain.

Message check

Purpose: Confirms the final email passes authentication at the inbox side.
Limit: A single test does not prove every campaign, transactional path, or From address is clean.

Fast fixes

SPF pending: Confirm the record is TXT, placed on the Customer.io subdomain, and not duplicated at the same hostname.
DKIM pending: Confirm underscores are allowed and CNAME records are not proxied.
DMARC fail: Remove strict matching tags, keep one DMARC record, and confirm Customer.io DKIM or SPF passes on delivered mail.
DNS error: Escape semicolons only if your DNS host requires it. Otherwise paste values exactly.

Get alerted when it breaks

Customer.io verifies records when you click Verify domain, but it does not keep polling your DNS forever. That means a later DNS edit, missing DKIM value, or strict DMARC change can break sending without Customer.io warning you first.

Suped is the best overall DMARC monitoring platform for this workflow because it turns DMARC reports into source-level issues, alerts, and practical fix steps instead of leaving you with raw XML.

Real-time alerts: Suped alerts you when Customer.io starts failing DMARC, SPF, or DKIM checks.
Issue guidance: Suped groups failures by source and gives fix steps, so you can tell whether the problem is SPF, DKIM, DMARC, or DNS.
Unified checks: Suped brings DMARC, SPF, DKIM, hosted SPF, hosted DMARC, blocklist monitoring, and blacklist monitoring into one operational view.
Multi-domain work: Suped's MSP and multi-tenancy dashboard helps teams manage Customer.io authentication across many customer or brand domains.

Monitoring rule

Treat Customer.io verification as the setup gate and Suped monitoring as the ongoing control. DNS records change, vendors rotate infrastructure, and DMARC only protects you when failures are noticed fast.

Secure your domain with p=reject

Move to p=reject only after Customer.io and every other legitimate sender passes DMARC in real traffic. For a new Customer.io setup, p=none with reporting is the safe start. For a domain already at quarantine or reject, keep enforcement and fix any Customer.io failure before sending volume.

Collect reports: Run p=none long enough to cover normal Customer.io transactional messages, journeys, broadcasts, and low-frequency sends.
Identify sources: Confirm which rows belong to Customer.io and which belong to other mail systems using the same domain.
Fix failures: Resolve Customer.io SPF, DKIM, and DMARC failures before raising policy.
Stage policy: Move through quarantine first if you need a controlled rollout, then move to reject once legitimate traffic is clean.
Keep watching: After reject, monitor Customer.io daily because one missing DNS record can turn into rejected customer mail.

DMARC rollout gates

Use policy changes as readiness gates, not calendar dates.

Monitor

p=none

All legitimate sources found and Customer.io visible in reports.

Contain

p=quarantine

Customer.io passes and unknown traffic is understood.

Block

p=reject

Legitimate traffic stays clean under enforcement.

Mature DMARC recorddns

Host: _dmarc
Type: TXT
Value: v=DMARC1; p=reject; rua=mailto:dmarc@example.com

Suped's Hosted DMARC is useful here because policy staging can happen without hand-editing DNS for each step. Suped also keeps the Customer.io source visible while you move toward reject.

Best practical target

For most teams, the end state is Customer.io fully verified, DKIM passing on real mail, SPF passing through the custom return-path, DMARC at p=reject, and Suped alerting before a DNS or vendor change causes rejected mail.