Marketing Cloud Next handles SPF and DKIM; DMARC is yours to publish
An authenticated domain gives Marketing Cloud Next SPF and DKIM. DMARC is a record you publish yourself, and most orgs we scan have none. Here is the sequence.
Salesforce's deliverability guidance for Marketing Cloud Next is explicit on the split: once a domain is authenticated, Marketing Cloud Next takes care of SPF and DKIM, and every send passes SPF because an activated authenticated domain is required to send at all. DMARC is different. Salesforce provides a suggested record, but it "must be configured separately", by you, in your DNS. Nothing in Setup publishes it for you.
- Product
- Marketing Cloud Next
- Edition
- edition not stated in the source
- Topic
- Deliverability
- Last verified
Who this applies to
- Every Marketing Cloud Next org that sends email from its own domain
- Teams that completed domain authentication and assumed the job was done
- Edition: not stated; the guidance is the same for Growth and Advanced
Why it matters
Gmail, Yahoo and Microsoft now expect DMARC from bulk senders. Without it marketing mail is rate-limited or junked at exactly the providers your customers use, and anyone can send mail that looks like you. In the orgs we have scanned this year the pattern is consistent: authenticated domains done, DKIM keys active, and no DMARC record for the sending domain or its parent. It is the cheapest deliverability fix there is, and it sits with whoever owns DNS rather than with the marketing team, which is why it does not get done.
Try it
- List the domains you send from: every authenticated domain in Marketing Cloud Next Setup and every from address, including the parent domain if you send from a subdomain.
- Look up _dmarc.
as a TXT record for each. No record, or a record without v=DMARC1, is the finding. - Publish v=DMARC1; p=none; rua=mailto: on each domain. Marketing Cloud Next Setup > Domains shows the suggested record; p=none changes nothing about delivery yet, it only starts the reports.
- After two to four weeks, read the aggregate reports. Add any legitimate third-party senders you find to SPF and DKIM before you tighten the policy.
- Move to p=quarantine, then p=reject. Re-check the record after each change; a typo in a DMARC record is itself a deliverability incident.
Example use case
A company sending from three regional from addresses had DKIM active on all three domains and DMARC on none. The DNS owner published p=none with a shared reports mailbox in an afternoon; the reports showed a payroll system sending unauthenticated mail from one domain, which was added to SPF before the policy moved to quarantine a month later.
Prerequisites, limitations and risks
- Domain authentication completed in Marketing Cloud Next Setup for every sending domain
- Access to the DNS for those domains, or the person who has it
- A mailbox for DMARC aggregate reports that someone will actually open
Documented behaviour above comes from the sources listed below. Availability varies by edition, SKU and region - confirm entitlements in your own org before you rely on a feature.
Sources
- Addressing Email Deliverability Issues with Marketing Cloud Next (Salesforce Help)
- Authenticating Marketing Cloud Next Emails (Salesforce Help)
- Domain Settings in Marketing Cloud Next (Salesforce Help)
Stuck on this in your own org?
Blueport is a Sydney-based Certified Salesforce Consulting Partner with 100+ implementations since 2018. If a step above does not match what you see in Marketing Cloud Next, tell us - it is either an edition difference or a change worth knowing about, and we will find out which.
Talk to our team