The TXT record

The TXT or “descriptive text” DNS record type was created to hold human-readable text. It now plays a critical role in the prevention of spam on the Internet.

The TXT record type was introduced in the original DNS specifications (RFC 1034 and 1035) in 1987. They were to be used for notes and text created by DNS administrators. There was originally no definitive purpose for TXT records. They were used for whatever information the DNS administrator thought was useful. This included contact information, the locations and owners of machines, humorous messages, and other administrivia.

TXT records were used this way until 2003. In 2003 efforts began to fight back against spam and other abuses of email. This led to the creation of SPF (Sender Policy Framework). SPF stores email authority information in TXT records. Other uses for the TXT record type have been added over the years.

TXT record format

The RFC 1035 definition of the record data for TXT record is one or more “character-strings”. Each character string can be at most 255 characters long.

TXT records also have a Time-to-Live value in seconds, like all other DNS records. A simple example TXT record for example.org with a TTL of 3600 seconds (one hour) might look like this:

example.org. 3600 TXT "Welcome to the example domain!"

There are a few somewhat confusing aspects of TXT records. Namely, the use of quotation marks and multiple character strings. Quotation marks are not necessary if you are working with TXT records in a DNS provider’s web portal. When editing a traditional zone file, quotation marks are required around each string.

Each TXT record can contain multiple character strings. Each character string may contain up to 255 characters. Multiple TXT records may also exist at a single name in the DNS. See our ‘related questions’ section below for more details.

The examples on this page will use DNS zone file format so will contain quotation marks.

A real world TXT example

Let’s examine the actual TXT response for icann.org. At the time this page was written, the TXT response using dig or our TXT lookup tool is:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18975
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;icann.org.                     IN      TXT

;; ANSWER SECTION:
icann.org.              600     IN      TXT     "v=spf1 ip4:192.0.32.0/20 ip4:199.91.192.0/21 ip4:64.78.40.0/27 ip4:162.216.194.0/27 ip4:64.78.33.5/32 ip4:64.78.33.6/31 ip4:64.78.48.205/32 ip4:64.78.48.206/31"
                                                " ip6:2620:0:2d0::0/48 ip6:2620:0:2830::0/48 ip6:2620:0:2ed0::0/48 include:salesforce.icann.org -all"

The DNS administrator for ICANN has followed SPF requirements and created a single TXT record with two strings. There are two strings because the total length of the SPF record is longer than 255 characters.

Also note that quotation marks surround each character string. These quotation marks are not part of the TXT data. Dig included them so we can see where each string begins and ends.

Uses of the TXT record type

The TXT record was intended for free-form text entered by DNS administrators. Use of the TXT record has been expanded to other applications over the years.

Today, TXT records are mainly used for:

• SPF — Sender Policy Framework
• DKIM — Domain Keys Identified Mail
• DMARC — Domain-based Message Authentication, Reporting & Conformance
• MTA-STS — SMTP MTA Strict Transport Security
• Domain verification
• DNS-SD — DNS Service Discovery

Sender Policy Framework (SPF)

SPF is specified in RFC 7208. SPF uses DNS TXT records to list the mail servers permitted to send email for a domain. The creators of SPF used TXT records out of convenience. There was an attempt to create a dedicated DNS record type for SPF but this was officially deprecated in RFC 7208 section 3.1.

Below is a very simple SPF record example. This record states that the mail servers at the IP addresses 10.0.0.1 and 10.0.0.2 are permitted to send mail for the example.org domain:

example.org. 3600 TXT "v=spf1 ip4:10.0.0.1 ip4:10.0.0.2 -all"

Domain Keys Identified Mail (DKIM)

DKIM is specified in RFC 6376. DKIM uses DNS TXT records to publish the public key from a domain’s public-private key pair. This public key is used to securely validate emails signed with a digital signature.

Unlike SPF records, the DNS TXT record for DKIM is not created at the root of the domain. The string following “p=” in the record data of the TXT is a public key. An example DKIM record for the example.org domain is shown below. (The public key is truncated for readability.)

default._domainkey.example.org. 3600 TXT "v=DKIM1;t=s;p=MIGfMA0GCSqGS..."

Domain-based Message Authentication, Reporting & Conformance (DMARC)

DMARC is specified in RFC 7489. DMARC uses DNS TXT records to specify email policy for a domain. The policy specifies what action to take if SPF or DKIM checks fail on email received from the domain.

Like the DKIM record, the DMARC record is not created at root of the domain. An example is shown below. This example specifies that mail which does not pass DMARC checks should be placed in quarantine. Reports should be sent to admin@example.org.

_dmarc.example.org. 3600 TXT "v=DMARC1; p=quarantine; rua=mailto:admin@example.org"

SMTP MTA Strict Transport Security (MTA-STS)

MTA-STS is specified in RFC 8461. MTA-STS allows a mail service provider to declare it accepts Transport Layer Security (TLS) to secure SMTP connections. It can also specify if other SMTP servers should refuse to deliver email to the domain if TLS is unavailable.

Below is a simple example of a TXT record for MTA-STS. The existence of this record signals that SMTP servers should attempt to retrieve the MTA-STS policy for the example.org domain using an HTTPS get request. This record also gives the current policy ID.

_mta-sts.example.org. 3600 TXT "v=STSv1; id=20220601120000Z;"

Domain verification

In recent years it has become popular to use a DNS TXT record to prove ownership of a domain. A service provider gives the domain’s administrator a challenge string. The administrator must publish the challenge string in a TXT record in their DNS zone. The service provider performs a DNS query for the TXT record and verifies that the challenge string has been published. This proves that the administrator controls DNS for the domain.

The format of the domain verification TXT record varies with provider. Always follow your provider’s instructions exactly. The name of the service is usually included in the challenge string, so to verify a domain with Google the record might look something like this:

example.org. 3600 TXT "google=6e6922db-e3e6-4a36-904e-a805c28087fa"

The IETF draft sahib-domain-verification-techniques contains a survey of current uses of this method.

DNS Service Discovery (DNS-SD)

DNS-SD is specified in RFC 6763. DNS-SD allows services to be discovered by application clients through the DNS. This is an alternative to SRV records. The record data of the TXT record contains a set of key/value pairs preceded by length bytes. DNS-SD is not currently in widespread use.

Finding TXT records for a zone

The TXT records for a zone can be queried with the dig or nslookup command line tools. To find the mail servers for wikipedia.org, use this command:

dig TXT wikipedia.org

On operating systems that support nslookup, you can use the following:

nslookup -type=txt wikipedia.org