Fix Pardot (Account Engagement) emails going to spam

Marketing Cloud Account Engagement, still labeled Pardot in much of the app, is a different product from Marketing Cloud Engagement and authenticates in a completely different way. It verifies your sending domain with a validation key that proves ownership and nothing more, treats DKIM as optional, and routes every bounce through a Salesforce host such as bounce.s7.exacttarget.com, so SPF does not align with your From address unless you request a custom return path. This guide covers the DomainKey record at 200608._domainkey, the tracker domain CNAME that rewrites every link in your email, the custom return path you have to open a case for, and how to test a real Account Engagement send with Unspam.

Run a free spam test How to test your sends

Why Marketing Cloud Account Engagement emails land in spam.

Account Engagement never required DKIM, so most accounts have no aligned identifier

Salesforce verifies a sending domain with a validation key TXT record, and that key alone is enough to send: the help documentation states that Account Engagement does not currently require a verified DKIM record on the email sending domain and only strongly encourages one. DKIM is the only identifier that aligns with your From address out of the box, because the return path stays on a Salesforce host unless you open a support case for a custom return path. Without the DomainKey TXT record published at 200608._domainkey.yourdomain.com, a DMARC evaluation has nothing aligned to pass on, and a p=quarantine or p=reject policy on your own domain then filters your own campaigns. Domain Management still shows the domain as verified either way, which is why so many verified domains are completely unauthenticated.

SPF passes for Salesforce, never for you

Salesforce documents that Account Engagement emails pass SPF automatically because Salesforce controls the sending infrastructure, and that no specific SPF configuration is necessary on your end. The receiving server checks the return path, which Salesforce documents as a host like bounce.s7.exacttarget.com, bounce.s10.mc.pd25.com or bounce.j.s11.pdmailservice.com, so the pass is recorded against a Salesforce domain and SPF alignment fails on every send. Adding a Salesforce include to your root SPF record changes nothing about that. The only way to align the return path is a custom return path, which Salesforce provisions through a support case and not through any screen in the product.

Every link in the email still points at pardot.com

Account Engagement rewrites links and vanity URLs through the tracker domain, and when no tracker domain is selected on an asset it falls back to the account's primary tracker domain. An account that never validated its own CNAME serves all of that on the default go.pardot.com domain, so a message carrying your brand in the From line carries links on a domain the recipient has no reason to trust. Salesforce recommends adding a custom domain and serving all Account Engagement content from it. Once you validate your own tracker domain and use Set as Primary, Account Engagement rewrites the URLs on your assets to it.

The sender hierarchy sends from domains you never configured

In Account Engagement the sender's email address decides which sending domain is used, so a campaign set to Assigned User, Account Owner or a CRM user field goes out from each rep's own address. At send time Salesforce walks the sender hierarchy from the top and uses the first address whose domain is verified, and if no sender in the hierarchy is valid the send fails outright. One campaign can therefore leave under several From domains, only some of which carry a DomainKey record, which splits your reputation and drops the unsigned portion into spam. Every domain your users send from needs its own entry in Domain Management with both records published.

You are judging deliverability from test proofs that are not real emails

Salesforce documents that the one-off Send to Individual Emails option does not produce a multipart MIME message: the HTML and plain text versions go out as two separate messages, and many email systems treat that as suspicious. The same article warns that repeated individual test sends can get the sender graylisted, naming Microsoft in particular, with deferrals lasting several hours, and states plainly that email test proofs should not be used as a measurement for deliverability. If your only evidence is a proof sent to your own work address, you are measuring an artifact of the test tool. A corporate address on both ends adds a second failure, because the filter classifies mail between two addresses on your domain as internal and then sees it arriving from an outside server.

You applied Marketing Cloud Engagement instructions to a Pardot account

Marketing Cloud Engagement and Marketing Cloud Account Engagement are separate products with separate authentication paths, and the names sit close enough together that teams follow the wrong runbook for months. There is no Sender Authentication Package, no Private Domain and no Reply Mail Management in Account Engagement. Authentication lives in Account Engagement Settings, then Domain Management: a validation key, a DomainKey record, and a tracker domain CNAME pointed at go.pardot.com. Buying SAP for a Marketing Cloud Engagement org does nothing for the mail your Account Engagement business unit sends, so confirm which product actually sent the message before you spend a quarter configuring the other one.

