DNS TXT record

SPF, at the domain apex, beginning `v=spf1`. Exactly one such record is permitted, and a second one invalidates both.

DMARC, at `_dmarc.example.com`, beginning `v=DMARC1`.

DKIM public keys, at `<selector>._domainkey.example.com`, which are the longest TXT records most domains publish.

MTA-STS policy version at `_mta-sts.example.com`, and TLS reporting addresses at `_smtp._tls.example.com`.

Verification strings from hosting providers, search consoles and SaaS platforms, which prove control of the domain and are otherwise meaningless.

A single character string inside a TXT record is limited to 255 bytes. A longer value must be split into several strings, which the protocol concatenates on reading.

DKIM keys of 2048 bits exceed that limit, so they are always split. The splitting is a DNS encoding matter, not part of the key.

Providers that accept a long value in a web form and split it correctly are common; providers that truncate it are not unknown, and the result is a key that parses as invalid.

This is why a DKIM record should be verified by querying it, not by trusting that the value pasted into the form was accepted.

A name may carry several TXT records, and DNS returns all of them. For verification strings that is fine — they are independent claims.

For SPF it is a hard failure. The specification allows exactly one record beginning `v=spf1`, and a domain publishing two has no valid SPF policy at all, even though both records look correct in isolation.

The usual cause is a migration: a new provider's record added without the old one being removed. Both are syntactically valid, and nothing warns.

DMARC behaves the same way: multiple records at `_dmarc` mean no policy is applied.

`dig example.com TXT +short` prints every TXT record at the apex, quoted. Long values appear as several adjacent quoted strings.

For the email conventions, query the specific name: `dig _dmarc.example.com TXT +short`, `dig selector1._domainkey.example.com TXT +short`.

Count the records beginning `v=spf1` before anything else. One is correct, zero means no policy, two means a broken policy.

Remove verification strings you no longer need. They are harmless individually and collectively they make the zone hard to read, which is how the duplicate SPF record survives unnoticed.