How do I warm up a new subdomain and domain after switching domains in Salesforce Marketing Cloud?
Updated on 25 Oct 2026: We refreshed the Salesforce warm-up guidance and added practical controls for campaign and journey volume.
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 use an older sender as a fallback only after its authentication and Salesforce configuration pass live tests.
Treat this as a reputation migration, not a pure DNS migration. A correctly configured Private Domain or Sender Authentication Package (SAP) in Marketing Cloud Engagement authenticates the mail, 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 subscribers who clicked or purchased recently and expect your mail.
- Do warm it: a new subdomain has little or no recipient history, even under a known parent domain.
- Do not panic over opens alone: automatic image loading and privacy protections distort open counts, so compare them with clicks and delivery data.
- Do measure business and complaint signals: falling revenue or clicks, rising complaints, and user reports of spam placement warrant investigation before the next volume increase.
- Do keep authentication: removing authentication rarely fixes inbox placement and creates new risk with bulk-sender requirements.
Start with engaged subscribers
Warm up the new sending subdomain by starting with your best subscribers, not by sending your normal calendar to the full file. 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 unauthenticated, repair and test its authentication before considering it for continuity sends.
Private Domain does not mean warm
In Marketing Cloud Engagement, a Private Domain supports SPF and DKIM when email authentication is enabled, but it does not include a dedicated IP. SAP adds account branding and Reply Mail Management; confirm whether your configuration uses a shared IP or a 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.
|
|
|
|---|---|---|
New root domain | No established domain history | Warm domain |
New subdomain | Visible sender | Required |
Existing shared IP | New domain pairing | Warm domain |
Existing dedicated IP | New sending domain, same IP | Warm domain; maintain steady IP volume |
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 when email authentication is enabled, but it does not brand wrapped links or images and does not include a dedicated IP. SAP adds account branding and Reply Mail Management, with sending IP configuration chosen during setup. 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. Confirm the IP choice and authentication status in Salesforce's domain configuration instructions before starting the ramp.
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.
Illustrated 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's 30-day warming example begins with 100 messages on day 1. This is an example, not a mandatory starting quota or completion deadline. For Marketing Cloud Engagement, size the opening cohort to your active audience and provider mix. Plan for several weeks, with more time for large audiences or recovery. 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
Selected daily volumes from Salesforce's 30-day example for Marketing Cloud Next. Each point is that day's volume, not a cumulative total or an automatic target for Marketing Cloud Engagement.
Daily send volume
- Days 1-3: send to recent clickers, purchasers, and reply-positive contacts only.
- Days 4-7: add other recently active, opted-in subscribers; do not qualify contacts on opens alone.
- Week 2: increase volume only where complaints, bounces, and spam-folder reports stay low.
- Week 3 onward: broaden only to subscribers with recent activity and valid permission; keep inactive contacts out of the ramp.
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. Review Google's sender requirements and Yahoo's sender requirements when setting these gates. Also aim for total bounces below 2%; investigate increases and suppress invalid addresses promptly. Reduce volume for a provider reporting repeated 4xx deferrals. A low complaint count at low volume is not proof of inbox placement.
Control warm-up volume in Salesforce Marketing Cloud Engagement
Build separate sendable data extensions for each mailbox-provider cohort and deduplicate by recipient address as well as Subscriber Key. Apply the existing suppression lists before selecting recipients. Your daily cap must include every campaign and journey using the new domain, across Business Units; an individual send limit is not a domain-wide budget.
- Prepare each daily cohort in Automation Studio, with approved provider counts and no accidental overlap between campaigns. Count email messages, not just unique contacts, against the daily budget.
- Enable Send Throttling in Setup > Email Studio > Email Optional Features, then set an hourly rate and delivery window for the relevant sends. Salesforce describes this rate as approximate, so limit the audience itself to enforce a small cohort.
- In each Journey Builder email activity, review Delivery Options. Set both a Delivery Window and an Hourly Threshold when controlling volume; a window alone does not limit hourly sends. Keep journey entry volume within the remaining domain budget.
- Check actual sends and provider responses before approving the next cohort. Account for queued messages that roll into later days; contacts queued in a journey email activity for more than 72 hours do not receive that message.
For example, a 400-message daily budget allows 250 campaign messages plus 150 journey messages, not 400 for each. Spread normal, expected content across the delivery window and avoid bursts. Passive domain aging does not create sending history; begin only after authentication, DNS, and consent checks pass.
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 on direct sends. DMARC passes when a passing SPF return-path domain or DKIM signing domain matches the visible From domain under its DMARC alignment mode. Relaxed mode accepts domains within the same organizational domain; strict mode requires an exact domain match. For Gmail and Yahoo bulk sending, the From domain must be covered by a valid DMARC policy of at least p=none. 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 introduced secure-by-default HTTPS for Marketing Cloud Engagement SAP and CloudPages domains on July 15, 2026. For affected branded web hostnames, replace legacy A or CNAME targets with the Salesforce-provided domain-specific endpoint (DSE), check certificate status, and ensure any restrictive CAA record permits the certificate authority in use. Follow Salesforce's DNS migration instructions; keep SPF, DKIM, and other mail records as specified in the Salesforce zone file.
Illustrative received-message authentication and unsubscribe headerstext
Authentication-Results: receiver.example; spf=pass smtp.mailfrom=email.example.com; dkim=pass header.d=email.example.com; dmarc=pass header.from=email.example.com From: Brand <news@email.example.com> Return-Path: <bounce@email.example.com> DKIM-Signature: d=email.example.com; s=<salesforce-selector>; ... List-Unsubscribe: <https://email.example.com/unsubscribe/recipient-token> List-Unsubscribe-Post: List-Unsubscribe=One-Click
- DMARC reports: use DMARC monitoring to see which Salesforce sources pass and which sources fail. Aggregate reports arrive after sending and do not reveal inbox or spam-folder placement.
- SPF record: use the exact Salesforce-provided value, publish only one SPF record per hostname, and keep evaluation within the 10 DNS-lookup term limit, including nested includes.
- DKIM selectors: verify that live campaign mail signs with the intended sending domain.
- Unsubscribe handling: verify both one-click unsubscribe headers and the body link, honor requests within two days, and apply the resulting suppression across campaigns and journeys.
- Blocklist checks: watch domain and IP listings with blocklist monitoring because a relevant blacklist listing can interrupt a ramp; investigate its scope alongside SMTP responses.
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.
A Salesforce "delivered" count means the receiving server accepted the message, not that it reached the inbox. The _Bounce data view records confirmed bounces, so retrying messages are not a complete real-time picture of deferrals. Use SMTP diagnostics and recipient-side checks alongside the data view. Salesforce's delivery troubleshooting FAQ explains these reporting limits.
Salesforce describes approximately 60 days of old SAP configuration retention, but confirm your actual support window before relying on it. 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. See Salesforce's SAP change considerations for the cutover dependencies.
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. Use only contacts with valid marketing consent and preserve existing unsubscribe, complaint, and invalid-address suppressions. A purchase alone does not establish marketing permission. Use confirmed opt-in for new acquisition where it fits the program. Keep unclear-permission contacts out of email sends; obtain permission through an appropriate existing customer channel before adding them.
|
|
|
|---|---|---|
Recent clickers | Yes | Clear intent |
Recent buyers | Yes | Recent activity; marketing consent still required |
Open-only users | Later | Noisy signal |
Inactive users | No | Complaint risk |
Unclear permission | No | Obtain valid consent before sending |
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.
Illustrative early warm-up audience mix
An example allocation, not a required ratio. All contacts need valid consent; open-only contacts require additional evidence of activity. Inactive contacts remain excluded in both phases.
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. An unauthenticated old route is unsuitable for fallback sends until its authentication is repaired and tested.
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.
Before a permanent rollback
- Main risk: verify authentication and Salesforce configuration before restoring any old sender.
- 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 domain and IP reputation affect warm-up
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.
Salesforce Marketing Cloud domain and IP reputation signals during subdomain warm-up.
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 DMARC reporting and email authentication platform supports this Salesforce Marketing Cloud workflow with source-level authentication results, issue alerts, and blocklist (blacklist) monitoring. Use it to identify authentication failures during the ramp alongside Salesforce delivery data.
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 reported authentication drops or blocklist listings during the ramp. DMARC reporting depends on receiver report delivery; it is not an immediate send-control or inbox-placement signal. For Salesforce-delegated DNS, submit supported record changes through Salesforce. For self-hosted DNS, Suped's Hosted SPF and SPF flattening can help with the SPF lookup limit; preserve the exact Salesforce authorization and confirm who controls the delegated hostname before changing records.
- 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 an authenticated fallback viable while the new subdomain builds sending history.
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 planning.
Reading a drop in opens as spam placement before checking inbox placement and revenue.
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 provider volume steady when that mailbox provider starts filtering more messages.
Marketer view
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 view
Marketer from Email Geeks says root domains and subdomains have related reputations, so neither identity is fully isolated.
2024-03-29 - Email Geeks
Recover after a failed domain warm-up
If a domain switch causes a deliverability drop, keep authentication enabled. Verify the exact sender configuration and distinguish DNS failures from provider filtering before increasing volume. Restart the ramp with recently active, opted-in subscribers.
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.
