For a Simplelists Multiple List account, add your domain under General Settings > Domains, obtain that account's SPF and DKIM records, and publish them at your DNS host. Then test the copy redistributed to a member, not only the original post. Simplelists can rewrite a sender's From address for DMARC compatibility, so the final visible From domain determines which authentication must align.
A Single List address forwarded from your own domain is a different route: forwarding into the list does not provide full custom-domain integration. This guide is a documentary review, not a test of a customer account, DNS configuration or message delivery.
Understand the two delivery stages
A member's mail system first sends a post to Simplelists. Simplelists then distributes copies to the group. SPF, DKIM and DMARC outcomes on those two hops can differ.
SPF checks the connecting sender against the envelope MAIL FROM domain, normally visible in Return-Path; for a null reverse-path, the applicable SPF identity is derived from HELO. It does not authenticate the visible From address by itself. RFC 7208 identities A redistributed message comes from a different server than the member's original post. A footer or subject change can also invalidate an original DKIM signature. A new list signature may pass, but DMARC still requires alignment with the final visible From domain.
Simplelists support documents its added sender information, bounce handling and DKIM signature. Do not remove the list's sender or return-address information to make a mail client's display look tidier: that can interfere with bounce processing and authentication.
Choose the correct Simplelists product and domain route
| Route | What it supports | What not to assume |
|---|---|---|
| Multiple List with your own domain | Full domain integration and account-displayed SPF/DKIM instructions | That adding the domain alone publishes DNS or proves delivery |
| Single List with an address forwarding to Simplelists | A convenient inbound address at your domain | That forwarding creates branded outbound DKIM or full custom-domain integration |
| Provider-owned Simplelists address | Provider-managed domain infrastructure | That you can edit the provider's DNS |
| External member posting from their own domain | Submission to the list, followed by redistribution | That your list DNS can authorize or repair the member's domain |
The official support page explicitly reserves full domain integration for Multiple List accounts. If your organization wants a branded list, establish this product requirement before changing DNS.
Prepare permissions and a safe domain boundary
You need account access sufficient to manage domains and list settings, DNS editing rights at the authoritative DNS host, and approved test members. If your account administrator restricts domain controls, have them perform the configuration or involve Simplelists support.
Save the current DNS values and list settings, including From rewriting, reply behavior, footer, subject prefix, digest delivery and attachment handling. List addresses are not necessarily the same domain as employee mailboxes. A dedicated list domain or subdomain can provide a clear operational boundary, but its routing and authentication must still be configured deliberately.
Do not replace the MX records for a domain already receiving ordinary business email without a planned mail-routing change. MX controls incoming delivery, not outgoing SPF authorization or DKIM signing. You can break employee mail while trying to fix a list's authentication.
Step 1: Add the custom domain and plan incoming routing
The official custom-domain guide describes General Settings > Domains, adding the domain and setting it as primary.
For a domain intentionally dedicated to Simplelists, official support specifies primary MX mx1.simplelists.com and secondary MX mx2.simplelists.com, at different priorities. These are incoming list-routing settings. They are not the SPF record or DKIM key, and changing them is not a generic cure for outbound DMARC failure.
Before publishing any MX change, have the routing owner approve the exact incoming domain, both targets and their chosen priority values against the intended routing plan. Account instructions alone are not authorization to redirect incoming mail. If your domain already serves mailboxes elsewhere, resolve the routing architecture with your mail administrator first. For Single List forwarding, retain that route's separate boundaries rather than treating it as a Multiple List domain migration.
Step 2: Obtain the account-issued authentication records
With the correct Multiple List account selected, open General Settings > Domains and find the SPF and DKIM details. Copy the exact owner names, record types and values for the intended domain. The custom-domain guide places these details in that tab; it does not provide a universal public key for every customer.
| Item to record | Why it matters |
|---|---|
| Account and intended primary domain | Prevents configuring another list account's identity |
| SPF owner and required mechanism | SPF is evaluated at an exact DNS name, not automatically inherited from a parent |
| DKIM selector and public record | The selector must match the signature used on redistributed mail |
| Current DMARC mode and reply settings | Rewriting changes the identity that DMARC evaluates |
| Existing DNS and TTL | Supports comparison, propagation diagnosis and a controlled correction |
Do not generate a random DKIM key pair on a third-party website for a hosted Simplelists route. Publishing its public key would not make Simplelists sign with the matching private key. If the account does not expose the expected record, ask support to confirm the supported configuration and activation requirements for that domain.
Step 3: Merge SPF and publish DKIM
Keep one SPF TXT policy per exact owner name. Edit the record starting v=spf1 and merge only the required Simplelists authorization, preserving other legitimate senders and the existing ending. Do not replace an organization's policy with a list-only example or add a second SPF policy alongside it.
If an SPF policy uses redirect=, review that delegated policy before adding mechanisms. An all mechanism causes redirect to be ignored; do not introduce all into an intended redirect-based policy or change its qualifier casually. RFC 7208 all and redirect
Under RFC 7208, SPF permits no more than 10 evaluated DNS-lookup-causing terms, counting nested evaluation as well as top-level include, a, mx, exists, ptr and redirect where evaluated. This is not simply ten DNS packets or ten visible includes. ip4, ip6 and all do not consume those terms. Remove demonstrably obsolete authorizations or ask your mail administrator to redesign overloaded sender scope; do not flatten a provider's changing infrastructure into unmaintained static addresses.
Publish the supplied DKIM public record at its exact selector owner. A hostname such as issued-selector._domainkey.example.com is a pattern, not a Simplelists-provided value. Copy the actual selector and complete tagged public TXT value, including all issued tags and key characters, not just the p= key. A long TXT value may use multiple component strings within one logical record; DNS concatenates those strings without adding spaces. Do not truncate it or create multiple independent DKIM TXT records at the selector. RFC 6376 TXT representation
For full owner issued-selector._domainkey.news.example.com, a relative editor in the example.com zone expects issued-selector._domainkey.news; in separately delegated news.example.com, it expects issued-selector._domainkey; in delegated _domainkey.news.example.com, it expects just issued-selector. Identify the actual authoritative zone first. These are syntax examples, not issued selector values. Do not append the zone twice or change nameserver delegation as an authentication shortcut.
If your current account supplies a CNAME, preserve that type and target rather than converting it into a TXT key. A CNAME must not share its owner with TXT, address or MX data, or a second CNAME. Identify the existing service before resolving a conflict. DNS alias rules Do not delete a working selector for another sender. Never publish a private DKIM key.
This CNAME branch is conditional on an issued account record, not a claim that every Simplelists account uses aliases. If the authoritative host is Cloudflare, set the alias to DNS only and turn off relevant per-record Flatten where available. Whole-zone flatten-all must not suppress the required literal CNAME answer; coordinate affected services before disabling that applicable setting. Apex and same-zone target behavior may still flatten independently. If the required literal alias cannot safely be retained, stop and coordinate a supported solution rather than inventing controls or changing the target. Cloudflare flattening · Verification exceptions
Step 4: Review DMARC mode and reply behavior
The general support explanation describes rewriting for sender domains with quarantine or reject. Its more specific DMARC mode guide, describes the combination of that policy and list message modifications such as headers or footers. Do not treat the general summary as proof that every message must be rewritten. The current feature guide also documents choosing always-rewrite instead of the default as-needed behavior.
DMARC mode controls are in List Settings for all account types. Under If the sender's email address is changed, Show original sender details in sender description and reply-to header displays the sender's name via the list; Show original sender details only in reply-to header instead uses the list description in From. General support also documents Do not add original sender details for incognito use. Choose with the list owner, not merely to obtain a green authentication result.
This explains why members may see a list address where they expected the author's address. The rewritten list domain needs working authentication. A signature aligned to the list domain does not authenticate an unchanged external member domain.
For announcement lists, approve a recognizable organizational identity and the intended reply destination. For discussion lists, decide how authors are identified and whether replies go privately or to the group. Anonymous-list settings cannot remove identifying details from message bodies, signatures or quoted threads; inspect those too. Preserve moderation and membership controls rather than weakening them to fix authentication.
Do not disable rewriting just to preserve appearance without testing the consequences. Equally, do not weaken an external sender's DMARC policy: you do not control it, and it may protect important mail. Test both personal replies and replies to the group so that an authentication fix does not unexpectedly expose a message to all members.
The ordinary support description of preserving From addresses and its DMARC rewriting description concern different circumstances. Inspect the actual received From address for each posting route instead of assuming every post is rewritten or none are.
Step 5: Check DNS, then test redistributed messages
These read-only queries use placeholders. Replace the domain and selector with those shown in your account. If the supplied DKIM record is a CNAME, query CNAME as well and follow its target to the public key.
dig +short NS lists.example.com
dig +short MX lists.example.com
dig +short TXT lists.example.com
dig +short TXT issued-selector._domainkey.lists.example.com
dig +short TXT _dmarc.lists.example.com
For a subdomain not separately delegated, the parent zone's nameservers may be authoritative; an empty NS response does not mean every other record is absent. Check the correct authoritative zone and a recursive resolver. Confirm one applicable SPF policy and the issued DKIM record. A missing local DMARC record requires checking inherited policy, not automatically creating a weaker record.
Next, send authorized non-sensitive posts to controlled members. Exercise the configuration people actually use:
- A post from your organization's domain.
- A post from an external sender whose domain enforces DMARC.
- A normal list copy with the configured footer and subject prefix.
- A digest, if your members use digests.
- An attachment or formatting conversion path, if enabled.
For each received copy, record the final From domain, envelope smtp.mailfrom, DKIM signing domain and selector, and trusted receiving service's SPF/DKIM/DMARC results. The custom-domain acceptance target is dkim=pass for a signing domain aligned with the final branded From address, plus a trusted dmarc=pass for that intended final domain. Approved list From rewriting is valid here: authenticate the final list identity, while recording that it does not prove the original external author's identity. An unexpected rewrite to an unrelated fallback domain is not completion of your branded-domain setup. Investigate SPF errors even where aligned DKIM supplies the DMARC pass. A generic provider signature or an original post's pass is not enough.
Use only the receiving service's trusted authentication result. Establish from its documented processing that externally supplied Authentication-Results fields are stripped or isolated/distinguished, and ignore those untrusted fields. Header position or a familiar authserv-id alone is not proof. If you cannot establish that boundary, obtain receiver-controlled logs or a message trace instead. RFC 8601 trust boundary
If the message retains an external member's From address, determine whether an aligned original signature survived. Do not count a list-domain signature as aligned to an unrelated external domain. If neither mechanism aligns, review the supported rewriting behavior with Simplelists.
If a member receives list mail through Google Workspace groups or another forwarding step, test the additional message path and distinguish raw DKIM passes from aligned policy results as well. A direct-member test does not cover that extra redistribution hop.
Manage DMARC without weakening an existing policy
Current DMARC, RFC 9989, requires at least one passing aligned mechanism: SPF or DKIM. Relaxed alignment generally accepts the same Organizational Domain; strict alignment requires an exact domain match. For final From announcements@example.com, a passing intended signature with d=mail.example.com aligns under relaxed mode when both share the same Organizational Domain, but not strict mode. A passing d=example.com aligns in both modes. Preserve existing strict settings rather than silently loosening them to obtain a pass. RFC 9989 DKIM alignment
Domains publishing p=reject must not rely solely on SPF for a DMARC pass and must apply valid DKIM signatures. Mailing lists and other indirect routes can still create interoperability problems, so test their final identities and transformations; a direct sender test does not cover redistribution. This is not permission to weaken an existing policy or disable approved list rewriting. RFC 9989 DKIM and interoperability
Before publishing a policy, check the final From domain and any applicable inherited policy. Keep established quarantine or reject protection. Only if no applicable policy exists and the domain owner approves monitoring should you create a single TXT record at _dmarc for that domain beginning v=DMARC1; p=none. Append ; rua=mailto: and your approved aggregate-report destination. Ensure that destination is provisioned. For a destination in a different Organizational Domain from the policy domain, the report-generating receiver must check DNS authorization before sending reports. A destination in the same Organizational Domain is excepted; a different hostname alone is not the test. The domain owner must separately approve the aggregate recipient and associated data sharing: DNS authorization is not privacy approval. RFC 9990, Section 4
For clarity, an apex From domain of example.com uses the full owner _dmarc.example.com, usually entered as _dmarc in that zone. A From subdomain of news.example.com uses _dmarc.news.example.com: enter _dmarc.news when editing the parent example.com zone, or _dmarc when editing a separately delegated news.example.com zone. These are owner-name examples, not instructions to override an existing applicable policy. Confirm whether your DNS host appends the zone name before saving.
Use aggregate reports under RFC 9990 to review legitimate list and non-list traffic before changing enforcement. Do not use the obsolete pct tag as a percentage rollout control. Failure reports may disclose message information, so omit ruf unless recipients and privacy handling are approved.
Troubleshoot the failed stage, not just the domain
| Symptom | Investigation |
|---|---|
| Post never reaches the list | Check MX or forwarding, moderation and member permission before changing outbound DKIM |
| Sender's own inbox lacks the copy | Simplelists notes that Gmail may suppress a duplicate of a message already in Sent; test another approved member |
| Simplelists says sent, member cannot find it | Inspect delivery receipt and spam filtering; sent means acceptance by the member's server, not inbox placement |
SPF permerror |
Check duplicate SPF, syntax and the ten-term limit at the actual envelope domain |
SPF temperror |
Check DNS availability and retry observations, not a speculative additional include |
SPF fail or softfail after redistribution |
Compare the changed sending IP and envelope identity; do not authorize list servers in every member's domain |
| Original DKIM fails after a footer | Inspect the final list signature and From rewriting; original content may have changed |
| DKIM passes but DMARC fails | Compare the passing d= with the final From domain and the applicable alignment mode |
| Only digest recipients fail | Test the digest's own final identity and signature instead of relying on an ordinary post |
Use Email delivery > Email failures to collect bounce details. The official delivery troubleshooting guide distinguishes delivery and recipient-side causes. Do not broadly allowlist all list traffic or bypass receiver security as the first fix. If a setting change caused the regression, compare the saved configuration and have its owner approve a targeted restoration; review queued or moderated messages before retrying to avoid duplicate distribution. Give support the list, posting time, affected route and sanitized headers; keep member addresses and message content out of public support posts.