To authenticate MarketingPlatform email, use the dashboard's domain checks to publish the requested SPF authorization and generate the domain's DKIM TXT record. Once SPF and DKIM validate, configure a custom return-path in Domain Checker if you want branded SPF alignment. Its CNAME destination is supplied in your account, and the return-path becomes active after successful detection. Verify the resulting email, not only the dashboard icons. SPF/DKIM setup, custom return-path setup.
Confirm the product, sender and DNS owner
This guide is for MarketingPlatform at marketingplatform.com, previously MailPlatform.dk. It is not Google Marketing Platform, another product with a similar name, or a guide to configuring employee mailboxes. You make sending-domain changes in MarketingPlatform and publish records through the DNS service authoritative for your domain. Those are separate systems.
Before starting, record the campaign's exact From address, any automated or transactional streams using that address, and the monitored Reply-To address. Authentication for example.com should not be assumed to cover a separate configuration for news.example.com. Record the account and the domain row being changed so generated settings do not get attached to the wrong brand.
MarketingPlatform checks Active, MX, SPF and DKIM. The domain must exist, and the sender address should exist on a functioning mail service. Preserve that inbound service while adding authentication. Official domain checks.
Save the current SPF, DKIM, DMARC, inbound MX and all records at the proposed return-path owner, including TTLs. If your registrar is not your authoritative DNS host, editing its unused zone will not change public results. A DNS administrator should resolve that ownership question before publishing anything.
Read the dashboard before composing DNS records
Open the dashboard and use the info control beside the SPF or DKIM status for the relevant domain. The dashboard exposes configuration details and should show green status once the records are detected. Its checks can lag publication because of DNS caching. Dashboard guidance.
Keep three distinct checkpoints in your implementation notes:
| Checkpoint | What it establishes | What it does not establish |
|---|---|---|
| The dashboard displays a requested record | The account's expected configuration | That your DNS host published it correctly |
| Public DNS returns that record | The record is available from the queried DNS path | That a campaign uses the expected signing or return-path identity |
| A delivered message passes authentication and alignment | What happened on that tested route | That every other campaign, domain or automation is configured identically |
If the dashboard offers a sample SPF policy containing other providers, treat it as something to reconcile with your real sender inventory. Do not authorize a website IP, MX server or unrelated service simply because it appears in an example.
Add the MarketingPlatform SPF authorization safely
The documented MarketingPlatform authorization is include:mailmailmail.net. For a domain used only for this service, with no existing SPF policy, the published single-sender pattern is:
Owner: example.com
Type: TXT
Value: v=spf1 include:mailmailmail.net -all
Replace the owner with the domain specified by your account's setup. This example is not a universal replacement policy. MarketingPlatform's documentation also discusses softer policy during incomplete sender discovery; retain your organization's approved ending rather than changing it incidentally. Provider SPF value.
If a record beginning v=spf1 already exists at that owner, merge the required authorization into that one policy before the terminal all mechanism. Preserve other legitimate senders. Do not add a second SPF record, repeat v=spf1, or copy historic Outlook or hosting-provider mechanisms from old examples. Non-SPF TXT verification records can remain.
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.
SPF checks the actual envelope MAIL FROM domain, usually shown in Return-Path and smtp.mailfrom. It does not check the visible From domain merely because that domain has an SPF record. The root-domain authorization requested by the platform and SPF alignment of an individual message are therefore separate checks. SPF records are not automatically inherited by subdomains. SPF identity and publication rules.
Evaluate the entire resulting policy, including nested includes, against SPF's ten DNS-querying-term limit. A short-looking policy can exceed it; a basic TXT lookup will not perform the evaluation. If the actual envelope domain is operated by MarketingPlatform, investigate its SPF failure with Support instead of trying to repair it by modifying an unrelated root record.
Generate and publish the DKIM TXT record
For a domain without MarketingPlatform DKIM, its DKIM info control offers generation of a domain-specific value. Publish the resulting TXT record. The official setup guide says emp._domainkey is commonly used, but your displayed hostname and public value govern the record. Do not invent the selector or reuse another account's key. Generated DKIM workflow.
Use a worksheet with the exact issued values:
Type: TXT
Full owner: the complete DKIM hostname shown for this domain
Value: the complete generated public DKIM value
For example, if the issued owner is emp._domainkey.example.com, a DNS editor that automatically adds the zone suffix may need emp._domainkey. If the sender domain is news.example.com inside the example.com zone, an issued owner of emp._domainkey.news.example.com would need emp._domainkey.news in that same kind of editor. Verify the saved full name. Do not strip _domainkey or publish the key at @.
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.
The public value must remain complete, without smart quotes, omitted characters or accidental spaces inserted into its key data. Some DNS systems display a long TXT record as several quoted character strings within one resource record; that is different from creating multiple competing records. Follow the DNS host's handling of long TXT values.
Keep unrelated DKIM selectors. A Microsoft 365 or other service's working DKIM key does not supply MarketingPlatform with a signing key. The sending platform retains its private key; only the public verification material belongs in DNS. DKIM key retrieval and selectors.
Return to the dashboard and verify the domain's status. If generation is unavailable or the displayed instructions disagree with your existing configuration, use MarketingPlatform Support rather than regenerating keys repeatedly. Its general authentication article provides a support route for obtaining domain-specific DKIM instructions. Provider assistance.
Configure a custom return-path after SPF and DKIM validate
In Domain Checker, open the domain's info panel, choose the return-path address/subdomain and copy the displayed destination. Publish the requested CNAME at that exact owner. MarketingPlatform checks automatically, also offers a manual reload, and starts using the custom return-path after validation. The documented prerequisite is completed SPF and DKIM configuration. Return-path workflow and activation.
Choose an unused subdomain, for example returns.example.com, rather than the root or a name already serving employee mail or a website. The example is not a provider target. Copy the destination from the setup panel; do not infer it from mailmailmail.net, another customer's DNS, or an old screenshot.
A CNAME owner cannot also hold ordinary TXT, MX, A or other conflicting data. Do not place a new SPF TXT record at the same owner to supplement the return-path CNAME. Do not delete an existing business service to force the alias into place. Select another name or obtain a migration plan. CNAME rules.
For Cloudflare-hosted DNS, keep this email return-path CNAME DNS-only, not proxied, and ensure CNAME flattening does not conceal the alias required for verification. Limit that guidance to the email record; unrelated web records need not be changed. Cloudflare proxy guidance, flattening and third-party verification.
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.
A custom return-path can provide aligned SPF, but it is not universally required to pass DMARC: a valid aligned DKIM signature can do that independently. With From newsletter@example.com and return-path returns.example.com, SPF alignment is relaxed, not strict. Strict aspf=s requires an exact domain match. Check actual d= for DKIM as well; do not assume what the platform signs until you inspect the message. DMARC alignment rules.
Preserve DMARC and enable useful reporting
Keep any established policy, including p=quarantine or p=reject, while you repair the new sending route. Authentication setup is not a reason to weaken protection for all your other senders. Avoid creating a second DMARC record at the same owner.
If no policy exists and you are beginning a monitored rollout, a starting example is:
Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Use your actual From domain and an approved reporting mailbox. For a subdomain sender, check both a directly published policy and any applicable parent policy before adding or changing records. p=none requests no quarantine/reject action for DMARC failures; it does not make all mail acceptable to a receiving provider. DMARC policy.
Monitor aggregate reports across MarketingPlatform, employee mail and other services. A reporting service outside your domain may need to publish external reporting authorization. Validate the approved rua destination and ensure reports are being processed, rather than equating an existing tag with useful monitoring. Aggregate reporting specification.
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 monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names.
Use EmailAuth to organize sender and alignment evidence when planning enforcement. Keep policy decisions tied to observed legitimate traffic, not solely to a dashboard's domain setup status.
Verify the published records and the delivered campaign
After replacing all example owners and the DKIM selector, your DNS administrator can run these read-only checks. The first TXT owner is the configured sender domain; the actual return-path owner must be checked separately.
dig +short NS example.com
dig +noall +answer example.com TXT
dig +noall +answer SELECTOR_FROM_ACCOUNT._domainkey.example.com TXT
dig +noall +answer returns.example.com CNAME
dig +noall +answer returns.example.com TXT
dig +noall +answer _dmarc.example.com TXT
The DKIM response should contain the account's complete public record at its correct owner. The CNAME should point to the issued target, and resolution for the return-path should lead to the provider-managed records needed for the route. The TXT query does not instruct you to create TXT beside a CNAME. Check authoritative answers as well as recursive resolvers if cached results disagree, and allow for previous positive and negative TTLs.
Then have an authorized operator send a controlled campaign through the same MarketingPlatform route used in production. Separately exercise relevant automations or transactional routes if they have different sender settings. Preserve the raw message and the receiver's trusted Authentication-Results. How receiver results are expressed.
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.
Your acceptance checklist should require:
- The intended From address, account and message stream.
dkim=passfor the intended branded signing domain, with that domain aligned to From under the effectiveadkimmode. Neither a second unrelated signature nor a DMARC pass supplied only by SPF proves branded DKIM is complete.spf=passfor the actual envelopesmtp.mailfrom, with the chosen custom domain when that feature was configured.dmarc=passfor the visible From domain under its effectiveadkim/aspfsettings.- No unexplained SPF
none,neutral,softfail,fail,temperrororpermerror, even where DKIM already supplies a DMARC pass. - Working reply handling and the expected bounce route.
A historical message predating the change cannot verify the new setup. Record its timestamp alongside the latest DNS and dashboard checks so cached DNS, old mail and current configuration do not get mixed together.
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.
Resolve common MarketingPlatform failures
| Symptom | What to check before changing records |
|---|---|
| Domain setup warning remains | Identify whether Active, MX, SPF or DKIM failed; do not assume every warning is an SPF issue |
| Existing SPF is rejected after adding the service | Look for duplicate SPF records, repeated version tags, broken merge syntax or excessive nested lookups |
| DKIM remains red | Compare the issued owner and full public value; check zone suffix duplication and whether DNS was edited at the authoritative host |
| Return-path cannot be configured | Complete SPF/DKIM prerequisites first, then inspect the correct domain's panel |
| CNAME exists but return-path is not detected | Check owner conflicts, exact target, DNS-only behavior, flattening and cached results before reloading |
| Dashboard is green but headers use another identity | Compare the campaign's real From domain and account with the domain row you configured; inspect a new same-route message |
| Both SPF and DKIM pass but DMARC fails | Check whether either passing identifier aligns, especially under strict modes |
| DMARC passes but campaign is blocked | Keep the full bounce response and investigate the actual rejection reason, not a generic deliverability assumption |
When escalating, include the domain row, generated record owner, DNS response, UTC timestamp, campaign reference and redacted authentication results. Do not send DNS credentials or private keys in a support message.
Documentation and verification limits
This guide was checked against public instructions, not a customer's account. No DNS changes, account changes, support submissions or sending tests were performed. Generated DKIM values, the return-path destination, platform activation and delivered-message results must be confirmed in your implementation.