Analizador de registros SPF, DMARC y DKIM

Pega el registro TXT o elige su tipo. La comprobación es solo de texto: sin consultas DNS, sin verificar firmas y sin probar la entrega.

Se ejecuta localmente en tu navegador
Esta herramienta procesa todos los datos localmente en tu navegador.
Registro DNS TXTPega un registro TXT SPF, DMARC o DKIM. El texto se contrasta con su RFC: sin consultas DNS ni verificación de firmas.
Resumen

Cómo leer un registro SPF, DMARC o DKIM

El analizador lee el registro pegado como texto y lo contrasta con las reglas de su propia especificación: mecanismos y modificadores SPF (RFC 7208), etiquetas DMARC (RFC 7489) y registros de clave DKIM (RFC 6376, actualizado por el RFC 8301). Cada aviso indica la regla que incumple la línea.

No se consulta ni se verifica nada: no hay consultas DNS, no se comprueba la firma de ningún mensaje y no se prueba la entrega. Un registro que pasa aquí es texto coherente; si coincide con lo que publica el dominio hay que confirmarlo en el DNS.

  1. Pega el valor del registro TXT o pulsa Cargar ejemplo. Conserva la etiqueta v= y las comillas tal como están publicadas.
  2. Deja el tipo en Detectar automáticamente o elige SPF, DMARC o DKIM cuando el registro sea ambiguo.
  3. Pulsa Analizar localmente. El informe muestra hallazgos, una tabla con los términos o etiquetas del registro y contadores como el presupuesto de consultas SPF, escrito x / 10.
  4. Lee la tabla junto a los hallazgos: el calificador y la nota repiten lo señalado, y la vista JSON lleva los mismos datos a una incidencia.
  5. Corrige el registro en el editor de la zona, espera a que pase el TTL y vuelve a pegar el texto para confirmar el cambio.

Qué debe contener cada tipo de registro

Qué cuenta el informe SPF

Los mecanismos se leen en orden con su calificador (+ pass, - fail, ~ softfail, ? neutral), y el registro no tiene que terminar en all: sin ese mecanismo, o con redirect=, el resultado de un host sin coincidencia depende de los valores que sí hayas indicado.

El límite de diez términos del RFC 7208 abarca include, a, mx, ptr, exists y redirect. ip4, ip6, all y exp no cuentan, y los términos duplicados cuentan otra vez. Los mecanismos escritos después de all aparecen en la tabla, pero nunca se evalúan.

Etiquetas DMARC que cambian el comportamiento

v=DMARC1 debe ir primero, y p= (none, quarantine o reject) es lo que aplican los receptores; sp= fija la política de los subdominios y pct= limita la proporción de correo afectada.

rua= y ruf= esperan URI, normalmente direcciones mailto:. adkim y aspf aceptan r o s, fo solo tiene sentido junto a ruf=, rf define únicamente afrf, y las etiquetas que DMARC no define se ignoran en lugar de invalidar el registro.

Claves DKIM y qué las hace utilizables

La clave se publica por selector: v=DKIM1 primero, k= con rsa o ed25519, y p= con la clave pública en base64. Un p= vacío no es un error: revoca la clave.

El RFC 8301 fija el mínimo criptográfico: una clave de menos de 1024 bits no puede producir una firma válida, 2048 bits es el tamaño recomendado y SHA-1 no debe usarse. La etiqueta s= debe incluir email, y t=y declara modo de pruebas.

Lo que una comprobación de texto no puede ver

Las cadenas de include de SPF, la alineación de DMARC y los registros de selector de DKIM se resuelven por DNS en el momento de la entrega. El analizador solo puede juzgar el texto que recibe, así que la ausencia de avisos no garantiza que un dominio envíe correo autenticado.

El registro de clave DKIM también depende del selector: pega el registro del selector que realmente firma (por ejemplo selector1._domainkey), no el de la raíz del dominio.

Herramientas recientes: