Registros TXT y verificaciones

Hasta ahora usaste registros que llevan a algún lado: A lleva a una IP, CNAME a otro nombre, MX a un servidor de correo. El registro TXT es distinto: no lleva a ningún lado, solo guarda texto. Y ese texto resulta ser una de las piezas más usadas de todo el DNS: con él demuestras que el dominio es tuyo (Google, Microsoft, Meta, Stripe…) y con él se publican SPF, DKIM y DMARC, las tres reglas que deciden si tu correo llega a la bandeja o a spam.

En esta lección aprenderás qué es exactamente un TXT, cómo funcionan las verificaciones de dominio, las reglas de comillas y longitud (las famosas cadenas de 255 caracteres) y cómo convivir con muchos TXT en el mismo nombre sin romper nada.

Concepto

Analogía: el tablero de avisos de tu casa

Imagina que tu dominio mitienda.com es una casa. Los registros A y MX son como la dirección y el buzón: le dicen a la gente a dónde ir. El registro TXT es el tablero de corcho en la puerta, donde pegas notitas:

"Sí, esta casa es de Erick" (verificación de Google).
"Solo el cartero de Google y el de mi hosting pueden dejar cartas a mi nombre" (SPF).
"Si alguien manda cartas falsas a mi nombre, tíralas a la basura y mándame un reporte" (DMARC).

Cualquiera puede leer el tablero (el DNS es público), pero solo el dueño puede pegar notas (porque solo él entra al panel de DNS). Esa es justo la idea de las verificaciones: si alguien logra pegar una nota con un código secreto que le dio Google, demuestra que controla el dominio.

txt

                 mitienda.com  (la "casa")
   ┌───────────────────────────────────────────────┐
   │  A      → 203.0.113.10        (la dirección)  │
   │  MX     → smtp.google.com     (el buzón)      │
   │  TXT    → tablero de avisos:                  │
   │     📌 "google-site-verification=abc123..."    │
   │     📌 "v=spf1 include:_spf.google.com ~all"   │
   │     📌 "MS=ms48213377"                         │
   └───────────────────────────────────────────────┘

Qué contiene técnicamente un TXT

Un registro TXT tiene las mismas partes que cualquier registro:

Campo	Ejemplo	Qué significa
Nombre	`@`, `_dmarc`, `google._domainkey`	En qué "nombre" se pega la nota
Tipo	`TXT`	Texto libre
Contenido	`"v=spf1 include:_spf.google.com ~all"`	El texto en sí
TTL	`Auto` (300 s en Cloudflare)	Cuánto lo guardan en caché los resolvers

El DNS no interpreta el contenido: para el servidor DNS es solo texto. Quien lo interpreta es el programa que lo consulta: Google lee su código de verificación, Gmail lee tu SPF, etc.

Nombres especiales con guion bajo

Muchos TXT no van en la raíz (@) sino en nombres que empiezan con _. El guion bajo indica "esto no es un sitio web, es un dato de servicio":

Nombre en Cloudflare	Nombre completo	Para qué
`@`	`mitienda.com`	Verificaciones y SPF
`_dmarc`	`_dmarc.mitienda.com`	Política DMARC
`google._domainkey`	`google._domainkey.mitienda.com`	Llave DKIM de Google
`_acme-challenge`	`_acme-challenge.mitienda.com`	Validación de certificados SSL por DNS
`_github-pages-challenge-usuario`	`_github-pages-challenge-usuario.mitienda.com`	Verificar dominio en GitHub Pages

Nombre corto vs nombre completo

En Cloudflare escribes el nombre corto (_dmarc) y el panel le agrega .mitienda.com solo. Si escribes _dmarc.mitienda.com, Cloudflare también lo entiende. Lo que nunca debes hacer es escribir _dmarc.mitienda.com.mitienda.com (pasa en otros paneles que agregan el dominio aunque ya lo hayas puesto). Si al guardar ves el dominio repetido, corrígelo.

Cómo funcionan las verificaciones de dominio

Cuando un servicio te pide "verifica tu dominio", el flujo siempre es el mismo:

txt

1. Tú:      "Quiero usar mitienda.com en tu servicio"
2. Servicio: "Demuéstralo. Pega este código en tu DNS:
              google-site-verification=Xk29fa..."