How Marketing Cloud Account Engagement authenticates your mail.

Account Engagement keeps four DNS facts apart that most teams treat as one. The validation key proves you own the domain and is the only record required to send. The DomainKey record is what actually signs your mail. SPF is Salesforce's to pass rather than yours. DMARC is yours alone, because Salesforce states that Account Engagement cannot supply DMARC authentication and that support cannot help configure it. Only two of the four come from the product: Account Engagement Settings, then Domain Management, then the Expected DNS Entries link next to the domain, which holds the validation key and the DomainKey. Salesforce supplies no SPF value and no DMARC value at all. Separately from all of this, the tracker domain is a CNAME to go.pardot.com and must never be the same domain as your email sending domain. Check each record with the Unspam SPF, DKIM and DMARC checkers before and after the change.

record	default	the problem	the fix
Validation key (TXT)	Nothing is published until you add the domain. Since July 1, 2023 a domain must be verified by a validation key before Account Engagement will send from it. Domains that had already been verified through DKIM under the older method kept their status without the new key.	A verified domain is not an authenticated one. The verified state in Domain Management means only that you proved ownership, and teams stop there believing authentication is finished. Keep the TXT record published, since it is the record Account Engagement checks the domain's ownership against.	In Account Engagement Settings, open Domain Management, click Add New Domain, then click Expected DNS Entries in the Actions column and copy the validation key. Publish it as a TXT record on that domain or a parent of it, then click Check DNS Entries to verify. Leave the record in place permanently.
DKIM (DomainKey)	Off until you publish it. Salesforce states that Account Engagement does not currently require a verified DKIM record to send from an email sending domain, and only strongly encourages one. The key Account Engagement issues is 1024-bit by default.	DKIM is the only identifier Account Engagement can align with your From domain, so without it a DMARC evaluation has nothing to pass on and Gmail and Yahoo bulk sender expectations go unmet. The failure is invisible inside the product, because Domain Management reports the domain as verified with or without a DomainKey.	In Domain Management, open Expected DNS Entries for the domain, copy the DomainKey value, and publish it as a TXT record at 200608._domainkey.yourdomain.com. On providers that append the zone to whatever you type, GoDaddy among them, enter only the host portion or the record propagates with your domain doubled. Allow up to 24 hours for signing to take effect, then confirm the d= value on a live send with the Unspam DKIM checker.
SPF	Configured by Salesforce rather than by you. The documentation says Account Engagement emails pass SPF automatically and that no specific SPF configuration is necessary on your end, and Domain Management reflects that pass.	The pass is recorded against the return path, which Salesforce documents as bounce.s7.exacttarget.com, bounce.s10.mc.pd25.com or bounce.j.s11.pdmailservice.com depending on the account. None of those is your domain, so SPF alignment fails on every Account Engagement send and DMARC cannot lean on it.	Keep your own SPF record valid for your other senders and confirm it with the Unspam SPF checker, but do not expect it to help Account Engagement. For alignment, open an Account Engagement support case and request a custom return path. Salesforce supplies the DNS records and leaves you to publish them, and there can be only one custom return path domain per business unit, with no variation per send.
DMARC	Absent unless you publish it. Salesforce is explicit that Account Engagement cannot supply DMARC authentication, that the configuration exists outside the product, and that support is unable to assist with setting it up.	With the DomainKey published, DMARC passes on DKIM alignment alone, which is what Salesforce means when it says DMARC works with Account Engagement out of the box. Without it, neither identifier aligns and a p=quarantine or p=reject policy on your own domain quarantines your own campaigns. Account Engagement also does not capture or report DMARC failures, so nothing in the app will tell you.	Publish v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com at _dmarc.yourdomain.com, confirm on a live send that DKIM aligns with your From domain, then tighten to quarantine and later reject once your reports read clean. Salesforce recommends partnering with an outside vendor for DMARC reporting because it captures none itself. Verify the published record with the Unspam DMARC checker.

