Select built-in delivery or custom SMTP first
Customer.io's email authentication documentation distinguishes its built-in delivery service from custom SMTP. For built-in delivery, it requires domain authentication using SPF and DKIM. For custom SMTP, it directs authentication responsibility to the SMTP provider rather than requiring the same domain-authentication setup inside Customer.io. This is the first decision in the configuration plan.
Record the workspace, delivery route, intended From domain and message categories. Identify whether a migration or exception causes some messages to use another transport. A single application can orchestrate several delivery paths, so a verified sending domain in one path is not evidence about every message triggered by that application.
This guide describes the documented built-in workflow and the boundary with custom SMTP. It does not assert that a particular Customer.io workspace is configured, that any credentials have been entered, or that any recipient has received a test message. The broader implementation acceptance remains open. Customer.io Email Authentication
Use the generated subdomain records
The built-in service provides domain-authentication records tied to the selected sending domain. Customer.io explains that its configuration uses a Customer.io-specific subdomain, illustrated with an account-specific cio identifier, rather than taking over the root domain. Preserve the actual generated owner names and values from the workspace; the illustration is not a value to copy into every customer's zone.
The documentation explicitly separates this SPF configuration from the root domain's SPF policy. Do not add a guessed Customer.io include to the root record simply because that is where other sending services have been configured. Map the account-generated subdomain and each record's purpose before submitting the DNS change.
The DNS administrator should check the authoritative zone, existing records and editor conventions for fully qualified names. Review the complete proposed record set, not only the public key that looks most obviously related to DKIM. A successful plan preserves unrelated mail infrastructure while establishing the intended provider-specific dependencies. We will not take over your root domain; manual authentication
Choose a controlled publication workflow
Customer.io documents both an automatic authentication option and manual DNS publication. An automatic helper can involve access to a DNS provider; that access is a separate security decision, not an implied permission granted by reading a setup guide. This manuscript proposes manual review of the generated change so the existing DNS owner can approve and apply the intended records through established controls.
Copy the record types, owner names and values exactly from the selected domain's instructions. Retain the before-state and a change reference. For long DKIM TXT data, distinguish multiple quoted character strings within one TXT record from multiple independent records. Do not truncate a key to fit an assumed interface limit or publish several conflicting key records because a display wraps the text.
The correct acceptance target is the published data at the intended name. Screenshots of a DNS editor can support the change history, but they do not by themselves establish what an external receiver can retrieve. Authenticate your domain manually; DNS provider FAQs; RFC 1035, section 3.3.14
Reconcile DMARC alignment settings before activation
Customer.io's built-in delivery guidance requires relaxed aspf and adkim settings for the documented setup. It also notes that omitted alignment tags use relaxed defaults. If the organization's current DMARC policy explicitly requires strict alignment, treat that as a design conflict requiring the domain owner's decision, not a tag to delete casually in order to satisfy a product checklist.
Use protocol terminology carefully. The visible author address is in the RFC5322 From field. SPF evaluates SMTP identities, including MAIL FROM, while DKIM has a signing domain identified by d=. DMARC compares the relevant passing identity with the author domain under the applicable alignment mode. The return path and visible From address should not be swapped in the evidence worksheet.
A policy change can affect other mail using the same domain. Consider the existing sender inventory, subdomain design and security requirements before deciding how to accommodate the route. The provider requirement does not prove that relaxing an organization's policy is authorized or appropriate in every case. Relax your aspf and adkim tags; RFC 9989, section 4.4; RFC 7208, section 2.4
Request verification and keep link tracking separate
After the required records are published, use Verify domain in Customer.io. The documentation says verification happens when requested rather than through continuous polling. A team waiting for the interface to discover a change automatically can therefore mistake an unrequested check for a DNS failure. Record the check time and actual outcome before investigating further.
Branded link tracking is another configuration with its own domain and CNAME verification requirements. It is not identical to authenticating the email's signing or envelope identity. Likewise, custom SMTP can still involve a separate tracking-domain setup even though the SMTP provider handles mail authentication. Keep these status indicators in separate worksheet rows.
When a check fails, first compare the selected workspace, domain and generated record list with the actual proposed DNS change. Do not repeatedly alter unrelated root records or change a DMARC policy merely because a tracking status is incomplete. Escalate the specific unresolved component with minimized evidence. Verify domain; custom SMTP and link-tracking guidance
Acceptance worksheet for a workspace handover
Use this proposed worksheet to prevent several green status indicators from being collapsed into one unsupported readiness claim.
- Transport inventory: list built-in delivery, custom SMTP exceptions and the messages assigned to each route.
- Sending domain: retain the selected workspace, From domain and actual generated subdomain identifiers.
- DNS plan: record every required owner, type and value, the authoritative zone and the approval reference.
- Alignment decision: record existing aspf/adkim settings and the domain owner's resolution of any strict-alignment conflict.
- Provider check: retain the time Verify domain was requested and its returned result.
- Tracking check: separately record whether a branded tracking domain is used and which verification applies.
- Message evidence: retain a minimized authorized sample with author, envelope and signing identities plus trusted validation results.
- Release ownership: identify who will review route changes, retire unused dependencies and approve production readiness.
This worksheet is an original proposed control. None of its rows is completed by the existence of this manuscript.
Fictional diagnosis: waiting for a check that was never requested
A fictional education platform publishes the records generated for its built-in Customer.io route. The administrator checks the interface several hours later and sees that the domain is still unverified. Assuming the root SPF record is wrong, a colleague proposes adding another mechanism there. The change request contains no evidence connecting that root policy to the generated subdomain.
The reviewer instead confirms that nobody selected Verify domain after publication. The proposed next step is to request the documented verification, inspect its actual result and then investigate only the unresolved records. Branded tracking remains a separate incomplete task, and no claim is made about received-message alignment until an authorized sample is reviewed. This fictional diagnosis does not report a real account event, a live DNS query or a successful test.