For Customer.io's built-in email delivery, add a sending domain, publish its account-generated MX, SPF and DKIM records on the specified subdomain, preserve or establish DMARC safely, and request domain verification. Do not merge the built-in SPF record into your root-domain SPF or replace your employee-mail MX records. Custom SMTP is a different route: its delivery provider controls authentication. Customer.io domain authentication.
Identify the workspace and delivery route
Write down the workspace, account region, From domain and actual delivery transport before changing DNS. This article concerns Customer.io Messaging email, not SMS, push, in-app messages or an unrelated product integration. The built-in procedure is domain-specific; do not assume another workspace's selectors or public keys apply.
For custom SMTP, Customer.io says you do not authenticate the domain through its built-in procedure. Follow the SMTP provider's SPF, DKIM and envelope-domain requirements instead. A sending domain still needs to be configured in Customer.io. If your SMTP server restricts connections by IP, consult Customer.io's current US/EU regional allowlists; those connection-source IPs are not a ready-made SPF policy for delivery to recipients. Custom SMTP documentation.
Do not turn an SMTP connectivity issue into a DNS-authentication change. A rejected connection, an unauthorized From address and a receiver's DMARC failure are different failures with different owners. Changing a DKIM key will not open a blocked network port.
Before setup, export the existing zone and identify other senders, inherited policies, delegated subdomains and record owners. Obtain approval for automatic DNS writes if your team uses a managed change process. Record the current From addresses for broadcasts, automations and transactional messages so later tests cover the paths you actually use.
Add the domain and collect its generated values
Open Settings → Workspace Settings → Email → Add sending domain. Enter the domain, display name and address, then use Show Records. For built-in delivery, expect account-specific MX destinations and priorities, SPF TXT and DKIM TXT, with a DMARC policy check. Customer.io offers manual publication or Entri automatic setup. Domain setup.
Create a record inventory rather than copying only the visually prominent DKIM row. Preserve the complete owner and value for each row and distinguish an MX record set containing multiple destinations from multiple unrelated setup tasks. An MX priority is part of the instruction, not an optional label.
An illustrative account subdomain might look like cioACCOUNT.example.com, with a DKIM owner beneath it. This is a shape to recognize, not a hostname to publish. Copy the exact generated names. If a screenshot, tutorial or previous workspace shows a different number, selector or key, it is not an alternative configuration.
For automatic setup, review the proposed owners, types and policy changes before authorizing access. For manual setup, send the approved inventory to the DNS administrator with the authoritative zone specified. A screenshot saying records were added is less useful than a saved before-and-after list of full DNS names.
Publish at the right DNS owners
Customer.io's account-specific subdomain arrangement keeps its SPF and return-path MX separate from root-domain mail. The correct action is to publish at those generated owners, not overwrite the apex. Built-in authentication layout.
SPF checks the SMTP MAIL FROM identity. Publish SPF as a TXT record, not the obsolete dedicated SPF record type. At each owner, keep only one applicable v=spf1 policy. If the generated subdomain already has conflicting SPF, investigate the existing use before replacing it. The ten DNS-lookup-term limit applies to that SPF evaluation, including nested includes; adding a separate subdomain policy does not mean appending it to the root policy. SPF standard.
Add all supplied MX destinations with their exact priorities at the generated return-path owner. Leave inbound MX at the organizational domain alone. In a DNS editor that groups MX values into one record set, place the destinations within that set rather than overwriting one with the other.
Before requesting verification, have the routing owner approve the complete resulting MX set for each generated owner, separately from copying Customer.io's packet. Compare the full owner, every numeric priority and every target against that approved set at both authoritative DNS and a recursive resolver. Stop on a missing, additional or mismatched entry; do not activate unapproved inbound routes. Preserve employee-mail MX and do not change parent nameservers, DNSSEC or forwarding for this task.
Publish the supplied DKIM public-key TXT at the exact selector owner. For a hypothetical cio._domainkey.cioACCOUNT.example.com, an editor managing example.com may want the relative name cio._domainkey.cioACCOUNT. Verify how your host appends the zone name; avoid example.com.example.com in the saved result.
For that illustrative cio._domainkey.cioACCOUNT.example.com owner, an editor managing a separately delegated cioACCOUNT.example.com uses cio._domainkey; an existing delegated _domainkey.cioACCOUNT.example.com zone uses cio. A full-name field takes the complete owner. Use the actual generated selector and subdomain. Preserve the existing NS delegation and active selectors, publishing with that authority rather than in an inactive parent copy. DNS zone boundaries.
A long key can be represented as multiple character strings within one TXT record. Do not shorten it or create multiple separate keys at the same selector. Compare the concatenated public answer with the original value. The private key stays with the signer; public DNS alone cannot make a provider sign with a different key. DKIM selectors and key records.
If a requested owner has a CNAME, resolve that collision before adding TXT or MX. A CNAME generally cannot coexist with other data at that name. Do not remove an alias whose purpose is unknown. DNS alias rules.
Resolve DMARC alignment without an unapproved downgrade
Customer.io's built-in route uses an account-specific subdomain for authenticated identities and documents relaxed SPF and DKIM alignment. Treat an existing strict-alignment policy as a design decision requiring review, not as a typo to delete. Customer.io alignment requirement.
Relaxed alignment permits identities under the same organizational domain; strict alignment requires an exact domain match. DMARC needs either aligned passing SPF or aligned passing DKIM. Thus two cryptographic or authorization passes can still fail DMARC when neither domain aligns with visible From. The applicable current standard is RFC 9989, replacing RFC 7489; its removed pct tag should not be added as a gradual-enforcement control. DMARC specification.
If your security policy requires strict alignment, pause the built-in rollout and discuss an acceptable route with the domain owner and Customer.io. Custom SMTP may provide a separately configurable route, but its actual capabilities must be verified with that provider. Do not promise a workaround merely because a settings screen allows a different From address.
Before publishing DMARC, query the exact From-domain policy owner and applicable parent policy. Preserve the existing record, including enforcement and report destinations. A new weaker child record can override inherited protection; an absent child TXT response is not permission to add p=none there.
Only if no direct or applicable inherited policy exists, and the owner approves an appropriate monitoring plan, an organizational-domain example is:
- Zone:
example.com. - Type:
TXT. - Name:
_dmarc. - Value:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com. - TTL: the DNS host's normal default or your documented change value.
The example's full owner is _dmarc.example.com, relative _dmarc in zone example.com. Use your real domain and an approved, functioning report mailbox. Preserve the semicolons and create one TXT policy, not a duplicate.
For an approved child-domain policy, _dmarc.news.example.com is relative _dmarc.news in zone example.com, or _dmarc in a separately delegated news.example.com zone. A full-name field uses the complete owner. These naming examples do not authorize a child override of inherited protection.
Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, which is not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as the policy domain is excepted; a different hostname alone does not make it external. Follow the report receiver's exact authorization instructions when needed. This protocol check is separate from the domain owner's approval to share report data with that recipient. RFC 9990 section 4.
Keep enforcement decisions separate from onboarding. If employee mail or a separately selected SMTP route uses Microsoft 365, consult the Microsoft 365 authentication guide for that service. Its records do not replace Customer.io's built-in account-subdomain packet.
Request verification and test public DNS
After publication, return to the domain's Authentication area and click Verify domain. Customer.io documents a possible verification window of up to 72 hours. Recheck after a correction rather than assuming publication alone requested a new validation. Verification procedure.
Use the real generated names in read-only queries such as these illustrative examples:
dig +short MX cioACCOUNT.example.com
dig +short TXT cioACCOUNT.example.com
dig +short TXT cio._domainkey.cioACCOUNT.example.com
dig +short TXT _dmarc.example.com
Check for every expected MX destination and priority, one correct SPF policy, the complete DKIM public key, and the intended DMARC policy. For a From subdomain, query its direct DMARC owner too and assess inheritance. If the account uses different shapes, use those instead of adapting the account to these examples.
Compare an authoritative answer with a public recursive resolver when results disagree. Save the timestamp, resolver and TTL. A missing record may indicate the wrong zone, duplicated suffix or unfinished publication, not merely a cache delay. Conversely, a provider's verified status is not a permanent promise about the current DNS state.
Keep link tracking separate from authentication
A branded link hostname is not the DKIM signing domain or the envelope identity. Customer.io has a separate Link Tracking tab with generated CNAME instructions. HTTP tracking targets differ by US/EU region, and HTTPS setup has additional requirements. Use the workspace's own instructions rather than copying a target from another region. Custom-domain link tracking.
Test links independently: confirm the intended hostname, certificate behavior and final destination on controlled content. A working tracking link does not prove DKIM passed; dmarc=pass does not prove a branded HTTPS link works. Record separate acceptance results so a tracking outage does not trigger an unnecessary authentication rollback.
Verify a delivered message from each route
Arrange a small authorized send to controlled receiving mailboxes through the actual built-in workflow. Inspect the receiver's trusted Authentication-Results, not an arbitrary header that a sender could have inserted. Record spf, smtp.mailfrom, dkim, header.d, dmarc and header.from, plus the DKIM selector from the signature. Authentication-results trust boundary.
Establish which results were generated inside the receiving service's known processing boundary and how that service removes, ignores or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving-mail administrator to confirm the boundary. A familiar authserv-id string or header position alone is not proof. Ignore attacker-supplied or otherwise untrusted fields; obtain receiver-controlled diagnostic evidence when provenance is uncertain. Operational receiving-result trust.
For the intended built-in configuration, require the intended Customer.io DKIM signature to pass and align with the unchanged approved branded From under the effective adkim policy, together with trusted receiver dmarc=pass for that From. Verify the selector and signing identity against this workspace's configuration. A rewritten provider From, unrelated passing signature or SPF-only DMARC success does not complete the branded DKIM setup. Save the message identifier and date alongside the exact workspace and From address.
Investigate SPF independently at the observed smtp.mailfrom owner even when aligned DKIM makes DMARC pass. For fail or softfail, compare the connecting source with the applicable authorizations and actual route; for permerror, check duplicate policies, syntax and the nested DNS-querying-term limit; for temperror, investigate DNS availability and retest after recovery. A passing but unaligned provider-owned identity is different from these failures. Do not try to repair a provider-owned envelope policy by adding speculative root-domain includes. SPF results.
Repeat for a materially different route, especially custom SMTP or a dynamically selected sender. One successful broadcast does not certify every transactional message. Authentication is necessary identity evidence, not a guarantee of acceptance, inbox placement or engagement.
Troubleshooting and frequently asked questions
SPF is correct but the domain will not verify. Why?
Check its owner, not just the value. The built-in policy belongs on the generated account subdomain, not inside root SPF. Also confirm TXT type and whether verification was requested after the correction.
The DNS editor rejects the DKIM value. Can I shorten it?
No. Ask how the editor accepts long TXT values and preserve the entire key in one logical record. Do not remove _domainkey, punctuation or key characters to satisfy a form.
Why does a message fail DMARC when SPF and DKIM pass?
Compare the authenticated domains with visible From and the applicable alignment modes. This is particularly important when strict alignment meets an account-subdomain route.
Do Customer.io records authenticate custom SMTP?
Not automatically. The selected SMTP service must authorize and sign its own outgoing route. Inspect the actual delivery provider and headers before choosing DNS changes.
What evidence supports this guide?
No customer DNS, account configuration, real-message delivery or deployed page was tested or changed. The procedures above describe checks to perform, not tests already passed.