LSoft LISTSERV SPF, DKIM and DMARC setup, step by step

For self-managed LISTSERV Classic or HPO, SPF authorizes the actual Internet-facing SMTP sender, while DKIM requires a locally generated RSA key, a public selector TXT record, a LISTSERV .dkim file, and the site variables DKIM_SIGN and DKIM_SIGN_ALL=1. LISTSERV loads signing keys at startup. Publishing DNS alone does not enable ordinary list-mail signing.

This guide covers LISTSERV 17.5 software administered on your own server. The current download page identifies release 17.5-2026a. It does not cover LISTSERV Lite, LISTSERV Maestro, or the EASE and ListPlex hosted services. The 17.5 DKIM manual limits this feature to Classic/HPO and excludes z/VM.

The clearest custom-domain use case is an organization-controlled announcement or newsletter From address. Discussion lists distributing other people's From domains need additional identity and rewriting checks; a key for your list domain cannot authenticate every member's original address.

The manual's 2010–2025 copyright range is not an article-update date. No keys were generated, server configuration changed, DNS edited or messages sent while preparing this guide.

On this page

• Confirm product, access and sending identities
• Authorize the real outbound MTA with SPF
• Generate a compatible DKIM key pair
• Publish the public selector record
• Configure LISTSERV signing
• Load the key and check every sending path
• Handle discussion-list rewriting and DMARC
• Verify DNS and delivered messages
• Troubleshoot LISTSERV authentication
• Frequently asked questions

Confirm product, access and sending identities

You need a LISTSERV server administrator, an authorized DNS administrator and access to the configuration of the SMTP system that actually delivers the mail. Being a list owner is not enough to manage site-wide signing keys and variables. Arrange any restart through the server's change process.

Keep these products separate:

• Self-managed LISTSERV Classic/HPO: this guide's local key files, site configuration and restart procedure.
• EASE: shared hosting on a common L-Soft domain. Its product description does not grant customers access to local signing files.
• ListPlex: hosted LISTSERV under a customer domain, described on the ListPlex product page. A custom hostname is not proof that customers use this self-managed key workflow.
• LISTSERV Maestro and Lite: different product or feature boundaries, not interchangeable labels for this setup.

Before editing, record the intended visible From domain, actual SMTP MAIL FROM domain, public outbound IP or relay service, intended DKIM signing domain, selector and authoritative DNS zone. These identities can differ. The server's NODE hostname is not automatically the correct answer for all of them.

Back up the existing LISTSERV configuration and DNS records securely. Inventory active keys and selectors. A new installation and a rotation of an already-working signer are different changes; do not overwrite an active private key or delete its public record just to follow an example.

Authorize the real outbound MTA with SPF

LISTSERV prepares and signs messages, but an SMTP MTA or relay may deliver them to the Internet. SPF must authorize that externally visible sender, not necessarily the LISTSERV machine's local IP address. L-Soft's SPF/DKIM/DMARC technical tip explicitly warns that the IP prefilled in Deliverability Assessment is often wrong for an SPF check.

SPF evaluates the SMTP MAIL FROM identity, not automatically the visible From. Inspect the actual route and envelope before deciding which DNS owner to edit. For example, an SPF record on example.com is not automatically used when the envelope domain is listserv.example.com.

Choose the correct authorization model

• For a directly operated outbound MTA, authorize its real public IPv4 and, where used, IPv6 sending addresses with ip4 and ip6 mechanisms.
• For an organizational relay, use its approved SPF authorization or an appropriate existing organizational SPF policy, as L-Soft's technical tip describes. Do not assume every address in the company's incoming MX set sends LISTSERV traffic.
• For a third-party SMTP relay, use that relay's documented sending-domain procedure. There is no universal L-Soft SPF include for all self-managed installations.

This structural example is not publishable until the placeholders and policy assumptions are resolved:

Type: TXT
Owner: <ACTUAL-MAIL-FROM-DOMAIN>
Value: v=spf1 ip4:<ACTUAL-PUBLIC-OUTBOUND-IPV4> -all

