When configuring DNS records, a common requirement is having multiple TXT records for the same subdomain - particularly for domain verification (like Google Workspace) and email authentication (SPF records). The DNS specification (RFC 1035) technically allows multiple TXT records per hostname, but implementation varies across DNS providers.

Major DNS providers handle this differently:

// AWS Route 53 approach (single multi-value TXT record)
"v=spf1 include:_spf.google.com ~all"
"google-site-verification=abc123"

versus other providers like Name.com that require separate records:

// Traditional approach (multiple TXT records)
Record 1: "v=spf1 include:_spf.google.com ~all"
Record 2: "google-site-verification=abc123"

Key factors to evaluate:

• DNS response size limitations (UDP packet size of 512 bytes)
• TTL (Time to Live) synchronization between records
• DNS propagation behavior differences
• Provider-specific limitations on TXT record length

For AWS Route 53 using CLI:

aws route53 change-resource-record-sets --hosted-zone-id Z1PA6795UKMFR9 \
--change-batch '{
  "Changes": [{
    "Action": "UPSERT",
    "ResourceRecordSet": {
      "Name": "example.com",
      "Type": "TXT",
      "TTL": 300,
      "ResourceRecords": [
        {"Value": "\"v=spf1 include:_spf.google.com ~all\""},
        {"Value": "\"google-site-verification=abc123\""}
      ]
    }
  }]
}'

For traditional DNS providers (BIND format example):

example.com. 300 IN TXT "v=spf1 include:_spf.google.com ~all"
example.com. 300 IN TXT "google-site-verification=abc123"

Use dig/nslookup to verify proper configuration:

dig TXT example.com +short
# Expected output for combined approach:
"v=spf1 include:_spf.google.com ~all" "google-site-verification=abc123"

# Expected output for separate records approach:
"v=spf1 include:_spf.google.com ~all"
"google-site-verification=abc123"

Watch for these potential problems:

• DNS providers that alphabetically sort TXT records (can affect SPF evaluation)
• Character limits in TXT records (typically 255 characters per string segment)
• Quoting requirements (some providers require escaping quotes)
• Rate limits when making multiple DNS API calls

When combining multiple authentication mechanisms in one record:

• Reduced risk of record modification timing attacks
• Potentially simpler DNSSEC signing
• But increased impact if the record needs modification

---

In DNS management, TXT records serve multiple purposes - from email authentication (SPF, DKIM, DMARC) to domain ownership verification. The RFC 1035 standard explicitly allows multiple TXT records for the same hostname, but implementation varies across DNS providers.

1. Single Record with Concatenated Values (AWS Route 53 Style):

example.com. 300 IN TXT "v=spf1 include:_spf.google.com ~all"
example.com. 300 IN TXT "google-site-verification=ABCD1234"

Or combined:

example.com. 300 IN TXT "v=spf1 include:_spf.google.com ~all" "google-site-verification=ABCD1234"

2. Separate Records (Name.com Style):

@ 3600 IN TXT "v=spf1 include:_spf.google.com ~all"
@ 3600 IN TXT "google-site-verification=ABCD1234"

To verify your TXT records are properly configured:

# Using dig command
dig +short txt example.com

# Using nslookup
nslookup -type=txt example.com

# Online tools like MXToolbox or Google Admin Toolbox

Common problems:

• DNS providers truncating long TXT records (max 255 characters per string segment)
• Some legacy systems not supporting multiple TXT records properly
• Propagation delays causing temporary verification failures

Workarounds:

# For systems with TXT length limitations:
example.com. IN TXT "part1" "part2" "part3"

# For verification services requiring specific record format:
_domainverification.example.com. IN TXT "google-site-verification=ABCD1234"

AWS Route 53 CLI example:

aws route53 change-resource-record-sets --hosted-zone-id Z1PA6795UKMFR9 \
--change-batch '{
  "Changes": [{
    "Action": "UPSERT",
    "ResourceRecordSet": {
      "Name": "example.com",
      "Type": "TXT",
      "TTL": 300,
      "ResourceRecords": [
        {"Value": "\"v=spf1 include:_spf.google.com ~all\""},
        {"Value": "\"google-site-verification=ABCD1234\""}
      ]
    }
  }]
}'

Terraform example for multiple TXT records:

resource "aws_route53_record" "spf" {
  zone_id = aws_route53_zone.primary.zone_id
  name    = "example.com"
  type    = "TXT"
  ttl     = "300"
  records = ["v=spf1 include:_spf.google.com ~all"]
}

resource "aws_route53_record" "google_verification" {
  zone_id = aws_route53_zone.primary.zone_id
  name    = "example.com"
  type    = "TXT"
  ttl     = "300"
  records = ["google-site-verification=ABCD1234"]
}

While multiple TXT records add minimal overhead to DNS resolution, best practices suggest:

• Keeping TTL values reasonable (300-3600 seconds)
• Grouping related verification records together
• Avoiding excessive TXT records (more than 5-6 becomes unwieldy)

Multiple TXT records don't inherently create security risks, but consider:

• Regular auditing of TXT records to prevent domain hijacking
• Using DNSSEC to prevent DNS spoofing
• Implementing proper IAM controls on DNS modification rights