mailingmanager SPF, DKIM and DMARC setup, step by step

For MailingManager’s dedicated sending-subdomain route, use a new, unused subdomain, obtain the current account-confirmed sending and DKIM CNAMEs, publish them at authoritative DNS, and ask MailingManager Support to validate the domain. Then configure and select the correct Email Profile and verify a fresh campaign’s branded DKIM and DMARC results. Do not copy public example tokens or mix the conflicting 1024- and 2048-selector instructions. MailingManager’s branded DNS guide, application domain guide.

The procedure below is based on public documentation, not access to your account or a live DNS/message test. No Support ticket or test campaign was sent while preparing it.

Choose the right route before editing DNS

This guide covers native MailingManager campaign and workflow email using a dedicated, unused sending subdomain. It does not migrate your website, employee mailboxes or parent-domain MX records. The application help also documents root-level authentication; that is deliberately outside this procedure because its MX changes can redirect inbound mail.

Choose an authorized subdomain such as news.example.com only after confirming it has no existing website, mailbox, CNAME, service or delegation that would conflict. The example name is not a recommendation to replace an existing news service. MailingManager explicitly warns against authenticating names already used for regular mail or website hosting. Domain Authentication Guide.

You need an existing account with permission to manage the relevant domain and Email Profile, authoritative DNS access, and someone authorized to request Support validation. Account Settings customization requires admin rights, but the public sources do not establish a single named role or paid-plan gate for every authentication action. Confirm missing controls with the account owner rather than assuming a different role or subscription. Account Settings.

Inventory and save existing DNS records, TTLs, NS delegations, selectors, direct/inherited DMARC policies and authorized report recipients. Identify every system using the parent and proposed child names. If staff mail uses Microsoft 365, keep that route intact; EmailAuth’s Microsoft 365 guide addresses that separate sender, not MailingManager campaigns.

Obtain a current packet and resolve the selector conflict

Use MailingManager’s domain-authentication guidance and the recommended DNS entries shown for your sending domain in System Monitor. Its SPF and DKIM help pages say that recommended settings are displayed on screen and can be exported as a PDF for the DNS administrator. This establishes where to obtain account-specific instructions; it does not make every value shown in a public example universal. SPF help, DKIM help.

The accessible public pages disagree on DKIM:

• The branded DNS page shows a selector beginning dkim2048 with a target under dkim-manager.net.
• The application domain guide shows a selector beginning dkim1024 with a different target under dnsentries.co.uk.
• The application DKIM help also contains a “1,048 bits” statement. Do not treat that typo as a cryptographic standard or key-size requirement.

Do not choose a selector based solely on which page looks newer: neither page exposed a reliable update date in the reviewed material. Ask Support to reconcile any disagreement with the current account’s full owner/type/target packet before publication. Do not combine the 2048 owner with the 1024 target, add both speculatively or silently rotate a working selector. Branded DNS instructions, application DNS instructions.

Capture the exact sending subdomain, sending CNAME target, DKIM full owner and target, chosen From identity and intended reply address in the approved change plan. Provider-looking strings and tokens in a public table are examples of that published configuration, not proof they are assigned to your account.

Publish the sending and DKIM CNAMEs safely

For this subdomain route, the two authentication functions are distinct:

• Sending-subdomain CNAME: points the selected child name to the confirmed provider destination. MailingManager documents SPF as automatically implemented through this subdomain authentication route.
• DKIM selector CNAME: points the full selector owner under the sending domain’s _domainkey namespace to the confirmed provider-managed key destination.

Use the exact account-confirmed values. No additional SPF TXT belongs at the sending CNAME owner, and this procedure does not require blindly adding an include to the parent-domain SPF. Do not copy the application help’s root-level MX/TXT table into a subdomain installation. Sending-domain record types.

The following is an owner-mapping example, not deployable DNS data:

Sending owner: news.example.com
Type: CNAME
Target: CURRENT_ACCOUNT_CONFIRMED_SENDING_TARGET

DKIM owner: ACCOUNT_SELECTOR._domainkey.news.example.com
Type: CNAME
Target: CURRENT_ACCOUNT_CONFIRMED_DKIM_TARGET

In the example.com parent zone, relative owner fields would normally be news and ACCOUNT_SELECTOR._domainkey.news. Check whether your editor automatically appends the zone name; entering an unnecessary suffix can create the wrong owner. Targets are destination hostnames, not URLs, TXT values or email addresses. Preserve their complete spelling and the DNS editor’s required treatment of a terminal dot.

A CNAME cannot coexist at its owner with ordinary TXT, A, AAAA, MX or a second CNAME record. If the proposed child already has any such records, stop and select another unused label or design an explicitly authorized migration outside this guide. Do not delete functioning records to make the tutorial fit. CNAME semantics.

Delegation needs special care. A separately delegated news.example.com zone has apex SOA/NS records, so its apex is not an ordinary place to put the required sending CNAME. Do not remove that delegation or substitute an ALIAS/ANAME automatically. Use another unused owner or obtain a provider-approved design. If only _domainkey.news.example.com is delegated, publish the selector CNAME at the authority serving that namespace; its relative owner there is the selector alone. Preserve all other selectors and delegation records.

