Salesforce Marketing Cloud SPF, DKIM and DMARC setup, step by step

Authenticate a Marketing Cloud Engagement sending domain through a Sender Authentication Package (SAP) or an email-authentication-enabled Private Domain. Use the DNS records issued for that domain and environment, wait for the sending domain to become Active, and verify a delivered message from each intended business unit. Adding an address in From Address Management alone does not authenticate it. A passing, aligned branded DKIM signature is the key acceptance check, alongside SPF and DMARC results. Salesforce domain configuration, authentication versus address verification

This guide is based on current public documentation. No tenant configuration, customer DNS, received message or live sending test was inspected.

Confirm the product, environment and authentication package

This guide covers Marketing Cloud Engagement, including its authenticated domain products. It does not apply Salesforce CRM's DKIM Keys workflow, Account Engagement settings or Marketing Cloud Next's domain configuration to Engagement. A shared vendor name does not make those procedures interchangeable.

Before choosing DNS records, record the Enterprise ID, business unit Member ID (MID), tenant environment, approved From domains and sending workflows. Include campaigns, journeys and any distinct triggered or transactional route. Check actual entitlements rather than assuming a feature is available because another business unit uses it.

Private Domain is a paid authentication product, does not include a dedicated IP and does not provide account link/image branding. It can be used across business units once present there as an authenticated domain. Private Domain FAQ

Salesforce requires SAP when sending more than 250,000 email messages per month; Private Domain alone is not a substitute for that volume requirement. Its SAP documentation lists one included SAP license for Pro and Corporate editions and five for Enterprise, while actual available entitlements must be checked in the account. SAP supports one branded domain per business unit; multiple Private Domains can supply different From addresses. Salesforce directs Hyperforce SAP setup through the account executive, so do not assume the Salesforce-hosted self-service sequence applies unchanged. SAP scope and edition considerations

Review sustained volume, current IP configuration and warm-up needs with the account owner. The self-service workflow offers shared IPs for planned volumes below 100,000 messages per month, but says not to select that option for a new sending domain on a tenant previously configured with a dedicated IP. Private Domain does not require a new dedicated IP; do not confuse that product characteristic with permission to change an established IP arrangement. IP selection restrictions

Missing SAP, Private Domain or SSL entitlements can disable configuration choices. Resolve those with the account owner rather than buying an unnecessary product merely to remove a sender-display label. Licenses and configuration limits

Choose a safe DNS boundary before generating records

Choose an unused sending subdomain where possible. Salesforce warns against using the corporate apex for SAP because record conflicts can interrupt websites and inbound mail. For a domain already used by other services, its current guidance requires self-hosted DNS rather than delegation; its recommended architecture separates a SAP subdomain from a root-domain Private Domain. SAP and Private Domain DNS FAQ

Inventory every existing record at and below the proposed domain. Save the current zone, TTLs, mail routing, DKIM selectors and DMARC policies. A DNS review must distinguish records for outbound authentication from website hosting, inbound employee mail, bounce handling, replies and tracking.

• Self-hosted DNS: your team publishes the issued records in the correct authoritative zone and maintains them.
• Delegated DNS: your team delegates the specific approved domain or child zone; Salesforce manages the records below that boundary.

For email.example.com, delegation belongs at email in the parent example.com zone. Do not change the parent domain's registrar nameservers when the intended change is only a child-zone delegation. Parent-zone copies of TXT records below a delegated child do not replace authoritative child records. Salesforce subdomain delegation

Configure the domain and obtain its issued DNS records

For a supported Salesforce-hosted self-service setup, the documented sequence is:

1. Open Setup, search for ssl, and choose Domain SSL Certificates.
2. Select New Domain; enter the domain and an address for configuration/certificate notifications.
3. Choose authentication with URL branding or authentication only, according to the entitlement and required outcome.
4. Select the approved IP arrangement and, when available and required, Reply Mail Management options.
5. Choose the DNS management model, review the configuration and submit.
6. For self-hosting, use Download Zone File from the sending domain's action menu. For delegation, follow the issued environment-specific nameserver instructions.