It assumes a new policy with only that authorized source and an owner-approved -all. Real deployments may require several addresses or relay authorizations. Do not use the technical tip's demonstration IPs, a private address such as the assessment screenshot's 192.168.6.27, or the placeholder above.

If an SPF record already exists, merge the necessary authorization into the one existing v=spf1 TXT policy at that owner, retaining other legitimate sources and the approved qualifier. Do not add a duplicate policy or overwrite it with a LISTSERV-only example.

SPF permits at most 10 evaluated DNS-dependent terms, including nested includes and redirects. Direct IP mechanisms do not consume that term budget, but a relay include can introduce additional evaluated terms. An all mechanism also causes redirect= to be ignored, regardless of their textual order. Review any existing redirect policy before altering it. These are RFC 7208 rules, not LISTSERV-specific exceptions.

The -all qualifier yields SPF fail when no earlier mechanism matches; it does not guarantee rejection by every recipient. Do not tighten or weaken it merely to obtain a green check.

Generate a compatible DKIM key pair

For this self-managed route, you generate and control the key pair. L-Soft does not issue a universal customer public key. Use an authorized local environment and approved key custody, not an online key-generation website.

Choose an owned signing domain and an unused selector. The examples below use signing domain listserv.example.com, selector ls2026, and local temporary filenames rsa.private and rsa.public. Substitute your own choices consistently. Before running commands, use a new protected working location and confirm those filenames will not overwrite existing keys.

Select the command for the actual OpenSSL version

First check the installed version:

openssl version

The LISTSERV 17.5 key-generation instructions distinguish the following formats. Run only the matching branch. These examples use 2048 bits rather than the manual's illustrative 1024, following RFC 8301's recommendation.

For OpenSSL 3.x:

openssl genrsa -out rsa.private -traditional 2048
openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM

For an existing OpenSSL 1.x environment:

openssl genrsa -out rsa.private 2048
openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM

The second branch documents compatibility, not a recommendation to install an old OpenSSL version. Have the server administrator use a supported cryptographic environment.

Check private and public formats separately

LISTSERV requires a PKCS#1 RSA private key, beginning with -----BEGIN RSA PRIVATE KEY----- and ending with -----END RSA PRIVATE KEY-----. A private file labeled BEGIN PRIVATE KEY is PKCS#8 and is not accepted by this documented LISTSERV loader. OpenSSL 3.x needs -traditional for the required output. Merely editing the banner does not convert the key format.

The public file normally uses BEGIN PUBLIC KEY and END PUBLIC KEY; that is correct. Do not confuse the public banner with the private-key incompatibility.

Protect private material using the server's approved ownership, access restrictions and backup process. Never put it in DNS, a public web directory, a support ticket or this guide's examples. Only the corresponding public key is published. The signing algorithm must be rsa-sha256, not obsolete rsa-sha1, as required by RFC 8301.

Publish the public selector record

Take the complete base64 content between the public PEM banners, remove the PEM line breaks and retain every character. The LISTSERV DNS chapter explicitly says its printed example keys are intentionally invalid; do not copy them.

For the hypothetical signing identity above:

Type: TXT
Full owner: ls2026._domainkey.listserv.example.com
Value: v=DKIM1; k=rsa; p=<COMPLETE-PUBLIC-KEY-BASE64-FROM-rsa.public>

The placeholder is not a usable key. The selector ls2026 must later match s= in the LISTSERV key file, and listserv.example.com must match its d=. The selector is your chosen identifier, not a mandatory L-Soft literal.

In a DNS panel managing the parent example.com zone, the relative owner is commonly ls2026._domainkey.listserv. In a separately delegated listserv.example.com zone, it is commonly ls2026._domainkey. Verify the actual resulting full name and the panel's suffix behavior. If _domainkey is delegated elsewhere, work with that namespace's administrator instead of deleting the delegation.

