Referencing this: https://crypto.stackexchange.com/questions/72297/recommended-key-size-for-dkim
What I get from this is (at the time) DNS providers (usually) allow for up to 1024 bit keys but not 2048 bit. Now, my provider does let me use 2048 and confirmed DKIM signs. Of course, the post claims 1024 is perfectly safe, but if I have the option to use 2048 I'd like to.
Am I good to go, so long as my provider supports that big of a TXT record? Or could there still be issues?
This depends on your use case. The stated purpose of DKIM is to verify the authenticity of the message. If this is the case, it is generally accepted to use 2048-bit RSA keys. The DNS server consideration is for your authoritative nameserver, so if that accepts entering records longer than 255 characters, the only consideration is receiving servers that can accept the mult-string record and support 2048-bit.
If, for some reason, there are receiving servers that cannot read the record or support larger than 1024-bit, then you could create new DKIM keys with associated new selector, as often as desired, say every day, making the probability of a key being compromised very low, since the message is usually authenticated within seconds of receipt.
There is also the option of Ed25519 keys, but this is not yet broadly supported by receiving servers.
If your use case is proof of work for passing various antispam tests, you probably could get away with 1024-bit if 2048-bit is causing problems. There are still large companies using 1024-bit, notably Substack and I know I've seen others.
Last but not least, the DKIM standard supports multiple signature headers, so depending on server overhead you could sign using multiple signatures and the receiving server can choose which signature to authenticate against.