Home / Categories / Deliverability
If I change my sending domain, do I start from scratch?
Partly. systeme.io names the domain as one of the elements that make up your sender reputation with each inbox provider, and its own advice is to warm up again and start gradually if you have to change it. Whether your account's place in systeme.io's own IP pool system also resets is not addressed by any article read for this answer.
The domain is one ingredient, not the whole recipe
systeme.io describes reputation as building on a "footprint": the domain name, the email address, the links used, and the sending IP addresses, taken together. Over time those form a sender profile, and inbox providers assign that profile a reputation, which decides whether mail lands in the main inbox, promotions, or spam.
Change one ingredient and the footprint changes with it. The domain is explicitly named as part of that footprint, so a new sending domain is, by systeme.io's own description, a different footprint from the one an inbox provider had already learned to trust.
What systeme.io tells you to do about it
Its advice is not to change a domain that already has a good reputation. Where change is unavoidable for deliverability reasons, the article is direct: "a warming process should be done, and you should start sending emails gradually." That is the same shape of advice given to a brand new sender, applied to a domain that is new even though the account behind it is not.
Nothing in that advice says the warm-up has to start from an absolute zero the way a new account does. It says gradual, not that history counts for nothing.
What is not addressed
The reputation reset systeme.io documents in detail is written about switching to a different sending platform altogether, changing the IP addresses and header configuration behind every email at once. Moving your domain while staying on systeme.io the whole time is a narrower case, and no article covers it on its own terms.
Two things are documented separately that bear on it, without the text ever connecting them to each other.
- Authentication is domain-specific, not account-specific. A new domain needs its own DNS records verified again (three CNAME records and a DMARC record, per systeme.io's own domain-authentication walkthrough), regardless of how long the account has been sending or how good its existing reputation is.
- The pool system is evaluated on the account. systeme.io's IP pool placement runs on the account's own open, spam and bounce statistics, and the management of shared IP reputation is described as handled by systeme.io itself rather than by anything tied to one domain.
Whether swapping domains resets an account's existing pool placement, the way switching platforms resets reputation with each inbox provider, is not stated either way in what systeme.io publishes. The domain-level trust an inbox provider has built and the account-level pool systeme.io manages internally are two different systems, documented in two different articles, and nothing in either one connects them for this specific case.
What to actually do while it rebuilds
Absent a specific article for this exact move, systeme.io's general advice for any reputation rebuild applies: send to the most engaged contacts first, keep the volume gradual rather than jumping straight back to full sends, and expect open rates to move around, in either direction, until the new domain settles with each inbox provider.
Did this answer your question?
Keep reading
- SPF, DKIM and DMARC, in plain English Three DNS records, what each one proves, and exactly what systeme.io hands you to paste.
- Why do my emails land in the promotions tab? Gmail decides this, not systeme.io. What shifts the odds, and why the tab costs less than it looks.
- What is a bounce, and what should I do about one? Hard, soft, and what the grey and blue addresses in your statistics are telling you.