If _domainkey.listserv.example.com itself is delegated, the same full owner ls2026._domainkey.listserv.example.com is relative ls2026 inside that delegated zone. Publish at that authority and preserve the existing NS delegation, rather than adding an ineffective parent-zone copy. DNS namespace and relative names.

Publish one TXT record. A DNS system may encode a long value as multiple quoted strings within that single record, joined without inserting spaces into the key. That is not the same as several TXT records each holding a fragment. RFC 6376, section 3.6.2.2 defines this concatenation.

If the chosen owner already has a CNAME, do not add conflicting TXT. Select a genuinely unused selector or resolve the existing dependency with its owner; RFC 1034, section 3.6.2 prohibits ordinary data coexisting with a CNAME at that name. No change to MX, parent nameservers or unrelated DKIM records is needed merely to publish this key.

Do not create the old _domainkey policy o=~. L-Soft retains that historical example but explicitly says it is no longer required by DKIM.

Configure LISTSERV signing

Create the LISTSERV key file

Following section 12.3, store the private key in a text file named xxx.dkim in LISTSERV's main/home directory, the directory containing the *.list files. For a first installation using one key, L-Soft recommends default.dkim.

The first line of that file must specify the signing domain and selector:

d=listserv.example.com; s=ls2026

Immediately follow that line with the complete PKCS#1 private PEM, including its RSA PRIVATE KEY opening and closing banners. Keep the real private content local. This is not the same file format as the DNS TXT value, and the private file must not contain the public v=DKIM1; p=... record instead.

Use a separate filename and planned cutover when rotating an existing key. Do not overwrite an active default.dkim without understanding which domains depend on it.

Set both signing variables

In the LISTSERV site configuration, authorize the domains for which the server may sign and enable normal message signing. For this single-domain example, the logical settings are:

DKIM_SIGN=LISTSERV.EXAMPLE.COM
DKIM_SIGN_ALL=1

Use your installation's site-configuration syntax. In Unix go.user, include the exports explicitly:

DKIM_SIGN="LISTSERV.EXAMPLE.COM"
DKIM_SIGN_ALL=1
export DKIM_SIGN DKIM_SIGN_ALL

These are configuration examples, not commands to run blindly in a terminal. Merge them into the existing settings without dropping other authorized signing domains. Section 12.3 documents DKIM_SIGN; section 12.5 documents DKIM_SIGN_ALL and its Unix export requirement.

By default, DKIM_SIGN_ALL=0 leaves ordinary list and non-list administrative mail unsigned. It signs only mail for which the caller explicitly requests signing, such as a DISTRIBUTE job with DKIM=YES. Supplying a key and DKIM_SIGN alone therefore does not complete the normal list-mail workflow.

DKIM_SIGN accepts a blank-separated list. An entry such as EXAMPLE.NET(OTHER) selects OTHER.DKIM; without an explicit mapping it uses the default key if present. The supported wildcard form is *.EXAMPLE.COM, not SALES.EXAMPLE.*. Do not authorize external domains merely because their owners subscribe to your lists.

Load the key and check every sending path

Startup is an activation gate

LISTSERV loads and validates keys at startup, according to section 12.4. Schedule the required start/restart through the administrator's approved process after the public key is available. Editing a file while the service is running does not prove the new key has been loaded.

Inspect the real startup log for the intended key name, correct d= and s=, appropriate RSA size and DKIM support enabled. These are expected checks, not a fabricated successful log. Invalid entries are skipped. If DKIM_SIGN is absent, or the installed edition lacks support, LISTSERV bypasses the feature.

The key's d= must equal or be a parent of the domain it is allowed to sign for. That loader permission does not guarantee strict DMARC alignment: a parent signing domain and a child From domain can relaxed-align without being identical.

Per-list and personalized-mail exceptions

Check sections 12.5 and 12.6 before accepting a site-wide green result:

