I can't comment on this specific scenario as there are unknowns such as rate-limiting by the server (see comment by JonasCz), entropy of the serial keys, etc. Here is a general approach to considering this when protecting your own systems.
Each of the ? in the serial key can take one of a number of values as defined by an alphabet. For example, binary alphabet limits them to [0,1], hex limits them to [0-F], etc. The cardinality (c) of the alphabet is simply the number of options; binary = 2, hex = 16, and so on. There are 20 ? so, best case for protection, we have c^20 possible choices from which to guess (assuming a good entropy source for their original generation).
- There are probably limitations on the actual choices in the form of checksums or authentication codes to validate a particular serial number. For example, the last 4 characters may be a truncated HMAC of the preceding ones, with security provided by the HMAC's key. There may simply be a non-cryptographic checksum which doesn't have a secret key.
- A variant of the birthday problem - we're not looking to match a specific serial number. There are a set of true serial numbers and a set of guessed ones; an intersection of these sets that is not empty is a success.
Once we have reduced the search space given the caveats we can assess the feasibility of the brute-force attack with this excellent calculation. ("Thermodynamic Limitations" in Schneider B. Applied Cryptography pp. 157‐8).