Customer.io sending domains: split system mail from marketing before you warm anything

In 1300 Edward I passed a statute aimed at goldsmiths selling metal below the true alloy as good. Silver had to meet the sterling standard of 92.5 per cent pure silver, and gold the "touch of Paris" at 19.2 carats. The "Guardians of the craft" were to go from "shop to shop", test the work and strike it with a leopard's head. No silver vessel could leave a workshop until it carried the mark, according to the Goldsmiths' Company Assay Office's history of hallmarking.

That mark answered one question: does this piece meet the standard? In 1363 an ordinance of Edward III added a second, the maker's mark, which identified the goldsmith responsible for the piece. By 1478 a date letter had joined them, changing every year, and Goldsmiths' Hall had become a permanent assay office... which is probably where the word "hallmark" comes from, the Goldsmiths' Company says. In 1757 counterfeiting a hallmark became a felony punishable by death.

Three marks, three separate questions: does it meet the standard, who made it, when was it tested. Mailbox providers ask the same questions of every email you send, and they keep the answers per sending domain. Put your password resets and your Black Friday promotion on the same domain and they get one mark between them. That is the case for splitting your Customer.io sending domains before you warm anything.

TL;DR: The root domain never sends. Customer.io places its DNS records on an account-specific subdomain rather than your root, and Google says Gmail tracks volume, feedback and sending limits per domain. So agree four names before the first email goes out. One subdomain for system mail (verification codes, receipts, password resets), one for lifecycle mail, one for broadcasts and newsletters (the warmed marketing spare), and one for link tracking. Names are free to change on day one and cost a restarted warm-up later. Gmail's spam-rate line is 0.3%, with 0.10% the level to stay under, and a promotion that crosses it must never share a domain with a passcode. The honest boundary: a team sending a few thousand emails a month with no transactional mail in Customer.io needs one marketing subdomain and the tracking domain, not four.

Why the root domain never sends from Customer.io

Customer.io's domain authentication page has a section headed "We will not take over your root domain". To authenticate a domain you place the records in an account-specific subdomain, which the domain authentication page writes as cio#####.yourdomain.com, rather than at the root. The page gives three reasons. The SPF record stays valid, passes DMARC alignment and does not count towards the lookup limit on your existing SPF record. The MX record leaves inbound mail to your own mail server alone. And the DKIM record carries the public key that matches the emails Customer.io signs.

So even if you type your bare domain into the sending domain field, the mail is signed and bounced through a subdomain of it. The Customer.io-managed subdomain "is always new from the perspective of inbox providers, even if your root domain has years of sending history". The domain warming page says to use the warm-up schedule for all new sending setups regardless. Your root domain's history buys you nothing at Gmail. You are building reputation on a subdomain either way, so choose names that mean something.

The one record that does sit on the root is DMARC. The authentication page says to add _dmarc only as a subdomain of the root domain, like _dmarc.root-domain.com, and not to any of your subdomains. That is the one piece of the setup you do once rather than once per sending name. Our post on the updated DMARC specification covers what it changes for Customer.io senders. The deliverability guide covers SPF, DKIM and DMARC from the ground up.

Reputation is kept per domain, so one domain means one score

Google's email sender guidelines are the clearest public statement of how Gmail keeps score. On volume: "Gmail tracks volume, feedback, and limits per domain and IP address". On authentication quotas: "DKIM and SPF quotas are specific to your domain. If you hit the limit, other domains that send from the same IP may not be affected." And on complaints: "If messages from your domain are frequently reported as spam, future messages from you are more likely to be marked as spam."

Customer.io's deliverability best practices say the same from the sender's side. Domain reputation "represents the reputation rating for all sending from a given domain", influenced by the domain in your from address and by the complaint rates of emails that include your domain in any links. Any complaint rate above 0.10% "may result in damage to your sender reputation at both the IP and Domain levels". A low IP or domain reputation, the page adds, is the most common reason an email is filtered to spam.

Google also recommends separating message types. If you must send from multiple IP addresses, it says, use a different one for each type, "one IP address for sending account notifications and a different IP address for sending promotional messages". Messages of the same category should share a from address (sales@, deals@, alert@ are its examples), and "don't include promotions in sales receipt messages".

On Customer.io's default shared IP pool you do not choose the IP, so that recommendation has to be honoured one level up, at the domain. A promotion that draws complaints on news.yourdomain.com moves the needle on news., while the password reset leaving account.yourdomain.com is judged on its own record. Share one domain and the two are one record.

Four subdomains, four separate reputations

Role	Example name	What sends from it	Why it is separate
System mail	account.yourdomain.com	Verification codes, receipts, password resets, security alerts	Highest stakes, lowest complaint risk. Must never inherit a marketing spam spike. Also the domain for Customer.io's transactional IP pool.
Lifecycle	play.yourdomain.com	Onboarding, behavioural automations, product-triggered nudges	The main marketing stream, highest volume, gets the full warm-up and the closest monitoring.
Warmed spare for marketing	news.yourdomain.com	Newsletters, one-off broadcasts, re-engagement to older segments	Kept warm at its own volume so a risky send has somewhere to go, and so lifecycle automations survive a bad broadcast.
Link tracking	link.yourdomain.com	The tracked links inside every email	A CNAME to Customer.io's tracking host so links carry your brand. Customer.io notes that link domains feed reputation too.

