The problem is that postbank.de uses name servers that send responses that are subtly untrue (bad type bitmaps in NSEC3) that cause problems for resolvers implementing an extremely aggressive version of RFC 8198 Aggressive Use of DNSSEC-Validated Cache. As far as I am aware, the only resolver that uses DNSSEC type bitmaps for synthesis is the open source Knot resolver, which Cloudflare uses for their 220.127.116.11 service. The problematic name servers are F5 devices used for postbank.de and other domains (the DNS violations tracker issue includes a number of Czech domains, presumably since Knot is a Czech product and is more commonly used there).
You are not seeing the DNSSEC records for any postbank.de domains from 18.104.22.168 because Cloudflare has disabled DNSSEC for postbank.de because of this incompatibility. Since it doesn’t query for the DNSSEC records, it cannot return them.
See the Problem with oneplus.com and postbank.de thread for more gory technical details (note that oneplus.com is not affected by this issue).
You can use any other DNSSEC-validating resolver, such as Google (22.214.171.124), Verisign (126.96.36.199), or Quad9 (188.8.131.52) to resolve these domains with DNSSEC records.
If you strongly prefer Cloudflare, consider opening a feature request issue for the Knot resolver to allow disabling the aggressive DNSSEC cache feature for particular domains without disabling DNSSEC validation entirely. Google’s resolver has this capability (see this example with even gorier technical details). and it is a poor operational response to disable the security features of DNSSEC (which are working for these domains) because F5 name servers are breaking the aggressive use of DNSSEC negative response cache.
Knot resolver has a few related issues already, but they are about fixing the aggressive negative caching, not enabling more nuanced operational responses.