There is no mathematical connection between the key exchange and the authentication part of the TLS handshake. TLS handshake just needs some way to do Diffie Hellman which is secure and some way to do end-point / counterparty authentication which is secure.
So you can do DHE with at least 2048bit group, or ECDHE with NIST P-256, or X25519 as the key exchange part, and you can do RSA with at least 2048bit key with PKCS#1 v1.5 padding or RSA-PSS padding, or ECDSA with NIST P-256, or in the future ed25519/ed448 as the authentication part. [1]
You are free to mix and match DHE with ECDSA, ECDHE with RSA, ECDHE and ECDSA with different curves, DHE and RSA with different number of bits, whatever.
Each algorithm has its own requirements for how to do it securely, as long as each part is secure you're good.
There is an argument that each part should match the strength of the others, as the weakest part will naturally be attacked so extra strength on the part which is not weakest is just wasted effort / resources (basically, don't invest in extremely strong door if you have paper walls).
So people say that if your TLS Record Protocol / bulk encryption have 128bit equivalent symmetric encryption and MAC (which is what you get with AES-128-GCM which is what you should be using), the key exchange and authentication should be about 128bit equivalent strength. This would be 256bit ECC (so exactly ECDHE and ECDSA with NIST P-256 or X25519 with Ed25519) or 3072bit RSA with DHE. But most people use 2048bit RSA (which is secure enough, though it is considered only 112bit symmetric equivalent). So you can use 2048bit DHE or 3072bit DHE. 4096bit DHE would be overkill, but would work.
Against the argument of matching algorithmic strength, I have to say that matching auth and key exchange strength is wrong because a certificate used only for auth needs only to stay unbroken until its date of expiry. Key exchange needs to stay unbroken as long as the confidentiality of the data needs to stay unbroken. So if 10 years from now the enemy can break your current certificate which is used only for auth, you don't really care because they can't MiTM your connections 10 years in the future using a certificate that by then has long expired. But if they can break the key exchange they can decrypt the data, and if the data needs to stay secret even 10 years from now, that's a problem. [2]
Thus, there is logic in making DHE stronger than the key of the certificate, and 3072bit DHE with only 2048bit RSA cert makes some sense, though most people don't need it.
In summary, use openssl dhparam 2048 to generate a file that postfix smtpd will use (configuration confusingly called smtpd_tls_dh1024_param_file). It's fine to use 2048, 3072 or 4096 here with any certificate. That command does take a while to finish, let it.
1 - You can even do PSK which is symmetric authentication instead of asymmetric authentication, but ~nobody does this. You can do RSA encryption to do both key exchange and auth, though you don't get forward secrecy so it's not allowed for HTTP/2 and in TLS 1.3 (and you shouldn't do this even when it's allowed).
2 - If you allow RSA key exchange that means the key for the certificate was used for key exchange and it needs to be kept safe for as long as data confidentiality matters, so no losing the keys for expired certificates on old hard drives you throw away. This is the argument for only support PFS cipher suites.
