The idea
Most DNS records have one job. An A record points a name at an address. An MX record points mail at a server. A TXT record just holds text.
That vagueness turned out to be useful. If you can put arbitrary text at a name only the domain owner controls, you have a way to publish policy and prove ownership at the same time. So TXT records quietly became the place where a lot of important things live.
- →SPF is a TXT record at your domain listing who may send email as you.
- →DMARC is a TXT record at _dmarc telling inboxes what to do with failures.
- →DKIM publishes its public key as a TXT record at a selector name.
- →Verification strings are TXT records too. When Google or a hosting platform asks you to prove you own a domain, this is usually how.
What it looks like
Three fields, and the value is just text. There is no clever syntax at the DNS level. Whatever meaning the string has comes from whoever reads it.
Name: @
Type: TXT
Value: v=spf1 include:_spf.google.com ~all
Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:[email protected]Use @ or a blank name for the root of your domain, depending on your host. On Route 53 the value must be in double quotes and the name field is left blank for the apex.
The mistake almost everyone makes
If you take one thing from this page, take this. It accounts for more broken DNS records than every other cause combined.
Most DNS panels take a relative name and add your domain to the end for you. So when you carefully paste in _dmarc.example.com, the record you actually create is _dmarc.example.com.example.com. That name resolves to nothing. Your record exists, it looks right in the panel, and it does absolutely nothing forever.
The fix is to enter just _dmarc. Just @ for the root. Just selector._domainkey for DKIM. Never the domain itself.
There is one notable exception. AWS Route 53 wants the fully qualified name and does not auto append. So the advice inverts depending on where your DNS lives, which is exactly why so many people get it wrong. When in doubt, look at an existing record in the same panel and copy its shape.
The 255 character limit
A single DNS text string cannot be longer than 255 characters. That is a hard rule from RFC 1035, it applies everywhere, and no DNS host can lift it.
Most of the time you never notice. SPF and DMARC records are short. Long DKIM keys are where it bites, because a 2048 bit key does not fit.
The answer is splitting. A long value becomes several quoted strings, which the reader joins back together. Some panels do this for you invisibly. Others, Route 53 among them, expect you to provide the split strings on one line yourself.
The practical takeaway: if you paste a long DKIM key and see it wrapped in quotes with a break in the middle, that is correct. Do not tidy it up.
A few things worth knowing
Small details that save an afternoon.
- →On Cloudflare, TXT records are always DNS-only. They cannot be proxied, so there is no orange cloud decision to make and nothing to get wrong. If you are looking for the toggle, it is not there by design.
- →You can have many TXT records at one name. Verification strings from several vendors coexist happily. SPF is the exception, and an important one: one SPF record per domain only, because a second one is a hard failure rather than a merge.
- →Changes are not instant. Records take time to propagate, sometimes well under an hour, sometimes longer. Add the record, then give it time before deciding it did not work.
- →Leave old verification strings alone unless you know. They look like clutter, but removing the wrong one can un-verify a service months later. If you cannot name what it belongs to, do not delete it.
Checking yours
The value of TXT records is that anyone can read them, which means you can too. Our free check reads the ones on your domain and tells you what is present, what is missing, and whether anything landed at the wrong name.
We have step by step instructions for every major platform, including the ones that will not let you.
See how to add DNS records on your platform