• Misc-Options= NO_DKIM_SIGNATURE disables signing for the affected list. Do not leave a debugging override enabled unintentionally.
• Misc-Options= KEEP_DKIM_SIGNATURE retains the incoming signature, but in this LISTSERV path the server does not add its own signature. It is not a general way to preserve an old signature and add a new branded one.
• For mail merge, Embedded Mail Merge must be enabled so LISTSERV signs the final recipient-specific content. Check EMBEDDED_MAIL_MERGE rather than assuming the default was never changed.
• DISTRIBUTE jobs have their own DKIM=NO|YES option. With the default site-wide signing mode, explicit caller requests still matter; verify the actual job route rather than generalizing from ordinary list mail.

Multiple DKIM signatures are allowed by the protocol. The manual's restriction describes this LISTSERV implementation's behavior, not a universal DKIM prohibition. Also check whether a downstream relay adds footers, rewrites signed headers or otherwise changes content after LISTSERV signs it.

Handle discussion-list rewriting and DMARC

Your key can sign for domains you control. It cannot make your list-domain signature align with an unrelated member's original From domain. SPF may likewise pass for the list's envelope while remaining unaligned with that member's visible From.

L-Soft's dmarc-request explanation documents rewriting list-message From addresses when the original domain publishes p=reject or p=quarantine. The resulting dmarc-request identity changes what recipients see. It is a list-interoperability mechanism, not proof that the original member domain was authenticated by your server.

Mail to those rewritten addresses must reach LISTSERV so it can forward replies to the original sender. The vendor says Windows accepts and routes them automatically; Unix requires appropriate SMTP-package configuration. Do not assume the reply route works because outbound DKIM passed. Messages addressed to dmarc-request and other non-list addresses are not themselves rewritten in the same way, and forwarded replies can encounter SPF problems.

Do not apply DMARC_NO_REWRITE broadly to suppress this behavior. L-Soft cautions that it is appropriate only when you own the domain and are certain its redistributed traffic can authenticate. Changing it is an identity and deliverability decision, not a routine DNS fix.

Keep the effective policy intact

Under RFC 9989, section 4.4, DMARC requires a passing SPF or DKIM identifier aligned with the visible From. Relaxed alignment means the same Organizational Domain; strict alignment means identical domains. For example, d=example.com and From news@listserv.example.com can relaxed-align but not strictly align.

Preserve the effective direct or inherited DMARC policy, alignment settings and reporting destinations. The technical tip's p=none sample is not permission to replace a working policy or override inherited enforcement. If no policy applies, choose an initial policy and monitoring plan with the domain owner after inventorying all legitimate senders. See RFC 9989 policy discovery.

Only if no direct or inherited policy applies and the owner approves an initial monitoring policy after that inventory, this first-record baseline can be used for the example From domain listserv.example.com:

Type: TXT
Full owner: _dmarc.listserv.example.com
Value: v=DMARC1; p=none

In the parent example.com DNS zone, the relative name is commonly _dmarc.listserv. In a separately delegated listserv.example.com zone, it is commonly _dmarc. If the actual From domain is instead example.com, its full owner would be _dmarc.example.com, commonly _dmarc in that domain's zone. Check suffix handling, select the actual identity and keep one policy at each intended owner. An empty direct lookup does not establish the absence of inherited policy, and a new child record must not bypass existing enforcement.

This baseline alone requests no aggregate reports. To collect them, add rua for an actual, owner-approved report destination to the same policy after arranging receipt and any required authorization. Do not copy a sample external mailbox.

If aggregate reports are directed to a different Organizational Domain from the domain where the policy was discovered, the receiver generating those reports must check external-reporting DNS authorization. A reporting destination within the same Organizational Domain is excepted; a different hostname alone does not trigger this requirement. RFC 9990, section 4 defines it. The domain owner's separate data-sharing approval is still necessary.

Verify DNS and delivered messages

Use Deliverability Assessment with the right identities

Open Deliverability Assessment under Server Administration. The 17.5 testing chapter mentions Site Configuration in its path, while its supplied screenshot and the technical tip show Deliverability Assessment as a direct menu item. Use the label in your installed version rather than treating that navigation difference as a separate feature.

