100% Uptime SLA, 24/7/365 Live Support & Fast Cloud Servers
The 'document' (TXT) DNS record enables a Domain Name System (DNS) administrator to enter document. Originally, the TXT record was intended as a place for notes that are human-readable. It is also possible now, however, to insert some machine-readable data into TXT documents. There can be several TXT records for one domain.
Example of a TXT record:
example.com record type: value: TTL
@ TXT This is an awesome domain! Definitely not spammy. 32600
Today, email spam prevention and domain ownership verification are two of the most significant uses for DNS TXT records, although TXT records were not initially designed for these uses.
The original RFC only indicates that in the 'value' field of a TXT record,' text strings' go. This may be any text that an administrator allows their domain to be associated with.
Most DNS servers would restrict how big TXT records can be and how many records they can hold so that for large volumes of data, administrators cannot use TXT records.
In 1993, a format for storing attributes and their corresponding values as specified by the Internet Engineering Task Force (IETF) within the 'value' area of TXT records. The format was simply an attribute and a value within the quotation marks (') and separated by an equal sign (=), such as:
RFC 1464, the 1993 document that defines this format, includes these examples:
host.widgets.com record type: value:
@ TXT "printer=lpr5"
sam.widgets.com record type: value:
@ TXT "favourite drink=orange juice"
This description has, however, been considered experimental, and it is not always followed in practice. If they make use of TXT records at all, some DNS administrators adopt their own formats within TXT records. For some uses listed below, TXT documents can also be structured in a particular way. For example, DMARC policies have to be structured in a standardised manner.
Often, spammers attempt to fake or forge the domains they send their email messages from. TXT records are a key component of a variety of different methods for email authentication that help an email server decide if a message comes from a trusted source.
Domain Keys Defined Mail (DKIM), the Sender Policy Framework (SPF), and Domain-based Message Authentication, Reporting & Conformance (DMARC) are standard email authentication methods. Domain controllers can make it more difficult for spammers to spoof their domains by configuring these records and can monitor attempts to do so.
SPF records: SPF TXT records list all servers allowed to send email messages from a domain.
DKIM records: DKIM operates using a public-private key pair by digitally signing each email. This helps verify that the email is in fact from the domain from which it appears to be. The public key is hosted in a domain-associated TXT record. (Learn more about encryption with a public key.)
DMARC records: Once DKIM and SPF are installed, DMARC TXT records can be set up. Under the title dmarc.example.com, a DMARC TXT record should be kept. Replaced with 'example.com' by the real domain name. The record's 'value' is the DMARC policy of the domain.
Although verification of domain ownership was not initially a feature of TXT documents, some webmaster tools and cloud providers have adopted this approach.
An administrator can prove that they manage the domain by uploading a new TXT record with particular information included or modifying the current TXT record. The TXT record can be verified by the tool or cloud provider to see if it has been updated as requested. This is much like when, by opening and clicking a connexion sent to that account, a user confirms their email address, ensuring they own the address.