Keep the issued authentication aliases visible in DNS, not behind an HTTP proxy. For Cloudflare, use DNS-only records and leave the per-record Flatten control OFF where available. Applicable zone-wide flatten-all settings must not suppress these CNAME answers; Cloudflare does not permit a per-record override while flatten-all is enabled. Coordinate any shared-setting change with the DNS owner, preserving dependent records through supported per-record settings or another provider-approved solution. Do not disable a zone-wide feature blindly. Cloudflare also flattens apex CNAMEs by default and same-zone targets regardless of the flattening setting, so an OFF control alone is not proof of visible aliases. Verify the authoritative answer; if the required CNAME cannot be exposed safely, stop and resolve the design with the DNS host and MailingManager. Preserve the delegation safeguards above. Other DNS hosts may use different controls. Cloudflare CNAME flattening documentation.

Keep tracking and mailbox routing separate

MailingManager’s public example has a separate tracking CNAME. Tracking links, forms and hosted pages are not the DKIM selector and do not establish SPF alignment. Set up tracking only if it is part of your approved campaign plan, using its own unused owner and current confirmed target. The provider documents automatic SSL after full tracking-domain authentication and warns that HSTS compatibility depends on that authentication; do not change HSTS or other security settings merely to force email authentication to pass. Tracking-domain guidance.

The dedicated sending subdomain permits the provider to process returned mail. That does not authorize moving the parent domain’s mailbox traffic or repointing website records. Confirm that the chosen owner and provider destination match the authorized routing plan before publication. If any new packet unexpectedly requests root MX, nameserver or unrelated routing changes, stop and clarify scope instead of treating those as incidental DNS steps.

SPF evaluates the connecting IP against the actual SMTP MAIL FROM identity, or HELO where applicable, not automatically the visible From. The public returned-mail description does not establish every message’s exact envelope localpart/domain or guarantee strict SPF alignment. Inspect the production message. Existing SPF at other owners must remain intact: one v=spf1 policy per evaluated owner, with the ten evaluated DNS-dependent term limit including nested mechanisms. An all mechanism causes redirect= to be ignored; do not casually append it to an existing redirect-based policy. Returned-mail requirements, SPF standard.

Preserve DMARC rather than delegating it accidentally

The provider examples include a _dmarc CNAME pointing to a provider-managed policy. That is a policy-control delegation, not simply another DKIM record. Do not publish it automatically. It can conflict with an existing TXT or replace the protection that would otherwise be inherited from the parent. The domain owner must deliberately approve any change in policy control and report destinations.

First identify the direct or applicable inherited policy for the intended From domain, including its alignment mode. Preserve working enforcement and authorized recipients. Do not duplicate DMARC, reset an existing policy to monitoring or use obsolete pct rollout advice. DMARC policy discovery, MailingManager DMARC help.

Only when there is no direct or applicable inherited policy and the owner approves a monitored first-policy rollout, a domain-owner-managed TXT example for this child domain is:

Owner: _dmarc.news.example.com
Type: TXT
Value: v=DMARC1; p=none;

Use _dmarc.news as the relative owner in the example.com zone, or _dmarc if an appropriate child policy zone is independently authoritative. Do not put this TXT at an owner already holding the provider’s policy CNAME. The example does not invent a report recipient; add reporting only under an approved monitoring/privacy plan, or establish another monitoring arrangement before rollout.

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, which may differ from the visible From domain. If those Organizational Domains differ, the report-generating receiver must check DNS authorization. Destinations within the same Organizational Domain as that policy domain are excepted; different hostnames alone do not imply external authorization is required. Permission in DNS does not replace the owner’s decision to share report data. RFC 9990 section 4.

Validate DNS, then obtain Support validation

Compare authoritative and recursive DNS answers with the approved packet. Replace every uppercase placeholder and example name before using these diagnostic templates:

dig @AUTHORITATIVE_NAMESERVER CNAME news.example.com
dig CNAME news.example.com
dig @AUTHORITATIVE_NAMESERVER CNAME ACCOUNT_SELECTOR._domainkey.news.example.com
dig CNAME ACCOUNT_SELECTOR._domainkey.news.example.com
dig TXT CURRENT_ACCOUNT_CONFIRMED_DKIM_TARGET
dig TXT news.example.com

The first four queries should expose the exact confirmed CNAME targets. Follow any further aliases to inspect the final DKIM public-key TXT and provider-managed SPF data. DNS presence alone cannot prove that a particular campaign will use that selector or envelope identity. A cached negative result can persist until its negative TTL expires; a wrong authoritative owner will not fix itself by waiting.

Application help allows 24–48 hours for some DNS propagation scenarios. After publishing and checking the records, contact MailingManager through your verified account Support channel and request domain validation. The branded guide explicitly says Support validates the domain in your account after you notify them. Do not skip this stage because public DNS or System Monitor looks correct. Support validation requirement, domain guide.

