Source review dated 8 November 2026. This is documentary guidance; account, DNS and received-message acceptance tests below have not been executed.
Define the Encompass messages you need to authenticate
A university or association may use Encompass for campaigns, community communications and operational notifications. Start with a list of those message classes, the visible From domain for each, and the team that owns the sending workflow. Keep the root institutional domain separate from departmental subdomains on the worksheet. A successful campaign test should not silently stand in for an untested community message.
This guide covers iModules Encompass as documented in Anthology's Encompass help. It does not provide universal selectors or a generic SPF include to copy. The published setup process is support-assisted, and exact DNS values must be generated for the requested domain. Treat instructions for another Anthology product as a different integration until its applicability is confirmed.
Complete the support-assisted configuration
Encompass's authentication guidance describes four stages: request DKIM configuration for the domain used in From, receive DNS values from support, have the domain manager publish them, and follow up with support for verification and completion. It notes that sending from a subdomain can require additional records. Encompass authentication setup
Prepare the request with the intended From domains, account or site identifier, affected message classes and DNS contact. Ask support to state which routes the supplied values cover and whether existing signing records should remain during transition. This is a preparation checklist, not a claim that a support request has been sent or accepted.
Before publication, classify each supplied record by purpose: signing, envelope-sender authorization, tracking or ownership verification. Record the full DNS owner, type and target or value. Check whether the DNS interface appends the zone automatically and inspect any existing data at a proposed CNAME owner. Publish only the approved set, preserve other legitimate senders, and retain the prior answers for recovery. If SPF changes are required, reconcile one policy per owner and evaluate the complete lookup budget rather than adding a second policy. SPF record and lookup rules
After the records resolve, return to Encompass support for its completion step. DNS publication and provider activation are different checkpoints. Preserve the support confirmation with the final records and the actual From domains used in the acceptance tests.
Do not confuse white labeling with universal alignment
The provider's separate SPF and DKIM article describes a private-IP or representative-assisted white-labeling route for matching signing and From identities. It restricts white labeling to Email Marketing messages without community content and describes separate subdomains for tracking and Return-Path. Encompass white-label scope
These details are not a reason to buy a private IP or assume a particular feature is enabled. Ask support how the current DKIM setup applies to your account and to community-content messages. If the two documented descriptions leave a route uncertain, hold that route's launch until the provider answers. Do not substitute a tracking hostname for the envelope domain merely because both are branded.
Likewise, changing a Sender header does not establish DMARC alignment. The relevant comparison is the visible From domain against a passing SPF identity or DKIM signing domain under the applicable alignment mode. A service-domain signature can validate cryptographically while failing that comparison for the institution's From domain. DMARC alignment requirements
Accept message classes individually and keep recovery narrow
Original acceptance plan: use controlled recipients and synthetic content to test a normal Email Marketing message, a departmental sender if used, and a community-content message if that workflow is in scope. For each, save the trusted receiver-added authentication results, From, envelope sender, DKIM d= and selector, and the originating workflow. Record both authentication and alignment, rather than a single green delivery result.
Illustrative failure: the main campaign aligns, but a community message does not. That is evidence to compare message-class coverage with support, not permission to weaken the institution's DMARC policy. Confirm whether the message uses an alternate route or identity before changing DNS. Keep any unaffected approved workflow available while holding the failed route.
When rollback is needed, pause the affected send, restore only the relevant approved DNS or sender configuration, and coordinate provider activation changes with support. Keep old valid selectors until queued mail and other dependencies are considered. Repeat acceptance after a From-domain, DNS-host or message-template route change. Authentication supports trust decisions but does not guarantee inbox placement or satisfy every bulk-sender requirement on its own.
Documentation reviewed on 8 November 2026. No Encompass account, support case, DNS zone or real campaign was tested. The acceptance plan and failure example are original guidance. Tenant-specific records, provider activation, receiver evidence and human approval remain open gates.