3. Tú:      (creas el TXT en Cloudflare)
4. Servicio: consulta el DNS público de mitienda.com
              ¿Aparece mi código?  ── sí ──► ✅ Verificado
                                    └─ no ──► ❌ "No encontramos el registro"

Puntos importantes:

El código es único para tu cuenta. Nadie más puede reutilizarlo.
No borres el TXT después de verificar. Muchos servicios revisan periódicamente y, si desaparece, pierdes la verificación (Google Search Console lo hace).
Algunos servicios permiten verificar con CNAME en lugar de TXT. Usa el que te pidan; ambos demuestran lo mismo.

Las verificaciones más comunes

Servicio	Tipo	Nombre	Contenido (ejemplo)
Google Search Console / Workspace	TXT	`@`	`google-site-verification=Xk29faQ...`
Microsoft 365	TXT	`@`	`MS=ms48213377`
Meta (Facebook / Instagram Business)	TXT	`@`	`facebook-domain-verification=7p3k...`
Zoho Mail	TXT	`@`	`zoho-verification=zb12345678.zmverify.zoho.com`
Apple (Apple Business, Sign in with Apple)	TXT	`@`	`apple-domain-verification=Ab12...`
Stripe (dominios de métodos de pago, correo con tu dominio)	TXT o CNAME	Lo que indique el panel	Copia exacto lo que muestre Stripe
Brevo	TXT	`@`	`brevo-code:9f8e7d...`
Let's Encrypt (validación DNS-01)	TXT	`_acme-challenge`	Token temporal

Los valores cambian

Los prefijos de la tabla son reales, pero cada servicio puede cambiar su formato. Copia siempre exactamente lo que te muestre su panel, incluido el nombre del host. Si te piden un nombre raro como _vercel o xyz123._domainkey, ese nombre es parte de la verificación.

Paso a paso: verificar `mitienda.com` en Google Search Console

Este es el caso más común y el que ilustra todos los demás.

Entra a Google Search Console y pulsa Agregar propiedad.
Elige el tipo Dominio (no "Prefijo de URL"). La propiedad de dominio cubre http, https, www y todos los subdominios, y solo se verifica por DNS.
Escribe mitienda.com y pulsa Continuar. Google te muestra un texto como:
txt
```
google-site-verification=Xk29faQb81LmN0pQrS7tUvWxYz-AbCdEfGhIjKlMn
```
1
Cópialo completo con el botón de copiar (no lo transcribas a mano).
En otra pestaña abre el panel de Cloudflare: elige tu cuenta → mitienda.com → DNS → Records (Registros) → Add record (Agregar registro). El nombre del menú puede variar un poco según la versión del panel, pero siempre está dentro de la sección DNS.

Llena el formulario:

txt

Type:    TXT
Name:    @
Content: google-site-verification=Xk29faQb81LmN0pQrS7tUvWxYz-AbCdEfGhIjKlMn
TTL:     Auto

Pulsa Save (Guardar).
Comprueba desde tu computadora (siguiente sección) que el registro ya es público.
Vuelve a Search Console y pulsa Verificar. Con Cloudflare normalmente funciona en menos de un minuto.

Buena práctica

Si la verificación falla, no la repitas diez veces seguidas. Primero consulta el DNS tú mismo. Si tu consulta no muestra el código, el problema está en tu registro; si sí lo muestra, espera unos minutos (el servicio puede tener caché) y vuelve a intentar.

Comprobar registros TXT

WindowsLinux / macOS

powershell

# Todos los TXT de la raíz
nslookup -type=txt mitienda.com

# Preguntando directo a Cloudflare (1.1.1.1) para saltarte la caché del router
nslookup -type=txt mitienda.com 1.1.1.1

# TXT de un nombre especial
nslookup -type=txt _dmarc.mitienda.com 1.1.1.1

# Alternativa de PowerShell, con salida más limpia
Resolve-DnsName mitienda.com -Type TXT -Server 1.1.1.1

bash

# Todos los TXT de la raíz
dig +short mitienda.com TXT

# Preguntando directo a un resolver público
dig @1.1.1.1 +short mitienda.com TXT
dig @8.8.8.8 +short mitienda.com TXT