This is a configuration procedure, not permission to accept a new paid entitlement or replace a live domain. Consult Salesforce for Hyperforce setup or an existing domain change rather than forcing an unavailable menu option. Current configuration workflow

The DNS file is specific to the account, selected domain and environment. Use its public record owners, types and values. Do not generate an unrelated DKIM key, copy another tenant's key, or assume the core CRM include:_spf.salesforce.com instruction applies here.

Salesforce's non-Hyperforce sample describes DKIM TXT records, SPF at the sending/bounce/reply owners, MX for bounce/reply functions, and CNAMEs for branded resources. It explicitly excludes Hyperforce, for which unique records are supplied during setup. The sample explains record roles; it is not your production zone file. DNS record maintenance

Publish exact owners without overwriting other services

Build a record-by-record plan from the issued file. In these examples, email.example.com is a fictional approved sending subdomain:

Here, @ means the current zone's apex, not automatically the corporate apex. Inspect the DNS editor's automatic suffix behavior before entering a full name. ISSUED-SELECTOR is a placeholder, not a Salesforce selector. Preserve the complete public key if the supplied type is TXT; adjacent character strings can form one TXT record. Never publish a private key.

For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.

A CNAME target is a hostname, not a URL. Do not put ordinary TXT, MX or other conflicting records at the same CNAME owner. If a required owner already serves another application, stop and resolve the design with the DNS and service owners.

For an issued authentication or ownership-verification CNAME, preserve the alias response. On Cloudflare, use DNS only, turn off record-specific Flatten, and check that zone-wide flatten-all does not mask the alias. Coordinate changes to shared zone settings with the DNS owner; other applications may depend on them. Confirm the alias in the authoritative zone instead of removing an intentional child delegation. Cloudflare CNAME verification safeguards

Keep the required literal CNAME answer: turn relevant per-record Flatten off where available and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting; flatten-all cannot be overridden per record. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration without breaking other services or removing NS delegation. These are DNS-host behaviors, not controls assumed in the sending provider. Cloudflare flattening controls and limits.

That rule is not a blanket instruction to disable proxies on branded web resources. Salesforce supports a separate self-hosted branded-domain proxy/WAF configuration using the Domain Specific Endpoint (DSE), with its own routing and certificate requirements. Follow that workflow for those web domains. Salesforce branded-domain proxy configuration

Do not bulk-import a zone file over an established corporate zone. Salesforce's current FAQ specifically warns that replacing existing A or MX records can break websites or mailbox reception; even adding a backup Salesforce MX can misroute mail when the primary mail service is unavailable. Resolve such conflicts with the DNS administrator and Salesforce before proceeding. Existing-service conflict guidance

Before publication or activation, the routing owner must separately approve the complete proposed record set: full owners, MX numeric priorities and target hostnames, and any issued A/AAAA destination addresses. Receiving a provider packet is not approval of its routing consequences. Reconcile it with the authorized design, preserve corporate mailbox and website routing, and compare the complete approved set at authoritative and recursive DNS. Stop on unapproved destinations, extra conflicting records or mismatched priorities; do not accept one matching target as proof of the whole set.

For delegation, use the provided environment's NS set. Salesforce documents different nameservers for Salesforce-hosted and Hyperforce tenants. Do not substitute a familiar exacttarget.com set for an issued ums-dns-salesforce.com set. Environment-specific delegation

Before publishing or activating the delegation, the DNS owner must separately approve the exact full child owner and complete environment-issued NS target set. Compare the complete approved set at the parent authority and recursive DNS, and confirm each child authority serves the intended zone. An issued set is not permission to move another service; stop on a mismatch and preserve unrelated delegations.

Understand SPF, the bounce domain and multi-bounce

SPF evaluates the SMTP envelope MAIL FROM identity. It does not simply check the domain visible in From, and a parent SPF policy does not automatically cover a child envelope domain. Use the issued SPF configuration at each required owner, preserving other authorized senders if that owner is genuinely shared. Keep one SPF policy per owner and evaluate the complete nested lookup budget against SPF's ten-term limit. SPF record selection and limits

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