Once you have updated these records, confirm they pass with Unspam's free SPF checker, DKIM checker, and DMARC checker.

How to test a Marketing Cloud Account Engagement campaign with Unspam.

Account Engagement has two built-in tests and neither one measures placement. The Testing tab in the classic builder runs Litmus rendering previews and a spam analysis, and Salesforce says the results do not guarantee whether an email ends up in the spam folder. The Lightning builder's test send strips merge field data and, if the logged-in user's domain is not verified, replaces your From address with test@ your first verified sending domain. Unspam does not connect to the Account Engagement API or to any other platform account, so the honest test is a real list email sent to a seed address on your normal sending domain and tracker domain.

01
Get your Unspam seed address and Test ID

Start a free spam test or an inbox placement test in Unspam and copy the seed address it generates. An inbox placement test delivers to seed mailboxes at Gmail, Outlook, Yahoo, Zoho, ProtonMail, AOL, GMX, and Amazon WorkMail so you see where each copy landed. It also issues a Test ID, and you must paste that ID into the subject line or the body before you send. Skip it and the message still reaches the seed mailboxes, but it is never matched to your test.
02
Add the seed as a prospect on a normal list

Do not reach for an Email Test List. Account Engagement builds those from your own users, creating a test prospect for each one, up to 100 recipients, so an outside seed address cannot go on one. Create the seed as a prospect instead and add it to a segmentation list named something like Deliverability Seed, so the message follows exactly the path a campaign follows.
03
Send it as a real list email, not a test proof

Send the actual email to that list from Account Engagement Email, using your production sender and the same tracker domain your campaigns use. Avoid the Send to Individual Emails option in the Testing tab: Salesforce documents that it splits the HTML and plain text into two separate messages rather than one multipart MIME message, and says email test proofs should not be used as a measurement for deliverability.
04
Check what actually left Account Engagement

In Unspam, confirm the DKIM d= value is your sending domain and not a Salesforce host, that the return path is what you expect (a bounce.s7.exacttarget.com style host unless you have a custom return path), and that every link resolves on your tracker domain rather than pardot.com. This is the first point in the workflow where you see the same headers a mailbox provider sees.
05
Read the results and fix before the next campaign

Review the spam score, the SPF, DKIM and DMARC verdicts measured on the live send, the blocklist and HTML checks, per-provider Inbox, Promotions, Spam or Missing placement, the client previews including dark mode, and the AI eye-tracking heatmap. Change one thing, send again, and you can attribute the difference instead of guessing.

The same test renders your campaign in 50+ real email clients, Gmail, Outlook, Apple Mail, iPhone, and Android among them, each in light and dark mode, via email client previews, so you confirm placement and rendering in one pass.

Marketing Cloud Account Engagement features that quietly affect delivery.

Verified is not authenticated

Domain Management marks a domain verified as soon as the validation key TXT record resolves, and that is the only record Account Engagement needs in order to send. DKIM sits on the same Expected DNS Entries screen and is merely recommended. Accounts run for years in that state, verified and never once signing a message with their own domain. Open Expected DNS Entries and look for the DomainKey line specifically rather than trusting the verified label.

Individual test sends are not multipart MIME

Salesforce documents that the Send to Individual Emails option delivers the HTML and plain text as two separate messages instead of one multipart MIME message, that many email systems treat this as suspicious, and that repeated use can lead to graylisting of the sender, with Microsoft named specifically and deferrals lasting hours. If your deliverability evidence came from that button, it is evidence about the button. Salesforce recommends test lists instead, and a real send to an outside seed beats both.

The tracker domain and the email sending domain must be different

Salesforce states that using the same domain for both features will likely result in authentication errors and deliverability trouble. If go.company.com is your tracker domain, it cannot also be your email sending domain. Tracker domains also have to be unique across business units, so a second business unit needs something like go2.company.com rather than a duplicate of the first.

The 2048-bit DKIM key story is inconsistent