# TXT de un nombre especial
dig +short _dmarc.mitienda.com TXT

# Preguntando al nameserver autoritativo (la "fuente de la verdad")
dig @ana.ns.cloudflare.com +short mitienda.com TXT

Una salida típica de dig +short mitienda.com TXT sería:

txt

"google-site-verification=Xk29faQb81LmN0pQrS7tUvWxYz-AbCdEfGhIjKlMn"
"v=spf1 include:_spf.google.com ~all"
"MS=ms48213377"
"facebook-domain-verification=7p3kq9z0x1y2w3v4u5t6"

Fíjate: cuatro TXT en el mismo nombre @, y es totalmente válido.

Autoritativo vs resolver

Si preguntas a ana.ns.cloudflare.com (tu nameserver) ves lo que hay ahora mismo en la zona. Si preguntas a 8.8.8.8 puedes ver una versión en caché hasta que venza el TTL. Cuando un cambio "no aparece", compara ambas respuestas: si el autoritativo ya lo tiene, solo es cuestión de esperar.

Varios TXT en el mismo nombre

Un nombre puede tener todos los TXT que quieras. Cada uno es un registro separado. Lo correcto es crear un registro por cada servicio:

txt

Tipo  Nombre  Contenido
TXT   @       "google-site-verification=Xk29fa..."      ← registro 1
TXT   @       "MS=ms48213377"                           ← registro 2
TXT   @       "facebook-domain-verification=7p3k..."    ← registro 3
TXT   @       "v=spf1 include:_spf.google.com ~all"     ← registro 4

Lo que no debes hacer es meter todo en un solo registro:

txt

❌ TXT @ "google-site-verification=Xk29fa... MS=ms48213377 v=spf1 include:_spf.google.com ~all"

Así ningún servicio encuentra su código, porque cada uno busca un registro que empiece con su prefijo.

Las excepciones: SPF y DMARC

Aunque puede haber muchos TXT, hay dos reglas estrictas:

Regla	Por qué
Un solo TXT que empiece con `v=spf1` por nombre	Si hay dos, el receptor devuelve `permerror` y el SPF falla para todos. Se combinan en uno solo (lección de SPF).
Un solo TXT que empiece con `v=DMARC1` en `_dmarc`	Con dos, el receptor ignora DMARC como si no existiera (lección de DMARC).

El error número uno al agregar un servicio de correo

Contratas Mailchimp, te dice "agrega este SPF" y creas un segundo TXT con v=spf1. Desde ese momento, el SPF de todo tu dominio queda roto, incluido el de Google Workspace. Antes de crear un SPF, busca si ya existe uno y edítalo.

Comillas y longitud: las cadenas de 255

Esta es la parte técnica que confunde a casi todo el mundo, así que vamos despacio.

Las comillas

En el formato de zona DNS (el que usan los servidores), el contenido de un TXT va entre comillas: "v=spf1 -all". Las comillas no son parte del texto, solo lo delimitan, igual que en programación "hola" es el texto hola.

En Cloudflare puedes escribir el contenido con o sin comillas y funciona igual:

txt

Content: v=spf1 include:_spf.google.com ~all        ← Cloudflare las agrega
Content: "v=spf1 include:_spf.google.com ~all"      ← también válido

Algunas versiones del panel muestran un aviso recomendando poner comillas; no pasa nada si lo haces. Lo que sí rompe el registro es mezclarlas mal:

txt

❌ "v=spf1 include:_spf.google.com ~all          (falta la comilla de cierre)
❌ ""v=spf1 include:_spf.google.com ~all""       (comillas dobles duplicadas)
❌ “v=spf1 include:_spf.google.com ~all”         (comillas tipográficas de Word)

Copiar desde Word, WhatsApp o un PDF

Esos programas cambian las comillas rectas " por comillas curvas “ ” y a veces agregan espacios invisibles. Copia los valores desde el panel original del servicio o pégalos primero en un editor de texto plano (Bloc de notas, VS Code).

El límite de 255 caracteres

El estándar DNS dice que un TXT está formado por una o varias cadenas (character-strings) y que cada cadena mide como máximo 255 bytes. Un registro puede tener varias cadenas seguidas; al leerlo, el programa que lo consulta (por ejemplo, el verificador de DKIM) las une sin espacios.

