How do I set up SPF and DKIM for Customer.io?
ChatGPT
Claude
Gemini
Perplexity
Grok
To set up SPF and DKIM for Customer.io's built-in email service, open Settings > Workspace Settings > Email, add the domain used in your From address, and choose automatic or manual authentication. Customer.io generates DNS records for an account-specific subdomain. Copy those exact values into your DNS provider, verify the domain, and test a new message. Do not replace or delete unrelated records on your root domain.
Quick takeaways
- This guide covers Customer.io's built-in delivery service, not a custom SMTP provider.
- Automatic setup uses Entri to add the required records through a supported DNS provider.
- Manual setup uses account-generated MX, SPF, and DKIM records, while DMARC remains on the root domain.
- Customer.io places its authentication records on an account-specific subdomain rather than merging them into your root SPF record.
- Verification in Customer.io, public DNS, delivered headers, and DMARC reports are separate checks.
What should I check before configuring Customer.io?
Confirm that the message will use Customer.io's built-in delivery service. If your workspace sends through custom SMTP, authenticate the domain with that SMTP provider instead. Customer.io's current domain-authentication documentation says its own sending-domain authentication is not required for custom SMTP, although a separate branded link-tracking record may still apply.
You need access to Workspace Settings, permission to add a sending domain, and access to the authoritative DNS zone. Decide which domain will appear after the @ in the production From address before changing DNS. Customer.io also requires a From address before domain authentication can finish.
Review the existing root-domain MX, SPF, DKIM, and DMARC records. Customer.io publishes its built-in-delivery records on an account-specific subdomain so they do not replace your normal inbound MX or root SPF policy.
Copy account-specific DNS values from the Customer.io workspace and domain you are configuring. Never publish subdomains, hosts, targets, keys, or tokens from another account or an online example. Do not delete existing root-domain DNS records.
Which setup method should I use?
Use Automatic setup when Customer.io offers your DNS provider through Entri and you are authorized to approve the changes. Review the proposed records before completing the connection. Automatic setup reduces manual entry, but it does not remove the need to verify the public answers and a delivered message.
Choose manual setup when the provider is unavailable, another team owns DNS, or your organization requires change control. Open Show Records in Customer.io and keep the page available while entering each record. Customer.io documents a separate Cloudflare authorization option in some account flows. Use the method shown in the workspace you are configuring.
How do I set up SPF and DKIM for Customer.io?
1. Add the sending domain
Open Settings > Workspace Settings > Email and select Add Sending Domain. Enter the domain, display name, and From address used by production messages, then add the domain. If the domain already exists, select it and open Show Records.
Source: Customer.io, "Authenticate a sending domain". Publication rights and current-interface review are still required. Open the full-size screenshot.
2. Choose automatic or manual authentication
Select Automatic setup and continue through Entri when that method fits your change process. For manual work, display the account-generated record list and copy each owner, type, value, priority, and other setting exactly as shown.
Source: Customer.io, "Authenticate a sending domain". Publication rights and current-interface review are still required. Open the full-size screenshot.
Some DNS interfaces append the zone name automatically. Check whether the host field expects only the relative label or the complete owner name before saving. Otherwise, a record intended for a Customer.io subdomain can be published with the root domain repeated twice.
3. Publish the account-generated records
Customer.io's manual built-in-delivery workflow displays MX, SPF, and DKIM records for its account-specific subdomain. Publish the complete set shown in your workspace.
Customer.io return-path record
- Record type: the account-generated
MXrecord type - Host: the account-generated Customer.io subdomain
- Priority and target: the values shown in the workspace
- Record type:
TXT - Host: the account-generated Customer.io subdomain
- Value: the complete SPF policy shown in the workspace
- Record type:
TXT - Host: the account-generated DKIM owner
- Value: the complete public key shown in the workspace
4. Preserve or publish DMARC at the root domain
Customer.io checks the root domain's DMARC policy separately from its account-specific authentication records. If a valid DMARC record already exists, preserve it. If no policy exists, plan a monitored deployment based on every legitimate sender, not Customer.io alone.
Publish one DMARC policy at _dmarc for the root domain. Do not create a different DMARC record on the Customer.io-specific subdomain unless your domain design and current standards require a deliberate exception.
5. Verify the domain in Customer.io
Wait for public DNS answers to update, return to the sending domain, and select Verify domain. Customer.io documents Verified, Unverified, and Undetermined states. Resolve every missing or mismatched record before treating the domain as ready.
6. Send a new production-path test
Send a message through the same Customer.io workspace, channel, and From address that production will use. Deliver it to a mailbox where you can inspect the raw headers. A message created before verification does not prove the verified path is working.
How does this setup affect DMARC?
Customer.io uses an account-specific subdomain for its return path, SPF, and DKIM identifiers. Its documentation says this design supports relaxed DMARC alignment with the related visible From domain. Under the current DMARC standard, DMARC passes when at least one authenticated SPF or DKIM identifier passes and aligns with the author domain under the published alignment mode.
Strict alignment can change the result because it requires an exact domain match. Do not loosen aspf or adkim only to clear a warning. First inspect a delivered message, confirm which identifier Customer.io used, and decide whether the policy or the sending-domain design should change.
Use Palisade's DMARC checker to confirm the published root-domain policy before changing enforcement.
How do I validate the setup?
Check public DNS
Resolve the exact owners shown by Customer.io through the authoritative DNS service and at least one public resolver. Check the MX answer, SPF TXT policy, DKIM TXT key, and the root-domain DMARC TXT policy. If resolvers disagree, wait for cache expiry and check the authoritative answer before editing the records again.
You can also check the SPF record and check the DKIM selector with Palisade. These checks show public DNS. They do not prove that Customer.io used the records on a real message.
Check the Customer.io status
Return to Settings > Workspace Settings > Email. The sending domain should show Verified, and the required record checks should be complete. This proves Customer.io can resolve the configuration it expects. It does not prove that every production message used the intended From address or signing identity.
Source: Customer.io, "Authenticate a sending domain". Publication rights and current-interface review are still required. Open the full-size screenshot.
Inspect a delivered message
Open the raw headers of the new test message and use the receiver-added Authentication-Results field. RFC 8601 defines this field and its trust considerations, so use results added by the receiving system rather than an untrusted copy inside the message.
Confirm spf=pass, dkim=pass, and dmarc=pass. Record the SPF MAIL FROM domain, the DKIM d= domain, and the visible From domain. At least one passing identifier must align for DMARC.
Review DMARC reports
Review aggregate reports after normal Customer.io traffic appears. Identify the Customer.io source, then confirm SPF, DKIM, alignment, and disposition results for the production From domain. A single test proves one message path. Reports show whether scheduled campaigns, transactional messages, or other workspaces behave differently.
Troubleshooting
Customer.io cannot find a record that exists in the DNS panel
Resolve the complete public owner name. The DNS provider may have appended the root domain to a full hostname, producing the domain twice. Edit the host field according to the provider's relative-name rules, then query the record again before selecting Verify domain.
The SPF record is correct but remains unverified
Confirm that the record type is TXT and that the policy is published on the Customer.io-specific subdomain shown in the workspace. Do not move it to the root domain or create a second root SPF record.
The DNS provider rejects the DKIM owner
DKIM owner names contain _domainkey, which requires an underscore. If the provider cannot publish the required owner, ask the provider to add it or move authoritative DNS to a service that supports standard DKIM records. Do not remove the underscore.
Customer.io shows Verified but DMARC fails
Inspect the delivered header domains. The message may use a From address outside the verified domain family, or the domain may require strict alignment that the Customer.io subdomain does not satisfy. Fix the From-domain choice or make a deliberate policy decision based on all legitimate senders.
Verification is still pending
Customer.io says verification can take up to 72 hours, although it often completes sooner. Check the authoritative and public answers rather than repeatedly replacing correct records. If the expected answers are public and the status remains unchanged, retry verification and contact Customer.io with the exact failing owner.
Check the domain beyond Customer.io
Run Palisade's Email Security Score against the production From domain after Customer.io verifies it. The score checks public authentication signals, but it does not prove that a delivered Customer.io message used the intended identities or provide continuous monitoring.
Fixing one Customer.io path does not show whether other services are still failing alignment. Palisade's DMARC Agent turns aggregate-report data into a prioritized list of sender, SPF, DKIM, and DMARC issues. It detects when authentication and alignment conditions indicate that a domain is ready for the next policy stage, then proposes the move for your team to review and apply. This human-in-the-loop workflow helps you progress toward p=reject while keeping policy changes under your control. Stronger authentication helps protect your domains and supports better email deliverability.
Palisade does not change Customer.io settings, control receiver handling, guarantee delivery, or apply a DMARC policy change without human approval.
Frequently asked questions
Do I need Customer.io authentication when I use custom SMTP?
No. Customer.io says its sending-domain authentication is not required when the workspace sends through custom SMTP. Authenticate the domain with the SMTP provider and validate that provider's return path, DKIM signature, and DMARC alignment instead.
Should I add Customer.io to my root SPF record?
No. For Customer.io's built-in delivery service, publish the account-generated SPF policy on the Customer.io-specific subdomain shown in the workspace. Preserve the single root SPF policy used by other services.
Do I need both SPF and DKIM for Customer.io?
Yes. Customer.io requires both records for its built-in email server. Publish every account-generated authentication record and confirm the complete set before relying on the domain for production sending.
Can I authenticate more than one sending domain?
Yes. Customer.io supports multiple sending domains, but each domain needs its own From address, account-generated records, verification state, and delivered-message test. Do not reuse one domain's values for another domain.
Does Customer.io configure DMARC for my whole domain?
No. Customer.io checks the root-domain DMARC policy, but the domain owner remains responsible for that policy and every legitimate sender it covers. Review aggregate reports before moving to stronger enforcement.
Will a Verified status guarantee DMARC pass?
No. Verified confirms that Customer.io found the expected DNS configuration. A production message still needs an aligned SPF or DKIM pass. Confirm that result in trusted receiver-added headers and aggregate reports.
Keep going with AI
Ask AI how this applies to you
Take this guide to your assistant — each question opens pre-filled, with a link back to this page so it can read the details.
- How do I set up SPF and DKIM for Customer.io?
- How does this apply to my domain?
- What should I do about it, step by step?
Written by
Samuel ChenardCEO & Co-Founder, Palisade
Samuel Chenard is the CEO and co-founder of Palisade, AI-first DMARC software for IT teams and MSPs, from one domain to thousands.
More from Samuel →
