You may already know that SPF records are TXT-type DNS records that domain owners create to mention SPF policies and enlist the mail servers they authorize to be used to send emails on their behalf. TXT records help store text-based information associated with a domain, which is then published on the DNS for public retrieval. Apart from SPF, TXT records are used for DKIM, DMARC, BIMI, domain ownership verification, Google-site verification for indexing and analytics, etc.
Here is an example of a standard DNS TXT record-
example.com TXT “v=spf1 include:_spf.google.com ~all”
TXT records are pretty flexible as they don’t have any strict formatting requirements. If a TXT record exceeds the character limit of 255 characters, it gets split into multiple parts. These records were initially meant for storing human-readable notes. But now they have evolved enough to contain machine-readable data also. Please note that one domain can have multiple DNS TXT records.
Components a DNS TXT record?
A DNS TXT record consists of several components that define its function and purpose. Below are the key components:
- Hostname (domain/subdomain): This specifies the domain or subdomain to which the TXT record applies. It can be the root domain (example.com) or a subdomain (_dmarc.example.com).
Example- example.com TXT “v=spf1 include:_spf.google.com ~all”
- Record type: It tells what the record type is. For a TXT record, the type is always ‘TXT’ as it indicates a text record.
- TTL (Time To Live): It’s an optional component that basically defines how long the record should be cached by DNS resolvers. It’s usually set in seconds (like 3600 seconds, which is equivalent to 1 hour).
Example- example.com 3600 TXT “v=spf1 include:_spf.google.com ~all”
- Record value: It’s the actual text data that is stored in the record. The structure of the value depends on what purpose it is meant for, such as email authentication, domain verification, or other custom text. A DNS TXT record can store up to 255 characters per entry. If the text is longer, it must be split into multiple quoted sections within the same record. Each part is enclosed in double quotes, and DNS automatically combines them into one string.
Example of SPF record value: “v=spf1 include:_spf.google.com ~all”
Example of DKIM record value: “v=DKIM1; k=rsa; p=MIGfMA0GC…”
Example for DMARC record value: “v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com”
Example of Google verification value: “google-site-verification=abcd1234…”
- Multiple TXT records: A domain can have multiple TXT records, but some applications (like SPF) may require a single consolidated entry.
How do DNS TXT records prevent email-based phishing and spoofing?
Creating DNS TXT records is one of the initial steps in setting up email authentication protocols (SPF, DKIM, and DMARC) so that illegitimate emails sent from your domain don’t land in the inboxes of targeted recipients.
SPF TXT records specify which mail servers are authorized to send emails on behalf of a domain, reducing the chances of attackers forging the ‘From’ address. When an email server receives a message, it checks the SPF record via a DNS lookup and verifies whether the sending IP is permitted; if not, the email can be rejected or marked as suspicious.
DKIM stores a public cryptography key corresponding to your domain. This allows receiving mail servers to retrieve the public key and verify if an email’s headers and content have been altered in transit. The sender signs the email using a private key, and the recipient uses the DKIM TXT record to validate the signature, ensuring message integrity.
DMARC builds on SPF and DKIM by defining a policy for how email providers should handle authentication failures. A DMARC TXT record specifies a domain’s policy (p=none, p=quarantine, or p=reject) and provides reporting addresses (rua and ruf) for forensic and aggregate reports, allowing domain owners to monitor unauthorized email activity. By implementing these DNS TXT records, organizations can prevent email spoofing, mitigate phishing attacks, and enhance their domain’s email security posture.
