Publish a long TXT value without adding unintended quotes or spaces

Copy the value from the provider's authenticated setup page and identify its record name and purpose. Record any existing TXT records at that name. A DNS name can legitimately have several unrelated TXT records, but separate TXT records are not the same as chunks inside one record.

1. Check the DNS editor's instructions for long values. Many interfaces accept one long value and split it into DNS character-strings automatically.
2. Avoid copying decorative quotation marks, line numbers or wrapped email formatting into the value. A displayed quote may be presentation syntax rather than a literal character to store.
3. Where manual chunking is required, keep each DNS character-string within its 255-octet limit and follow the provider's format. Do not introduce a space at a chunk boundary unless the original logical value contains one.
4. Save one intended logical record. For SPF, do not create several separate v=spf1 records at the same owner name as a way to split a long policy.
5. Query the record and compare the reconstructed value using the consuming protocol's rules. DKIM and SPF combine the strings within a record without adding separators.

In BIND zone-file notation, one TXT record can contain multiple quoted character strings. This short artificial example demonstrates joining, not a real verification or mail-authentication token. Follow your DNS provider's editor format when entering a long value.

_verify.example.com.  300  IN  TXT  "verification=abc" "def123"

dig _verify.example.com TXT +noall +answer

Read the result: The two strings represent the continuous value verification=abcdef123 for a protocol that concatenates them. No extra space is inserted between the chunks. Adding a space inside a quoted string changes the content. Separate TXT records are not automatically equivalent to chunks within one record.

Many web editors split long values automatically and expect the raw token without zone-file quotation marks. Compare the retrieved content with the provider's original value character for character. Preserve unrelated TXT records and avoid pasting a long value through software that replaces straight quotes with decorative quotes.

Run the provider's domain verification or authentication test after the authoritative answer is correct. For DKIM, inspect a newly sent message and verify its signing result rather than relying only on the DNS editor.

If verification fails, compare exact prefixes, key data, selector name and punctuation. A duplicated zone suffix or inserted newline can be more important than the visual appearance of separate quoted chunks.

• Add a provider's DNS verification record and remove it only when appropriate
• Query authoritative nameservers directly when diagnosing DNS
• Prepare a reversible DNS change with an exact before-and-after record list
• Publish a child zone's DS record in the correct parent zone

• RFC 1035
• RFC 7208
• RFC 6376

• ISC BIND: dig and delv reference