Sender verification failed when zone has DNSSEC issues

Apr 14, 2026
2
0
1
AT
Hello,

I have been a Proxmox Mail Gateway user for many years, but only became a forum member today. Unfortunately, only today (far too late, admittedly) I noticed that there were DNSSEC issues with one of my DNS zones. The zone itself hasn’t changed for quite some time, and the pre-signed zone that was transferred to the slaves has expired. So far, so “good”.

However, I then noticed that during this period my Proxmox MG setup refused to validate recipient addresses.
Code:
2026-04-10T16:52:04.585680+02:00 transport postfix/smtpd[617331]: connect from p-west3-cluster1-host2-snip4-4.eps.apple.com[57.103.73.145]
2026-04-10T16:52:05.248117+02:00 transport postfix/smtpd[617331]: Anonymous TLS connection established from p-west3-cluster1-host2-snip4-4.eps.apple.com[57.103.73.145]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
2026-04-10T16:52:05.632378+02:00 transport postfix/smtpd[617331]: NOQUEUE: reject: RCPT from p-west3-cluster1-host2-snip4-4.eps.apple.com[57.103.73.145]: 450 4.1.2 <user@example.org>: Recipient address rejected: Domain not found; from=<privaterelay.bounce.zxt6rh22n8@privaterelay.appleid.com> to=<user@example.org> proto=ESMTP helo=<outbound.ms.icloud.com>
2026-04-10T16:52:05.798969+02:00 transport postfix/smtpd[617331]: disconnect from p-west3-cluster1-host2-snip4-4.eps.apple.com[57.103.73.145] ehlo=2 starttls=1 mail=1 rcpt=0/1 data=0/1 rset=1 quit=1 commands=6/8

The problem with my zone was quickly identified by https://dnssec-debugger.verisignlabs.com/, namely:
Code:
RRSIG=14006 is expired
(The cause was that after migrating the DNS master, I forgot to reinstall/activate/whatever a cron job that re-signs zones which do not change very often.)

Now to my actual question:
Why the "Recipient address rejected: Domain not found;"? Or to be more precice: "Why the "Domain not found"?

The mail server behind @example.org is located in a private network behind this PMG host and is configured in the transport configuration using its IP address, without “use MX”.So what causes the PMG host to perform any kind of DNS lookup here?

After updating the zone, everything started working again immediately.

Yes, my local resolver validates DNSSEC, and no, I didn’t notice this for five days (it’s a pure mail domain, and a few emails did get through).

Do you have any ideas on how to better understand this message, or whether I might have some kind of configuration mistake somewhere?
 
You mean on the final Mailserver behind?
Because PMG did not even try to connect to the backend host...
The PMGs
Code:
$ postconf -n  smtpd_recipient_restrictions
smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination reject_non_fqdn_recipient check_recipient_access regexp:/etc/postfix/rcptaccess check_sender_access regexp:/etc/postfix/senderaccess check_client_access cidr:/etc/postfix/clientaccess check_policy_service inet:127.0.0.1:10022 reject_unknown_recipient_domain reject_unverified_recipien

I'd guess that reject_unknown_recipient_domain somehow kicked in?
According to the Postfix documentation: (https://www.postfix.org/postconf.5.html#reject_unknown_recipient_domain)
reject_unknown_recipient_domain: Reject the request when Postfix is not final destination forthe recipient domain, and the RCPT TO domain has 1) no DNS MX andno DNS Arecord or 2) a malformed MX record such as a record witha zero-length MX hostname (Postfix version 2.3 and later).
Thereply is specified with the unknown_address_reject_code parameter(default: 450), unknown_address_tempfail_action (default:defer_if_permit), or 556 (nullmx, Postfix 3.0 andlater). See the respective parameter descriptions for details.

And as my Nameserver verifies DNSSEC, and was therefore unable to verify anything from that zone (might be missing in postfixes eyes i guess?)
All the other parts (that I understand):
permit_mynetworks -> was external; next
reject_unauth_destination -> destination is part of relay_domain; next
reject_non_fqdn_recipient -> was FQDN; next
check_recipient_access -> empty; next
check_sender_access -> did not match; next
check_client_access -> did not match; next
check_policy_service -> (don't know but i guess it was ok...)
reject_unknown_recipient_domain -> might be the issue as the destination DNSSEC Zone was expired and the resolver honored DNSSEC
reject_unverified_recipient -> unsure as I think the "recipient address destination" was always reachable (transport definitions are plain IP addresses after all)