A DNS lookup can fail because the response does not fit the usable UDP exchange and the fallback path cannot complete. Large TXT records, DNSSEC material and response composition can expose this problem. Do not remove a key or shorten policy merely because a checker reports no record; first determine whether the resolver obtained a complete answer.
Read the truncation signal
References: RFC 1035 §4.1.1, RFC 7766 §5, RFC 6891 §6.2.3.
The DNS header's TC bit indicates truncation. A client that needs the missing data normally retries using TCP. Modern DNS implementations must support TCP under RFC 7766; DNS is not a UDP-only service. EDNS lets a requester advertise a larger UDP payload size, but that advertisement is not a guarantee that every network on the path will carry the packet.
IP fragmentation, firewalls and broken middleboxes can interfere with larger UDP responses. TCP may be required independently of whether a particular TXT value appears small in a web panel. Measure the response and path, not just the number of characters you pasted.
Separate the two resolver legs
References: RFC 7766 §5, RFC 7208 §4.4.
The stub-to-recursive and recursive-to-authoritative exchanges are distinct. Successful TCP from your laptop to a public resolver does not prove that the mail receiver's resolver can reach your authority over TCP. Likewise, a direct authority test does not reproduce every forwarding resolver used by a receiver.
Record query owner, type, server, transport, EDNS options, response size, flags and timing. A truncated partial response must not be interpreted as a complete set of selected SPF policies. SERVFAIL and timeout are not evidence that the name does not exist. Preserve the exact error before changing application records.
Reproduce a controlled fallback fault
In a disposable DNS lab, configure an answer large enough to exceed a deliberately small accepted UDP response size. First allow both UDP and TCP. Request the same owner and type and capture packets or a resolver trace. Expected evidence includes a truncated UDP response followed by a successful TCP answer when the client performs fallback.
Next block only the lab's TCP path at the chosen boundary. Repeat the query with identical input and cache state controlled. Expected outcome is a failed full lookup at that boundary despite a working UDP exchange. Restore the rule immediately after the test. This is a lab specification, not permission to alter production network security; that firewall-based procedure has not been executed for this article. The historical service-close experiment below is a different, narrower test.
With an installed BIND dig version supporting these options, dig @AUTH OWNER TXT +bufsize=512 +ignore can expose the UDP response without automatic TCP retry, while dig @AUTH OWNER TXT +tcp requests TCP explicitly. Substitute lab values, inspect the version's help and retain full output. The commands have not been executed here in this review. The retained custom-client capture does not validate dig behavior.
Repair transport before redesigning policy
References: RFC 7766 §5, RFC 7208 §3.2, RFC 7208 §3.3.
Confirm that the service listens on both transports and that the authorized network path permits the required traffic. Have the responsible operator review firewall or load-balancer changes. Re-test the same answer and capture completion over the intended path.
Keeping responses operationally manageable is useful, but splitting a TXT value into strings inside one record does not inherently reduce the total DNS response enough to solve transport faults. Splitting one SPF policy into multiple policy records creates a separate standards violation. Close the issue with transport evidence and then representative authentication results, not with a shorter-looking dashboard value.
Retained historical lab evidence
The retained capture is dated 7 November 2026. The following describes that bounded historical observation, not a new execution or a test of EmailAuth.ai.
The isolated DNS service deliberately emitted TC with an empty UDP answer for a large TXT response. The same question over TCP returned the full answer with TC clear and a wire length exceeding 512 bytes. Closing accepted TCP connections in the test service caused the client to fail. No firewall or production network setting changed. This tests actual UDP and TCP exchanges under forced truncation; it does not claim to test a DNS server's automatic size threshold or dig's own fallback implementation. The capture labels are large_udp_truncated; large_tcp_complete; tcp_failure.json. The retained runner and raw captures are included in this review package as historical evidence. They were inspected, not rerun for this review. Production DNS, DNSSEC and SMTP outcomes remain untested.