Informz SPF, DKIM and DMARC setup, step by step

To authenticate Informz campaign email, open Admin > Settings > Setup > Email Authentication in Higher Logic Thrive Marketing Professional, request the instructions for each sending domain, publish both generated DKIM CNAME records, and run TEST. The documented SMTP envelope uses informz.net, where Higher Logic manages SPF. Adding an SPF include to your visible From domain does not make that provider envelope align with your brand. Higher Logic's Professional authentication procedure

This guide is based on public documentation. No customer account, customer DNS configuration or delivered campaign was tested.

Confirm that you use Professional, not Enterprise

Informz is the former name of Thrive Marketing Professional. This guide covers that product's campaign-sending authentication. Thrive Marketing Enterprise, formerly Real Magnet, has different DNS instructions and a Support-completed activation process. Do not use Enterprise's rmsend.com records for an Informz account. Higher Logic community or Vanilla notifications also need their own product-specific instructions. Professional product identity

For Professional, keep these three identities separate:

A provider-owned envelope can pass SPF while failing SPF alignment with your From domain. An aligned, passing customer-domain DKIM signature can provide the DMARC passing path instead. SPF authorization, alignment and inbox placement are different outcomes. SPF identity rules · DMARC identifier alignment

Before changing DNS

Have the campaign administrator and DNS owner collect:

• The Professional account and every From domain used by campaigns, scheduled mail and child accounts.
• Authorized access to the account's authentication settings and to the DNS zone that actually hosts each record.
• The current SPF, DKIM and DMARC records, including inherited subdomain policy and other services using the same DNS names.
• The generated record set, the person approving publication, a controlled external test mailbox, and a rollback owner.
• A working campaign route to retain until the replacement passes all checks.

Use a domain your organization controls. A personal Gmail or Yahoo address is not a domain whose DKIM records you can authorize for Higher Logic. A dedicated marketing subdomain can make ownership clearer, but it does not automatically isolate reputation or escape the parent domain's DMARC policy.

Agree on parent-versus-child administration before generating changes. Professional supports central management by the parent or management within child accounts. When the parent is the default manager, its authentication settings apply across child accounts and only the parent has modification rights. Central settings do not remove the need to test each materially different sending route. Account ownership and domain requirements

Generate and publish the Professional DKIM records

1. Obtain the domain's current instructions

In the Admin interface, go to Settings > Setup > Email Authentication. Enter the exact sending domain and select GET INSTRUCTIONS. Save the displayed record names and targets, then repeat for other From domains.

Use the account-generated values. The provider's troubleshooting examples, such as s01a and s01b, are illustrations, not a promise that every account uses those selectors. Do not create a key in a third-party DKIM generator or substitute Enterprise selectors.

2. Publish both CNAMEs

Create a worksheet before saving anything:

Publishing only the currently active selector creates a failure waiting for a rotation. Preserve both aliases, and do not replace their targets with a copied TXT key. The CNAME allows the provider to manage the corresponding public key. Professional setup and rotation record

Check how your DNS editor handles owner names. For the illustrative full owner selector._domainkey.news.example.com:

• In the example.com zone, an editor that appends the zone needs selector._domainkey.news.
• In a separately delegated news.example.com zone, it needs selector._domainkey.
• An editor accepting full names needs the full owner, without appending the domain again.

These are name-placement examples, not selectors to publish. Find the authoritative zone rather than assuming the registrar or parent zone is the right place. If _domainkey or another relevant subdomain is already delegated with NS records, preserve that delegation and publish in its authoritative child zone. Do not delete the NS records to make the parent zone accept an alias. A CNAME owner must not collide with another service's TXT or CNAME record. Stop and resolve ownership with the administrators if it does.

If _domainkey.news.example.com itself is delegated, the illustrative owner selector._domainkey.news.example.com is relative selector in that delegated zone. Preserve its NS records and publish with that authority, not below the delegation in the parent zone.

If your DNS host offers proxying, use DNS-only for these aliases. If it offers CNAME flattening, ensure public queries still return the literal CNAME required by the provider. Set per-record Flatten off where available, and check that zone-wide flatten-all does not suppress these aliases. Check both per-record and zone-wide controls. For example, Cloudflare's zone-wide flatten-all setting cannot be overridden by its per-record toggle. Do not disable a zone-wide feature blindly: first assess other records that depend on it and obtain an appropriate narrow solution. Do not put a DKIM alias at the zone apex (@). Cloudflare's flattening behavior

Keep the required literal authentication CNAME answer visible, not just DNS-only. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of the setting; whole-zone flatten-all cannot be overridden per record. If mandatory behavior or shared configuration cannot preserve the required alias, stop and agree a supported arrangement with the DNS administrator instead of removing NS delegation or blindly disabling shared features. Cloudflare flattening limits.

3. Run the in-product test

After DNS publication, return to the same Professional authentication page and select TEST. A successful DNS save does not complete this step. Higher Logic explicitly requires a successful authentication test. Retest if you correct the owner, target or rotation alias. Required activation check

Keep the generated instructions and successful test timestamp with the change record. Do not remove another sender's selectors or alter unrelated account authentication while diagnosing this domain.