A client we set up in September 2026 agreed these four names, account., play., news. and link., before a single email left Customer.io. Their system mail stays on their existing transactional provider for now, so account. is reserved and not yet sending. That is the cheap version of this decision. When their verification codes do move, the name and the records are already waiting.

The split between play. and news. is the part people question. Both are marketing, so why two? Because they fail differently. Lifecycle mail goes to people who just did something and expect it; broadcasts go to a list, some of whom have forgotten you. Complaints come from the broadcast, so it gets its own name, and the onboarding sequence that pays the bills carries on from a domain the incident never touched.

Customer.io's own transactional pool assumes the split

Customer.io's IP addresses page describes a separate transactional IP pool with "stricter bounce and spam thresholds" than the default shared pool. The requirement is explicit: "you'll need a separate sending domain from your parent domain dedicated to transactional sending." Once a domain is in that pool, the docs warn, "you can no longer use it to send automations or broadcasts."

Read that as the product saying how it wants to be configured. The pool is only open to a domain that sends nothing else, so a team that wants its receipts on it needs account. from the start. Dedicated IPs are the other route, but they are a Premium and Enterprise feature with a minimum of 50,000 emails a week. For most teams reading this, the domain is the lever you have.

What each sending subdomain needs in DNS

The authentication page lists four DNS records for each domain you send from. One MX record with two hostnames, which creates a custom return-path on your subdomain for bounce and spam feedback and lets Customer.io mail pass DMARC alignment. One SPF record, as TXT. One DKIM record, as TXT. And one DMARC record on the root domain, with v=DMARC1; p=none as the minimum, which Customer.io has checked against Gmail and Yahoo's requirements since 1 February 2024. Both SPF and DKIM must verify. If either is missing, the docs say, deliveries may fail because the domain is no longer verified.

Two details catch teams with several subdomains. First, your DMARC policy must use relaxed alignment. Customer.io signs the return-path, SPF and DKIM headers from the account-specific subdomain, so a strict aspf or adkim tag would fail alignment and bounce or quarantine every email. Unset tags are already relaxed. Second, Customer.io only reads your records when you click Verify domain. It does not poll, so a record removed in a DNS tidy-up goes unnoticed until deliveries fail.

Verification can take up to 72 hours, though the docs say it usually happens faster. A workspace can hold up to 10 sending domains before Customer.io asks you to explain the use case, so four is well inside the limit.

Link tracking is a separate record. The link tracking page has you add a CNAME that aliases e.customeriomail.com or e-eu.customeriomail.com, depending on your account region, and the sending domain must be verified first. HTTPS tracking needs additional steps outside Customer.io, such as a reverse proxy, or the Automatic setup route through Entri. One honest gap: the docs walk through link tracking one sending domain at a time, from that domain's Link Tracking tab. They do not say whether one tracking hostname can serve several sending domains, so confirm that in your workspace rather than assume it.

Decide the names before warm-up, not after

The warming page carries the rule this whole post hangs on, under its core best practices, don't switch domains mid-warm-up: "Starting warm-up on one domain and switching to another mid-process resets all progress. Commit to your sending domain before beginning, and see the warm-up through on that domain."

That is the cost curve. On day one a subdomain is a name in a planning document, and renaming it is find-and-replace. On day twenty it is a reputation in progress, and renaming it means starting again at stage one. Google says the same from the other end: after "any significant changes to your sending infrastructure or email header structure, increase the modified segment of traffic separately". A new subdomain is a new segment with its own ramp.

Each marketing subdomain in the plan is therefore its own warm-up. The docs' rule is that no stage should increase volume by more than 1.5x the previous one, and any later jump above 1.5x your daily average is a new warm-up event. The full schedule, and how to automate it with Daily ramp, is in our post on domain warming. One more timing rule. The docs say inbox providers treat mail from a domain registered within the last 30 days as high-risk, so wait until the root is at least that old.

System mail is the awkward one to warm, because a password reset cannot wait for stage four. That is one more argument for bringing it onto account. early and letting its volume grow with sign-ups, rather than cutting a busy stream over in a single day.

If you are migrating, this is a day-one decision

A migration is the cheapest moment to make this call, because nothing has been warmed yet. Every domain you create is new to Gmail whatever your old provider's history; the only question is how many names that newness is split across. Our ESP migration guide puts the domain plan in the first week for this reason.

When we moved AIRE Health from an internal custom email system to Customer.io, the work was a data plan and a campaign redesign as much as an email move. Campaign conversion went from 7.0% to 17.8%. The sending setup is the least glamorous part of such a project, and the hardest to redo once campaigns are live.

