germano commented

Fedora mailing list messages often are classified as spam by GMail. As you can see from messages sources, dmarc and other checks are failing.
A good overview of the DNS configuration problems can bee seen at
https://mxtoolbox.com/emailhealth/lists.fedoraproject.org/
then mind the warning

These results are for fedoraproject.org.
Did you really mean to run lists.fedoraproject.org?
Click Here

and click the "Click Here" button to run the tests against lists.fedoraproject.org.
You will see 5 buttons (Problems, Blacklist, Mail Server, Web Server, DNS) that let you expand the various categories

Fedora mailing list messages often are classified as spam by GMail. As you can see from messages sources, dmarc and other checks are failing. A good overview of the DNS configuration problems can bee seen at https://mxtoolbox.com/emailhealth/lists.fedoraproject.org/ then mind the warning ``` These results are for fedoraproject.org. Did you really mean to run lists.fedoraproject.org? Click Here ``` and click the "Click Here" button to run the tests against lists.fedoraproject.org. You will see 5 buttons (Problems, Blacklist, Mail Server, Web Server, DNS) that let you expand the various categories

kevin commented

2025-04-11 00:26:13 +00:00

We can take a look. Thanks.

We are often on various blocklists because people subscribe, forget that they did and report the posts they get as spam. ;(

I am not sure what its meaning about 'dns record not found'... lists.fedoraproject.org definitely resolves.

But we can look into it and see what we can do.

We can take a look. Thanks. We are often on various blocklists because people subscribe, forget that they did and report the posts they get as spam. ;( I am not sure what its meaning about 'dns record not found'... lists.fedoraproject.org definitely resolves. But we can look into it and see what we can do.

germano commented

2025-04-11 00:49:07 +00:00

Author

dns record not found it means that a DNS "record A" does not exist for the subdomain, but it's not a serious problem

`dns record not found` it means that a DNS "record A" does not exist for the subdomain, but it's not a serious problem

kevin commented

2025-04-11 00:55:47 +00:00

uh...

✗ host -t a lists.fedoraproject.org
lists.fedoraproject.org has address 140.211.169.196
lists.fedoraproject.org has address 8.43.85.67
lists.fedoraproject.org has address 34.221.3.152
lists.fedoraproject.org has address 152.19.134.198
lists.fedoraproject.org has address 152.19.134.142
lists.fedoraproject.org has address 38.145.60.21
lists.fedoraproject.org has address 67.219.144.68
lists.fedoraproject.org has address 38.145.60.20
lists.fedoraproject.org has address 8.43.85.73

uh... ``` ✗ host -t a lists.fedoraproject.org lists.fedoraproject.org has address 140.211.169.196 lists.fedoraproject.org has address 8.43.85.67 lists.fedoraproject.org has address 34.221.3.152 lists.fedoraproject.org has address 152.19.134.198 lists.fedoraproject.org has address 152.19.134.142 lists.fedoraproject.org has address 38.145.60.21 lists.fedoraproject.org has address 67.219.144.68 lists.fedoraproject.org has address 38.145.60.20 lists.fedoraproject.org has address 8.43.85.73 ```

phsmoura commented

2025-04-14 19:03:48 +00:00

Metadata Update from @phsmoura:

Issue priority set to: Waiting on Assignee (was: Needs Review)
Issue tagged with: low-gain, low-trouble, ops

**Metadata Update from @phsmoura**: - Issue priority set to: Waiting on Assignee (was: Needs Review) - Issue tagged with: low-gain, low-trouble, ops

germano commented

2025-04-15 13:02:09 +00:00

Author

Additional infos from https://www.checktls.com/TestReceiver

[...]
Cert Hostname DOES NOT VERIFY (smtp-mm-ib01.fedoraproject.org != bastion.fedoraproject.org | DNS:bastion.fedoraproject.org | DNS:smtp-mm-cc-rdu01.fedoraproject.org)
		(turning on Send SNI might fix this: Try It)
		So email is encrypted but the host is not verified
[...]
Cert Hostname DOES NOT VERIFY (smtp-mm-osuosl01.fedoraproject.org != bastion.fedoraproject.org | DNS:bastion.fedoraproject.org | DNS:smtp-mm-cc-rdu01.fedoraproject.org)
		(turning on Send SNI might fix this: Try It)
		So email is encrypted but the host is not verified

Additional infos from https://www.checktls.com/TestReceiver ``` [...] Cert Hostname DOES NOT VERIFY (smtp-mm-ib01.fedoraproject.org != bastion.fedoraproject.org | DNS:bastion.fedoraproject.org | DNS:smtp-mm-cc-rdu01.fedoraproject.org) (turning on Send SNI might fix this: Try It) So email is encrypted but the host is not verified [...] Cert Hostname DOES NOT VERIFY (smtp-mm-osuosl01.fedoraproject.org != bastion.fedoraproject.org | DNS:bastion.fedoraproject.org | DNS:smtp-mm-cc-rdu01.fedoraproject.org) (turning on Send SNI might fix this: Try It) So email is encrypted but the host is not verified ```

germano commented

2025-04-16 12:58:49 +00:00

Author

learndmarc.com output I got by passing the email headers (taken from my gmail account) corresponding to the message
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/message/Y3SEQTPGMJJHTLHRJV6WIS6UIR6YOFS6/

DMARC Results

--- Connection parameters ---
Source IP address: 38.145.60.11
Hostname: bastion.fedoraproject.org
Sender: users-bounces@lists.fedoraproject.org

--- SPF ---
Domain: lists.fedoraproject.org
Identity: RFC5321.MailFrom
Auth Result: PASS
DMARC Alignment: fedoraproject.org != gmail.com

--- DKIM ---
Domain: n/a
Selector: n/a
Algorithm: n/a
Auth Result: none
DMARC Alignment: n/a

--- DMARC ---
RFC5322.From domain: gmail.com
Policy (p=): none
SPF: FAIL
DKIM: FAIL
DMARC Result: FAIL

--- Final verdict ---
The DMARC disposition is set to 'none'. This means that DMARC does not take any specific action regarding the delivery of the message. In most cases, this indicates that the message will be delivered successfully. However, it's important to remember that other mechanisms, such as a spam filter, can still reject or quarantine a message.

---------------------
Thanks for using learndmarc.com
This free service is brought to you by URIports.com - DMARC Monitoring Reinvented.

for comparison, this is the learndmarc.com output you get by passing the headers of a message from kde-devel@kde.org mailing list, which never is classified as spam by GMail

DMARC Results

--- Connection parameters ---
Source IP address: 46.43.1.242
Hostname: letterbox.kde.org
Sender: kde-devel-bounces@kde.org

--- SPF ---
Domain: kde.org
Identity: RFC5321.MailFrom
Auth Result: PASS
DMARC Alignment: PASS

--- DKIM ---
Domain: kde.org
Selector: lists
Algorithm: rsa-sha256
Auth Result: PASS
DMARC Alignment: PASS

-- DKIM ---
Domain: kde.org
Selector: users
Algorithm: rsa-sha256
Auth Result: PASS
DMARC Alignment: PASS

--- DMARC ---
Warning: No DMARC record found – this can severely impact your email deliverability and harm your domain’s reputation!

RFC5322.From domain: kde.org
Policy (p=): reject (simulated)
SPF: PASS
DKIM: PASS
DMARC Result: PASS

--- Final verdict ---
DMARC does not take any specific action regarding message delivery. Generally, this means that the message will be successfully delivered. However, it's important to note that other factors like spam filters can still reject or quarantine a message.

---------------------
Thanks for using learndmarc.com
This free service is brought to you by URIports.com - DMARC Monitoring Reinvented.

learndmarc.com output I got by passing the email headers (taken from my gmail account) corresponding to the message https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/message/Y3SEQTPGMJJHTLHRJV6WIS6UIR6YOFS6/ ``` DMARC Results --- Connection parameters --- Source IP address: 38.145.60.11 Hostname: bastion.fedoraproject.org Sender: users-bounces@lists.fedoraproject.org --- SPF --- Domain: lists.fedoraproject.org Identity: RFC5321.MailFrom Auth Result: PASS DMARC Alignment: fedoraproject.org != gmail.com --- DKIM --- Domain: n/a Selector: n/a Algorithm: n/a Auth Result: none DMARC Alignment: n/a --- DMARC --- RFC5322.From domain: gmail.com Policy (p=): none SPF: FAIL DKIM: FAIL DMARC Result: FAIL --- Final verdict --- The DMARC disposition is set to 'none'. This means that DMARC does not take any specific action regarding the delivery of the message. In most cases, this indicates that the message will be delivered successfully. However, it's important to remember that other mechanisms, such as a spam filter, can still reject or quarantine a message. --------------------- Thanks for using learndmarc.com This free service is brought to you by URIports.com - DMARC Monitoring Reinvented. ``` for comparison, this is the learndmarc.com output you get by passing the headers of a message from kde-devel@kde.org mailing list, which never is classified as spam by GMail ``` DMARC Results --- Connection parameters --- Source IP address: 46.43.1.242 Hostname: letterbox.kde.org Sender: kde-devel-bounces@kde.org --- SPF --- Domain: kde.org Identity: RFC5321.MailFrom Auth Result: PASS DMARC Alignment: PASS --- DKIM --- Domain: kde.org Selector: lists Algorithm: rsa-sha256 Auth Result: PASS DMARC Alignment: PASS -- DKIM --- Domain: kde.org Selector: users Algorithm: rsa-sha256 Auth Result: PASS DMARC Alignment: PASS --- DMARC --- Warning: No DMARC record found – this can severely impact your email deliverability and harm your domain’s reputation! RFC5322.From domain: kde.org Policy (p=): reject (simulated) SPF: PASS DKIM: PASS DMARC Result: PASS --- Final verdict --- DMARC does not take any specific action regarding message delivery. Generally, this means that the message will be successfully delivered. However, it's important to note that other factors like spam filters can still reject or quarantine a message. --------------------- Thanks for using learndmarc.com This free service is brought to you by URIports.com - DMARC Monitoring Reinvented. ```

mschwarz commented

2025-04-19 17:43:41 +00:00

one view to the TXT record and you see the lack of a DMARC entry.

You can use this one to get rid of google:

"v=DMARC1; p=none;"

one view to the TXT record and you see the lack of a DMARC entry. You can use this one to get rid of google: "v=DMARC1; p=none;"

zlopez commented

2025-04-23 13:09:58 +00:00

Contributor

I thought that adding DMARC on mailman would be enough, but it seems that we need to add it to DNS as well.

kevin commented

2025-04-23 23:20:11 +00:00

Well, in mailman thats mitigation for the sender of the email having DMARC (to avoid the lists sending as that user from our outgoing server, which would be rejected).

This is google being... google and demanding DMARC I guess.

We do have:

host -t txt _DMARC.fedoraproject.org
_DMARC.fedoraproject.org descriptive text "v=DMARC1; p=none; rua=mailto:dmarc-admin@fedoraproject.org; ruf=mailto:dmarc-admin@fedoraproject.org; fo=0"

for the base domain.

Outgoing emails from the list go via bastion and are signed, but from bastion, which might make something cranky.

I'm fine adding the none record for lists for now.

Well, in mailman thats mitigation for the sender of the email having DMARC (to avoid the lists sending as that user from our outgoing server, which would be rejected). This is google being... google and demanding DMARC I guess. We do have: host -t txt _DMARC.fedoraproject.org _DMARC.fedoraproject.org descriptive text "v=DMARC1; p=none; rua=mailto:dmarc-admin@fedoraproject.org; ruf=mailto:dmarc-admin@fedoraproject.org; fo=0" for the base domain. Outgoing emails from the list go via bastion and are signed, but from bastion, which might make something cranky. I'm fine adding the none record for lists for now.

germano commented

2025-04-25 13:02:45 +00:00

Author

Mailman "munging" (which is enabled on KDE lists) description from chatgpt o3
https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/dmarc-mitigations.html

What “munging” the From: header means

“Munging” (literally “to mangle or scramble”) is the act of rewriting the From: field by the mailing-list software.
When this option is enabled, Mailman takes the original message and:

Replaces the sender address

From: Mario Rossi <mario@example.com>

becomes, for example

From: Mario Rossi via ListName <listname@lists.domain.org>

Moves the author’s real address into Reply-To: (or sometimes Cc:) so that replies can still reach the original poster.

The end result is that, after the list relays the mail, the domain in From: matches the domain of the server actually sending it; SPF and DKIM are therefore “aligned,” and the message passes DMARC checks.

Why it’s done

List servers add footers, tweak the subject, and modify headers → the author’s DKIM signature no longer verifies.
The list server’s IP is usually not in the author’s SPF record.
If the author’s domain publishes a strict DMARC policy (p=quarantine / reject), recipients such as Gmail or Yahoo would reject or spam-folder the message.
By rewriting From: to use the list’s domain, SPF (and DKIM, if the list signs outgoing mail) now align with that domain, so DMARC passes.

Mailman documents this as the munge_from action in its “DMARC Mitigations” guide and the official wiki describes it as “Rewrite (Munge) the From: header … to avoid DMARC rejection.”

How to configure it in Mailman

Mailman 2.1
- from_is_list = Yes (old)
- or dmarc_moderation_action = Munge From (recommended in ≥ 2.1.18).
Mailman 3
- dmarc_mitigate_action = munge_from
- Optionally set dmarc_mitigate_unconditionally = Yes to apply it to all messages, or leave it off to affect only those from domains with strict DMARC.

Advantages

Excellent deliverability: messages from domains with strict DMARC don’t get rejected or spam-filtered.
No need to block posters from “gmail.com,” “yahoo.com,” etc.

Drawbacks

The From: header recipients see no longer shows the true author’s address; some users find this confusing.
Tools that rely exactly on From: (e.g., git am, certain mail filters) can break.
Strictly speaking it bends RFC 5322, which expects the real author in From: (though the practice is widely accepted).

In a nutshell

From munging simply changes the visible sender so the domain matches the mailing list’s domain, sidestepping DMARC blocks.
Mailman lets you enable it with a single setting—use it when deliverability matters more than keeping the From: header 100 % intact.

Mailman "munging" (which is enabled on KDE lists) description from chatgpt o3 https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/dmarc-mitigations.html ------------- ### What “munging” the **From:** header means *“Munging”* (literally “to mangle or scramble”) is the act of **rewriting the `From:` field by the mailing-list software**. When this option is enabled, Mailman takes the original message and: 1. **Replaces the sender address** ``` From: Mario Rossi <mario@example.com> ``` becomes, for example ``` From: Mario Rossi via ListName <listname@lists.domain.org> ``` 2. **Moves the author’s real address** into `Reply-To:` (or sometimes `Cc:`) so that replies can still reach the original poster. The end result is that, after the list relays the mail, **the domain in `From:` matches the domain of the server actually sending it**; SPF and DKIM are therefore “aligned,” and the message passes DMARC checks. --- #### Why it’s done * List servers add footers, tweak the subject, and modify headers → the author’s DKIM signature no longer verifies. * The list server’s IP is usually **not** in the author’s SPF record. * If the author’s domain publishes a strict DMARC policy (`p=quarantine` / `reject`), recipients such as Gmail or Yahoo would **reject or spam-folder** the message. * By rewriting `From:` to use the list’s domain, SPF (and DKIM, if the list signs outgoing mail) now align with that domain, so DMARC passes. Mailman documents this as the **`munge_from` action** in its “DMARC Mitigations” guide and the official wiki describes it as “Rewrite (Munge) the From: header … to avoid DMARC rejection.” --- #### How to configure it in Mailman * **Mailman 2.1** * `from_is_list = Yes` (old) * or `dmarc_moderation_action = Munge From` (recommended in ≥ 2.1.18). * **Mailman 3** * `dmarc_mitigate_action = munge_from` * Optionally set `dmarc_mitigate_unconditionally = Yes` to apply it to all messages, or leave it off to affect only those from domains with strict DMARC. --- #### Advantages * Excellent deliverability: messages from domains with strict DMARC don’t get rejected or spam-filtered. * No need to block posters from “gmail.com,” “yahoo.com,” etc. #### Drawbacks * The `From:` header recipients see **no longer shows the true author’s address**; some users find this confusing. * Tools that rely exactly on `From:` (e.g., `git am`, certain mail filters) can break. * Strictly speaking it bends RFC 5322, which expects the real author in `From:` (though the practice is widely accepted). --- ### In a nutshell *From munging* simply **changes the visible sender** so the domain matches the mailing list’s domain, sidestepping DMARC blocks. Mailman lets you enable it with a single setting—use it when deliverability matters more than keeping the `From:` header 100 % intact.

kevin commented

2025-04-28 18:51:15 +00:00

We already have dmarc mitigation enabled for all lists. We have it set to do mitigations when the sending domain has a reject or quarantine setting.
I don't think we want to enable it unconditionally.

I've added a placeholder DMARC txt record to hopefully fix things. Please test.

We already have dmarc mitigation enabled for all lists. We have it set to do mitigations when the sending domain has a reject or quarantine setting. I don't think we want to enable it unconditionally. I've added a placeholder DMARC txt record to hopefully fix things. Please test.

kevin commented

2025-04-30 21:43:34 +00:00

So, any change for anyone?

germano commented

2025-04-30 22:08:40 +00:00

Author

I don't see much improvement. This message sent yesterday has still been classified as spam

DMARC Results

--- Connection parameters ---
Source IP address: 38.145.60.11
Hostname: bastion.fedoraproject.org
Sender: devel-bounces@lists.fedoraproject.org

--- SPF ---
Domain: lists.fedoraproject.org
Identity: RFC5321.MailFrom
Auth Result: PASS
DMARC Alignment: fedoraproject.org != redhat.com

--- DKIM ---
Domain: n/a
Selector: n/a
Algorithm: n/a
Auth Result: none
DMARC Alignment: n/a

--- DMARC ---
RFC5322.From domain: redhat.com
Policy (p=): quarantine
SPF: FAIL
DKIM: FAIL
DMARC Result: FAIL

--- Final verdict ---
The DMARC disposition is set to 'quarantine'. The recipient treats the message with suspicion, which can lead to various actions based on the recipient's capabilities. These actions may include placing the message in the spam folder, subjecting it to heightened scrutiny, or flagging it as suspicious.

---------------------
Thanks for using learndmarc.com
This free service is brought to you by URIports.com - DMARC Monitoring Reinvented.

I don't see much improvement. [This message](https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2XGFPFLDNPVIIVXVQG4MELWXQIXSOUUD/) sent yesterday has still been classified as spam ``` DMARC Results --- Connection parameters --- Source IP address: 38.145.60.11 Hostname: bastion.fedoraproject.org Sender: devel-bounces@lists.fedoraproject.org --- SPF --- Domain: lists.fedoraproject.org Identity: RFC5321.MailFrom Auth Result: PASS DMARC Alignment: fedoraproject.org != redhat.com --- DKIM --- Domain: n/a Selector: n/a Algorithm: n/a Auth Result: none DMARC Alignment: n/a --- DMARC --- RFC5322.From domain: redhat.com Policy (p=): quarantine SPF: FAIL DKIM: FAIL DMARC Result: FAIL --- Final verdict --- The DMARC disposition is set to 'quarantine'. The recipient treats the message with suspicion, which can lead to various actions based on the recipient's capabilities. These actions may include placing the message in the spam folder, subjecting it to heightened scrutiny, or flagging it as suspicious. --------------------- Thanks for using learndmarc.com This free service is brought to you by URIports.com - DMARC Monitoring Reinvented. ```

mschwarz commented

2025-05-04 22:16:46 +00:00

And noone wonders, why it complains that fedoraproject is not redhat.com?

The link to a website without headers of that email, does not help, so i searched the mail on the dev-ml.

I checked SPF for both domains, and from the fact, that redhat.com got named, i have to assume and checked with the original mail to the list, that it's the original senderdomain which has been used to send over bastion, which must fail, as bastion is not listed in redhat.com's SPF entry.

fedoraprojects and redhats dmarc entries are syntactically valid and the report names SPF as failed.

BTW: pagure.io is used as a sender domain for the FI-ML and does not have SPF at all. Maybe someone wants to fix this or gmail won't take those mails either.

Conclusion: x@redhat.com is not allowed to be send over bastion by SPF..

Solution: Introduce SRS or add bastion to redhat's SPF entry (way easier).

2.BTW: Why did DKIM failed for the reporting tool? I checked the original mail and DKIM is correct. At least that should have passed. (note: dkim is dns based and dns can fail)

And noone wonders, why it complains that fedoraproject is not redhat.com? The link to a website without headers of that email, does not help, so i searched the mail on the dev-ml. I checked SPF for both domains, and from the fact, that redhat.com got named, i have to assume and checked with the original mail to the list, that it's the original senderdomain which has been used to send over bastion, which must fail, as bastion is not listed in redhat.com's SPF entry. fedoraprojects and redhats dmarc entries are syntactically valid and the report names SPF as failed. BTW: pagure.io is used as a sender domain for the FI-ML and does not have SPF at all. Maybe someone wants to fix this or gmail won't take those mails either. Conclusion: x@redhat.com is not allowed to be send over bastion by SPF.. Solution: Introduce SRS or add bastion to redhat's SPF entry (way easier). 2.BTW: Why did DKIM failed for the reporting tool? I checked the original mail and DKIM is correct. At least that should have passed. (note: dkim is dns based and dns can fail)

mschwarz commented

2025-05-04 22:20:14 +00:00

spfquery --scope mfrom --id x@redhat.com --ip 38.145.60.11

fail
Please see http://www.openspf.org/Why?s=mfrom;id=x%40redhat.com;ip=38.145.60.11;r=c1.resellerdesktop.de
redhat.com ... 73t7ezjz._spf._d.mim.ec: Sender is not authorized by default to use 'x@redhat.com' in 'mfrom' identity (mechanism '-all' matched)
Received-SPF: fail (redhat.com ... 73t7ezjz._spf._d.mim.ec: Sender is not authorized by default to use 'x@redhat.com' in 'mfrom' identity (mechanism '-all' matched)) receiver=xxx.resellerdesktop.de; identity=mailfrom; envelope-from="x@redhat.com"; client-ip=38.145.60.11

QED

# /usr/bin/spfquery --scope mfrom --id x@redhat.com --ip 38.145.60.11 fail Please see http://www.openspf.org/Why?s=mfrom;id=x%40redhat.com;ip=38.145.60.11;r=c1.resellerdesktop.de redhat.com ... 73t7ezjz._spf._d.mim.ec: Sender is not authorized by default to use 'x@redhat.com' in 'mfrom' identity (mechanism '-all' matched) Received-SPF: fail (redhat.com ... 73t7ezjz._spf._d.mim.ec: Sender is not authorized by default to use 'x@redhat.com' in 'mfrom' identity (mechanism '-all' matched)) receiver=xxx.resellerdesktop.de; identity=mailfrom; envelope-from="x@redhat.com"; client-ip=38.145.60.11 QED

kevin commented

2025-05-05 16:03:50 +00:00

The problem here seems to be redhat.com doesn't trigger the mailman dmarc mitigation (because dmarc policy on redhat.com doesn't require it, but then the email hits SPF issues.

There is almost no chance that redhat.com will add us as a sender in SPF records.

The problem here seems to be redhat.com doesn't trigger the mailman dmarc mitigation (because dmarc policy on redhat.com doesn't require it, but then the email hits SPF issues. There is almost no chance that redhat.com will add us as a sender in SPF records.

mschwarz commented

2025-05-06 07:52:42 +00:00

than there is only one solution left: SRS (Sender Rewriting Scheme)

Rewriting the sender to an allowed form with a working domain, so SPF will pass.

than there is only one solution left: SRS (Sender Rewriting Scheme) Rewriting the sender to an allowed form with a working domain, so SPF will pass.

kevin commented

2025-05-06 17:00:34 +00:00

Right and the only way I see to do that is to enable the mailman dmarc mitigation always. I guess we can do that but it might confuse some people.

kevin commented

2025-05-06 17:01:42 +00:00

Is the devel list the only place folks are seeing this issue?

Rows
Columns

fix DNS configuration of lists.fedoraproject.org to stop email messages being classified as spam #12487

Mailman "munging" (which is enabled on KDE lists) description from chatgpt o3 https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/dmarc-mitigations.html

What “munging” the From: header means

Why it’s done

How to configure it in Mailman

Advantages

Drawbacks

In a nutshell

/usr/bin/spfquery --scope mfrom --id x@redhat.com --ip 38.145.60.11

Mailman "munging" (which is enabled on KDE lists) description from chatgpt o3
https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/dmarc-mitigations.html