Keep the provider’s confirmation with your change record. This guide has not contacted Support, and the propagation window is not a promise about ticket response time or successful activation.

Select the authenticated domain in an Email Profile

Once the domain is validated, configure the identity the actual message will use:

1. Expand Templates in the sidebar and open Email Profiles.
2. Choose New Email Profile when a new profile is needed, fill in the relevant fields and choose Save Changes. Inspect an existing profile before altering it, since other templates may depend on it.
3. Use the validated sending subdomain in the intended From address. Set only an authorized reply destination.
4. Select the intended Email Profile when creating or configuring the Email Template used by your campaign or workflow.

The profile controls sending, replies and opt-out behavior. Preserve unsubscribe and suppression settings during authentication work; they are not DNS troubleshooting switches. Email Profiles.

From and Reply addresses are independent. The default direct-to-external-mailbox reply route does not require moving that mailbox into MailingManager. Do not enable optional reply tracking as part of DKIM setup: tracked replies record the message and attachments inside the application, forward them, and can trigger suppression of queued campaigns depending on settings. Those are separate data-handling and workflow decisions.

Messages sent directly to the From address are ignored by default according to the profile documentation. Optional Returned Mail Forwarding applies across all Email Profiles sharing the same From address, not just the profile being edited. Do not enable it or change its recipient without assessing that shared effect and obtaining the appropriate authorization. Reply and returned-mail behavior.

Accept the setup only after a real message check

Use an authorized controlled recipient and the actual native campaign or workflow template with its selected profile. Test each materially different production path; a staff-mailbox message or an unrelated campaign cannot establish this profile’s behavior. No such tests have been performed for this guide.

Inspect the received message using the receiving service’s original-message tools. Confirm which Authentication-Results fields were generated inside its known receiving processing boundary and its documented treatment of externally supplied fields. If that is unclear, ask the receiving administrator. A familiar authserv-id string or header position alone cannot authenticate the result; ignore untrusted or attacker-inserted fields. RFC 8601 security requirements.

Save the intended From, actual SMTP MAIL FROM result, intended DKIM d= and s=, and trusted receiver results. The acceptance gates are:

• The From address still uses the intended customer sending subdomain, not a rewritten provider-domain identity.
• The intended MailingManager DKIM signature passes and its d= aligns with the visible From under the effective policy.
• The trusted receiver reports dmarc=pass for that From. DMARC passing through SPF alone is not evidence that this DKIM configuration works.
• SPF is checked independently. Repair fail and softfail, temporary DNS temperror and permanent evaluation permerror even when aligned DKIM permits DMARC to pass.

Relaxed alignment compares Organizational Domains; strict alignment requires exact domain equality. A child Return-Path aligned with a parent From under relaxed rules may fail strict SPF alignment. Do not assume the public CNAME table proves strict alignment. DMARC identifier alignment.

Troubleshooting and rollback

The CNAME does not appear: check the authoritative zone, auto-appended suffix, owner conflicts, proxy state and applicable flattening rules. If the child is already delegated or in use, stop rather than deleting NS/MX/A records.

The account shows a different selector from the public article: use the current account/Support reconciliation, not a mixture of dkim1024 and dkim2048. Preserve the previous selector until rotation and queued-message handling are agreed.

DNS is correct but the domain cannot send: confirm Support has validated the domain in this account. Then check the Email Profile and the template’s actual selected profile. DNS checks and a saved profile are different stages.

DKIM is absent or fails: inspect the actual message selector and signing domain, confirm its CNAME resolves to the intended full public key, and compare the campaign’s selected profile. The provider says missing or invalid DKIM entries can leave messages unsigned. A generic signature from another domain is not a substitute for the intended aligned signature. DKIM help.

Replies or bounce processing behave unexpectedly: distinguish Reply-To delivery, direct-to-From mail, returned-mail processing and optional forwarding. Check shared profile dependencies before changing any recipient or forwarding feature. Do not solve a bounce-processing issue by repointing the company’s root MX.

Mail authenticates but is filtered: inspect actual bounce responses, consent, complaints, reputation and content. Neither correct DNS nor a newly validated domain guarantees delivery.

If rollback is necessary, pause the affected campaign/workflow using the authorized operational process. Restore the previous approved profile selection if appropriate and coordinate domain validation changes with Support. Restore only your DNS changes from the baseline after checking current dependencies. Do not remove provider CNAMEs while active campaigns, returned mail or tracking still require them. Retain old selectors for legitimate queued/recent mail until safe retirement is confirmed. Keep parent MX, unrelated SPF, inherited/direct DMARC and other teams’ records intact, then repeat acceptance tests before resuming.

Sources and maintenance

The branded DNS guide and application help were accessible when checked, but no reliable vendor update dates were visible. Their differing selectors are retained as an explicit reconciliation requirement, not silently resolved by inference. Primary sources are the branded DNS instructions, domain guide, System Monitor, SPF, DKIM, returned mail, Email Profiles and DMARC. Recheck the issued packet and run the same acceptance gates after selector rotation, profile changes or a sending-route change.