For native Maropost Marketing Cloud campaigns, configure the account-issued sending-domain records, verify the required custom Return Path and maintain a separate verified link-tracking domain. DNS publication, each account verification control and an actual campaign’s authenticated sender are separate checks. There is no universal SPF include, DKIM selector or CNAME target to copy from another account.
This guide covers the current CNAME-based DKIM workflow and non-branded campaigns using an approved default sending domain. “Non-branded” is the platform’s campaign classification, not permission to accept an unrelated From identity. Brand-specific campaign overrides, Commerce Cloud/Neto, Service Cloud support mail and other SMTP services are outside this scope. Marketing Cloud DNS prerequisites.
No customer account, DNS change, permission change or campaign send was performed.
Confirm access and approve the affected routes
Identify the Marketing Cloud account, intended From domain, campaign workflow, current defaults and authoritative DNS administrator. The operator needs the DNS Setup privilege. If controls are missing, ask the authorized administrator to review the required access; do not grant broad administration or contact-export permissions as a troubleshooting shortcut. Users and permissions.
Inventory existing SPF, DKIM selectors, DMARC policies, aliases and NS delegations at every proposed owner. Keep an approved before-state. The website host or registrar is not necessarily the active DNS operator.
Before enabling a custom Return Path or publishing its alias, approve the exact bounce-routing hostname and destination. Separately approve the tracking domain’s destination, link-routing function and data-handling consequences. A generated packet does not authorize repointing a live hostname. Stop if an owner conflicts with a website, another sender, a mailbox or a delegated namespace. Do not alter MX, nameservers, DNSSEC or forwarding to satisfy this guide.
Create the sending domain and obtain its records
Open Settings > DNS Setup > Sending Domains > New Domain. Enter the intended domain without leading whitespace or an initial capital letter, then Next. The Domain Verification page supplies the required account-specific values. Choosing Done defers verification; it does not complete authentication. Sending-domain procedure.
Use the issued SPF TXT and DKIM CNAME owners and values, preserving their actual types. After publication, their controls are Verify TXT and Verify CNAME respectively. For DMARC, the UI also needs the same complete approved policy value that is actually in DNS before Verify TXT. Obtain the complete packet before making changes; do not guess missing fields.
Maropost’s March 13, 2025 release changed DKIM to internally generated selectors, 2048-bit keys and CNAME-based publication. Older tutorials that ask you to invent a selector or paste a TXT key are not the current new-domain route. This does not authorize deleting old records: a migration needs dependency and queued-message checks, plus separate approval. Dated DKIM change.
Publish safely at the correct DNS owners
Map each issued full name to the zone you actually edit. For an illustrative selector._domainkey.mail.example.com, a parent example.com editor may need selector._domainkey.mail; a separately delegated mail.example.com editor may need selector._domainkey. If _domainkey is separately delegated, use its actual authority. These are mapping examples, not Maropost-issued names. Avoid the DNS editor appending the domain twice. DNS zones and delegation.
At a CNAME owner, do not add TXT, A, AAAA, MX or a second CNAME. Resolve collisions without deleting existing services or NS delegations. Use exact issued destinations, not merely a hostname that ends in a familiar vendor suffix. Publish only public DNS material, never private signing keys or credentials. DNS record representation.
Where a required CNAME must remain visible, keep it DNS-only rather than behind an HTTP proxy. For Cloudflare, check per-record, whole-zone, apex and same-zone flattening: disable the relevant per-record Flatten option when available and ensure applicable zone behavior preserves the required CNAME answer. Do not make unrequested global changes. If mandatory behavior prevents that answer, coordinate a supported configuration instead of inventing a switch. Cloudflare flattening controls.
Reconcile SPF instead of adding a second policy
SPF authenticates the SMTP MAIL FROM domain, not automatically the visible From. Publish the current issued authorization at its actual owner, then validate the real envelope identity on a delivered campaign. A parent-domain SPF policy is not inherited by its children.
Keep one v=spf1 TXT policy per evaluated owner. Merge only the approved necessary authorization into an existing policy while preserving legitimate senders and qualifiers. Do not replace apex SPF blindly. The budget is ten evaluated DNS-dependent terms, including nested lookups, not ten includes. An all mechanism makes redirect ineffective; adding authorization after all does not work. Distinguish invalid syntax, duplicate policies and lookup-limit errors from an ordinary unauthorized sender. SPF processing rules.
Preserve DMARC and match the account value
Check both the direct and applicable inherited policy before publishing the issued DMARC owner. An empty lookup at one name does not establish that there is no policy. Preserve existing enforcement and authorized report recipients. Never downgrade quarantine or reject, add a child monitoring override, duplicate the policy or copy the vendor’s example reporting address just to pass validation.
Only if no applicable policy exists, the owner approves and monitoring is appropriate may a first TXT policy begin with v=DMARC1; p=none. For From example.com, the owner is _dmarc.example.com; for From mail.example.com, it is _dmarc.mail.example.com. In the parent zone the latter is _dmarc.mail, or _dmarc in the separately delegated child zone. That minimal policy does not request reports. Do not add obsolete pct rollout assumptions. Current DMARC policy rules.
Enter the complete actual approved DNS policy into Maropost’s DMARC Record Value field and use Verify TXT. If the account expects a conflicting value or cannot accommodate the approved inherited policy, stop and resolve it with Support and the domain owner rather than weakening protection.
Aggregate report destinations require owner approval. When the report destination’s Organizational Domain differs from the Organizational Domain of the domain where the policy was found, the mail receiver generating the report must check DNS authorization. A destination within that same Organizational Domain is excepted. This protocol check does not replace permission to share data. RFC 9990 section 4.
Verify the required custom Return Path
After routing approval, use the Domain Verification page’s Custom Return Path toggle and Host field to obtain the CNAME for the intended subdomain. Copy the issued full owner and target, publish at the correct authority, then use Verify Return Path Record. Do not guess how the UI expands the prefix; compare its resulting full hostname before publication. Custom Return Path controls.
The Return Path handles envelope/bounce identity, not the visible From or the Reply-To mailbox. Its verification does not guarantee strict SPF alignment. A child envelope domain can align under relaxed policy but fail exact-domain strict alignment. Inspect the actual delivered MAIL FROM rather than assuming the alias name proves the envelope used.
Maintain a separate verified link-tracking domain
Maropost requires at least one verified tracking domain before campaigns can send. If an approved working one already exists, preserve it and its historical links rather than creating a replacement unnecessarily.
For a new approved tracking hostname, open Settings > DNS Setup > Link Tracking Domains > New Domain, enter the domain and choose Next. Copy its issued CNAME owner and target to authoritative DNS, then use Verify CNAME. Done only postpones verification. Confirm the exact destination and routing approval before publication. Link-tracking setup.
A tracking alias is not a DKIM selector. Do not reuse an occupied website hostname or delete an old tracking domain simply because a newer one verifies. Review dependencies before changing any tracking default.
For the non-branded campaign scope here, the sending-domain guide requires a default sending domain. Use Set as Default only after the owner approves the resulting campaign scope. Preserve an existing approved default when it is already the intended one; switching an account-wide default can affect other sends. A domain’s presence in a list is not proof that a campaign actually uses it.
Separate optional monitoring from authentication
The sending-domain overview lists Google Postmaster Tools alongside checks, but its dedicated section labels it Recommended. Do not silently make a new Google account or delegate access as part of DNS setup. Such monitoring needs separate authorization and does not prove DKIM or DMARC success. If the live account blocks progress, resolve that requirement with Maropost rather than bypassing it.
Test the actual campaign after account verification
Confirm the required SPF, DKIM, DMARC, Return Path and tracking checks, plus the approved default used by the intended non-branded campaign. There is no separate undocumented DKIM Activate switch to invent.
Use an approved, controlled external recipient through the intended native campaign workflow. Do not release a scheduled customer send, import an audience, re-enable unsubscribed contacts or test another product’s SMTP endpoint. A preview, DNS checker or account green check alone is not evidence of the final authenticated message.
Obtain the original message and results produced inside the receiving service’s known processing boundary. Consult its documented handling of externally supplied Authentication-Results, or request an administrator trace. Matching authserv-id text or header position alone is not trust; ignore injected external result fields. Authentication-Results trust rules.
Record the actual From, SMTP MAIL FROM, intended Maropost DKIM d= domain and s= selector, and trusted SPF/DKIM/DMARC results. Require the intended signature to pass and align with the intended brand From, plus dmarc=pass. An unrelated passing signature or a rewritten provider From does not validate this setup.
DMARC itself passes through either aligned SPF or aligned DKIM. Relaxed alignment compares Organizational Domains; strict aspf or adkim requires exact domain equality. SPF failure does not automatically mean DMARC failure when aligned DKIM passes, despite the simplified provider description. Conversely, SPF-based DMARC success does not prove DKIM works. See raw DKIM versus aligned DKIM results.
Investigate SPF fail, temporary DNS errors and permanent syntax/lookup-budget errors independently. Verify approved tracking links without triggering purchases or account actions. Keep evidence private and retest materially different send paths. Authentication does not guarantee inbox placement.
Troubleshooting without unsafe shortcuts
Done was clicked but the domain is unusable: return to Verify Domain and finish the required checks. Saving the domain is not verification.
DKIM verifies in DNS but is absent from the campaign: check the actual selected/default route and From, then ask Support to inspect signing. Do not remove unrelated keys or accept a different provider signature.
An old TXT selector is still present: do not blindly delete it after a new CNAME validates. Account verification does not establish that no queued message or shared service still depends on the old selector.
Return Path fails: check the fully expanded issued host, authoritative zone, alias target and conflicts. Do not promise strict alignment from a child alias or redirect bounces to an unapproved destination.
Tracking is unverified: complete its separate CNAME verification without assuming DKIM verification covers it. Preserve existing link destinations and history.
DMARC’s UI value differs from DNS: reconcile the actual approved policy and the account field. Do not replace protective policy with an example merely to make them match.
A message is rejected despite successful checks: inspect the actual rejection and route. A DMARC failure alone does not prove it caused rejection; recipient policy, limits, consent and reputation need separate diagnosis.
For recovery, pause the affected workflow where operationally safe and coordinate restoration to the last approved state. Do not delete domains, selectors or defaults as a routine rollback. Give Support necessary redacted domain/selector/status evidence through an approved channel, not credentials, private keys or customer message contents.