Source review dated 8 November 2026. This is documentary guidance; account, DNS and received-message acceptance tests below have not been executed.
Start with the EASE product boundary
L-Soft describes EASE as LISTSERV-powered hosting for newsletters, announcements, discussion groups and email communities on a shared server under a common L-Soft domain. Its product page points to ListPlex for a dedicated virtual LISTSERV instance with a customer's domain. That distinction must be resolved before promising customer-domain authentication on EASE. EASE product description.
Record the actual service, list address, hosting node, list owner and business requirement. Determine whether the organization needs successful delivery from the hosted list identity, an unchanged customer-domain From address, or both. These are different acceptance criteria. Keep existing working settings and identify which configuration belongs to L-Soft's service administrators rather than to the list owner.
Implementation hold: the retrieved EASE product documentation confirms DKIM support but does not provide an EASE-specific customer-domain selector, public-key publication procedure or custom envelope setup. Do not invent those records or present a self-managed LISTSERV procedure as an EASE tenant capability. Obtain written, current instructions for the exact account before making any customer-domain authentication change.
Ask for the identities the service actually uses
EASE's feature checklist advertises DKIM support and DMARC-compatible discussion lists, including private replies. These statements establish product capabilities at a general level; they do not prove which signing domain a particular list uses or whether it aligns with a customer's chosen From address. EASE deliverability and security features.
Prepare a focused support worksheet: identify the list and intended From domain; ask which envelope domain and DKIM d= domain the service will use; request the exact selector and public DNS instructions if customer-domain signing is supported; establish who activates and rotates the key; and ask how announcements, discussion posts, digests and administrative messages differ. Include the desired reply behavior. Do not transmit private keys or subscriber lists to obtain this clarification.
A supported answer may require no customer DNS change, or it may establish an account-specific procedure. If the current service cannot satisfy the required customer identity, assess an appropriate supported service with the owner rather than weakening the customer's domain policy. Treat any service migration, purchase or domain delegation as a separate decision.
Understand list redistribution and From rewriting
LISTSERV documentation explains that distributing a member's message can trigger DMARC problems when the member's original From domain is retained. L-Soft describes rewriting From addresses for domains with restrictive policies and forwarding replies through generated dmarc-request addresses. This is software behavior relevant to the investigation, not evidence that every EASE list has a particular configuration. L-Soft explanation of rewritten list addresses.
Compare both the original submitted message and the delivered list copy. A DMARC pass for a rewritten hosted-domain From address does not demonstrate that an unchanged customer-domain From address authenticated successfully. Likewise, a broken original DKIM signature can coexist with a valid signature applied after list processing. Inspect all signatures and determine which one actually supplies an aligned path.
Do not disable rewriting merely to preserve familiar branding. Confirm the account's supported behavior and test the precise alternative first. The provider's discussion of server-level controls does not establish that an EASE list owner can or should change them. Include private replies in testing because their forwarding path can differ from the initial distribution to subscribers. L-Soft explains that mail to a dmarc-request address is forwarded without From rewriting and may fail SPF when forwarded. Diagnose that reply path separately rather than treating successful list distribution as proof that private replies work.
Keep DNS permissions tied to the measured route
SPF authenticates the SMTP envelope domain, and DKIM signs using its d= domain. DMARC relates successful authentication to the delivered message's visible From domain. It needs at least one aligned passing SPF or DKIM path. If the envelope and signature are both under provider domains while From remains a customer domain, their authentication passes alone do not establish customer-domain alignment. SPF, DKIM and DMARC.
L-Soft also publishes setup instructions for administrators operating a LISTSERV site. Those instructions explain the software and DNS roles, but their example selectors, IP addresses and server configuration are not EASE account values. Use them only to understand the questions, not to populate production DNS. LISTSERV site authentication guide.
If L-Soft supplies a supported customer-domain procedure, preserve the prior records, review existing senders and publish only the approved changes. Keep one SPF policy at each applicable owner name and check lookup limits. Confirm the authoritative zone and retain the provider's activation acknowledgement. Do not add an assumed L-Soft include or alter domain-wide DMARC merely because a third-party guide proposes it.
Define the original evidence gate
Original acceptance worksheet, not an executed test: create a controlled list or approved test audience, submit harmless content and preserve both the submitted and received message sources. Build a received-message identity table for each relevant announcement, discussion, digest or administrative route. Include the list and node, time, original and delivered From domains, Return-Path, receiver SPF identity and result, every DKIM d= and s= pair, and the trusted receiver's DMARC result. Test private replies separately.
Accept only the explicitly agreed identity outcome. Document any rewriting, content modification and provider-owned authentication path. If the test fails, preserve bounce details, pause the affected rollout and seek account-specific diagnosis instead of removing protective policy or server safeguards. Restore only changes made under the approved recovery plan.
No EASE account, live DNS record or received list message was tested here. The original evidence gate is unmet, and customer-domain implementation remains on hold pending provider-confirmed tenant instructions and original message evidence. Independent technical review and human SME approval remain required before publication or production approval.