Skip to content

Current receiver architecture enforces SPF before DMARC, which can result in emails getting unnecessarily bounced

I've been experimenting with mailing lists in order to better understand the consequences of !343. Here's what I've learned:

The advice in https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html works with gmail.com. In this example, the sender's domain has a very strict SPF policy (-all), which excludes the IP address of the mailing list server that's forwarding this email to gmail.com. Note how there's a SPF fail, but DMARC still passes:

image

This is because DMARC only requires SPF or DKIM to pass, it require both of them to pass:

A message satisfies the DMARC checks if at least one of the supported authentication mechanisms:

https://datatracker.ietf.org/doc/html/rfc7489#section-4.2

Note: "authentication mechanisms" are defined in https://datatracker.ietf.org/doc/html/rfc7489#section-4.1 (the only 2 are "DKIM" and "SPF").

However, this same email is rejected by my simple-nixos-mailserver with a message like this:

Recipient address rejected: Message rejected due to: SPF fail - not authorized. Please see http://www.openspf.net/Why?s=mfrom;id=[REDACTED];ip=[REDACTED];r=[REDACTED] (in reply to RCPT TO command)

The DMARC RFC7489 actually does call this out as a potential issue. From https://datatracker.ietf.org/doc/html/rfc7489#section-10.1:

Some receiver architectures might implement SPF in advance of any DMARC operations. This means that a "-" prefix on a sender's SPF mechanism, such as "-all", could cause that rejection to go into effect early in handling, causing message rejection before any DMARC processing takes place. Operators choosing to use "-all" should be aware of this.

My understanding is that this reflects simple-nixos-mailserver's current receiver architecture.

This is a pretty loose statement: it doesn't say that this is an incorrect receiver architecture, but it does prevent domains from using stricter SPF rules. Is simple-nixos-mailserver's current receiver architecture intentional? Would you be open to changing it to not bounce emails that fail SPF but pass DMARC?