I honestly would prefer to put this into the comments, but they don't leave much space.
Based on your reference to the Salesforce forum (maybe contrary to Sander de Jong) I assume you do not actually see "<SFMC_URL>" in your error message, but that this is meant as a placeholder for the actual URL, which is constantly the same.
It is very, very unlikely a Salesforce configuration or coding mistake causes an intermittent UnknownHostException. It is neither likely some Salesforce Marketing Cloud hostnames as such have sometimes the problem not be resolved by the DNS in general. The likely reason is that the DNS resolution of the box that runs your Java is unreliable. What I would do:
Make sure this Java box has two different DNS servers configured - a primary and a backup - and there is no question they're reliable and accessible. Check "Hardware and connection properties" (on my Windows 11) or /etc/resolv.conf (Unix/Linux).
To get rid of the dependency on the "not-so-extremely reliable" DNS servers of our employer, my colleagues and I used to configure the backup as 184.108.40.206, which is Google's free DNS. This is generally frowned upon for privacy reasons, but I can't think of any scenario, where this could harm your company's interests in the given case (assuming no other processes use name resolution on this box).
Temporarily I'd configure a static IP address for the given hostname in the /etc/hosts (Unix/Linux environment) resp. C:\Windows\System32\drivers\etc\hosts (many Windows systems) file. This should be a shortlived experiment, because Salesforce IPs can vary. But - say - it's not likely to happen in the next 12 hours. If you then see other, connection related error messages popping up, the most likely problem is that the Java box is not reliably connected to the internet at all or it has some problem with its own load.
All that being said, in theory Java should be fine. If the DNS doesn't cause troubles for a longer time period, the JRE remembers the IP of the host - at least, if such caching is configured properly in:
. Two properties are relevant in this context (see for example here):
networkaddress.cache.ttl . This can be interpreted as resulting from the ratio between the frequency of IP changes in the SF Marketing Cloud (very low) and the unreliability of the DNS (apparently elevated). I'd go for something high, say 120 seconds, but base this on the observation how often my hostname resolution works and how often not. It should definitely not be 0!
networkaddress.cache.negative.ttl. I'd set this to 0 or 1.
However this just sets defaults. I don't know anything regarding the environment Java is executed in your case. From what I can recall, Java application servers or Spring could have their own opinions on such variables and overwrite them application-specific during start-up.