When one subdomain and a tracking domain is enough

The plan above is for teams with transactional mail in Customer.io, or on its way there, and enough marketing volume to keep two names warm. If you send a few thousand emails a month and your verification codes come from a backend that is not moving, four subdomains is process for its own sake.

Two facts set the boundary. Google's bulk-sender requirements, including DMARC and one-click unsubscribe, apply from 5,000 messages a day to Gmail accounts, and our Gmail spam-rate post covers what changes at that line. And a subdomain you cannot keep warm is not a spare, it is a cold domain with a name. The warming docs treat a jump above 1.5x your daily average as a new warm-up event, so a "spare" that sends nothing for months gives you nothing when you need it.

For that team the plan is one marketing subdomain and the link-tracking domain. Still write the other names down: the day the product team asks to move receipts into Customer.io, the answer is already agreed. Outlook has its own list for high-volume senders, set out in our Outlook post, and none of it changes the naming decision.

What to do this week

1. Write the four names into your setup document, even the ones that will not send yet, with who owns DNS.
2. Confirm your root domain's DMARC record uses relaxed alignment, or sets no aspf and adkim tags, before you add the first subdomain.
3. Add the marketing subdomain and the link-tracking CNAME first, verify both, and set up Google Postmaster Tools for the subdomain you are warming.
4. Start the warm-up on that one domain and see it through. Add the second marketing name when you have a send that belongs on it.
5. If receipts or passcodes are coming into Customer.io, add account., and request the transactional IP pool for it once it is verified.

If you would rather have someone who has done this many times set it up with you, that is what we do. Tell us about your sending setup and we will say which version of the plan fits.

Frequently asked questions

Should I send Customer.io email from my root domain or a subdomain?

A subdomain, and in practice you have no choice. Customer.io's domain authentication docs place the SPF, DKIM and MX records on an account-specific subdomain. The heading is "We will not take over your root domain". Only DMARC goes on the root.

How many sending domains can I add to a Customer.io workspace?

Up to 10 without asking. The authentication docs say you can add multiple sending domains to a workspace and must set up at least one before sending. Past 10, Customer.io asks you to explain the use case.

What DNS records does Customer.io need for each sending domain?

Four, according to the authentication docs. One MX record with two hostnames for the custom return-path, one SPF record as TXT and one DKIM record as TXT. The fourth is a DMARC record on the root domain, with v=DMARC1; p=none as the minimum. Custom link tracking adds a separate CNAME, per the link tracking page.

Where does the DMARC record go when I have several sending subdomains?

On the root domain only. The authentication docs say to add _dmarc only as a subdomain of your root, like _dmarc.root-domain.com, and not to any of your subdomains. The same page says the policy must use relaxed aspf and adkim values, or leave those tags out, because Customer.io signs from a subdomain.

Does each Customer.io sending subdomain need its own warm-up?

Yes, if it sends marketing volume. The domain warming docs say the Customer.io-managed subdomain is always new to inbox providers even when the root has years of history. The warm-up schedule applies to all new sending setups, and switching domains mid-warm-up resets all progress. The schedule is in our domain warming post.

Can I use the same link tracking domain for all my sending domains?

Customer.io's docs do not say. The link tracking page configures tracking from each sending domain's own Link Tracking tab, with a CNAME to e.customeriomail.com or e-eu.customeriomail.com. The sending domain must be verified first. Whether one hostname can serve several sending domains is not stated, so test it before planning around it.

What spam rate does Gmail require, and is it measured per domain?

Below 0.3%, measured in Postmaster Tools, and Google says to keep it under 0.10%. Google's sender guidelines state that Gmail tracks volume, feedback and limits per domain and IP address. Frequent spam reports against a domain make its future messages more likely to be marked as spam. That is why a promotion and a passcode should not share a subdomain.

Do I need separate subdomains if I only send a few thousand emails a month?

No, not for system and marketing mail. Google's stricter bulk-sender requirements apply from 5,000 messages a day to Gmail accounts, per its sender guidelines. The warming docs treat any jump above 1.5x a domain's daily average as a new warm-up event, so an idle spare is not a spare. With no transactional mail in Customer.io, one marketing subdomain plus the link-tracking domain is the right size.

Sources

• Customer.io, Domain authentication, documentation, updated 1 September 2026.
• Customer.io, Track links with your domain, documentation, updated 1 September 2026.
• Customer.io, Safely warm up your sending domain, documentation, updated 1 September 2026.
• Customer.io, IP addresses: shared vs dedicated, documentation, updated 1 September 2026.
• Customer.io, Email deliverability best practices, documentation, updated 14 September 2026.
• Google, Email sender guidelines, Gmail Help, read 21 September 2026.
• The Goldsmiths' Company Assay Office, History of Hallmarking, read 21 September 2026.
• The Goldsmiths' Company, The History of Hallmarking, read 21 September 2026.
• NerveCentral, AIRE Health case study.