What They Carry
A DNS zone has records with fixed jobs: A for the website address, MX for the mail server. TXT records have no fixed job, so they became the place to publish statements about the domain that other systems read.
SPF lists which servers may send mail for the domain. One record, at the domain itself.
gableexterior.example. TXT "v=spf1 mx -all"
DKIM publishes the public key that lets a receiving server check the signature on each message. One record per signing key, under a subdomain.
DMARC tells receiving servers what to do with mail that fails the other two, and where to send reports. One record, at _dmarc under the domain.
Verification strings from Google Search Console, the Google Business Profile, Microsoft, and others: a random value the service hands over, which it then looks for in the domain's DNS to confirm the person adding it controls the domain.
Where It Goes Wrong
Two SPF records on one domain, which is invalid and makes both fail. A DKIM record with a typo in the long key, so every signature fails. Verification records from services the business left years ago, still sitting there. A DMARC record copied from a blog post with someone else's reporting address in it. None of this breaks the website, so none of it gets noticed until mail starts landing in spam.
How To Check It
A DNS lookup for the TXT records at the domain and at _dmarc under it. There should be one SPF, one DMARC, and only verification strings for services still in use. On a Mail-in-a-Box setup the mail records are generated by the server and cannot be mistyped.
The Foundation Connection
TXT records hold the Verified Identity layer of the Digital Foundation in place: the three email authentication records live here, and so does every proof of domain control a business ever has to give.
