Treat the list as a second sending step
A Simplelists message has at least two relevant stages: the member submits a post, then the list redistributes it. Authentication that worked on the original submission may not describe the copy delivered to members. This guide addresses custom domains on documented Multiple List accounts and the behavior of redistributed messages. It does not assume that every account type, list setting or original sender uses the same identity.
Begin by choosing the business outcome. An announcement list may consistently represent the organization. A discussion list may need to display different members and direct replies appropriately. Record which behavior people expect before changing sender rewriting. Otherwise a technically successful change can make conversations confusing or disclose details an anonymous list intended to hide.
Establish the domain and incoming routing boundary
Simplelists’ own-domain guide describes adding a domain through General Settings, then Domains, in a Multiple List account, setting it as primary and checking the resulting list addresses. This is the provider’s 2017 setup article, so confirm the current account controls before using its navigation. It also points administrators to the account’s SPF and DKIM information. Retrieve the values from the correct account and domain rather than copying a public example.
The same guide names mx1.simplelists.com and mx2.simplelists.com for primary and secondary incoming MX, respectively, and warns that changes can take up to 72 hours. Confirm current account instructions and actual cache state rather than treating elapsed time as acceptance. Treat that as an incoming-routing decision. If the organization already receives employee mail at its root domain, replacing those MX records could affect far more than the list. Decide whether a dedicated list subdomain is appropriate, identify the existing mail owner and record the approved routing scope before publication.
Keep incoming routing and outgoing authentication on separate worksheet rows. Successful delivery of a post into the list does not prove that copies sent out of it will authenticate. Conversely, a DKIM problem does not by itself justify moving the company’s inbound mail.
Obtain and review the account issued records
Capture the full record owner, type, public value and intended domain for each issued entry. Compare the proposed owner with existing DNS data to avoid selector collisions or a duplicated domain suffix. Review changes in the authoritative zone, not simply in the registrar account if another provider hosts the DNS.
For SPF, preserve other legitimate senders at the same domain. RFC 7208 defines how multiple SPF records and DNS-dependent terms are processed. Review the complete policy and nested lookup cost before authorizing an additional service. Do not create a competing SPF policy because a setup screen displays a standalone example.
For DKIM, compare the issued selector and public record with the signature generated on a controlled list message. RFC 6376 defines the d= and s= fields. A published key is useful only when the actual message carries a corresponding valid signature. Keep every observed signature, including any original member signature, in the evidence packet.
Decide how to handle external member identities
Simplelists’ DMARC explanation distinguishes sending from an account domain from redistributing mail originating at another domain. It describes conditional rewriting for outside domains. Its feature guide also documents an option to rewrite consistently and controls for showing original sender details.
Those options deserve a human decision. A committee may prioritize a stable list address; a discussion group may prioritize recognizing the contributor. Record the chosen From display and reply destination, then check both in the delivered copy. If anonymity matters, review the body and quoted thread too. Hiding one header cannot erase a member’s signature block or previously quoted address.
Do not assume that the list can sign as an unrelated external member’s domain. Identify the final visible From domain and the authentication path that supports it. Preserve the expected conversation behavior while investigating any mismatch rather than changing several settings at once.
Include content modifications in the test plan
A footer, header insertion or subject prefix can affect an original signature, depending on what was signed. Simplelists’ delivery troubleshooting guide discusses these changes when investigating suspected-spoofing rejection. It also says the envelope sender is normally the list address and points to the email-delivery view for recipient-server details.
Build a small matrix: an organization sender, an outside sender with a strict policy, and the actual list modification settings. Add digest or other distinct delivery modes only if the organization uses them and the account supports them. Each row must represent a real workflow, not a theoretical feature checklist.
Use harmless posts and controlled recipients. Retain send time and message identifier so the list log can be matched to the received copy. Test an external receiver as well as the organization’s own gateway when both are relevant. Internal acceptance may depend on a local exception that external members do not share.
Record the final identity and result
For each delivered copy, record visible From, Reply-To, envelope domain, all DKIM d= and s= pairs, and the trusted receiver’s SPF, DKIM and DMARC results. Keep the original post’s result separately. The two stages answer different questions and should not overwrite each other in the test record.
RFC 9989 defines DMARC alignment. Identify the passing mechanism and the domain relationship that supports it. A provider-domain pass unrelated to the final From domain does not establish that relationship. A rewritten From address may change the relevant comparison, which is why inspecting the final copy is essential.
If the receiving server rejects a message, preserve its exact diagnostic text. If it accepts the message but the recipient cannot find it, continue the delivery investigation without assuming a DNS failure. Avoid broad allowlisting as an initial substitute for identifying the authentication outcome.
Use the list redistribution worksheet
The Simplelists route and sender behavior worksheet (create a separate review record with the fields described here) records the incoming list domain, original poster category, rewriting decision, content changes and final identities. It gives the business owner a place to approve reply behavior and the mail administrator a place to attach the technical result.
Before signoff, compare all test rows. One successful organization announcement does not validate an outside member’s discussion post. Leave uncovered routes explicitly pending and state what additional test is required. Keep the domain configuration and list settings version with the results so later changes can be traced.
Fictional diagnostic case involving a discussion footer
Fictional written case only: SLS-01 stipulates original From member@outside.example with an original passing signature d=outside.example. In the redistributed copy that original signature fails after a footer change; final From remains member@outside.example. The list’s envelope, any additional signatures and their results are unknown, so no full DMARC verdict follows. The list owner must inspect the final copy and documented rewriting settings, approve the intended reply behavior, and test that exact route. Adding SPF at the organization’s domain does not repair an unrelated original signature. No real list or message was inspected.
Recover settings without disturbing member mail
Record the earlier list settings and DNS state before a controlled change. If replies or sender presentation become wrong, pause the affected rollout and restore the approved behavior while the owner reviews it. Coordinate any record retirement with remaining lists and queued messages. A shared domain may support several lists with different operating schedules.
Retest after domain changes, rewriting changes, new footers, routing changes or a migration. This unpublished draft still requires live account inspection, issued values, DNS observations, received-message evidence, original-scope acceptance, visual review and human SME approval.
Separate a passing message from enforcement readiness
RFC 9989 Section 7.4 requires valid DKIM for a domain publishing p=reject and cautions about indirect-mail interoperability. A single aligned SPF result does not by itself justify a reject-policy rollout. Review all legitimate routes and policy ownership separately from this provider setup.