txt

Un TXT con una sola cadena (corto):
  "v=spf1 include:_spf.google.com ~all"

Un TXT con dos cadenas (largo, p. ej. una llave DKIM de 2048 bits):
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu5x...(hasta 255)"
  "Qk7v2...resto de la llave...IDAQAB"

Lo que lee el receptor:
  v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu5x...Qk7v2...IDAQAB

¿Qué significa para ti en Cloudflare?

Pega el valor completo en una sola línea. Cloudflare lo divide automáticamente en cadenas de 255 al publicarlo.
Si el servicio te da el valor ya dividido en trozos con comillas ("parte1" "parte2"), también puedes pegarlo así; Cloudflare respeta los trozos.
Lo que nunca debes hacer es dividirlo tú en dos registros TXT distintos: serían dos notas separadas, no una nota larga.

Cuando consultes un TXT largo con dig, lo verás partido:

txt

$ dig +short google._domainkey.mitienda.com TXT
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu5x..." "Qk7v2...IDAQAB"

Ese espacio entre "..." "..." es solo cómo dig muestra las dos cadenas; el receptor las une sin espacio. Está bien.

¿Y el tamaño total?

Además de las cadenas de 255, hay límites prácticos al tamaño total: Cloudflare acepta contenidos de TXT de hasta 2048 caracteres, y respuestas DNS muy grandes (muchos TXT largos en el mismo nombre) pueden necesitar TCP. Para el uso normal (verificaciones, SPF, una llave DKIM de 2048 bits) no te vas a topar con esos límites.

Casos de uso reales

Caso 1: el cliente quiere Search Console, Meta y Workspace

La zona TXT de mitienda.com queda así:

txt

Tipo  Nombre              Contenido
TXT   @                   google-site-verification=Xk29fa...
TXT   @                   facebook-domain-verification=7p3kq9z0x1...
TXT   @                   v=spf1 include:_spf.google.com ~all
TXT   google._domainkey   v=DKIM1; k=rsa; p=MIIBIjANBgkq...IDAQAB
TXT   _dmarc              v=DMARC1; p=none; rua=mailto:dmarc@mitienda.com

Nota que el código de Google Workspace y el de Search Console son el mismo tipo (google-site-verification). Si verificas ambos con cuentas distintas tendrás dos TXT google-site-verification con códigos diferentes, y está bien.

Caso 2: "Verifiqué hace un año y hoy Search Console dice que perdí el acceso"

Casi siempre es porque alguien "limpió" el DNS y borró TXT que parecían basura, o porque se cambiaron los nameservers a otro proveedor y no se copiaron los TXT. Solución: vuelve a crear el TXT (Search Console te muestra el código otra vez en Configuración → Usuarios y permisos → Propietarios verificados, la ruta puede variar).

Caso 3: limpiar TXT viejos con seguridad

Antes de borrar un TXT pregúntate:

¿Empieza con v=spf1, v=DKIM1, v=DMARC1? No lo borres sin entender el correo del dominio.
¿Es una verificación (*-verification=, MS=)? Pregunta al cliente si todavía usa ese servicio. Si ya no lo usa, puedes borrarlo.
¿No sabes qué es? Busca el prefijo en internet. Anota el registro en un archivo antes de borrarlo, por si hay que restaurarlo.

Exporta la zona antes de tocar nada

En Cloudflare, dentro de DNS → Records hay una opción para exportar la zona (Import and Export / Exportar). Descarga el archivo antes de cualquier limpieza grande: es tu respaldo.

Errores comunes

Síntoma	Causa probable	Solución
"No encontramos el registro TXT"	Lo creaste en el registrador y los NS apuntan a Cloudflare	Créalo en la zona del proveedor al que apuntan los NS (lección 3)
El TXT aparece en `ana.ns.cloudflare.com` pero no en `8.8.8.8`	Caché del resolver	Espera el TTL; usa TTL bajo para pruebas
Nombre duplicado: `@.mitienda.com` o `mitienda.com.mitienda.com`	Escribiste el dominio completo en un panel que lo agrega	Deja solo `@` o el nombre corto
SPF "falla" desde que agregaste otro servicio	Dos TXT `v=spf1`	Combínalos en uno (SPF)
DKIM inválido	Se coló un espacio o salto de línea al pegar la llave	Vuelve a copiar desde el panel original, en una sola línea

