Previous answers both tell part of the story here, but there's a few different aspects to understand.
Firstly, why do these code points exist? Unicode has the ambition to replace all previous ways of encoding text, which means it contains a lot of different types of script and symbol. Among those are things which look like letters (because they are) but are treated as symbols by mathematicians. For instance, U+211D DOUBLE-STRUCK CAPITAL R is the "ℝ" symbol used to represent "the set of all real numbers".
The code points used in your spam e-mail are from a block of these called Mathematical Alphanumeric Symbols.
Secondly, why do they get treated as "normal" letters in some contexts? Unicode defines a set of "normalization forms", because some natural characters can be represented more than one way with Unicode code points. For instance, "â" is code point U+00E2, but it can also be represented with "a" (U+0061) + the modifier U+0302 COMBINING CIRCUMFLEX ACCENT. "NFC" is a mapping which converts characters into "composed" forms where possible (e.g. [U+0061, U+0302] becomes U+00E2); "NFD" converts them into "decomposed" forms where possible (e.g. U+00E2 becomes [U+0061, U+0302]).
In this case, there is no difference in representation between "NFD" and "NFC", but there is an additional normalisation called "NFKC", which uses "compatibility" mappings. These are one-way mappings that select more common code points which are equivalent in usage, such as "ffi" (U+0066, U+0066, U+0069) as a replacement for the combined ligature "ﬃ" (U+FB03) - or in the current case, a standard Latin "u" (U+0075) for the mathematical symbol "𝙪" (U+1D66A).
How does this relate to URLs? The standard for handling Unicode in domain names is called "IDNA", and is quite a complicated standard. The relevant parts I was able to find are these:
- RFC 5890 specifies that all strings should be normalised according to NFC before use in domains. This would be relevant for some URLs, but not the code points we're looking at here.
- RFC 5892 lists a number of code points as "DISALLOWED": a domain name containing those code points is simply not allowed to exist. That list includes the code points we're looking at ("1D552..1D6A5; DISALLOWED").
- RFC 5894 clarifies that the disallowed code points are those which would change if they were normalised according to NFKC. It therefore suggests that user agents (e.g. browsers) might want to apply NFKC mappings on user input prior to treating it as a domain name.
So, as far as I can make out:
- "𝙪𝙯𝙣𝙙𝙧𝙚𝙨𝙨.COM" is not a valid domain name
- a browser encountering it is allowed to transform it to "uzndress.com" rather than displaying an error (just as it transforms the "COM" to lower-case "com")
As a final note, which you didn't ask, but is worth discussing: why did the spam e-mail use this domain, if it's not valid? The reason is that if a spam filter looks only at the text of messages, without applying a mapping such as NFKC, different "spellings" of the same domain may not trip the filter. So using these code points is the same as writing "uZnDreSs.cOm" and hoping that the spam filter doesn't apply case folding.
Note that this is a different issue than that of IDN homograph attacks where visually similar code points can be used in valid domain names, such as "еbаy.com", which looks like "ebay.com" but is actually a different domain, mixing Latin and Cyrillic letters. (NFKC does not convert Cyrillic to Latin, as they are different alphabets which happen to have some visually similar letters.)