A TXT record looks cut off at the 255-character limit
What this check looks for
One of your TXT records appears to have been truncated where the DNS forces long values to be split. Whatever reads it — usually a DKIM key — sees an incomplete value and rejects it.
Why it matters
A DKIM public key or a long SPF record that has been cut off is not partially working; it fails every time it is read. The record looks present in every control panel, which is why this fault survives so long.
When the check passes, your report says: “Long TXT records are split and rejoined correctly”.
What it costs your score
When this check fails it removes 6 points from your DNS score, before the status, confidence and repeat multipliers are applied. DNS carries a weight of 10 in the overall score.
It shares the dns.records.txt family ceiling of 12 points: however many findings that family produces, together they cannot remove more than that from DNS. One underlying problem showing up in several places is still one problem.
- Severity
- medium
- Default confidence
- high
- Status when triggered
- warn
- Deduction
- 6 points
- Family cap
- dns.records.txt · 12
- Category
- DNS
- Module
- Dns records
- Fix owned by
- dns host
- In the ruleset since
- 2026.09
How to fix it
Re-publish the value as one TXT record split into quoted 255-byte strings.
A truncated value fails every time it is read, while still looking present in your control panel.
Recover the complete value from wherever it was generated — for DKIM, from the provider's setup page.
Split it into quoted strings of at most 255 bytes each, all inside one TXT record.
Publish the single record and delete any fragments left behind.
Most control panels do the splitting for you if you paste the whole value into one field; check the result rather than trusting it.
How to confirm it worked
dig +short TXT ‹domain› — join the quoted strings and compare against the original value
{{recordName}}. 3600 IN TXT ( "first 255 bytes…" "remainder…" )A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Technical detail
A TXT record at ‹domain› ends with a character-string of exactly 255 bytes: ‹record excerpt›…. RFC 1035 §3.3.14 limits one character-string to 255 bytes, and RFC 7208 §3.3 requires a reader to concatenate the strings of a single record with no separator — so a long value is published as *one record with several strings*, not as several records and not as a value chopped at 255. A final string of exactly the maximum length is what a value that hit the limit and stopped looks like. A value that happens to be exactly 255 bytes long is legal, which is why this is reported as strong evidence rather than as proof.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.
Other dns records checks
- The domain has no IPv6 address
- The domain apex is a CNAME, which the DNS does not allow
- A CAA record marked critical uses a tag no authority understands
- CAA forbids every authority from issuing a certificate
- The CAA reporting address is not a usable URL
- No CAA record says which authorities may issue certificates
- Two TXT records of the same kind are published at one name
- The domain has no A or AAAA record
- Records are published with a very long TTL
- Records are published with a very short TTL
- A wildcard record answers for every subdomain