Confirm the MarketingPlatform account and sending identity
This guide covers the email service documented at marketingplatform.com, whose first-party help pages identify MarketingPlatform ApS and link to its application. It does not describe Google Marketing Platform or a generic marketing automation category. Identify the actual account, brand, campaign or automation, From domain and DNS owner before requesting a change. MarketingPlatform domain setup.
Make the business requirement explicit: which address should recipients see, who should receive replies, and which workflow must remain available during the change? Record existing settings and public DNS answers before editing them. If several brands share an account, create separate acceptance rows for their domains instead of assuming that one successful newsletter approves everything. Use a controlled campaign and harmless content so troubleshooting does not reveal customer data or accidentally send an unfinished promotion.
Use the dashboard as configuration evidence
MarketingPlatform's dashboard exposes SPF and DKIM status, with an info control beside each item for configuration details. Its documentation instructs the administrator to return after DNS publication and check for a green state, allowing time for changes to become visible. Support links are also available from the dashboard. Dashboard and Menu.
Capture the domain associated with each status, the time of the check and the displayed instruction. A screenshot is more useful when it contains the selected domain and record owner than when it contains only a green icon. Do not treat that indicator as evidence of the identities in a message that has not yet been sent. Keep three milestones in the change log: the record was saved, the provider validated it, and a receiver accepted an aligned message. None should be silently substituted for another.
The setup guide checks Active, MX, SPF and DKIM. The first two concern the domain and its mail-receiving readiness; they do not prove outbound alignment. Resolve an ownership or mailbox problem with the responsible administrator rather than replacing the institution's or company's existing MX records just to clear an icon. Domain checker components.
Publish a deliberate SPF change rather than a sample policy
The documented MarketingPlatform authorization mechanism is include:mailmailmail.net. Inspect the dashboard's proposed value and merge the needed authorization into the existing policy at the intended owner. Do not copy the guide's complete illustrative record, which contains unrelated mechanisms and another provider's include. MarketingPlatform SPF setup.
Before saving, identify other applications authorized by that policy and document what each retained mechanism permits. Publish one applicable SPF policy at the owner, not a second competing TXT policy. Count DNS-lookup-causing terms across nested mechanisms against the SPF limit; counting only the words visible in the top-level record is insufficient. Keep the terminal policy consistent with the approved domain design. SPF publication and lookup processing.
An authorization at the visible From domain does not itself force the message to use that domain as its SMTP envelope. The receiver's SPF identity must be observed. If a campaign passes SPF under a provider domain but fails DMARC, investigate identity alignment before adding more includes. Broadening permissions at an unrelated owner can increase trust without fixing the original failure.
Generate the DKIM value for the selected domain
Use the DKIM info control to obtain the domain's generated TXT record. The guide commonly shows an emp._domainkey owner, but the account's complete host and value must determine publication. Never invent the public key or copy one from another account. MarketingPlatform DKIM instructions.
Check how the DNS host expects names to be entered. A fully qualified owner pasted into a relative-host field can produce a duplicated domain; a record published at the root cannot satisfy a selector lookup somewhere else. Compare the saved value with the generated record, including any long public-key text, and retain the previous record if the change is a rotation. If the dashboard and public DNS disagree after caching has been considered, give support both observed and expected values instead of repeatedly regenerating keys.
DKIM acceptance requires a real signature that verifies, not just a discoverable record. Record the d= signing domain and s= selector from each received signature. There may be more than one, and a provider signature should not be mistaken for the customer's aligned signature. DKIM signature and verification specification.
Add a custom return-path through Domain Checker
MarketingPlatform documents a custom return-path workflow after SPF and DKIM are configured. In Domain Checker, use the domain's information panel to choose the return-path address and subdomain, then create the CNAME with the exact destination copied from that panel. The service checks DNS automatically and offers a manual reload; after validation, the documented arrangement uses the custom return-path for sends from that domain. Custom return-path setup.
Choose a host that has no conflicting purpose and document why it belongs to this sending domain. Do not guess the destination from the provider's company name, reuse a tenant value found online or place a CNAME over a live mailbox host. Record the requested host, the publicly resolved destination and the provider activation state. Then inspect a campaign sent after activation to confirm that the effective envelope changed as intended.
The provider's return-path article describes it as necessary for full DMARC compliance, but the protocol distinction is narrower: DMARC can pass through either aligned passing SPF or aligned passing DKIM. A custom return-path can enable the SPF route; it is not universally necessary when DKIM already provides alignment. A subdomain relationship also needs assessment under relaxed or strict policy settings. Preserve the existing security policy and prove the actual outcome. DMARC identifier alignment.
Diagnose bounces without misclassifying the recipient
MarketingPlatform distinguishes hard, soft and other bounce categories. Its code 55 indicates a remote rejection associated with SPF, DKIM or DMARC policy, whereas code 21 concerns a DNS-related failure and other codes cover connection or content problems. These are useful starting points, not complete diagnoses. Obtain the actual response text and the affected campaign before deciding what to change. Email bounce codes and rules.
For an authentication-related rejection, compare the attempted From domain, the configured domain row and the recently published records. If no copy reached a controlled receiver, preserve the provider event and SMTP response while arranging a separate safe diagnostic send. If the message arrived, use the receiver's original source rather than a forwarded copy, because forwarding can alter the authentication path.
Do not mark every policy-blocked address permanently invalid, and do not mass-resend the campaign merely because a record is now green. First establish which messages were submitted, which were rejected and which may still be pending. Coordinate any retry with the campaign owner so recipients do not receive duplicates. An authentication pass also does not guarantee inbox placement; content, reputation and recipient handling remain separate investigations.
Build the original campaign identity table
The acceptance design here has not been run. Send through the exact campaign or automation route and retain an original identity-table row for each materially different domain and workflow. Required fields are account and campaign reference, workflow, timestamp, message identifier, visible From, Reply-To, Return-Path, trusted receiver SPF domain/result, every DKIM d=/s= and result, DMARC result, alignment modes and restricted original-message location. Add dashboard validation times and the approved DNS change reference.
Compare the expected identities with observed ones; leave fields unknown until evidence exists. Test reply routing and any business-critical campaign links separately. If authentication breaks after a change, pause the affected send, restore the last approved setting where safe and preserve unrelated senders. Remove or replace only a record whose ownership and dependency have been checked. Repeat the controlled message after recovery instead of declaring success from the rollback alone.
No MarketingPlatform tenant, live DNS or received message was inspected for this manuscript. Account-specific values, exact-route applicability, the completed original received-message identity table and human SME review remain outstanding. This is an unpublished, evidence-based setup candidate, not a claim that a customer's campaign has been verified.
Keep a decision record for retries
Before a retry, assign each original campaign event to accepted, rejected, pending or unknown using available provider evidence. Keep authentication remediation separate from recipient-list decisions. The campaign owner approves only the intended retry population after duplicate risk is assessed. A changed DNS record does not establish the earlier submission state.