Q: Why do my lists sometimes generate spoofing complaints and what should I do about them?

List owners might sometimes see these types of entries about spoofing in their daily error monitoring reports or hear from mail administrators complaining that LISTSERV is spoofing their domain.

550 Rejected by header based Anti-Spoofing policy

Typically, what "spoofing" means in this context is that LISTSERV is distributing mail from a user, with the user's original "From" address intact. LISTSERV does indeed do this, and, in fact, is normally required to do this by email standards (specifically section 3.6.2 of RFC 5322, which specifies that the "From" address must belong to "the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message").

While it's questionable how appropriate a negative term like "spoofing" is for what LISTSERV does in this situation, you may still get questions about it. Here is some information that can help you investigate and handle these sorts of situations.

DMARC Problems

There is a widely supported type of policy that domains can publish called DMARC. This allows the owners of domains to say which mail servers are allowed to send mail from their domains. In this case, "from" specifically refers to the address found in the "From:" header of messages and not to the return path or any other headers.

It also says what should happen if mail is received from other mail servers. The three types of DMARC policies are "p=none", meaning that no adverse action should be taken; "p=reject", meaning that the message should be rejected; and "p=quarantine", which means that the message should be treated as suspicious.

This means that if LISTSERV distributes a message from an email address whose domain has a "p=reject" or "p=quarantine" DMARC policy, and keeps the original "From:" header intact, then many of the list subscribers' mail servers will probably reject the message, resulting in errors complaining of spoofing and/or DMARC violations. If this happens often enough, you could start seeing subscribers being removed due to the repeated bounces.

To avoid this, LISTSERV rewrites the "From:" address of messages coming from domains with a "p=reject" or "p=quarantine" DMARC policy.

Additional information about this feature can be found in Section 13.3 - How does LISTSERV comply with DMARC in the LISTSERV Advanced Topics Manual.

However, in rare cases, a situation could arise where a domain has a DMARC "p=reject" or "p=quarantine" record, but LISTSERV isn't able to find the record for some reason, and therefore doesn't know it should rewrite the address.

To see if that's the problem with a particular bouncing message, look at the address of the message's original sender, and check its DMARC policy using an online tool like this one:

If the domain has a policy, it will typically contain one of "p=none", "p=reject" or "p=quarantine".

If it does find a DMARC record, then you can check whether LISTSERV is able to find the same record using the "debug query txt" command described in
Section 13.4 - Debugging DMARC errors in LISTSERV of the Advanced Topics Manual.

If it doesn't find the record or reports an incorrect version of it, then contact L-Soft support with the results of your investigation and we will advise on how to proceed.

If LISTSERV is seeing the correct DMARC record, then the problem should not be DMARC-related.

Mail Policy Problems

In some cases, mail administrators for a domain will institute a policy that they will only accept mail from their own domain if it comes from their own mail servers. Then, whenever someone from that domain posts a message to a mailing list, any subscribers from that domain won't get the message, and instead you'll see the message bouncing for those subscribers.

Since LISTSERV is not doing anything wrong here – it is following all applicable standards, as well as common practice – this is best addressed by the domain's administrators. Some ways this can be handled, include:

  • The domain's mail administrators could change their mail servers' policies so that they accept these types of messages instead of bouncing them.
  • The administrators of the affected domain could change their DMARC record to "p=reject", at which point LISTSERV would start rewriting mail from them, as described above and in Section 13.3 - How does LISTSERV comply with DMARC of the Advanced Topics Manual.
  • Subscribers from the affected domain may wish to subscribe using an email address at a domain that doesn't experience this problem.

Next Steps

© L-Soft 2022. All Rights Reserved.