Multiple quoted strings in a DKIM lookup do not by themselves mean the key is damaged. Distinguish several strings within one TXT record from several TXT records at the same owner name. Concatenating the entire lookup output can mix different keys.
Concatenation stops at the record boundary
RFC 6376 TXT handling describes joining strings in order within a record. Read Cloudflare’s long-TXT handling within that boundary. Two resolvers need not display identical quoted chunks; compare reconstructed values and the number of answer records.
A small parser reading length bytes and strings joined the test input 04 part 03 2nd into part2nd and rejected a length exceeding the remaining bytes. This is a TXT-format boundary test. part2nd is not a DKIM public key, and the result does not establish a valid mail signature.
Build the owner name from the actual selector
dig TXT selector1._domainkey.example.com +noall +comments +answer +authority
dig NS example.com +shortexample.com and selector1 are placeholders. First check the signing domain in d=, the selector in s=, and the record type required by the mail provider. If the provider requires a CNAME, do not substitute TXT arbitrarily. Also check for a duplicated zone suffix and verify the actual authoritative delegation.
Distinguish NXDOMAIN, NOERROR without a TXT answer, and SERVFAIL as absent name, absent answer of that type, and lookup failure. Do not treat all three as a mistyped key. Keep TTLs and query times and compare authoritative data with recursive caches. TXT troubleshooting is not a matter of applying the web-proxy toggle used for A, AAAA or CNAME traffic.
Once DNS is correct, inspect the receiving system’s Authentication-Results and selector on a new test message. DNS resolution, DKIM verification and DMARC alignment are separate outcomes. Account for the existing sending path and cache lifetime when rotating keys. This article does not report a successful real delivery test.