When you move marketing email sending to HubSpot, you add its records — two DKIM CNAMEs, plus SPF and DMARC TXT records — alongside your existing setup; you do not immediately delete the old tool's records. Keep the previous sender's DNS entries until that tool has sent its last campaign and you've monitored deliverability from HubSpot for a few weeks, because those records are what authenticate mail the old platform still sends (and what receiving servers expect for anything in flight or on a schedule). The one record type that needs active merging rather than stacking is SPF: a domain may publish only one SPF TXT record, so you combine HubSpot's include mechanism with your existing one instead of adding a second record.
Connecting an email sending domain in HubSpot creates three authentication layers, each with its own record type:
HubSpot's domain connection wizard generates the exact values and verifies them once they're live. Two setup notes worth knowing: the sending domain shouldn't be one you're already using for another purpose like hosting your website, and CNAME flattening or proxy features at your DNS provider should be turned off for these records or verification can fail. A sending domain can also be connected to more than one HubSpot account at once, which matters for multi-brand organizations.
Nothing, at first — and that's correct. Each record type behaves differently during the overlap:
| Record type | Add for HubSpot | Old tool's record | When to remove the old one |
|---|---|---|---|
| DKIM (CNAME/TXT per selector) | Two new CNAMEs with HubSpot's selectors | Keep — selectors are unique per platform, so DKIM records coexist harmlessly | After the old tool sends its final campaign |
| SPF (TXT) | Merge HubSpot's include into your existing SPF record | Keep the old include in the merged record | After cutover, remove the old mechanism from the single merged record |
| DMARC (TXT) | One policy record for the domain (add only if none exists) | Shared — DMARC is policy, not routing, so there's one per domain | Never "removed" per tool; review the policy once migration settles |
The SPF rule deserves emphasis: a domain may publish only one SPF record, with the version tag and the all-mechanism (like -all or ~all) appearing exactly once. Two parallel SPF TXT records invalidate both. The correct move is to edit the existing record to include both senders during the overlap, then remove the old sender's mechanism after the migration.
Removal is safe when three things are true:
Only then do you delete the old DKIM selectors and strip the old include from SPF. Doing this early breaks authentication for any straggler sends; doing it late costs nothing but a tidy DNS zone.
For the broader deliverability context around authentication, list hygiene, and sender reputation, see our email deliverability best practices guide.
Vantage Point runs HubSpot marketing migrations end to end, and email cutover is the step where do-it-yourself projects most often stumble — a missed SPF merge or an early DNS deletion can take weeks of sender reputation with it. Our team plans the record changes, coordinates with your DNS and IT owners, sequences the warm-up, and verifies authentication before and after the switch. Senior consultants only — no junior handoffs; the experts you meet are the experts who deliver.
If email migration is one piece of a larger platform move, our HubSpot implementation practice handles the full cutover — sending domains, lists, templates, and consent — as one managed sequence.
We'll review your current DNS and sending stack, map the exact record changes, and sequence the cutover so nothing lands in spam.
Not immediately. Keep the old DKIM selectors and SPF mechanism until the old platform has sent its last campaign — including automated and transactional mail — and HubSpot has run cleanly for a few weeks. Removing records early breaks authentication for anything still sending through the old tool.
No. A domain may publish only one SPF TXT record, with the version tag and the all-mechanism appearing exactly once; two parallel SPF records invalidate both. During the overlap, edit your existing record to include both senders, then remove the old mechanism after cutover.
No. DKIM records are keyed by selector, and each platform uses its own selectors, so HubSpot's two CNAMEs coexist with your old tool's DKIM records without interference. Each platform signs with its own selector, and receivers look up whichever the message references.
DMARC is a domain-level policy, not a per-tool route, so there's only ever one DMARC record. If you don't have one, the migration is a good time to add it; if you do, keep it and use its aggregate reports during the overlap to confirm exactly which sources are sending as your domain and whether they're passing.
Long enough for the old platform to finish all scheduled and automated sends and for HubSpot to complete a proper warm-up — typically a few weeks of normal volume. The trigger for cleanup is evidence (verified HubSpot authentication, quiet DMARC reports for the old source), not a date on the calendar.
Any mail still sent by the old platform — a forgotten re-engagement series, a webinar tool, an event-triggered autoresponder — suddenly fails DKIM and SPF alignment. Depending on your DMARC policy, that mail gets quarantined or rejected outright, and the failure can spill over into broader sender-reputation damage at the worst possible time: right as the new platform is establishing itself.