What should you do with SPF?

Higher Logic describes informz.net as Professional's envelope domain with SPF already configured. Its suggestion to add include:informz.net to a customer domain appears under the separate, obsolete Sender ID mechanism. It is not evidence of a custom Return-Path feature, and it does not prove aligned SPF for your From address. Provider SPF and Sender ID explanation

Therefore, do not replace your domain's existing SPF policy with an Informz-only record. Do not add a second v=spf1 record. If an account-specific requirement calls for an SPF change, have the mail administrator reconcile it with every legitimate sender at the actual envelope-domain owner.

Evaluate the complete SPF dependency path, including nested include and redirect processing. The limit is ten evaluated DNS-lookup-causing terms, not ten visible includes or ten DNS packets. Unrelated TXT verification records may coexist with one SPF policy. Multiple quoted strings within that one TXT record are also different from multiple SPF records. SPF publication and processing limits

If an existing SPF policy uses redirect=, preserve its intended authorizations and final semantics through a reviewed merge. Any all mechanism causes redirect to be ignored, so appending a canned policy or an all without reviewing that dependency can change which senders are authorized. SPF redirect semantics.

For a worked explanation of why the From domain is often the wrong DNS name to edit, see EmailAuth's SPF guide to the SMTP envelope identity.

Keep DMARC policy and reporting under domain-owner control

DMARC passes when at least one authentication path both passes and aligns with the visible From domain. Relaxed alignment uses the applicable organizational-domain relationship; strict adkim=s or aspf=s requires exact domain equality for that path. Two domains owned by the same company do not automatically align. DMARC standard

Before publishing anything at _dmarc, inspect the existing policy and applicable parent policy. Preserve enforcement, alignment settings, reporting destinations and subdomain treatment. Do not replace an established p=reject or inherited policy with a generic p=none example to make this campaign work.

For a genuinely new domain with no applicable policy, an administrator may approve a monitoring-only starting record:

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

This is an illustration, not a default change for an existing domain. p=none does not request rejection or quarantine on DMARC failure and does not request aggregate reports without a rua destination. It also does not guarantee delivery.

For the approved first policy at From example.com, full TXT owner _dmarc.example.com maps to _dmarc in that zone. For From news.example.com, full owner _dmarc.news.example.com maps to _dmarc.news in the parent example.com zone or _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve any existing direct or inherited policy; this mapping does not authorize a child monitoring override.

Add reporting only to an approved, controlled destination. If the reporting destination's organizational domain differs from the Organizational Domain of the domain where the policy is discovered, the report receiver must publish the appropriate external-destination authorization. Approve privacy, access and retention before sending authentication metadata to an outside processor. Do not copy an example reporting address or enable message-level failure reports without a separate privacy review. Aggregate-report authorization and privacy

Compare the Organizational Domain of the aggregate-report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted, even when its hostname differs. This protocol check does not replace the domain owner’s separate approval to share report data with that recipient. RFC 9990 section 4.

Verify public DNS and a delivered campaign

Public DNS checks

Substitute your real names in these illustrative, read-only commands. selector-from-account is a placeholder, not a Higher Logic selector.

dig +short NS example.com
dig CNAME selector-from-account._domainkey.example.com
dig TXT selector-from-account._domainkey.example.com
dig TXT _dmarc.example.com

Repeat for the second generated alias and the actual delegated zone, if any. Check the authoritative server and an independent recursive resolver when results disagree. The CNAME answer should match the generated target; the DKIM lookup should resolve to a usable public key. Examine full output and response status: empty +short output alone does not distinguish a missing record from a timeout or DNS error. Respect positive and negative cache lifetimes instead of assuming a fixed propagation deadline.

Delivered-message checks

Send a harmless, authorized campaign through the real Professional workflow to a controlled external mailbox. Open its original message source, not a forwarded screenshot. Record the account, campaign, time, From domain, Return-Path, receiving connection IP, SPF identity/result, every DKIM d= and s=, and DMARC result.

Trust only authentication results produced by receiving infrastructure you control or trust. An attacker can prepend Authentication-Results, even with a plausible authserv-id. If the receiving service cannot distinguish or remove untrusted fields, use an independent trusted mailbox or receiver trace. Authentication-results trust boundary

Accept the new configuration only when:

1. The intended Professional DKIM signature passes and its d= aligns with the actual From domain under the applicable policy.
2. The trusted receiver reports DMARC pass. A generic pass through some other signature or SPF alone does not prove the branded DKIM setup works.
3. SPF's actual result is understood. A passing, unaligned informz.net identity is different from fail, temperror or permerror; those errors still need investigation.
4. Replies reach the intended team, and representative child-account, automation and other From-domain routes also pass their relevant checks.

Repeat after DNS migration, selector rotation, account changes or a content-modifying gateway change. A signature that passed before a later footer or security rewrite may not pass at the final recipient. Authentication success does not guarantee inbox placement.

Troubleshooting

Pause the new campaign route if acceptance fails. Restore only the changes made in this deployment, with the recorded owner. Do not delete shared DKIM records or weaken domain-wide DMARC to hide one sender's fault.