A TXT record is a DNS record that holds arbitrary text. The "arbitrary" part is key – it means these records can be used for a wide variety of purposes, not just IP addresses or mail servers. SPF, DKIM, and DMARC are specific applications of TXT records designed to combat email spoofing and phishing.
Let’s see how this plays out in a real-world scenario. Imagine you’re setting up email for example.com. Your mail server is mail.example.com, and you want to use Google Workspace for your email.
Here’s what the DNS records might look like in your DNS provider’s interface (this is a simplified example, actual interfaces vary):
Record Type: TXT
Name/Host: @ (or example.com.)
Value/Text: "v=spf1 include:_spf.google.com ~all"
This is your SPF record. It tells receiving mail servers which mail servers are authorized to send email on behalf of example.com. In this case, it’s saying: "Email from _spf.google.com is okay, and anything else should be considered suspect (~all)."
Now, for DKIM. This is where things get a bit more involved, as it requires generating a public/private key pair. You’d typically do this within your email service provider (like Google Workspace). Let’s say Google generates a selector named google for you.
Record Type: TXT
Name/Host: google._domainkey (or google._domainkey.example.com.)
Value/Text: "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy9c3J4Xg...<very long public key>...AQAB"
This DKIM record contains your public key. When your mail server sends an email, it digitally signs the message using its private key. The receiving server looks up your public key in this TXT record and uses it to verify the signature. If the signature is valid, it confirms the email hasn’t been tampered with and originated from an authorized sender.
Finally, DMARC. This record ties SPF and DKIM together and tells receivers what to do if an email fails these checks.
Record Type: TXT
Name/Host: _dmarc (or _dmarc.example.com.)
Value/Text: "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"
This DMARC record states: "This is a DMARC version 1 policy. If an email fails SPF and/or DKIM checks, treat it as quarantine (e.g., send it to spam). Send aggregate reports of failures to dmarc-reports@example.com."
The problem SPF, DKIM, and DMARC solve is email spoofing. Without them, anyone could send an email claiming to be from you@example.com, even if they’ve never touched your mail server. SPF lists authorized senders. DKIM cryptographically verifies the sender. DMARC enforces these checks and provides reporting.
The surprise is how these TXT records, which are fundamentally just text strings, can enforce such strict security policies. They rely on a trust chain: your DNS provider is trusted to serve these records accurately, and receiving mail servers are trusted to interpret them correctly.
To see this in action, you can use tools like dig or nslookup on your command line.
For SPF:
dig TXT example.com
You’ll see output similar to:
;; ANSWER SECTION:
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"
For DKIM:
dig TXT google._domainkey.example.com
And you’ll get your public key.
For DMARC:
dig TXT _dmarc.example.com
Which will show your DMARC policy.
The levers you control are the Name/Host and the Value/Text fields. The Name/Host specifies which domain or subdomain the TXT record applies to. The Value/Text is the actual policy or key. For example, _dmarc means this policy applies to _dmarc.example.com. If you wanted a separate DMARC policy for mail.example.com, you’d create a TXT record at _dmarc.mail.example.com.
The most counterintuitive aspect is how the ~all in SPF or p=quarantine in DMARC are interpreted. They aren’t hard-coded into the DNS protocol itself. Instead, it’s the receiving mail server’s software that is programmed to understand these specific text formats as instructions. A server that doesn’t understand SPF or DMARC will simply ignore the TXT record, rendering it useless for security.
What many people miss is the importance of the "selector" in DKIM. If you have multiple mail services sending email for your domain (e.g., Google Workspace for general email and SendGrid for transactional emails), you’ll need separate DKIM records, each with a unique selector (e.g., google._domainkey and sendgrid._domainkey). The receiving server uses the selector to find the correct public key to verify the signature.
The next step after configuring these records is monitoring your DMARC reports to ensure legitimate emails aren’t being flagged and to identify potential spoofing attempts.