For Encompass, formerly iModules and Anthology Encompass, request DKIM configuration from Encompass support for the domain used in your visible From address. Support generates the DNS values; your domain administrator publishes them; then you return to support for domain verification and completion. Do not invent a universal SPF include or DKIM selector. Verify a new message from each covered workflow for the intended aligned DKIM signature and dmarc=pass. Encompass authentication workflow.
Encompass is now an Encoura product. Encoura's February 2026 acquisition announcement includes Encompass and continuity of service and support. Its current product page includes bulk email campaigns. That continuity does not make every Encoura or Anthology product share one email configuration. Acquisition announcement, Encompass by Encoura.
No support request, customer account, DNS change or delivery test was performed for this guide.
On this page: Scope · Prerequisites · Setup · SPF · DNS checks · DMARC · Acceptance · Troubleshooting · FAQs
Identify the Encompass message class
This guide covers the support-assisted authentication process for Encompass Email Marketing, with separate verification of community-content and operational messages where the institution uses them. It does not assume a campaign-domain setup covers all mail generated by a university, association, community site or giving form.
Encompass's separate SPF/DKIM article describes white labeling for Email Marketing without community content, with different subdomains for tracking and Return-Path. It discusses a private-IP option or working with a representative. The more recent authentication article describes support-generated DKIM without telling readers to purchase an IP first. Treat these as distinct documented descriptions, not evidence that every account needs a dedicated IP or that every route has the same branding. White-label scope, support-assisted setup.
Make a route worksheet before requesting changes:
| Message class | Record before configuration | Acceptance boundary |
|---|---|---|
| Email Marketing without community content | Campaign, From domain, account/site and current signing identity | Confirm the requested DKIM or white-label route applies |
| Email Marketing with community content | Content type and actual envelope/signing identities | Do not assume the documented white-label option covers it |
| Departmental or chapter sender | Each distinct From subdomain and its owner | Obtain confirmation and records for that domain |
| Community or operational notification | The exact generating workflow and visible sender | Ask support which authentication route covers it; do not infer from a campaign test |
If support cannot establish a route's supported signing identity, hold that route's branded launch. Keep a separately approved, working channel available. No DNS adjustment can make an unsupported sending identity become supported.
Prepare a domain-specific support request
Coordinate the Encompass administrator, institutional mail/security owner and DNS administrator. Give support the account/site identifier, intended From domains, message classes and DNS contact through the institution's normal support channel. No student, donor or alumni personal records are needed to describe the configuration.
Ask support to supply or confirm:
- The exact supported From domain and intended DKIM signing domain for each route.
- Each full DNS owner, record type and complete public value or CNAME target, including every required selector.
- Whether a custom envelope/Return-Path is supported for that route, who operates its DNS and what SPF authorization applies.
- Separate tracking records, if any, so they are not confused with authentication.
- Any additional records for departmental subdomains, current entitlement requirements and the activation sequence.
- How verification is completed, whether existing selectors must remain, and the approved rotation and rollback process.
The documented workflow specifically warns that subdomain senders can need additional records. Treat a root-domain request as incomplete if the real From address uses a department's subdomain. Domain and subdomain requirements.
Save existing DNS answers and TTLs before editing. Confirm who owns the parent zone and whether alumni.example.com or its _domainkey namespace is delegated elsewhere. Website administration or registrar access alone may not grant control of the active DNS authority.
Complete the support-assisted DKIM workflow
- Request configuration for the actual From domain. List each required message class rather than asking to authenticate the institution's brand in general.
- Receive the current provider-issued values. Match them to the correct site and domain. Separate signing, envelope, tracking and ownership-verification records.
- Publish the approved records in authoritative DNS. Preserve the supplied types and full owners. Do not infer CNAME versus TXT, selector names or targets from an unrelated tenant.
- Return to Encompass support. Request its domain verification and completion step after public DNS resolves correctly. Keep the completion confirmation with the final record set.
These are the four documented stages. DNS publication alone is not the final stage. Official Encompass procedure.
A DKIM lookup uses SELECTOR._domainkey.SIGNING_DOMAIN; later, a received signature must supply the matching s= and d=. Publish only public records. Never publish a private key or generate a substitute key that Encompass does not use. If support supplies TXT, preserve the whole public value. Multiple quoted strings may form one TXT record and are concatenated; they are not multiple separate keys. DKIM DNS binding.
If support supplies CNAME, preserve the alias and exact destination. Do not place key text inside a CNAME, use a URL with https://, or create TXT alongside an existing CNAME at the same owner. A conflicting selector needs a supported resolution, not deletion of another sender's key. See avoiding DKIM selector collisions.
Why white labeling is not a universal alignment switch
The white-label documentation separates a tracking subdomain from a Return-Path subdomain and excludes community-content messages from that white-label option. A branded link proves nothing about the DKIM signing domain. Equally, a changed Sender header does not make DMARC pass: DMARC compares the visible From domain with the authenticated SPF or DKIM domain. Encompass white-label limitations, DMARC identifier alignment.
Do not purchase a private IP simply because an older article mentions one. Ask the representative which current option meets the required message-class and domain scope. A provider-domain DKIM signature can be valid but unaligned with your institution's From domain.
Configure SPF only for the confirmed envelope route
SPF checks the SMTP MAIL FROM domain, usually represented by Return-Path after delivery. Confirm the receiver's smtp.mailfrom identity for each message class. The visible From, Reply-To and tracking hostname are different identities. An SPF change at example.com does not repair mail whose envelope is under a provider-owned domain, nor does it apply automatically to bounce.alumni.example.com. RFC 7208 identity rules.
This guide deliberately supplies no universal Encompass SPF include. Use support's current instructions for the actual envelope route. If it provides a customer-owned SPF TXT policy, merge only the necessary authorization into the existing single policy at that owner, before its terminal all, preserving legitimate senders and the approved qualifier. Evaluate a redirect= policy separately. If support delegates a bounce owner with CNAME, do not add SPF TXT at that same owner. If the envelope remains provider-controlled, its operator maintains that domain's SPF.
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.
An SPF policy can evaluate at most 10 DNS-lookup-causing terms across nested processing: include, a, mx, ptr, exists and redirect. ip4, ip6 and all do not consume this term budget. Additional mx/ptr address-query bounds and the recommended limit of two void lookups also matter. Ten top-level includes is not a safe interpretation. Check the merged policy rather than copying a provider's current IP answers into an unmanaged flattened record. RFC 7208 section 4.6.4, safe SPF merging.
Verify the records at the right DNS authority
For a fictional issued owner assigned._domainkey.alumni.example.com, an editor serving example.com normally needs assigned._domainkey.alumni. An editor serving a separately delegated alumni.example.com normally needs assigned._domainkey. Some editors accept a full name; inspect the result so the domain suffix is not appended twice. An empty NS answer for the child name alone does not prove a failure: establish the closest enclosing zone using SOA and delegation evidence.
If _domainkey.alumni.example.com is itself delegated, publish the same illustrative assigned._domainkey.alumni.example.com owner as relative assigned in that zone. Preserve that NS delegation; a parent-zone duplicate beneath it is not authoritative.
The following reader-run commands contain placeholders. Replace every value with the real support-issued owner and observed envelope identity; do not publish these examples.
ZONE='example.com'
AUTH_NS='ns1.dns-host.example'
DKIM_OWNER='ISSUED_SELECTOR._domainkey.alumni.example.com'
MAIL_FROM_DOMAIN='CONFIRMED_ENVELOPE_DOMAIN'
FROM_DOMAIN='alumni.example.com'
dig +short NS "$ZONE"
dig @"$AUTH_NS" "$DKIM_OWNER" CNAME +norecurse
dig @"$AUTH_NS" "$DKIM_OWNER" TXT +norecurse
dig "$DKIM_OWNER" CNAME
dig "$DKIM_OWNER" TXT
dig "$MAIL_FROM_DOMAIN" TXT
dig "_dmarc.$FROM_DOMAIN" TXT
Use the authoritative zone appropriate to each owner; the envelope may be managed by a different organization. For a CNAME-based key, expect the exact issued alias and a usable public key after following it. For a TXT-based key, expect the issued public key directly; an empty CNAME answer is then normal. Verify every issued selector, not only a scanner's guessed selector list.
Compare authoritative and recursive responses after applicable positive and negative caches expire. Read full DNS output: NXDOMAIN, no data for one type, and SERVFAIL are different findings. Investigate delegation and DNSSEC where appropriate. For issued CNAMEs, use DNS-only records with each record's Flatten off, and verify that zone-wide settings do not flatten these names. Coordinate any shared or zone-wide change with the DNS owner after reviewing its impact on other services. Preserve legitimate child-zone and _domainkey NS delegation; publish at the delegated authority rather than deleting delegation to make a parent-zone copy work. CNAME verification and delegation safeguards.
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.
Return the confirmed public answers to support for verification. Its completion message proves the provider-side step was accepted; it does not prove a delivered message aligned.
Keep institutional DMARC policy intact
DMARC needs an authenticated identifier aligned with visible From: a passing aligned SPF result or passing aligned DKIM signature suffices at message level. Relaxed alignment uses the applicable organizational domain; strict alignment requires an exact match. Check aspf and adkim, which default to relaxed. A departmental From and root-domain d= may align under relaxed mode but not strict mode. RFC 9989.
Keep established quarantine or reject policies and authorized reporting destinations. Check both a direct _dmarc record and applicable inherited policy. The current standard uses DNS-tree-walk discovery and replaces RFC 7489; it removes pct, so do not promise percentage-based rollout using old examples. Creating a child p=none can weaken an inherited policy even when that child had no record. See subdomain policy inheritance.
Only after confirming no direct or inherited policy applies, an authorized domain owner may approve this first monitoring-policy shape. It is fictional, not a blanket instruction to reset an existing policy:
Type: TXT
Full owner: _dmarc.alumni.example.com
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Provision the actual reporting destination and assign someone to review it. p=none requests no DMARC-based handling change; it cannot guarantee delivery. If reports go to an external service, obtain its authorization record instructions. The report consumer normally publishes a TXT authorization at POLICY_DOMAIN._report._dmarc.REPORT_DESTINATION_DOMAIN under the reporting destination's authority. Do not invent that record in the school's zone. Approve the disclosure of traffic and infrastructure data, recipient, retention and access. RFC 9990 external reporting.
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.
For the approved first policy at From example.com, full TXT owner _dmarc.example.com maps to _dmarc in that zone. For From alumni.example.com, full owner _dmarc.alumni.example.com maps to _dmarc.alumni in the parent example.com zone or _dmarc in a separately delegated alumni.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.
Before raising enforcement, inventory all legitimate senders and indirect routes, especially alumni forwarders and mailing lists. RFC 9989 section 7.4 requires domains publishing p=reject to apply valid DKIM signatures and not rely solely on SPF. For this configuration, require the intended branded DKIM pass and alignment, not just an SPF-supplied DMARC pass. Interoperability considerations.
Test campaigns and community content separately
After support completes activation, an authorized administrator should send synthetic messages to controlled recipients through the real workflow. Do not use a donor campaign or community-wide announcement as a test. Include a normal Email Marketing message, a departmental From domain if used, a community-content message, and any operational route support says is covered. Test direct delivery first, then an approved forwarding path separately.
Retain each route's UTC send time, From domain, Return-Path and DKIM d=/s=. Use receiver-controlled diagnostics, or have the receiving administrator establish which Authentication-Results fields actually came from its trusted infrastructure. Confirm how its boundary strips or clearly distinguishes external results, including sender-inserted fields that forge the receiver's own authserv-id. A familiar identifier or header position alone cannot establish provenance. Do not use a copied header inside forwarded content or an arbitrary passing signature as evidence. If the boundary cannot be established, obtain receiver-side diagnostics before acceptance. RFC 8601 forged-header safeguards.
The acceptance record should answer:
| Check | Required observation |
|---|---|
| Provider completion | Support confirms the intended site, domains and message-class coverage |
| DNS | All issued owners/types/values resolve from the correct authority |
| Intended DKIM | Receiver reports dkim=pass for the configured signing domain and selector, aligned under actual policy |
| DMARC | Receiver reports dmarc=pass for the expected visible From domain |
| SPF | Actual envelope identity, result and alignment are recorded; errors are resolved or explicitly investigated |
| Route coverage | Campaign, community, department and operational paths are not substituted for one another |
One aligned mechanism is sufficient for the protocol's DMARC pass, but SPF-only success does not complete this custom-DKIM deployment. A provider-domain DKIM pass is also insufficient when the objective was institutional signing. Investigate actual SPF fail, softfail, permerror or temperror separately even if aligned DKIM produces dmarc=pass; DMARC success does not clear an SPF fault. Review aggregate reporting after it arrives to look beyond a few samples. Use redacted diagnostic evidence through approved support channels, not public uploads containing donor or student data.
Troubleshooting and recovery
| Finding | Likely question | Next action |
|---|---|---|
| Public DNS is correct but no intended signature appears | Was support's completion step finished for this route? | Confirm activation and send a new message, not an old queued sample |
| Campaign works but community content fails | Is this excluded from the white-label route or using another identity? | Hold that class and ask support for its supported configuration |
| Root sender works but a department fails | Were the actual subdomain and its DNS authority included? | Obtain and validate any additional issued records |
dkim=pass but dmarc=fail |
Does d= align, and does SPF offer another aligned pass? |
Correct the supported domain configuration; Sender/Reply-To edits cannot repair alignment |
| DKIM body hash fails | Was signed content modified by a gateway or indirect route? | Compare direct delivery with the changed route before replacing keys |
SPF permerror |
Duplicate SPF, bad syntax, include/redirect loop, missing included policy or excess lookup terms? | Repair the evaluated policy at the actual envelope owner |
SPF temperror |
Temporary resolution failure, timeout, authority or DNSSEC problem? | Diagnose DNS reliability and retest |
SPF fail/softfail or none |
Wrong envelope owner, absent policy or missing valid sender? | Confirm support's intended route before authorizing any source |
If recovery is needed, pause only the affected sending route. Restore its approved previous records or sender configuration in coordination with support. Retain valid old selectors until queued-message verification and other dependencies are considered. Do not weaken institutional DMARC, delete unrelated authorizations or disable filtering to conceal a route gap. Repeat acceptance after sender-domain changes, key rotation, DNS migrations and changes in message class. Authentication does not guarantee inbox placement or meet every bulk-sender requirement by itself.