Source review dated 8 November 2026. This is documentary guidance; account, DNS and received-message acceptance tests below have not been executed.
Identify the product and domain owner
This guide covers the Informz sending route documented as Higher Logic Thrive Marketing Professional. It does not establish the same configuration for other Higher Logic products. Before changing DNS, record the account, intended campaign, visible From address and person responsible for its domain. Higher Logic documents an informz.net envelope identity and a customer-domain DKIM setup. That distinction determines which authentication path can align with your brand. Higher Logic domain authentication.
Prepare a change record containing the current sender configuration, authoritative DNS answers, scheduled sends and rollback owner. Identify all domains used by active campaigns, not just the account's most familiar address. If several teams use the same domain, agree who can change its selectors and who approves wider policy changes. Keep an existing working campaign route available until the replacement passes testing.
Publish the account's DKIM instructions
In the Admin interface, open Settings > Setup > Email Authentication. Enter the domain, choose GET INSTRUCTIONS and give the generated CNAME details to the DNS administrator. Publish both requested aliases, including the secondary record used for key rotation, then return and run TEST. Higher Logic treats its successful authentication test as a required setup step. Parent accounts can centrally manage domain authentication for child accounts; establish that ownership before making changes. Setup and child-account controls.
Use a worksheet with separate columns for full owner name, record type, target and existing data. Confirm whether the DNS editor appends the zone automatically. Avoid a doubled domain and check that an alias does not collide with another integration's record. Copy the account's complete instructions rather than a generic selector example. A successful save in the DNS editor proves only that the editor accepted an entry; query the published answer and retain it with the change.
Understand the SPF boundary
The documentation says informz.net already has SPF authorization. Its separate suggestion to add include:informz.net to the customer's domain concerns legacy Sender ID checks. Adding that include cannot turn an informz.net envelope into your own domain. The retrieved setup does not establish a custom Return-Path option. SPF and Sender ID explanation.
SPF evaluates the SMTP envelope domain, rather than authenticating the visible From address directly. If an actual message has a provider envelope unrelated to the From domain, a passing SPF result is not an aligned SPF result for that From domain. A passing DKIM signature with an appropriately aligned signing domain can instead satisfy DMARC. Check the published alignment mode when deciding whether a subdomain relationship is sufficient. SPF, DKIM and DMARC.
Do not replace an existing SPF policy or add a second SPF record merely to follow a campaign checklist. Inventory legitimate senders first and check DNS-lookup cost if a change is approved. Treat DMARC enforcement separately: strengthening policy affects other mail streams that use the same From domain, including billing and employee mail.
Test the campaign that will actually run
Original acceptance worksheet, not an executed test: send a harmless campaign to controlled external mailboxes. Record the send time, account, workflow, visible From domain, Return-Path, receiver SPF identity and result, every DKIM d= and s= pair, and the receiver's DMARC result. Keep the original message source in a restricted evidence location. Test reply routing as a separate business requirement.
Accept the change only when the intended campaign uses the approved From address, its trusted receiver result shows an aligned passing authentication path, and replies reach the right team. Repeat for materially different domains or account routes. One successful message does not demonstrate every child account or automation is covered.
If the platform test fails, compare full owner names, alias targets, the secondary selector and DNS visibility. If DKIM passes but DMARC fails, compare the signing and From domains before changing policy. Pause the new sender rollout while investigating and restore only the configuration changed in this deployment.
No tenant, live DNS record or received message was tested here. Account-specific instructions, message evidence and human mail-security review remain open before production approval.