Mailrouting anhand der Absenderadresse

I do not think you will find this feature, as the definition of "Sender" is so complicated:

• Is it the envelope sender or the Message's "From" header?
• Should senders be handled differently based on whether they pass or fail authentication?
• Which authentication method is required?  SPF alone? DMARC only?  Something else?

It is not clear what a vendor would be expected to implement.

- - - - - - 

However, I have considered this approach to partitioning my incoming mail:

• Primary MX requires TLS encryption
• Alternate MX performs StartTLS (best-effort)

Traffic to the alternate MX could have different Spam Filtering rules on the theory that the unencryted messages are higher risk.

However, after evaluating traffic that was blocked or allowed based only heuristic rules, I found that the percentage of encrypted spam was only slightly lower than the percentage of accepted mail.   So it did not appear that my spam blocking rate could be significantly improved based on this partition.  Additionally, I could not define a strategy for spam filtering configuration that would benefit from knowing that the traffic was pre-filtered based on encryption.

Given GDPR, I expect encrypted spam percentages to grow, because the spammers will still want to attack European servers that require TLS 1.2 encryption for everything.

Of course, any attempt to partition incoming mail also creates uncertainty.  If the primary MX rejects a connection, the recipient cannot know for certain whether the sending system will interpret it as:

• a reason to try the other server
• as a reason to wait and retry the same server later, or
• a reason to go away permanently.

Sorry if this long digression has no value to the original question.  

I do not think you will find this feature, as the definition of "Sender" is so complicated:

• Is it the envelope sender or the Message's "From" header?
• Should senders be handled differently based on whether they pass or fail authentication?
• Which authentication method is required?  SPF alone? DMARC only?  Something else?

It is not clear what a vendor would be expected to implement.

- - - - - - 

However, I have considered this approach to partitioning my incoming mail:

• Primary MX requires TLS encryption
• Alternate MX performs StartTLS (best-effort)

Traffic to the alternate MX could have different Spam Filtering rules on the theory that the unencryted messages are higher risk.

However, after evaluating traffic that was blocked or allowed based only heuristic rules, I found that the percentage of encrypted spam was only slightly lower than the percentage of accepted mail.   So it did not appear that my spam blocking rate could be significantly improved based on this partition.  Additionally, I could not define a strategy for spam filtering configuration that would benefit from knowing that the traffic was pre-filtered based on encryption.

Given GDPR, I expect encrypted spam percentages to grow, because the spammers will still want to attack European servers that require TLS 1.2 encryption for everything.

Of course, any attempt to partition incoming mail also creates uncertainty.  If the primary MX rejects a connection, the recipient cannot know for certain whether the sending system will interpret it as:

• a reason to try the other server
• as a reason to wait and retry the same server later, or
• a reason to go away permanently.

Sorry if this long digression has no value to the original question.