Account Engagement issues a 1024-bit DomainKey by default. The DNS configuration guidance says you can open a support case to request a 2048-bit key and calls a dedicated sending IP highly recommended before you do. Salesforce then describes the result two different ways. One article says a 2048-bit key produces a Custom DKIM Entry warning in the Email Sending Domain table and that no further action is needed so long as your DNS entries stay in place. Another says customers using a 2048-bit key will not see their email sending domain DKIM verified in Account Engagement even though the record is present in DNS. Treat the in-app verified flag as unreliable at 2048-bit and confirm the signature on a live send instead.

What real Marketing Cloud Account Engagement senders run into.

The deliverability problems Marketing Cloud Account Engagement senders hit most often, each with the fix that resolves it.

Our test emails keep landing in junk but Salesforce support says there is nothing wrong with the account

If you tested with Send to Individual Emails from the Testing tab, Salesforce's own documentation says those proofs are not multipart MIME messages: the HTML and plain text go out as two separate messages, and many email systems treat that as suspicious. Using a corporate address on both ends stacks a second failure on top, because the filter classifies mail between two addresses on your domain as internal and then sees it arriving from a third-party server outside your network. Salesforce states outright that email test proofs should not be used as a measurement for deliverability.

The fix Stop testing with individual proofs. Have IT allowlist your Account Engagement sending IP, which you find in Account Engagement Settings under Account Information in the Sending IPs field, so internal tests stop tripping the internal-network rule. Then measure placement with a real list email to an outside seed address rather than to a colleague on your own domain, and read the headers on that send. Bear in mind that a run of individual proofs can get you graylisted, Microsoft especially, which makes the next real send look worse than it is.

The newsletter reaches the inbox but anything sent from a sales rep goes straight to spam

Campaigns set to Assigned User, Account Owner or a CRM user custom field take the From address from the user record, so the sending domain changes from prospect to prospect. Salesforce evaluates the sender hierarchy from the top at send time and uses the first address whose domain is verified, which means an unverified rep domain silently falls through to whatever comes next, and if nothing in the hierarchy is valid the send fails. Domains you never added in Domain Management have no DomainKey record, so those messages go out unsigned while your marketing domain is signed.

The fix List every domain your users send from and add each one in Account Engagement Settings, Domain Management, with both the validation key and the DomainKey record published. Where reps sit on a domain you cannot authenticate, set the last entry in the sender hierarchy to a General User or Specific User on a verified domain, and put the human touch in the reply-to address instead of the From. Then send from each domain to a seed address and confirm the DKIM d= value matches before you trust it.

I added the DomainKey a week ago and Account Engagement still will not show DKIM as verified

The DomainKey record has to live at 200608._domainkey.yourdomain.com, and DNS providers that append the zone to whatever you type turn that into a doubled hostname that resolves nowhere. Salesforce calls out GoDaddy by name for this behavior. Signing also does not begin the moment the record resolves: the documentation asks for up to 24 hours after the record is in place. And if someone requested a 2048-bit key, Salesforce warns that the domain will not show DKIM as verified in the app at all, even with a correct record in DNS.

The fix Query the record directly instead of trusting the app: look up 200608._domainkey.yourdomain.com and check you get back one TXT record matching the Expected DNS Entries value, with no doubled domain and no duplicate entry. If your provider appends the zone, enter only the host portion. Give signing a full 24 hours, then send to a seed address and read the d= value on the delivered message, which is the only check that reflects what mailbox providers see.

Our own IT team flagged the campaign as phishing because every link went to pardot.com

Account Engagement rewrites links and vanity URLs through the tracker domain, and when no tracker domain is chosen on the asset it uses the account's primary tracker domain. An account that never validated its own CNAME serves all of that from the default go.pardot.com domain, so the From line says your brand and every href says something else, which is exactly the shape a phishing filter is trained on. Salesforce recommends adding a custom domain and serving all Account Engagement content from it.

The fix Add a tracker domain in Domain Management, point the CNAME at go.pardot.com for production or go.demo.pardot.com for a sandbox, publish the validation key as a TXT record on your root domain or upload the pardot_XXXXXX.txt validation file to your web root, then validate it and choose Set as Primary. That rewrites the URLs on your Account Engagement assets to the new domain. Pick a subdomain that is not your email sending domain, since Salesforce warns that reusing one domain for both causes authentication errors, and confirm on a seed send that no pardot.com link survives.

