Real Magnet SPF, DKIM and DMARC setup, step by step

Higher Logic Thrive Marketing Enterprise, formerly Real Magnet, documents three domain-authentication CNAMEs: send pointing to client.rmsend.com, and the two DKIM selectors HLMAE1 and HLMAE2 pointing to their corresponding rmsend.com targets. Publish the records for each sending domain, verify public DNS, then ask Higher Logic Support to complete the account setup. Wait for its readiness confirmation before testing the newly authenticated campaign route. Enterprise authentication procedure

The provider labels the send CNAME “SPF Authentication” but separately describes an mmsend.com envelope. Do not infer the actual Return-Path or SPF alignment from the record label alone. Verify the account's delivered-message identities.

This is documentary guidance. No customer account, customer DNS configuration or delivered message was tested.

Which Higher Logic product does this configure?

This guide is for Thrive Marketing Enterprise, formerly Real Magnet. The Professional product, formerly Informz, uses a different generated-record workflow and an in-product TEST. Its informz.net examples are not Enterprise settings. Separate Professional workflow Community and Vanilla notifications are also outside this procedure. Enterprise's former-name statement

For Enterprise, DNS publication and provider activation are separate milestones. A correct-looking CNAME does not show that Higher Logic has enabled signing for your account or selected the intended campaign domain.

Gather the domains, owners and existing records

Before requesting DNS edits, record:

• The Enterprise account, account owner and Support contact authorized to handle its domain setup.
• Every visible From domain, including marketing subdomains and domains used by child accounts.
• The authoritative DNS zone for each required name and the administrator who controls it.
• Existing records at send and both selector names, plus current SPF and DMARC policies.
• Other campaigns and services sharing these names, a controlled external test mailbox, and a rollback plan.

Choose a From domain your organization controls. Ownership of an email address at a consumer provider does not let you publish that provider's DKIM records for Enterprise.

Decide whether the parent account centrally manages authentication or whether child accounts manage their domains. Higher Logic documents both arrangements. When the parent is the default manager, its settings apply across child accounts and only the parent has modification rights. Treat selector collisions as an ownership issue, not permission to overwrite another account's working record. Enterprise domain and child-account requirements

Publish the three documented Enterprise CNAMEs

The following is the vendor's template adapted to the reserved example domain example.com. Replace only the example sending domain with your real domain, and reconcile any different account-specific instructions with Higher Logic before publication.

These are three separate records. Do not paste v=spf1 into the send CNAME or turn a DKIM CNAME into a TXT record containing a copied key. Publish both DKIM selectors, not only the one that appears on today's message. Official DNS templates

Place each owner in the right DNS zone

If your From address is newsletter@news.example.com, the corresponding owners are send.news.example.com, HLMAE1._domainkey.news.example.com and HLMAE2._domainkey.news.example.com. The provider targets remain as documented above unless Support issues different instructions.

For a DNS editor that automatically appends the zone:

For the send alias, use send.news in the parent zone or send in the delegated zone. If the editor accepts fully qualified names, use the full owner once. Verify the final published name to catch doubled suffixes.

Preserve any legitimate NS delegation of _domainkey or another relevant child zone. Publish the record in that zone rather than deleting its delegation to make a parent-zone alias work.

An existing send hostname may serve a website, tracking platform or different sender. A CNAME cannot coexist at the same owner with TXT, A, AAAA, MX or another CNAME. DNS alias rule Do not delete an active record or invent send2 as a workaround; have the DNS owner and Higher Logic agree on a supported arrangement. Do not put these aliases at the zone apex (@).

Higher Logic asks organizations with internal and external DNS to update both views. Public receivers must be able to resolve the public records; an internal-only answer is insufficient. Coordinate any split-DNS changes with the owners rather than replacing the entire zone. Publication and DNS-provider cautions

Preserve literal CNAME answers

If your DNS host offers an HTTP proxy, make these aliases DNS-only. Set per-record Flatten off where available, and ensure zone-wide flatten-all does not suppress the literal CNAME answer used for verification. Cloudflare documents that flattening all CNAMEs can break third-party verification and cannot be overridden per record while that zone-wide setting remains enabled. Cloudflare flattening controls

Do not switch off a shared DNS feature without checking its effect on other records. Ask the DNS owner for the smallest supported change that preserves the required alias. If mandatory apex or same-zone flattening prevents the required literal CNAME, stop and coordinate a supported design with Higher Logic and the DNS host; do not invent an override. Neither blanket proxy changes nor disabling DNS security is a necessary default step in this setup.

Check DNS, then complete Support activation

Replace the example domain before running these read-only checks:

dig +short NS example.com
dig CNAME send.example.com
dig TXT send.example.com
dig CNAME HLMAE1._domainkey.example.com
dig TXT HLMAE1._domainkey.example.com
dig CNAME HLMAE2._domainkey.example.com
dig TXT HLMAE2._domainkey.example.com

The three CNAME answers should match the documented targets. Recursive TXT lookups should follow the aliases and return the relevant provider-published authentication data; the DKIM targets should expose usable public keys. Do not interpret a DNS lookup as proof that mail is being signed.

When answers disagree, compare the correct authoritative nameserver with an independent public recursive resolver. Inspect response status, answer content and TTL. An empty short answer is not enough to distinguish missing data, a timeout or a server failure. A public cache may also retain a previous missing-record response.

Once DNS is correct, use Higher Logic's official Support channel to provide the account and domain setup. The documented procedure requires its team to verify the entries, complete configuration and notify you that the account is ready. Record that confirmation. Do not substitute a guessed Professional TEST button for Enterprise activation. Support completion requirement