Inspect the host name and enter the actual public outgoing IP for the route being evaluated. The default server IP may be internal or may not be the SMTP sender. Review the separate DKIM Private Key, DKIM Public Key and SPF results. A matching local/public key is useful configuration evidence, not proof of a delivered message's alignment or successful signing on every list.

These illustrative read-only lookups use the earlier example domain and selector; replace them with your actual identities:

dig TXT ls2026._domainkey.listserv.example.com +noall +answer
dig TXT listserv.example.com +noall +answer
dig TXT _dmarc.listserv.example.com +noall +answer

The second lookup checks SPF only if that domain is the actual MAIL FROM domain. The last checks a direct DMARC record; an empty answer alone does not rule out an inherited policy.

Require evidence from the actual route

Send only to controlled recipients with authorization. Test the organization-owned list From address and the actual delivery modes you use: ordinary list distribution, digest, administrative messages, personalized mail merge and relevant DISTRIBUTE jobs. Check discussion-list rewrite and reply handling separately.

For each original received message, preserve its visible From, actual MAIL FROM, DKIM d= and s=, trusted receiver authentication results and the route that generated it. For the new branded signing route, require the intended LISTSERV signature to pass DKIM and align with the intended From, plus trusted dmarc=pass. A pass obtained only through SPF does not prove the DKIM setup works. A rewritten sender is not success for an unchanged-brand acceptance goal.

Use receiver-generated or verified authentication evidence. Header position or a familiar authserv-id string alone does not establish trust; RFC 8601, section 7.1 describes forged authentication results. EmailAuth's DKIM selector guide explains how to keep the signing domain and selector from the same signature together.

Use receiver-controlled diagnostic output, or have the receiving administrator establish which fields were generated inside its known processing boundary and document how externally supplied Authentication-Results are removed or distinguished. A familiar authserv-id string or header position alone does not establish provenance. Ignore attacker-inserted or otherwise untrusted results, including a forged field naming the expected receiver. Operational receiving-boundary requirements.

Troubleshoot LISTSERV authentication

The key never loads

Check the edition, file location and filename mapping; the required first-line d=/s=; private PKCS#1 format; and the server's ability to read the file under its approved permissions. Check DKIM_SIGN and Unix export. Read the startup error rather than assuming a visible public key enabled signing.

The key loads but list mail is unsigned

Check DKIM_SIGN_ALL=1, its Unix export, the sender domain's authorization, and any NO_DKIM_SIGNATURE or KEEP_DKIM_SIGNATURE list setting. Confirm that the message actually passed through this LISTSERV instance and signing path.

Personalized messages fail DKIM

Verify Embedded Mail Merge and inspect downstream content changes. Confirm the message used the expected key and selector. A generic non-personalized test does not validate the mail-merge path.

SPF fails despite a green DKIM result

Inspect the real MAIL FROM and public SMTP source. Separate fail from temperror and permerror: missing authorization or wrong route, temporary DNS trouble, and malformed/duplicate/over-budget SPF need different fixes. Aligned DKIM may still make DMARC pass, but it does not repair those SPF faults.

DKIM passes but DMARC fails

Compare the passing d= with the actual visible From under the effective alignment mode. Check whether it is an external member identity, a parent/child strict-alignment mismatch, or a rewritten identity different from the one you intended. Do not weaken policy to conceal a route that cannot authenticate the requested identity.

A rotation breaks delayed messages

Use a new selector for a new key, publish its public record before an approved signer cutover, and confirm the loaded key and actual signatures. Retain old public records while they remain needed for delayed or previously signed messages. Do not remove shared selectors or other applications' records; define retirement with the responsible owners.

Sources and verification limits

The runnable workflow comes from the LISTSERV 17.5 DKIM manual, its linked key, DNS, configuration, startup, use, restrictions and testing chapters, and the official SPF/DKIM/DMARC technical tip. Current standards govern protocol details where historical examples or wording differ.

Configuration checks, public DNS and delivered authentication are separate stages. None was performed on a customer system for this guide, and successful authentication does not guarantee inbox placement.