How to configure Mailman with DMARC and handle Gmail deliverability issues?
Published 26 Apr 2025
Updated 17 Oct 2026
15 min read
Summarize with
Updated on 17 Oct 2026: We clarified Mailman DMARC settings, Gmail authentication checks, and recovery for subscriptions disabled by delivery failures.
Configure Mailman for DMARC by making the list domain the authenticated visible sender when message changes break the author's authentication. That means using Mailman's From rewrite option, signing the final outbound list message with DKIM, publishing SPF for the envelope sender and DMARC for the list domain, and testing real list traffic at Gmail before tightening policy. ARC can preserve the incoming authentication assessment when the original From must remain, but delivery depends on the receiver's trust in the ARC signer.
Suped's DMARC monitoring can separate passing list traffic from sources that still fail and show reported quarantine or reject dispositions. Those reports do not show whether a delivered message reached the inbox or spam folder.
Recommended Mailman DMARC setup
A practical starting point for Gmail-heavy lists is to rewrite Header From to the list address, DKIM-sign the message after Mailman has made all subject, footer, and header changes, and verify the list domain's DNS. For most discussion lists, start with Munge From instead of Wrap Message because replies stay more natural and recipients see a normal message instead of an attached message wrapper.
- Mailman: set DMARC mitigation to Munge From, then choose unconditional rewriting or targeted dmarc_addresses patterns based on test results.
- Outbound MTA: sign after Mailman has finished altering the message, with a DKIM d= domain that matches Header From under the domain's DMARC settings.
- DNS: publish SPF for the actual envelope sender (MAIL FROM) domain, publish the DKIM public key, and publish DMARC for the list domain in Header From.
- Gmail: test with real subscribers, because authenticated list mail can still enter spam with poor reputation or high complaint rates.
- Reporting: track aggregate reports by source IP, list domain, DKIM selector, and receiver so Gmail problems do not hide inside total pass rates.
The default starting point
Use Munge From first. It replaces the author address in Header From with the list address, then keeps the original author visible in the display name and Reply-To or Cc, depending on reply settings. Wrap Message uses a list-domain outer message and attaches the original message, preserving its original From inside the attachment. Choose it when that presentation is required and subscribers accept the reply behavior.
|
|
|
|---|---|---|
Normal discussion list mail | Munge From | Visible From becomes the list |
Original From retained inside an attachment | Wrap Message | Replies and message display need testing |
Failures tied to particular author addresses | Target those authors or rewrite all posts | More From changes |
Preserve the original visible From | Avoid signed-content changes; evaluate ARC | Original DKIM must survive or the receiver must trust ARC |
Pick the Mailman action based on the failure mode, not on preference alone.
Flowchart showing Mailman rewriting and signing list mail before Gmail delivery
Why Mailman breaks DMARC
DMARC checks whether Header From has a matching authenticated domain through SPF or DKIM. SPF authenticates the envelope sender domain, while DKIM identifies its signing domain in d=. DMARC passes when either method passes with a matching domain; it does not require both. A mailing list receives a message from the author, changes headers or body content, then sends it through the list server. SPF checks the list server's IP against the envelope domain, and DKIM fails if list changes alter signed content.
That is why a list message can look legitimate to people but fail a normal DMARC evaluation. The original author did not send the final message to the Gmail subscriber. Mailman did. If Header From still names the author's domain, SPF for the list's envelope domain does not authenticate that identity, and the author's DKIM signature must survive for DMARC to pass. Gmail can consider ARC for indirect mail; a List-ID identifies the list but does not authenticate the author. A Mailman users thread documents Gmail filtering even with unconditional From rewriting, so rewriting alone does not guarantee inbox placement.
Without rewriting
- Header From: still shows the original author's domain.
- SPF: can pass for the list's envelope domain without matching the author's domain.
- DKIM: fails when list changes alter signed content.
- DMARC: fails when no matching authenticated domain remains.
With rewriting
- Header From: uses the list address or list subdomain.
- SPF: can pass for the list's envelope domain.
- DKIM: passes when the final message is signed and the key is valid.
- DMARC: passes when SPF or DKIM passes with a domain matching the rewritten Header From.
A common Gmail failure patterntext
Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=lists.example.net; dkim=fail header.d=author.example; dmarc=fail header.from=author.example
Relaxed DMARC domain matching is the default and allows domains with the same organizational domain. Strict matching, requested with aspf=s or adkim=s, requires an exact domain match for that method. If Header From is list@l.example.com and the signer uses d=example.com, relaxed DKIM matching works but strict matching fails. Changing only Reply-To or Sender does not change the identity DMARC checks.
Mailman settings that matter
The exact labels differ between Mailman 2.1 and Mailman 3, but the intent is the same. The list should take ownership of the visible sender identity before delivery when it rewrites From. The outbound mail system should then authenticate that final message as the list domain. In Postorius, open the list's Settings and DMARC mitigations controls; labels depend on the installed version. The following example uses the Mailman 3 shell for one list, rather than mailman.cfg.
Mailman 3: rewrite every post on one listtext
$ mailman shell -l list@l.example.com >>> from mailman.interfaces.mailinglist import DMARCMitigateAction, ReplyToMunging >>> mlist.dmarc_mitigate_action = DMARCMitigateAction.munge_from >>> mlist.dmarc_mitigate_unconditionally = True >>> mlist.reply_goes_to_list = ReplyToMunging.no_munging >>> commit()
Mailman Core 3.3.9 and later support dmarc_addresses, a list of author addresses or regular expressions that receive mitigation regardless of the author's published DMARC policy. With dmarc_mitigate_unconditionally set to False, patterns such as ^.*@gmail\.com$ and ^.*@googlemail\.com$ target posts written by those authors, not posts delivered to Gmail subscribers. Other authors remain subject to policy-based mitigation. Use unconditional mitigation when consistent From behavior matters more than preserving every author's address.
Mailman 2.1 legacy per-list optionstext
dmarc_moderation_action: Munge From dmarc_quarantine_moderation_action: Yes from_is_list: Munge From, when needed for all list mail anonymous_list: No, unless the list must hide authors
Mailman 2.1 is end of life; keep these settings for existing installations and plan migration to Mailman 3. After rewriting, sign with a DKIM selector for the list domain. If Mailman adds a footer after DKIM signing, the signature fails. The DKIM signer must sit after Mailman in the outbound path. If preserving the author's From instead, avoid changes to content covered by the author's DKIM signature.
Illustrative DNS records for a list subdomaindns
l.example.com. IN TXT "v=spf1 ip4:192.0.2.10 -all" s1._domainkey.l.example.com. IN TXT "v=DKIM1; k=rsa; p=..." _dmarc.l.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@l.example.com"
Replace the documentation IP address and abbreviated DKIM key with real values. This SPF record applies only when the envelope sender uses l.example.com; check the delivered Return-Path for the actual bounce domain, and authorize every outbound IPv4 or IPv6 address used for it. Publish one SPF record per envelope domain and keep DNS-querying SPF terms within the 10-lookup limit. Use a DKIM key of at least 1024 bits for Gmail, preferably 2048 bits. Replace the rua address with a working report destination; an external reporting domain must authorize reports when required.
Do not damage replies
Header rewriting can break user expectations if Reply-To gets stripped or forced to the list. Keep replies predictable: announce the change to list owners, test Reply and Reply all, and preserve the poster for discussion lists unless list-directed replies are the established behavior. Check first_strip_reply_to before removing an author's existing Reply-To.
If DNS access is slow or split across teams, Hosted DMARC is Suped's option for managing policy changes after the initial DNS setup. Use it to coordinate the list domain's policy rollout with report review.
Gmail delivery checks
Gmail treats mailing-list messages as indirect mail, so Google's direct-mail DMARC domain-matching requirement does not apply in the same way. Authentication is still required. Gmail evaluates SPF and DKIM results alongside reputation and complaint signals, and uses list identification and trusted ARC evidence for indirect mail. Rewriting From and signing as the list domain gives Gmail a straightforward authenticated identity when the original DKIM signature does not survive.
The common Gmail trap
Rewriting only when the author's domain publishes quarantine or reject can miss other Gmail delivery failures. If failures follow particular author domains, use Mailman Core 3.3.9 or later dmarc_addresses patterns for those authors, or test unconditional Munge From. A Gmail recipient address alone does not trigger dmarc_addresses.
|
|
|
|---|---|---|
DMARC fail | No passing SPF or DKIM domain matches Header From | Check From rewriting and the signing or envelope domain |
DKIM fail | Signed-content changes or an incorrect key | Verify the selector and public key; sign after final changes |
Spam folder despite authentication passes | Reputation or subscriber complaints | Check consent, complaint levels, and sending volume |
550 5.7.26 | Authentication failure or a DMARC policy rejection | Read the full SMTP response and compare final authentication results |
Use the Gmail symptom to choose the next check.
Send a real post through the list to a Gmail mailbox, open the message's More menu, and choose Show original. Read Gmail's own Authentication-Results. With Munge From, look for dmarc=pass and dkim=pass with header.d matching the list's Header From, plus SPF for the envelope sender. With a preserved author From, inspect ARC-Authentication-Results and the ARC chain as well. If delivery reaches spam despite valid authentication, check stale subscribers, complaints, sudden volume jumps, and misleading message elements.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
The message headers matter more than the admin setting name. A valid ARC chain is evidence of sealed authentication assessments, not proof that Gmail trusts its signer or that the original message authenticated successfully. If Gmail reports DKIM failure for the list domain, check for content changes after signing, a missing selector, or a mismatched public key.
GNU Mailman 3 Postorius DMARC mitigation and From rewriting settings
When the list passes authentication but Gmail still filters it, work through general Gmail deliverability causes as a separate problem. Authentication helps Gmail evaluate the message; it does not erase reputation history or user-level spam signals.
Handle Gmail bounces and disabled subscriptions
Repeated Gmail rejections can raise a subscriber's Mailman bounce score and disable delivery. After fixing authentication, check the member's delivery status: changing DMARC settings does not automatically restore disabled subscriptions.
- Capture the full delivery status notification and outbound MTA log entry, including the SMTP code, recipient, queue ID, and timestamp. A rejection has no delivered Gmail message whose Show original view can be inspected.
- Treat 4xx responses as temporary deferrals and let the MTA retry with its configured backoff. For 5xx permanent failures, fix the stated cause before a controlled test; repeatedly resending unchanged messages does not fix authentication.
- Check whether the subscribed address forwards to Gmail. Compare direct and forwarded delivery, and inspect authentication after the extra hop. With the subscriber's agreement, subscribing their final Gmail address removes that forwarding hop.
- After a successful delivery test, re-enable affected members in Mailman's membership controls and watch bounce processing. Keep bounce handling enabled so invalid addresses do not accumulate.
The Mailman users thread includes reports of forwarding-related Gmail failures that eventually disabled subscriptions. Use SMTP logs for rejected messages and DMARC reports for domain-level authentication trends; aggregate reports do not identify individual disabled members.
ARC and Gmail list requirements
ARC (Authenticated Received Chain) preserves authentication assessments across forwarding and mailing-list handling. Validate incoming authentication before Mailman changes the message, then seal the final result. Gmail decides whether to trust the ARC signer. Keep a stable List-ID on each list message so receivers can identify the list; List-ID itself does not make DMARC pass.
- ARC: validate incoming authentication before modification and seal the final message at the end of the pipeline.
- List-ID: keep a stable, human-readable identifier on every list message.
- Infrastructure: use matching forward and reverse DNS for every sending IP, including IPv6, and transmit mail with TLS.
- Traffic quality: aim for Gmail-reported spam rates below 0.1% and prevent them reaching 0.3%; send only to confirmed subscribers.
- Subscriptions: retain unsubscribe headers and test one-click handling where required. A mailto-only List-Unsubscribe header does not implement RFC 8058 one-click unsubscribe.
For personal Gmail accounts, all senders need SPF or DKIM; bulk senders need SPF and DKIM plus a DMARC policy, with p=none accepted. Gmail counts messages across the same primary domain toward roughly 5,000 messages in 24 hours, and bulk status persists once reached. Its enforcement ramp-up began in November 2025. Check applicable subscription requirements, including an HTTPS one-click endpoint with List-Unsubscribe-Post, a visible unsubscribe link, and honoring requests within 48 hours. Do not assume Mailman's default headers provide the complete one-click workflow.
Mailman 3 has global ARC support, but it is disabled by default. Enable it after setting the authentication service identifier, signing domain, selector, and private key. Publish the matching public key at selector._domainkey.domain. Trust upstream authentication service identifiers only for systems you control, and remove forged incoming Authentication-Results that claim those identifiers. The incoming checker must run before message changes and the ARC signer must run after them.
Mailman 3 ARC configuration outlineini
[ARC] enabled: yes authserv_id: lists.example.com trusted_authserv_ids: mx.example.com domain: lists.example.com selector: arc privkey: /etc/mailman3/arc.key
ARC supplements list authentication
ARC does not guarantee inbox placement or repair an invalid list-domain DKIM signature. Keep DKIM signing after Mailman changes and ensure later processing does not invalidate the ARC seal. Use ARC to preserve the original authentication assessment for indirect mail.
Gateway rewriting or Mailman
If you already run distribution lists in Microsoft 365, distinguish envelope rewriting from visible From rewriting. Microsoft 365's Sender Rewriting Scheme (SRS) changes MAIL FROM, not Header From, so SRS alone does not repair DMARC when the author's DKIM signature breaks. A gateway that explicitly supports visible From rewriting and final DKIM signing is an alternative, but verify that capability before planning the change.
Gateway From rewriting
- Speed: avoids migration when an existing gateway supports and correctly signs the rewritten identity.
- Control: depends on gateway support for visible From rewriting and per-list rules.
- Risk: can surprise list owners if reply behavior changes globally.
Mailman
- Control: gives list-specific DMARC behavior and owner workflows.
- Operations: needs patching, backups, queue monitoring, and access controls.
- Fit: works well when mailing lists are core infrastructure.
For security review, Mailman is mature open-source software, but that does not automatically pass an audit. Document patch cadence, admin roles, operating system hardening, SMTP relay permissions, archive exposure, bounce handling, logging, backups, and incident response.
Migration decision
Choose migration when list ownership, moderation, archives, or per-list DMARC controls justify the operational work. For a delivery-only problem, first verify whether a supported gateway configuration can authenticate the visible sender and preserve expected replies.
Monitoring and rollout
Roll out Mailman DMARC changes in stages. Start with a small pilot covering different list volumes and Gmail subscribers. Confirm that rewritten messages pass DMARC, that preserved messages carry valid ARC when enabled, that replies still work, and that moderators understand what subscribers will see in the From line.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped's DMARC platform supports this workflow through aggregate report analysis and issue investigation. Compare the list domain's source IPs and receiver results before and after a Mailman or DNS change. Reports for your list domain cover messages using that domain in Header From; failures against a preserved third-party author domain are reported to that domain's report destination. Use Gmail test messages and MTA logs to fill that gap.
Before tightening policy, run the list domain through a DMARC checker and then run a broader domain health check. Verify the policy record and SPF configuration, then check the DKIM selector used in a real delivered message; a domain-only scan cannot discover every selector.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Once reports show stable passes, replace the list domain's policy record in stages. Keep p=none while discovering legitimate sources, then publish p=quarantine after coverage and exception handling are clean. Publish p=reject only after list posts and every service sending with that domain, including moderation and subscription notifications, pass under real traffic. RFC 9989 removed pct, so do not use it to phase enforcement. Publish only one DMARC record at the name, and allow for DNS cache expiry before assessing each change.
Publish one DMARC stage at a timedns
Stage 1: _dmarc.l.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@l.example.com" Stage 2: _dmarc.l.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@l.example.com" Stage 3: _dmarc.l.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@l.example.com"
Mailman configuration practices
Best practices
Rewrite Header From for Gmail-heavy lists, then sign the final message after list changes.
Keep Reply-To behavior explicit so list replies do not shift without owner approval.
Track Gmail results separately because total DMARC pass rates can hide receiver-specific failures.
Common pitfalls
Rewriting only reject-policy senders misses Gmail failures caused by other authentication problems.
Signing before Mailman adds footers breaks DKIM and leaves the list looking unauthenticated.
Treating Mailman migration as a DMARC-only fix ignores patching, queues, archives, and access.
Expert tips
Use a list subdomain so Mailman policy, DKIM selectors, and reports stay cleanly separated.
Test real Gmail mailboxes before enforcement because header simulators miss reputation signals.
Use Wrap Message when the original From must remain inside the attached message, and test replies.
Sending Mailman through an SMTP relay
An authenticated SMTP relay works when it authorizes the list domain used in Header From. Relays that require verified sender domains often reject posts when Mailman preserves arbitrary author addresses, so apply Munge From before the relay handoff. Confirm that the relay signs the final content with a matching DKIM domain and does not add a footer after signing.
Frequently asked questions
Use Munge From first for normal discussion lists. It gives Gmail a list-domain Header From while keeping messages readable. Wrap Message uses a list-domain outer message and retains the original message as an attachment; choose it when that presentation is needed and test replies.
Test unconditional rewriting for consistent behavior, or use Mailman Core 3.3.9 or later dmarc_addresses patterns for affected author addresses. These patterns match the author, not the recipient. Policy-only rewriting does not address every Gmail rejection, including failures involving authors with p=none.
ARC can support delivery while preserving the original From when a receiver trusts the chain and its recorded authentication results. It does not guarantee acceptance. Use Munge From plus final list-domain DKIM signing when a directly authenticated list identity is needed.
The passing domains must match Header From under the applicable DMARC settings. A pass for an unrelated hostname does not satisfy that check, and an earlier hop's pass is not Gmail's final result. Inspect Gmail's Authentication-Results and any ARC evidence; for rejected messages, use the full SMTP response and outbound logs.
Yes, when the relay authorizes the list domain and Mailman uses that domain in Header From. Relays that require verified sender domains often reject preserved third-party author addresses, so apply Munge From before the relay handoff.
Mailman can fit audited environments, but approval depends on the deployment. Document patching, admin access, queue controls, archive permissions, logging, backups, and SMTP relay restrictions.
