How do I warm up a new subdomain and domain after switching domains in Salesforce Marketing Cloud?
Updated on 23 Aug 2026: We updated this guidance with Salesforce's current domain-warming, SAP cutover, DSE, PTR, and recovery requirements.
Yes, you need to warm up a new Salesforce Marketing Cloud sending subdomain after switching domains. This applies whether the IP stays the same or changes, and it also applies to Marketing Cloud Next shared-IP sending. Verify authentication first, send only to your most engaged recipients, increase volume in controlled steps, watch complaints and inbox placement by mailbox provider, and avoid using the old unauthenticated domain as a long-term escape route.
Treat this as a reputation migration, not a pure DNS migration. A Private Domain or Sender Authentication Package in Marketing Cloud Engagement makes the mail authenticated, but mailbox providers still need to learn that recipients want mail using the new visible sending identity. If the audience also includes old, imported, or newly merged contacts, audit permission and list age before increasing volume. If you skipped warm-up, pull volume back, stabilize the high-priority sends, then rebuild the new domain's sending history with the people most likely to open, click, reply, move messages out of spam, or avoid complaints.
- Do warm it: a new subdomain has little or no recipient history, even under a known parent domain.
- Do not panic over opens alone: after a domain or authentication change, image prefetching changes can make opens look worse than inbox placement.
- Do measure business and complaint signals: lower revenue or clicks, higher complaints, and user reports of spam placement mean the warm-up needs a reset.
- Do keep authentication: removing authentication rarely fixes inbox placement and creates new risk with bulk-sender requirements.
The direct answer
Warm up the new sending subdomain by starting with your best subscribers, not by sending your normal calendar to the full file. Salesforce recommends no more than a few hundred messages per day at the start for a brand-new Marketing Cloud Next domain or subdomain. Marketing Cloud Engagement has no universal starting number, so size the opening cohort around recent clickers, purchasers, reply-positive contacts, and other people with activity in the last 30 to 60 days. Then ramp by mailbox provider because Gmail, Microsoft, Yahoo, and corporate domains do not all react at the same pace.
If your new authenticated domain has already been hit by poor early performance, pause or reduce broad campaigns until provider-level metrics stabilize. Send only essential mail through the safest available authenticated path. If the old route is genuinely unauthenticated, do not move major campaigns back there as a strategy. Use it only as a planned continuity path if the business accepts the risk, then rebuild the new subdomain properly.
Private Domain does not mean warm
In Marketing Cloud Engagement, a Private Domain adds authentication but does not include a dedicated IP. An SAP includes a Private Domain and dedicated IP. Marketing Cloud Next begins on shared IPs and can assign dedicated IPs based on volume. In every case, a new domain still needs wanted-mail history, and a new dedicated IP needs its own IP warm-up.
|
|
|
|---|---|---|
Root domain | Brand history | Monitor |
New subdomain | Visible sender | Required |
Existing shared IP | New domain pairing | Warm domain |
New dedicated IP | No sending history | Warm IP and domain |
A compact view of what needs warm-up after a Salesforce Marketing Cloud domain switch.
What changed when you moved to a Private Domain
A Marketing Cloud Engagement Private Domain applies SPF and DKIM authentication to an approved sending domain, but it does not brand wrapped links or images and does not include a dedicated IP. An SAP includes the Private Domain, a dedicated IP, account branding, and Reply Mail Management. Salesforce's delegation guide explains the DNS delegation model. Mailbox providers still see a new authenticated sending identity after either change, so they recalculate reputation using fresh recipient behavior.
Before the switch
- Old identity: mailbox providers had prior engagement history for the previous sending route.
- Known cadence: your send frequency and complaint pattern had a longer data trail.
- Authentication gap: if the old route lacked proper authentication, it carried policy and spoofing risk.
After the switch
- New identity: the subdomain needs engagement history under the new authenticated setup.
- New pairing: the domain and sending IP need a stable record together.
- Verifiable mail: DMARC alignment plus SPF or DKIM lets receivers verify the authorized identity.
Salesforce Marketing Cloud Engagement authenticated sending domain setup.
Use a branded subdomain, not a lookalike domain
Use a subdomain of the primary brand domain when you can, such as email.example.com or em.example.com. Avoid cousin or lookalike domains such as example-email.com because they train customers to accept mail from a domain that resembles the brand but is not the brand. Do not use sfmc, exacttarget, or Salesforce branding in the sending domain, since recipients should recognize your brand.
A Marketing Cloud Engagement Private Domain change requires a new Private Domain purchase, and an SAP domain change requires a new SAP SKU plus reconfiguration. Pick a durable subdomain before warm-up starts, then keep the visible From domain, reply handling, tracking domain, and authentication setup consistent.
A separate root domain can look like a shortcut when the main domain is hard to access, but it adds brand-recognition and trust work. Press for a clean branded subdomain first, then warm it with controlled volume.
A practical warm-up plan for Salesforce Marketing Cloud domains
For Marketing Cloud Next, Salesforce says a brand-new domain or subdomain should start with no more than a few hundred messages per day. For Marketing Cloud Engagement, use the same slow approach but size the opening cohort to your active audience and provider mix. Ramp more slowly if you already saw spam placement or a sharp revenue drop. Do not use a fixed calendar if complaints, bounces, or inbox placement tell you to hold.
Example warm-up volume path
Illustrative daily volume for a new Salesforce Marketing Cloud subdomain when early metrics stay healthy, not a universal quota.
Daily send volume
- Days 1-3: send to recent clickers, purchasers, and reply-positive contacts only.
- Days 4-7: add recent openers and suppress anyone with weak or stale behavior.
- Week 2: increase volume only where complaints, bounces, and spam-folder reports stay low.
- Week 3 onward: bring back broader segments gradually, with separate rules for inactive contacts.
Use mailbox-provider gates
If Gmail is healthy but Microsoft is filtering, do not raise Microsoft volume because the total average looks fine. Aim to keep Gmail's reported spam rate below 0.1% and never let it reach 0.3% or higher. Yahoo requires bulk senders to stay below 0.3%. Hold a provider's volume when complaints rise, even if the blended average remains low.
Check the technical setup before sending volume
Before ramping, confirm the DNS and message headers. Start with a domain health check to catch obvious setup errors, then send a real email test from the exact sender profile. The live message matters because a DNS record can look fine while the campaign uses a different From domain, return path, DKIM selector, tracking setup, or unsubscribe header.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Confirm that SPF and DKIM pass, and that the visible From domain aligns with at least one of them so DMARC passes. The From domain must be covered by a valid DMARC policy with at least p=none for bulk sending. Also verify forward and reverse DNS for the sending IP, TLS in transit, one-click unsubscribe for marketing mail, and a visible unsubscribe link in the message body.
Salesforce now uses secure-by-default HTTPS for Marketing Cloud Engagement SAP and CloudPages domains. Confirm that each affected domain points to its Salesforce-provided domain-specific endpoint (DSE), that certificate status is healthy, and that any required CAA record permits certificate issuance before cutover.
Received-message checks after a test sendtext
Authentication-Results: spf=pass; dkim=pass; dmarc=pass From: Brand <news@email.example.com> Return-Path: <bounce@email.example.com> DKIM-Signature: d=email.example.com; s=<salesforce-selector>; ...
- DMARC reports: use DMARC monitoring to see which Salesforce sources pass and which sources fail.
- SPF record: use the exact Salesforce-provided value and keep self-hosted records below the DNS lookup limit.
- DKIM selectors: verify that live campaign mail signs with the intended sending domain.
- Unsubscribe handling: keep list-unsubscribe, one-click unsubscribe, and the body link working before broad marketing sends.
- Blocklist checks: watch domain and IP listings with blocklist monitoring because a blacklist event can stop a healthy ramp.
Protect the cutover before retiring the old SAP domain
A Marketing Cloud Engagement SAP domain change is a reconfiguration, not a simple rename. Inventory every Business Unit, Delivery Profile, assigned sending IP, Private Domain, and old SAP dependency before the switch. One SAP domain can be configured per Business Unit, so do not assume that the old and new SAP domains can run in parallel.
- PTR and FCrDNS: reverse-resolve every assigned IP. If its PTR hostname uses the old SAP domain, ask Salesforce to update it before that domain stops resolving.
- Old DNS: keep old NS delegation or self-hosted records active while earlier emails still depend on images, tracked links, unsubscribe handling, or Reply Mail Management.
- Live header tests: test the new SAP sender, any Private Domain in the Business Unit, and each IP that previously used the old SAP domain in PTR.
- Bounce diagnostics: query the _Bounce data view in Automation Studio and inspect SMTPBounceReason for FCrDNS, DKIM fail, SPF fail, Block, or Reject responses.
Salesforce typically retains the old SAP configuration for about 60 days, but removing customer-controlled NS delegation or DNS records ends resolution as soon as that change propagates. The result can be broken images, tracking links, unsubscribe paths, and reply handling in messages already delivered. Set the retirement date from the useful life of old messages and confirm PTR changes before deleting anything.
Plan rollback before cutover
A rollback works only if the required Salesforce configuration, DNS, certificates, sender profiles, and old-domain dependencies are still viable. Record the exact restore steps and success checks before changing the SAP domain.
How to segment the first sends
The first warm-up sends are not the place to rescue inactive users. Early mail should generate wanted-mail signals. That means recent clicks, replies, purchases, form submissions, account logins, and positive site behavior. If a user has not engaged in a long time, keep them out until the new subdomain has stronger history.
Check permission source and list age before early volume leaves Salesforce Marketing Cloud. Contacts imported during a rebrand or CRM cleanup should not enter the first ramp just because they exist in a data extension. Prefer contacts with clear consent, and use confirmed opt-in for new acquisition where it fits the program. Put older or unclear contacts into a repermission path, then suppress contacts who do not respond.
|
|
|
|---|---|---|
Recent clickers | Yes | Clear intent |
Recent buyers | Yes | High trust |
Open-only users | Later | Noisy signal |
Inactive users | No | Complaint risk |
Unclear permission | No | Repermission first |
Warm-up segments ranked by risk.
The usual mistake is to ramp the total file evenly. Use a provider-based split. For example, Gmail recipients who clicked in the last 30 days get a separate cap from Microsoft recipients who clicked in the last 30 days. If one provider starts filtering, hold that provider without stopping every other send.
Suggested early warm-up mix
A practical split for the first phase, weighted toward people who have acted recently.
Recent clicks
Recent purchases
Recent opens
Inactive
Should you switch back to the old domain
Switching back is viable only when the old authenticated configuration remains active and rollback was planned before cutover. Marketing Cloud Engagement allows one SAP domain per Business Unit, so old and new SAP domains cannot be assumed to run in parallel. If the old route is unauthenticated, it is a weak stop-gap even when its earlier reputation gives a short-term lift.
Temporary fallback
- Best case: use an older authenticated sender whose Salesforce configuration and DNS still work.
- End condition: retire the fallback when the new route meets its provider-level success gates.
- Volume rule: send only messages that cannot wait while the new route stabilizes.
Permanent rollback
- Main risk: unauthenticated mail has weaker protection and poorer policy fit.
- Reputation risk: bad engagement on either identity can affect the parent domain.
- Better path: repair the new authenticated subdomain with a controlled ramp.
If you need a deeper migration checklist, the domain change plan is useful for sequencing DNS, audience, content, and monitoring decisions.
How reputation passes between domain, subdomain, and IP
The root domain and subdomain have partly separate reputations, but they are not sealed off. A new subdomain can develop its own history, while the parent domain can still influence how receivers judge it. Bad performance on a subdomain can also weaken the broader brand identity over time.
Flowchart of SFMC domain, subdomain, shared IP, and inbox reputation signals.
Shared IPs do not remove this need. The IP already has shared history, but your domain on that IP is still a new pairing. That is why a Private Domain on a shared Salesforce Marketing Cloud IP can still filter worse for a while. For a closer look at this issue, see shared IP checks and the related subdomain impact guide.
How Suped fits into the workflow
Suped's product fits this Salesforce Marketing Cloud workflow because the work extends beyond DNS checking. It connects DMARC visibility, SPF and DKIM validation, issue detection, real-time alerts, blocklist (blacklist) monitoring, and clear steps to fix problems while volume is moving.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
In Suped, use the domain dashboard to confirm which Salesforce sources authenticate, the issues view to catch failing records, and alerts to flag sudden authentication drops or blocklist listings during the ramp. For Salesforce-delegated DNS, submit supported record changes through Salesforce. For self-hosted DNS, Suped's Hosted SPF and SPF flattening can help when the authorized senders exceed the SPF lookup limit.
- Before launch: verify DMARC, SPF, DKIM, DSE, certificate status, and reporting for the exact sending domain.
- During warm-up: watch authentication pass rates, new sources, volume changes, and blocklist listings.
- After stabilization: move DMARC policy forward carefully and keep alerts on for future Salesforce changes.
Views from the trenches
Best practices
Start with the most engaged recipients so early mailbox signals come from wanted mail.
Keep the old route stable while the new subdomain earns predictable engagement data.
Track inbox placement, complaints, bounces, and revenue before changing the ramp pace.
Common pitfalls
Assuming a private domain on a shared IP removes the need for domain warm-up steps.
Reading a drop in opens as spam placement before checking inbox and revenue data.
Ramping the full list at once instead of splitting volume by each mailbox provider.
Expert tips
Ask Salesforce support to verify PTR records before any old SAP domain stops resolving.
Query SMTP bounce reasons after cutover to separate DNS failures from reputation blocks.
Hold volume steady when one mailbox provider starts filtering more than the rest.
Marketer from Email Geeks says a new private domain still needs warm-up because authentication does not create reputation by itself.
2024-03-29 - Email Geeks
Marketer from Email Geeks says root domains and subdomains have related reputations, so neither identity is fully isolated.
2024-03-29 - Email Geeks
What to do next
Do not solve a Salesforce Marketing Cloud domain deliverability drop by removing authentication. Confirm the product and IP configuration, verify DSE and PTR records, reduce broad volume, send the new subdomain only to high-confidence recipients, and ramp by provider while watching complaint rate, bounce reasons, inbox placement, revenue, and DMARC results.
If the new subdomain already has poor early signals, keep it in recovery until provider-level results stabilize. Keep the list tight, use familiar content, avoid risky reactivation sends, and do not increase volume after a bad day. Broaden the audience only after the subdomain meets its gates, and keep DMARC reporting active so later Salesforce changes do not go unnoticed.
