On this page
A TXT record that is too long usually fails because DNS stores each string in chunks of up to 255 bytes, and the whole answer still has a practical size ceiling. Long SPF strings from flattening, oversized DMARC lists, or a DKIM key pasted twice are the usual causes. You can check what the world actually sees with a simple lookup.
dig +short example.com TXTYou should see one or more quoted strings. Receivers join the quoted chunks that belong to a single TXT record, then parse the result. Separate TXT records at the same name are not chunks of one record; they are independent answers. That difference matters for SPF, DKIM, and DMARC.
How chunks and multiple records differ
One SPF policy belongs at the apex as a single TXT record. Two SPF TXT records at the same name produce a permerror. Multiple DKIM keys use separate names such as s1._domainkey and s2._domainkey, not extra TXT lines on the apex. Site verification tokens may sit beside SPF as additional apex TXT records; do not fold them into the SPF string.
When dig shows "v=spf1 include:..." "include:..." as parts of one record, the panel split the string correctly and receivers will concatenate it. When dig shows two full v=spf1 records, that is broken. A panel that inserts extra quotes in the middle of an SPF mechanism can also create a permerror, so always compare the published answer to what you intended.
Keep SPF, DKIM, and DMARC within limits
cPanel splits a long DKIM public key across quoted chunks for you. That behavior is correct. Do not paste the same key again as a second TXT record “to be safe.” A 2048-bit DKIM key is fine when the panel handles the split.
SPF should stay short enough to read: a few include: mechanisms and a ~all or -all at the end. If you have many SaaS senders, move the ones that support it onto a dedicated subdomain rather than stuffing every path into one apex record. For DMARC, one rua address you actually read is enough. A long list of rua and ruf URIs is a common way the record grows into nonsense.
Confirm you are editing the live nameservers
If TXT never seems to update, you may be changing the zone on the wrong side of DNS. Nameserver settings at the registrar must match the servers that hold the zone you edit. Our nameservers are ns1.logicweb.com and ns2.logicweb.com when the domain uses LogicWeb DNS.
Before you keep appending to a record that recursive resolvers never read, review NS at the registrar vs NS in the zone. Fix the delegation first, then publish one clean SPF at the apex, let AutoSSL and your mail tools manage DKIM where they can, and keep DMARC simple.
Tagged
Was this article helpful?
Be the first to rate this article.