There is an important multi-brand case. Salesforce documents a default envelope of bounce.[SAP-domain], including when a different-root Private Domain supplies the visible From. SPF can pass but be unaligned. Its support-enabled Multi-Bounce Domain feature changes the envelope to bounce.[Private-Domain] per sending domain. It is enabled at MID level. Before enabling it, the required bounce-domain MX and SPF records must resolve; retest every Private Domain afterward. Multi-Bounce Domain prerequisites and behavior

This does not change DMARC into an “SPF and DKIM must both align” rule. DMARC requires either aligned SPF or aligned DKIM. A correctly signed Private Domain can pass DMARC through DKIM even while SPF is unaligned. A receiver can impose additional local requirements, but those are not the DMARC pass definition.

Also, bounce.brand.example is not exactly equal to brand.example. It may align under relaxed rules, but not strict aspf=s. Check the effective alignment mode; do not weaken it without the policy owner's approval. Under relaxed alignment, organizational-domain discovery follows the current specification rather than a simple visual suffix test. DMARC identifier alignment

Wait for Active, then confirm each business unit

The sending-domain states have different meanings:

For the self-service workflow, Salesforce says the In progress setup stage can take up to five business days. Its assisted-setup FAQ instead describes a typical minimum of five business days, excluding self-service and Hyperforce automated setups. These are different workflows, not a universal five-day deadline; obtain the applicable schedule before a campaign cutover. Self-service domain states, assisted setup timing

DNS detection is not activation. Verify the intended domain's state, then confirm authenticated-domain availability and the selected sender configuration in the actual business unit. Private Domain business-unit availability

A domain appearing in one business unit does not prove every journey uses it. Likewise, a green SSL state for a branded URL is not proof of DKIM activation. Retain the account/domain scope, configuration completion time and chosen sending route before collecting message evidence.

Validate public DNS with the actual generated values

The commands below are read-only templates. Substitute the full names from the issued configuration and the actual authoritative server. They are not results from a live tenant.

# Locate parent authority and, where applicable, child delegation.
dig example.com NS +noall +answer
dig email.example.com NS +noall +answer

# Check the issued selector and type; follow any issued alias to its key.
dig ISSUED-SELECTOR._domainkey.email.example.com TXT +noall +answer
dig ISSUED-SELECTOR._domainkey.email.example.com CNAME +noall +answer

# Verify the envelope/bounce owner's SPF and bounce handling.
dig bounce.email.example.com TXT +noall +answer
dig bounce.email.example.com MX +noall +answer

# Check other MX owners only when required by your issued configuration.
dig reply.email.example.com MX +noall +answer
dig leave.email.example.com MX +noall +answer
dig email.example.com MX +noall +answer

# Compare authoritative DNS with cached recursive answers.
dig @AUTHORITATIVE-NS bounce.email.example.com TXT +noall +answer

# Inspect From-domain DMARC and any applicable parent policy.
dig _dmarc.email.example.com TXT +noall +answer
dig _dmarc.example.com TXT +noall +answer

Expect the exact issued public key or CNAME chain and one SPF policy at each relevant owner. For every required MX record, compare the full owner name, numeric priority and target hostname with the approved issued configuration, including bounce, reply and any other required owners. Resolve discrepancies with Salesforce and the DNS owner; do not guess targets or copy campaign MX records onto the corporate apex. A name resolving does not prove its value is correct. An empty answer requires checking the DNS response status, queried owner, record type, authority and delegation. Do not treat every error as propagation: NXDOMAIN and SERVFAIL need diagnosis, including DNSSEC where relevant.

Compare authoritative and recursive answers after the relevant cache TTLs. If a domain is delegated, check the authoritative child service rather than relying on an obsolete record in the parent zone. When an actual message uses a different selector, follow its d=/s= pair using the DKIM selector guide.

Prove branded signing on delivered messages

After Active status, use controlled recipients and production-equivalent sends for every relevant domain/MID/route. Open the original received message. Use the destination's trusted authentication results, not a header of unknown origin or a dashboard's aggregate green badge. Authentication-Results trust boundary

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

