TXT Record Lookup - Check Email Authentication Records

TXT (Text) records store arbitrary text data in DNS. They're primarily used for email authentication (SPF, DKIM, DMARC), domain verification for services like Google and Microsoft, and security policies. Unlike A records (which point to IP addresses), TXT records can contain any text up to 255 characters per string, with support for multi-part records.

SPF lists authorized mail servers ('who can send'), DKIM adds cryptographic signatures ('is it genuine'), and DMARC sets policy for failures ('what to do if checks fail'). SPF prevents server spoofing, DKIM prevents message tampering, and DMARC provides enforcement and reporting. All three work together—implementing just one provides limited protection. For best email deliverability, configure all three with DMARC set to p=reject.

Domains can have unlimited TXT records. Most domains have multiple: one SPF record, multiple DKIM selectors, one DMARC record, and various verification records for services. However, you can only have ONE SPF record per domain—if you need to authorize multiple services, use 'include:' mechanisms in a single SPF record rather than creating multiple SPF records.

Use our TXT Lookup to find the SPF record (green badge, starts with 'v=spf1'). A valid SPF should: 1) Include all your email-sending services, 2) End with '-all' or '~all', 3) Have fewer than 10 DNS lookups (include/redirect count toward this limit). If you don't see an SPF record, one needs to be created. If SPF authentication is failing, check that all sending services are included.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells email receivers what to do when SPF or DKIM checks fail. Without DMARC, receivers make their own decisions. With DMARC, you control the policy: 'p=none' (monitor), 'p=quarantine' (spam folder), or 'p=reject' (block). DMARC also enables aggregate and forensic reporting so you can see who's sending email using your domain.

Services like Google Workspace, Microsoft 365, and Facebook Business provide a unique verification code. You add a TXT record to your domain's DNS (usually at the root level) containing that code. The service then checks DNS for the record. Common patterns: 'google-site-verification=[code]', 'MS=[code]', 'facebook-domain-verification=[code]'. Our tool highlights these with service-specific badges.

Common SPF failures: 1) Too many DNS lookups (max 10—each 'include:' counts), 2) Sending service not in SPF (add with 'include:'), 3) Hard fail '-all' but legitimate sender missing, 4) Multiple SPF records (you can only have one), 5) Syntax error (check for typos), 6) DNS propagation not complete (wait 24-48 hours). Use DNS Checker to verify propagation across global servers.

Major services requiring TXT verification: Google Workspace/Search Console (google-site-verification), Microsoft 365 (MS=), Facebook Business (facebook-domain-verification), Apple Business/Developer (apple-domain-verification), AWS SES (custom format), Mailchimp, SendGrid, and most SaaS platforms with custom domain features. SSL certificate authorities also use TXT for domain validation.

No—you can only have ONE SPF record per domain. Having multiple SPF records causes a 'permerror' and email authentication fails. To authorize multiple email services, use 'include:' mechanisms within a single SPF record. Example: 'v=spf1 include:_spf.google.com include:sendgrid.net include:mailchimp.com ~all' authorizes Google, SendGrid, and Mailchimp in one record.

TXT record propagation typically takes 1-48 hours depending on the previous TTL value. If your old TXT record had a 24-hour TTL, some DNS servers will cache it for that duration. To speed up changes: 1) Lower TTL to 5-10 minutes 24 hours BEFORE making changes, 2) Make the change, 3) Use our DNS Checker tool to monitor global propagation, 4) Restore normal TTL after propagation is confirmed.