Última actualización: julio de 2026

En resumen: Al terminar esta guía tu zona DNS alojada en Hetzner publicará un registro SPF correcto para tu servidor de correo. Los servidores receptores podrán reconocer quién puede enviar en tu nombre.

Requisitos previos

  • Una zona DNS en Hetzner (Hetzner Console; las zonas existentes pueden seguir en la antigua DNS Console)
  • Sabes qué servidores envían email por tu dominio (tu propio servidor de correo, buzón de hosting, servicio de newsletter)

¿Qué es SPF?

SPF (Sender Policy Framework) es un registro TXT en el DNS de tu dominio. La propia documentación de Hetzner lo resume de forma concisa: se añade un registro TXT al archivo de zona que enumera los servidores SMTP autorizados del dominio. Los servidores de correo receptores comprueban en cada mensaje entrante si el servidor que lo entrega está en esta lista. Sin SPF, cualquier servidor puede enviar correo en tu nombre — y tu correo legítimo acaba antes en spam.

Para ponerlo en contexto: SPF por sí solo no es una protección completa. Solo junto con DKIM y DMARC se convierte en una base sólida. Pero SPF es el punto de entrada más sencillo.

El punto de partida en Hetzner

Hetzner DNS es un servicio de DNS puro: a diferencia de los hosts compartidos, no hay un interruptor SPF listo para usar, porque Hetzner no sabe dónde funciona tu correo. Escribes el registro tú mismo — lo cual encaja bien aquí, ya que como usuario de Hetzner DNS normalmente gestionas tu propia infraestructura de todos modos.

Excepción: si usas konsoleH (hosting web de Hetzner) con servidores de nombres de konsoleH, el sistema define automáticamente un registro SPF por defecto — ahí solo necesitas actuar si servicios externos también deben enviar.

Guía paso a paso

1. Comprueba si SPF ya está activo

Lo más rápido, desde el terminal:

dig TXT example.com +short | grep spf1

Como alternativa, introduce tu dominio en el escáner MXAudit gratuito — comprueba a la vez la sintaxis del registro y el límite de lookups.

2. Construye el registro para tu configuración

El caso clásico, cuando envían los mismos servidores que también reciben (tu MX apunta a tu servidor de correo):

v=spf1 mx -all

El mecanismo mx autoriza las direcciones IP de todos los nombres de host MX de tu dominio — si cambia la IP del servidor, el registro SPF sigue siendo correcto automáticamente, siempre que el registro MX sea correcto.

Si envían máquinas adicionales que no están en el MX (p. ej. un host de envío separado), las añades explícitamente — el ejemplo de Hetzner de la documentación:

v=spf1 mx ip4:213.133.98.98 a:test.example.com -all
MecanismoEfecto
mxpermite los servidores detrás de los registros MX de tu dominio
ip4: / ip6:permite una dirección IP fija o una subred
a:hostpermite la IP detrás del registro A/AAAA del host indicado
-allhardfail: solo los servidores listados explícitamente pueden enviar

Con tu propia infraestructura, -all es la elección correcta — conoces tus vías de envío. Si tienes dudas durante una reconstrucción, empieza con ~all y endurece a -all tras unos días.

3. Introduce el registro en la Hetzner Console

Abre tu zona DNS y crea un nuevo registro:

CampoValor
TipoTXT
Nombre@ (para el dominio principal)
Valor"v=spf1 mx -all"

Dos peculiaridades de Hetzner de la documentación: para el dominio principal, @ va en el campo Nombre, y el valor TXT debe ir entre comillas.

4. Añade servicios de envío externos (si hace falta)

Una herramienta de newsletter, un CRM o un sistema de tickets necesita su valor include: en el mismo registro (de la documentación de ese servicio, busca “SPF”). Rige la regla: solo un registro SPF por dominio — edita el existente, nunca crees un segundo. Lo mismo se aplica en konsoleH: los servicios externos deben añadirse al registro definido automáticamente.

5. Espera hasta que el cambio esté activo

Los cambios de DNS tardan: según el TTL y el caché puede tardar unas horas hasta que todos los servidores del mundo vean el nuevo registro.

Reenvíos: por qué SPF se rompe ahí — y qué tiene que ver SRS

La documentación de Hetzner explica un punto con más detalle que la mayoría de los hosts: el reenvío automático solo funciona con SPF si el servidor que reenvía reescribe la dirección del remitente en el envelope — de lo contrario el destinatario final comprueba tu registro SPF contra la IP del servidor que reenvía y lo rechaza. El método estandarizado de reescritura se llama SRS (Sender Rewriting Scheme). Si gestionas tú mismo un servidor de correo que reenvía, activa SRS; como remitente no puedes hacer nada contra el reenvío mal configurado de otro — para eso están DKIM y DMARC.

Verifica el resultado

Comprueba tu configuración con el escáner MXAudit gratuito — te muestra de inmediato si tu registro SPF es sintácticamente correcto y cuántos lookups de DNS consume (el límite es 10).

O directamente en el terminal:

dig TXT example.com +short | grep spf1

La salida debe contener exactamente un registro con v=spf1.

Errores habituales

Olvidar las comillas. En la Hetzner Console el valor TXT debe ir entre comillas — sin ellas el registro no se crea correctamente.

Dos registros SPF. Dos entradas TXT con v=spf1 provocan un permerror — los servidores receptores entonces ignoran SPF por completo. Todas las fuentes van en un único registro.

mx sin registros MX que coincidan. v=spf1 mx -all autoriza exactamente los servidores de tus registros MX. Si envía una máquina que no aparece ahí (p. ej. un cron job en el servidor web), se rechaza — añádela mediante ip4: o a:.

+all al final. Un +all permite enviar a cualquier servidor y deja todo el registro sin efecto — no lo copies.

Superar el límite de lookups de DNS. SPF permite un máximo de 10 lookups de DNS por comprobación; mx, a: y cada include: cuentan. Con muchos servicios externos se pone justo — MXAudit los cuenta por ti.

Más información