A chunk of our list quietly stopped receiving emails and nobody unsubscribed

Account Engagement marks a prospect Undeliverable after a single hard bounce, or after five soft bounces, and suppresses them from every send after that. The trap is inside Salesforce's own definition of a hard bounce: some mail servers hard-bounce an address when the message is suspected as spam. So a stretch of broken authentication does not only push you to the spam folder, it converts filtered recipients into permanently suppressed prospects, and the list keeps shrinking long after the underlying problem is fixed.

The fix Fix the authentication first, then work backwards through the bounce records: Account Engagement lets you reset the hard bounce or soft bounce count on a prospect record once the cause is resolved. Line the bounce spike up against the dates you changed DNS or sender settings to separate a genuinely bad address from a filtered one. Going forward, keep bounce rates well below the 10% on a single mailing that Salesforce warns can damage your deliverability, hold complaints under the 0.3% Gmail enforces, and rebuild volume gradually if you have paused sending for more than a week.

Marketing Cloud Account Engagement deliverability, answered.

Is Marketing Cloud Account Engagement the same thing as Marketing Cloud Engagement?

No. They are separate products with separate authentication paths, which is the single most common reason a Pardot fix goes nowhere. Account Engagement is the product formerly called Pardot, and Salesforce still shows the old name in parts of the app. Its authentication lives in Account Engagement Settings, then Domain Management: a validation key, a DomainKey TXT record and a tracker domain CNAME to go.pardot.com. Marketing Cloud Engagement uses the Sender Authentication Package and Private Domain, neither of which exists here.

Do I need to add Salesforce to my SPF record for Account Engagement?

No. Salesforce documents that Account Engagement mail passes SPF automatically because Salesforce controls the sending infrastructure, and that no specific SPF configuration is necessary on your end. An include would not help either, because the check runs against the Salesforce return path rather than your From domain. Keep your own SPF record accurate for your other senders, and rely on DKIM for DMARC alignment.

Why does my Account Engagement mail look like it came from a Salesforce domain?

The return path on Account Engagement sends is a Salesforce host. Salesforce documents examples such as bounce.s7.exacttarget.com, bounce.s10.mc.pd25.com and bounce.j.s11.pdmailservice.com, and says that return path information cannot be removed. Gmail surfaces the mismatch as a via line. Publishing the DomainKey record makes DKIM sign as your own domain, which is what DMARC needs and what usually clears the via line, and a custom return path requested through support aligns the envelope itself.

How do I get SPF alignment on Account Engagement?

Open an Account Engagement support case and ask for a custom return path. Salesforce works with its deliverability team to give you DNS records to publish and does not configure your DNS for you. There can be only one custom return path domain per business unit and it is not variable per send. Salesforce is clear that this adds SPF domain alignment to strengthen an existing DMARC policy, not to replace DKIM, so publish the DomainKey first.

Does the spam analysis in the Testing tab tell me whether I will reach the inbox?

No, and Salesforce says so. The rendering tests and spam analysis in the classic builder's Testing tab are powered by Litmus, and Salesforce states that the results do not guarantee whether emails end up in the spam folder, because sender reputation is not something a content scan can see. The feature ships with the Advanced Email Analytics package, in Plus, Advanced and Premium editions and at extra cost on Growth, and each render is stored for 90 days. Use it for rendering and content, and measure placement with a real send.

Can Unspam connect to my Account Engagement account and test sends automatically?

No. Unspam does not integrate with the Account Engagement API or any other platform API, and it never connects to your account. The two integration points are a seed address you send to and, for automated tests, SMTP credentials you supply yourself. For Account Engagement that means adding the seed as a prospect and running a real list email, which is the only way to see the headers, the rewritten tracker domain links and the placement your prospects actually get.

Marketing Cloud Account Engagement platform details were verified against publicly available documentation in August 2026 and may have changed since. Marketing Cloud Account Engagement is a trademark of its respective owner. Unspam is not affiliated with or endorsed by Marketing Cloud Account Engagement.

Test your next Marketing Cloud Account Engagement campaign before your subscribers do.

Start a free spam test Inbox placement test