Ejercicios

Consulta los TXT de google.com y de github.com. ¿Cuántos tienen? ¿Puedes identificar alguna verificación y el SPF?
Tu cliente te pide verificar mitienda.com en Meta. Ya existen estos TXT en @: un google-site-verification y un SPF. Escribe exactamente qué registro crearías en Cloudflare.

Un compañero creó esto. ¿Qué está mal?

txt

TXT  @  "v=spf1 include:_spf.google.com ~all"
TXT  @  "v=spf1 include:servers.mcsv.net ~all"

Te dan una llave DKIM de 410 caracteres. ¿La divides en dos registros TXT? ¿Cómo la pegas en Cloudflare?
Search Console no verifica. Escribe los dos comandos (uno de Windows y uno de dig) que usarías para saber si el problema es tu registro o la caché.

Ver solución

Windows: nslookup -type=txt google.com 1.1.1.1. Linux/macOS: dig +short google.com TXT. Verás varias verificaciones (google-site-verification, facebook-domain-verification, MS=, etc.) y un registro v=spf1 .... Los valores cambian con el tiempo.

Un registro nuevo, sin tocar los existentes:

txt

Type:    TXT
Name:    @
Content: facebook-domain-verification=EL_CODIGO_QUE_TE_DIO_META
TTL:     Auto

Hay dos registros SPF en el mismo nombre. El receptor devuelve permerror y el SPF falla. Se debe dejar uno solo combinando los mecanismos: v=spf1 include:_spf.google.com include:servers.mcsv.net ~all (en la siguiente lección verás que, para Mailchimp, en muchos casos ni siquiera hace falta).
No. Es un solo registro TXT. En Cloudflare pegas el valor completo en una sola línea en el campo Content; Cloudflare lo divide en cadenas de 255 automáticamente. Dos registros serían dos llaves inválidas.
Preguntando al autoritativo y a un resolver público:
powershell
```
nslookup -type=txt mitienda.com ana.ns.cloudflare.com
```
1
bash
```
dig @8.8.8.8 +short mitienda.com TXT
```
1
Si el autoritativo muestra el código y 8.8.8.8 no, es caché: espera. Si el autoritativo tampoco lo muestra, el registro está mal creado o en la zona equivocada.

Resumen

Un TXT guarda texto; el DNS no lo interpreta, lo interpreta quien lo consulta.
Las verificaciones consisten en pegar un código único en un TXT (a veces CNAME) para demostrar que controlas el dominio. No las borres después.
Puede haber muchos TXT en el mismo nombre: uno por servicio. Pero solo un SPF por nombre y un DMARC en _dmarc.
Las comillas delimitan el texto; en Cloudflare son opcionales. Cuidado con las comillas curvas al copiar.
Cada cadena de un TXT mide máximo 255 caracteres; los valores largos se dividen en varias cadenas dentro del mismo registro. Cloudflare lo hace solo.
Comprueba con nslookup -type=txt y dig +short ... TXT, preguntando al autoritativo cuando haya dudas.
Siguiente: SPF: quién puede enviar correo por ti.

Registros TXT y verificaciones ​

Concepto ​

Analogía: el tablero de avisos de tu casa ​

Qué contiene técnicamente un TXT ​

Nombres especiales con guion bajo ​

Cómo funcionan las verificaciones de dominio ​

Las verificaciones más comunes ​

Paso a paso: verificar mitienda.com en Google Search Console ​

Comprobar registros TXT ​

Varios TXT en el mismo nombre ​

Las excepciones: SPF y DMARC ​

Comillas y longitud: las cadenas de 255 ​

Las comillas ​

El límite de 255 caracteres ​

Casos de uso reales ​

Caso 1: el cliente quiere Search Console, Meta y Workspace ​

Caso 2: "Verifiqué hace un año y hoy Search Console dice que perdí el acceso" ​

Caso 3: limpiar TXT viejos con seguridad ​

Errores comunes ​

Ejercicios ​

Resumen ​