Record the visible From, evaluated smtp.mailfrom, sender IP, each DKIM d= and s=, individual results and DMARC result. DKIM identifies its signing domain in d= and selector in s=; it signs the message rather than encrypting it. DKIM signature fields

Accept the route only when:

• The intended branded DKIM signature is present, passes verification and aligns with the actual From under the effective policy.
• DMARC passes for that From domain. A pass through another mechanism does not excuse a missing intended branded signature.
• SPF passes in a direct, unforwarded test for the expected envelope domain, with alignment recorded separately.
• The sender configuration, domain and business unit match the approved route.

Treat SPF fail, softfail, permerror, temperror or unexpected none as unresolved, even if DKIM keeps DMARC passing. Check the actual evaluated owner, sender IP, syntax, duplicate policies, nested lookup budget, DNS errors and any forwarding hop. For provider-managed/delegated records, escalate with the domain, MID, time and redacted header; for self-hosted records, compare against the issued configuration. Do not add a root-domain include to repair a failing unrelated bounce domain. SPF results

Diagnose the actual smtp.mailfrom result independently: fail or softfail calls for checking the connecting sender against the approved authorization; temperror is a transient evaluation failure, often DNS; permerror requires checking malformed or duplicate policies and the evaluated lookup budget. An aligned DKIM pass does not repair these SPF faults. Do not change an unrelated apex policy to fix a provider-controlled envelope domain. SPF result definitions.

A fictional multi-brand example: From offers@example.net, envelope bounce.email.example.com, and a passing signature d=example.net. SPF may pass without alignment, while the branded DKIM path supplies DMARC. Enabling multi-bounce changes the design, so test bounce.example.net prerequisites and new messages rather than assuming the feature repairs all domains automatically.

Keep DMARC reporting separate from provider activation

Inspect the From domain's policy and any inherited parent policy. Preserve existing enforcement, reporting addresses and alignment settings. Do not overwrite an established p=reject record or add a weakening child policy to make one test easier.

For a new approved monitoring deployment with no applicable existing policy, a sample is:

Owner: _dmarc.email.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the example domain and report address. Publish one policy at that owner. External reporting destinations can require destination-side DNS authorization. p=none requests monitoring rather than DMARC enforcement; it does not turn failed authentication into a pass or promise inbox delivery. DMARC policy, aggregate reporting

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4. For an owner-approved first policy at the apex From domain example.com, use full owner _dmarc.example.com, relative _dmarc in that zone; the existing child mapping remains separate.

For Salesforce-delegated domains, policy changes go through Salesforce support; self-hosted owners manage their own authoritative DNS. Salesforce points customers to a reporting tool for authentication-failure visibility, so a configured SAP/Private Domain is not proof that someone is collecting and reviewing reports. Salesforce monitoring guidance

Review reports across normal sending cycles and all legitimate services, not just this tenant. Current RFC 9989 requires valid DKIM for domains using p=reject, discusses indirect-mail risks and removes the legacy pct tag. Do not base a new enforcement rollout on that tag. See how to read DMARC aggregate reports.

Test replies, links and recovery separately

Authentication does not prove that reply forwarding, image URLs, web-view links, tracked links or unsubscribe actions work. Check representative functions using controlled recipients and the configured domain. Salesforce's bulk-sender addendum describes commercial one-click unsubscribe headers; inspect the actual headers and HTTPS destination rather than assuming a visible unsubscribe button must appear in every mailbox. Salesforce bulk-sender addendum

If Reply Mail Management forwards replies, obtain the mail owner’s separate approval of the exact forwarding recipient before selecting or submitting that address. Confirm the configured address matches that approved destination; domain authentication or receipt of a Salesforce record packet does not authorize sharing replies with another mailbox. Salesforce domain configuration.

Before cutover, name the person who can pause affected sends or return to the previously verified sender route. Preserve old keys and branded resource records through an agreed retirement window: queued mail and already-delivered messages may still depend on them. Avoid dismantling a delegation as a first troubleshooting step.