There are a number of factors involved here.
First, UDP's maximum payload size is 65535. However, the IPv4 header and UDP header count as part of that 65535, so practically speaking, the maximum user-payload size is 65504.
Second, you can't receive more than the smallest receive buffer at any level in the stack. I could explain how to get around this, but I won't, because…
Finally, any packet larger than a single MTU will get fragmented along the way. Unless the fragments just happen to arrive in exactly the same order they were sent, and without any sizable delay, they cannot be reassembled, so you will lose the entire packet. Even on a connection with only 1% Ethernet packet loss, you can expect more than a third of your large UDP packets to be lost. There are very few applications where this is acceptable.
So, what should you do? Well, there are three different answers:
- Set up a dedicated network that can guarantee near-perfect reliability.
- Write your own protocol to sit on top of UDP and break up large packets into MTU-sized packets.
- Just use TCP instead of UDP.
There are some cases where option 2 makes sense—e.g., with many streaming A/V protocols, the audio frames, video iframes, and metadata are all under 1K, and can usually be dropped with no major consequence, so it's not worth the cost of using TCP just to deal with the keyframes, so instead they break the keyframes up into 1K chunks (e.g., rectangular sections of the window) or write explicit TCP-esque check-and-resend code just for keyframes, etc.
But usually, if you need to send large messages around, TCP is going to be a lot easier.