Re: Sendmail and DKIM for bounce messages?

On 3/12/25 10:52 AM, Otto J. Makela wrote:

We have servers which send out emails using a client domain: clients have set up SPF records that allow us to do this, and DKIM keys have been set up so our Sendmail/OpenDKIM smarthost setup can sign the messages correctly. When mail gets delivered normally, everything is OK.

I don't know if it matters, but I feel I should ask, do the SPF records authorize the originating servers and / or the smarthost?

However, there are issues when message bounces are generated for our smarthost, and it tries to deliver it to the sender the customer used.

Please clarify which system is rejecting the incoming message and which system is the system obliged to send the DSN?
Is the smart host not accepting the message from the original sending host and thus the original sending host is obliged to generate the DSN?
Or is the recipient's MX not accepting the message from the smart host and thus the smart host is obliged to generate the DSN?
You indicate that the DSN is from the null reverse path and going to the original envelope sender.
What are the From: and To: headers in the DSN?

Apparently, the setup I currently have does not DKIM sign messages where the sender is the classic email bounce empty sender <>

I don't remember the last time I saw a DKIM signed DSN.  But I don't remember ever looking.

This means that messages will languish in the mail queue for days if the client's email systems (typically M365, Google or some such large email handler) will not accept them, and then cause double bounces.

Please share a sample rejection reason from the recipient's MX.
I'd think that for any message; DSN or otherwise, to get stuck in queue until it expires, the receiving system would have to return temporary failures.  If the receiving system returned permanent failures, the DSN would turn into a double bounce immediately.
I'm trying to deduce the actual email flow and full responses at each step and think about how SPF / DKIM / DMARC would influence things.

Is this just some configuration option I need to change, or what?

I don't know.
I need more specifics to be able to speculate.
The only thing that comes to mind is that the DSN recipient's receiving system is rate limiting as an anti-spam measure and the drain queue rate is slower than the queue fill rate, thus the backup -> eventual overflow of DSNs in the queue.
--
Grant. . . .