@Laudian this screenshot how it looks like after update. I create it without this whitespace but when I press edit button it shows with this whitespace. Also, right after update when I dig it I got answer with whitespace.
That’s completely normal, TXT records are automatically split every 255 characters. You can dig any DKIM record you want, they all have this whitespace if they are longer than 255 characters.
This is correct. DNS strings are limited to a maximum of 255 bytes; the quotes just make that more explicit. There is no difference either way in how these records are served at the edge. The only difference is that with quotes, the splitting is done directly in the API, so you can see it happening and have control over it.
The quoted representation is the more correct and unambiguous one (because its behavior is clearly defined by RFC 1035) while the unquoted representation is always interpreted as a single string. Something like hello world (not quoted) would be two strings per RFC 1035 (and the space character would be discarded), but in our case would be interpreted as one string (with the space character). It’s also not clearly specified how exactly escape sequences and special characters would behave in an unquoted content. Quoting solves all of that ambiguity: the record content will exactly match what you see in, e.g., DiG’s output, and what you’d see in a zone file export.
In the future we may improve the UI to make it easier to edit quoted records with multiple strings (or at least to avoid confusion around the intermediate extra quotes). Suggestions around that are always welcome—I’ll pass them along!
In the meantime, I’d recommend keeping the quotes. They make the split more explicit and reduce ambiguity without actually changing anything about your record at the edge.
-