A DNS TXT record is a type of DNS entry that holds free-form text attached to your domain name. Anyone can query it publicly, and that is exactly why email authentication uses it: your SPF, DKIM, and DMARC policies are published as TXT records so receiving mail servers can read them and decide whether to trust your mail. If you have ever been told to "add a TXT record" in your DNS, it was almost certainly for one of those three.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
The original purpose of TXT records was general notes and human-readable information. In practice, machine-readable email policies took over. When Gmail, Outlook, or Yahoo receive a message claiming to be from your domain, they look up specific TXT records to verify it. Get the text wrong by a single character and authentication fails, so it helps to understand exactly what these records contain and how the fields work.
What a TXT record actually is
A TXT record is one of many DNS record types, alongside A, MX, CNAME, and NS. Where an A record maps a name to an IPv4 address and an MX record points to a mail server, a TXT record just stores a string of text. There is no fixed format enforced by DNS itself. The meaning comes from a convention that both the publisher and the reader agree on.
Email authentication defines those conventions. SPF text starts with v=spf1. DMARC text starts with v=DMARC1. DKIM text contains a public key with v=DKIM1; k=rsa; p=.... A receiving server knows which record to fetch and how to parse the string once it arrives. That is the whole trick: TXT records are a general-purpose container, and email standards pour a specific structured string into them.
Every TXT record you create has three parts you will set in your DNS provider: the host (also called name), the value (the text itself), and the TTL. Get those three right and the record works.
Host, value, and TTL explained
The host (or name) says which domain or subdomain the record belongs to. For a root SPF record you enter @, which most DNS panels translate to the bare domain like example.com. For DMARC you enter _dmarc, which becomes _dmarc.example.com. For DKIM you enter something like selector1._domainkey, which becomes selector1._domainkey.example.com. The host is a common source of mistakes. If you accidentally type _dmarc.example.com into a panel that already appends your domain, you end up with _dmarc.example.com.example.com and the record is invisible to mail receivers.
The value is the quoted text string. This is the SPF, DKIM, or DMARC policy. Whitespace and case inside the value matter for some tags and not others, so copy values exactly as your provider gives them.
The TTL (time to live) is how long, in seconds, resolvers may cache the record before checking again. A common default is 3600 seconds (one hour). A lower TTL like 300 means changes propagate faster but generates slightly more DNS traffic. When you are actively editing records, a shorter TTL is convenient. Once things are stable, a longer TTL is fine.
The three email records that live in TXT
Here is an annotated example of each, using the domain example.com.
SPF lists which servers are allowed to send mail for your domain. Host @, value:
v=spf1 include:_spf.google.com include:sendgrid.net -all
That reads as: SPF version 1, authorize Google Workspace and SendGrid to send, and reject (-all) everything else. There must be exactly one SPF TXT record per domain. Two SPF records is a hard failure. For the full walkthrough see how to set up SPF.
DKIM publishes a public key so receivers can verify a cryptographic signature on your mail. Host selector1._domainkey, value:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...
The p= value is a long base64 public key, often over 255 characters, which matters in a moment. The selector (selector1) lets you run more than one key at once. See how to set up DKIM.
DMARC tells receivers what to do when SPF and DKIM fail, and where to send reports. Host _dmarc, value:
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s
That publishes a reject policy with strict alignment and an aggregate report address. Start at how to set up DMARC if you are building this from scratch. If you want the conceptual difference between all three, read SPF, DKIM, and DMARC explained.
The 255-character limit and the multiple-strings gotcha
This is the single most common reason a technically correct record still fails, so it is worth slowing down on.
A single character-string inside a TXT record cannot exceed 255 characters. This is a limit in the DNS wire format itself, defined in RFC 1035, not a rule your provider invented. Short records like SPF and DMARC are nowhere near it. DKIM keys, especially 2048-bit RSA keys, routinely exceed 255 characters.
The standard fix, described in RFC 7208 for SPF and used the same way for DKIM, is to split the value into multiple quoted strings inside one record. Instead of one 400-character string, you publish:
"v=DKIM1; k=rsa; p=MIGfMA0GCS...firstpart" "secondpart...IDAQAB"
When a resolver reads a TXT record with multiple strings, it concatenates them back together with no separator and no added spaces. So the two chunks above become one continuous key again. Two things break people here. First, some DNS panels want you to enter the quotes yourself and some add them automatically, which can produce doubled quotes. Second, if a space sneaks in at a split point, the reassembled key is corrupt and DKIM fails with a body hash or signature error. Most managed DNS hosts and mail providers now handle the splitting for you when you paste a long key, so prefer pasting the whole value into a single record and letting the panel chunk it rather than splitting by hand.
If you do split by hand, split at an arbitrary character boundary in the key, not on a logical boundary, and never insert whitespace between the closing and opening quotes.
How to read and verify your live records
Because TXT records are public, you can inspect anyone's. On the command line, dig txt example.com returns the SPF and any other root TXT records, dig txt _dmarc.example.com returns the DMARC policy, and dig txt selector1._domainkey.example.com returns a DKIM key. The output shows each quoted string, so you can see immediately whether a long DKIM key was split into multiple strings.
The faster path is to paste your domain into the checker at the top of this page. It fetches your live SPF, DKIM, and DMARC TXT records, reassembles any split strings, validates the syntax against the relevant RFCs, and flags problems like a missing DMARC record, two SPF records, or a broken key. If you are still mapping out what you need, what DNS records do I need for email lays out the full set.
Frequently asked questions
Is SPF a TXT record or its own record type?
SPF is published as a TXT record. There was once a dedicated SPF record type (type 99), but RFC 7208 deprecated it in 2014. Modern receivers only look at the TXT record, so publish your v=spf1 policy as TXT and do not create an SPF-type record.
Can I have more than one TXT record on the same domain?
Yes, a domain can hold many TXT records at once, for example an SPF record plus a domain verification string from Google or Microsoft. The important exception is SPF: you may have only one TXT record that begins with v=spf1. Multiple SPF records cause a permanent error and break authentication for everyone sending from that domain.
Why does my DKIM record fail when the value looks correct?
Almost always because of the 255-character split. A 2048-bit DKIM key is longer than one string can hold, so it must be stored as multiple quoted strings that the resolver rejoins. If a space slipped in between the strings, or the record was truncated when pasted, the reassembled key is wrong and the signature will not verify even though the value looks right at a glance.
What TTL should I use for email TXT records?
A TTL of 3600 seconds (one hour) is a sensible default once records are stable. Lower it to 300 seconds while you are actively editing so changes take effect quickly, then raise it again. TTL only affects caching speed, not whether the record is valid, so it will never be the cause of an authentication failure by itself.