Ask Support to clarify the expected envelope/Return-Path for your account as part of this handoff. Share public DNS values and relevant account identifiers, not DNS passwords or private signing keys. If message evidence is needed, use an approved secure channel and the minimum necessary data.

Understand the SPF and Return-Path distinction

Enterprise's documentation contains two relevant descriptions:

1. Its DNS template labels send.<domain> → client.rmsend.com as SPF authentication.
2. Its SPF explanation identifies mmsend.com as the sending envelope domain with SPF already configured. The separate include:mmsend.com suggestion appears under legacy Sender ID.

The public page does not establish that every Enterprise account will use send.<domain> as the actual MAIL FROM after activation. Publish the supported required records, but confirm actual behavior with Support and the trusted receiver. Do not promise aligned SPF merely because the send alias exists. Enterprise SPF and Sender ID sections

SPF evaluates the connecting IP against the SMTP MAIL FROM domain, or the applicable HELO identity for a null reverse path and relevant HELO checks, not the visible From by itself. Adding include:mmsend.com to example.com cannot change an envelope that remains mmsend.com. If the envelope is provider-owned and unrelated to your From domain, SPF may pass without providing the DMARC-aligned SPF path. An intended, aligned customer-domain DKIM signature must still be validated. SPF identity rules

Leave the existing customer SPF policy intact unless a supported requirement identifies an actual change. Preserve Microsoft 365, Google Workspace and every other legitimate sender. At any owner, publish only one SPF policy; unrelated TXT verification records are fine. Evaluate nested include and redirect dependencies within the ten-term DNS-processing limit. Do not flatten provider ranges into static IP lists without a maintained update process. SPF record selection and limits

Preserve the existing qualifier and redirect design. Any all mechanism makes redirect ignored regardless of its qualifier; do not append all to a redirect policy casually. Qualifiers specify SPF results, not guaranteed rejection or delivery. SPF all processing

For the difference between a cryptographic signature pass and brand alignment, see EmailAuth's raw DKIM versus aligned DKIM guide.

Preserve DMARC enforcement and reporting

DMARC compares the visible From domain with a passing SPF identity or a passing DKIM signing domain. Either aligned path can satisfy DMARC. Relaxed alignment uses the applicable organizational domain; strict alignment requires an exact match. A shared corporate owner is not an alignment relationship. DMARC specification

For a hypothetical visible From newsletter@example.com, a passing intended Enterprise signature with d=news.example.com aligns in relaxed mode but not strict mode. A passing intended d=example.com aligns in both. A passing envelope at send.example.com would likewise align with From example.com only in relaxed SPF mode, not aspf=s; this is an illustration, not a claim that Enterprise uses that envelope. Identifier alignment

Inspect the current _dmarc policy and applicable parent policy before making changes. Retain existing p, subdomain treatment, adkim, aspf and reporting destinations. Creating a child policy can override inherited protection, so a new marketing subdomain is not automatically a blank-policy environment.

Only if there is no direct or applicable inherited policy, and the domain owner approves an appropriate monitoring plan, a first-policy example is:

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

For _dmarc.example.com, use relative _dmarc in the example.com zone. For _dmarc.news.example.com, use _dmarc.news in the parent zone or _dmarc in an authoritative delegated news.example.com zone. These mappings do not authorize overriding parent protection. Do not replace a stronger existing policy with this example. It requests no DMARC quarantine or rejection and contains no reporting destination. Authentication and local receiver filtering can still affect delivery.

Add rua only for an approved reporting mailbox or service. For a destination in a different Organizational Domain from the policy domain, the report-generating receiver must check the report-destination operator's DNS authorization before sending. A destination within the same Organizational Domain is excepted; a different hostname alone is not external. Authorization and same-domain exception Obtain approval for the metadata shared, processor access and retention. Preserve existing destinations rather than replacing them with an arbitrary example address, and review message-level failure reports separately for privacy. External reporting authorization

Verify the campaign at a trusted receiver

After Support confirms readiness, send an innocuous authorized campaign through the actual account, sender address and workflow. Use a controlled external recipient where you can inspect full message source and receiving logs.

Record:

Only rely on results from receiving infrastructure you control or trust. A sender can forge Authentication-Results fields and copy a legitimate-looking authserv-id. If your receiver cannot establish provenance and remove or distinguish untrusted fields, use an independent trusted mailbox or message trace. RFC 8601 trust requirements

Completion requires both a passing, aligned intended Enterprise DKIM signature and DMARC pass. A generic DMARC pass supplied by SPF or a different signature does not prove that the branded DKIM configuration works. Inspect the signature for the actual From domain, not just the first dkim=pass line. A rewritten provider-owned From is not successful authentication of the original intended brand.

A provider SPF pass without alignment can be expected for a provider-owned envelope. A raw SPF fail, softfail, temperror or permerror is a separate diagnostic finding, not an acceptable synonym for “unaligned.” Investigate it even if DKIM supplies DMARC pass.

Test every materially different From domain, child account, automation and gateway path. Retest after message-modifying hops, DNS migration or key rotation. Do not assume a signature valid at an intermediate hop survives a later footer or banner modification. These checks establish authentication, not a guarantee of inbox placement.

Troubleshoot by the failing layer

If a new route fails, pause its rollout and send the domain names, public DNS answers, Support readiness reference and restricted receiver evidence to the appropriate administrators. Restore only the deployment's own changes. Do not remove shared selectors, authorize unknown relays or lower domain-wide DMARC as a shortcut.