Deauthorize marketing vendor
How to remove Salesforce Email (Sales Cloud, Pardot, Marketing Cloud)from your domain's SPF and DKIM
Salesforce's email stack spans three products: Sales Cloud (the CRM), Pardot / Account Engagement (marketing automation), and Marketing Cloud (the rebranded ExactTarget bulk-mail platform). Each has its own SPF include + DKIM. Buying Salesforce often means three separate vendor authorizations on your DNS, not one.
When you'd want to do this
- Replaced Salesforce CRM entirely (HubSpot, Microsoft Dynamics, custom).
- Cancelled Pardot but kept Sales Cloud - need to remove Pardot-specific records only.
- Dropped Marketing Cloud after a budget review; kept transactional CRM email.
- Consolidating two Salesforce orgs after an acquisition.
What Salesforce Email (Sales Cloud, Pardot, Marketing Cloud) adds to your DNS
You need to remove every record below for the de-authorization to be complete. Removing only the SPF include: but leaving DKIM keys published is still a partial authorization - the vendor can sign mail as your domain even without SPF alignment if the recipient has a permissive DMARC policy.
| Type | Host | Look for |
|---|---|---|
| TXT | apex (example.com) | include:_spf.salesforce.com Sales Cloud SPF include. Authorizes Salesforce's transactional + agent-from-CRM sends. |
| TXT | apex | include:_spf.pardot.com Pardot / Account Engagement SPF include. Only present if you have Pardot. |
| TXT | apex | include:exacttarget.com or include:cust-spf.exacttarget.com Marketing Cloud SPF include. Lives under the exacttarget.com domain because of the legacy acquisition. |
| TXT | <selector>._domainkey.example.com | v=DKIM1; k=rsa; p=... Per-org DKIM. Selector names vary by Salesforce product and account vintage. Look for any DKIM TXT mentioning 'salesforce', 'pardot', or 'exacttarget' in the d= tag. |
| CNAME | pi.<custom>.example.com (Pardot tracker) | go.pardot.com or <org>.pardotemail.com Pardot tracker subdomain. Used for click + open tracking. Remove if dropping Pardot. |
| CNAME | em.example.com or e.example.com | mta-prod-<region>.exacttarget.com Marketing Cloud sending domain CNAME. Remove if dropping Marketing Cloud. |
Step-by-step
- Stop sending through Salesforce Email (Sales Cloud, Pardot, Marketing Cloud) first. Check every app, webhook, and automation that hits the vendor's API or SMTP. Pause those before touching DNS - if you flip the DNS first you'll just spend a week chasing bounces from a vendor that's still wired up on your application side.
- Remove the DKIM record(s) at the hosts listed above. Removing DKIM first means any mail still queued from Salesforce Email (Sales Cloud, Pardot, Marketing Cloud) fails alignment, which is the safer failure mode - the receiver quarantines or rejects rather than silently delivering signed-as-you mail from a vendor you no longer control.
- Remove the SPF include. Open your SPF TXT record at the apex. Look for the exact
include:entry shown above. Remove the entire token (including theinclude:prefix). Leave the rest of the record untouched. Verify the byte-count of the record is now under 450. - Remove the CNAMEs, if any. CNAMEs for tracking domains and return-paths are dead weight once the vendor is gone; some DNS UIs surface them as "orphan records" later if you forget.
- Wait for propagation. 1-4 hours for most providers. The old SPF entry stays cached at receivers for the TTL you published (often 5 min - 1 hour).
Verify it's gone
Run a vendor-consolidation report on your domain. Salesforce Email (Sales Cloud, Pardot, Marketing Cloud)should be gone from the vendor list. If it's still showing under SPF or DKIM, the DNS edit either didn't save or hasn't propagated yet - re-check in 30 minutes.
You can also do a manual spot-check with dig TXT example.com (replace with your domain). The output should no longer show the Salesforce Email (Sales Cloud, Pardot, Marketing Cloud) include.
What you'll lose
Each cloud has separate consequences:
- Sales Cloud SPF removed: agent emails sent from inside Salesforce (single-send, list email) fail authentication. Workflow rule emails fail too.
- Pardot: nurture programs, list emails, autoresponders all break.
- Marketing Cloud: journey-builder sends, triggered sends, transactional sends via the SOAP / REST APIs all break.
Common gotchas
Three clouds, three migrations.Don't assume removing one Salesforce SPF include is sufficient. Customers running Sales Cloud + Pardot + Marketing Cloud need to remove three separate authorizations (and possibly two or three sets of DKIM CNAMEs / TXT records).
Marketing Cloud sender authentication package (SAP). If you bought SAP, Marketing Cloud provisioned a vanity domain (e.g. cloud.example.com or a fully separate subdomain) with its own A and MX records. That subdomain often has 4-6 records to remove, not just one.
SF org migration sequencing.If you're migrating between Salesforce orgs (e.g. acquired company move), publish the new org's DNS records FIRST, wait for propagation, validate the new sender authentication in the new org's console, then remove the old org's records. Doing it in the other order causes a week of agent-mail bouncing.
Just want to rotate keys instead?
If you're keeping Salesforce Email (Sales Cloud, Pardot, Marketing Cloud) but want to rotate credentials (a stronger move than just changing the API key - it forces all old DKIM signatures invalid), do it from the vendor side first: Salesforce Email (Sales Cloud, Pardot, Marketing Cloud) console →
While you're here: audit the rest
The median domain we've analyzed has 6 vendors authorized in DNS and 3 of them can send mail as you. If you just removed one, see who else is on the list.
Run a vendor-consolidation report →