¿Qué es SPF?

SPF (Sender Policy Framework) es un registro DNS que indica qué servidores de correo están autorizados a enviar correo en nombre de tu dominio. Cuando un servidor de correo receptor recibe un mensaje que dice provenir de [email protected], consulta el registro SPF de tu dominio para verificar si la IP del servidor remitente está en la lista aprobada. Si no, es más probable que el mensaje se marque como spam o se rechace.

SPF se publica como un registro TXT en la raíz de tu dominio. Un registro SPF típico para Google Workspace se ve así: v=spf1 include:_spf.google.com ~all.

¿Qué es DKIM?

DKIM (DomainKeys Identified Mail) es un método de autenticación de correo que firma criptográficamente tus mensajes salientes para que los destinatarios puedan verificar que no fueron alterados en tránsito. Tu proveedor de correo genera un par de claves pública/privada — la clave privada firma el correo saliente y la clave pública se publica en tu DNS como un registro TXT en un subdominio de selector concreto como google._domainkey.tudominio.com.

Los servidores receptores obtienen la clave pública, verifican la firma y usan el resultado como una señal para decidir si el mensaje es legítimo. DKIM funciona junto con SPF y DMARC para una autenticación completa del correo.

¿Qué es DMARC?

DMARC (Domain-based Message Authentication, Reporting and Conformance) es una política DNS que indica a los servidores de correo receptores qué hacer cuando un correo falla la autenticación SPF o DKIM — y dónde enviar los informes sobre los fallos de autenticación. Se apoya en SPF y DKIM en lugar de reemplazarlos.

Un registro DMARC básico se ve así: v=DMARC1; p=none; rua=mailto:[email protected]. La política (p=) puede ser none (solo supervisión), quarantine (enviar el correo sospechoso a spam) o reject (bloquear por completo).

¿Cuál es la diferencia entre SPF, DKIM y DMARC?

SPF indica qué servidores pueden enviar correo por tu dominio, DKIM prueba criptográficamente que un mensaje no fue modificado, y DMARC indica a los destinatarios qué hacer cuando las verificaciones SPF o DKIM fallan y solicita informes.

Velo así:

• SPF = la lista de invitados. «Estos servidores tienen permiso para enviar correo desde mi dominio.»
• DKIM = el sello a prueba de manipulaciones. «Este mensaje llegó exactamente como lo envié.»
• DMARC = el reglamento y la auditoría. «Si la lista de invitados o el sello fallan, esto es lo que hay que hacer — y envíame un informe.»

Los tres son registros DNS. Juntos forman la pila moderna de autenticación de correo y son exigidos por grandes proveedores como Google y Yahoo para los remitentes masivos.

¿Por qué mis correos van a spam?

La causa más común es una autenticación de correo ausente o mal configurada — concretamente SPF, DKIM o DMARC. Los servidores de correo receptores (Gmail, Outlook, etc.) puntúan cada mensaje y envían los de baja puntuación a la carpeta de spam. Una autenticación ausente, dominios de remitente incoherentes, una reputación baja o un contenido de tipo spam bajan la puntuación.

Para diagnosticar, verifica tu dominio con una herramienta como el verificador gratuito de MXHelper. Normalmente verás uno o varios de estos problemas:

• Sin registro SPF — los servidores receptores no pueden verificar tus servidores de envío
• Sin firma DKIM — los mensajes no están firmados criptográficamente
• Sin política DMARC — tu dominio es vulnerable a la suplantación
• Envío desde un servidor ausente de tu registro SPF

Corrige primero la autenticación y luego revisa el contenido (sin frases de tipo spam, una proporción equilibrada de texto y enlaces, una versión en texto plano incluida).

¿Cómo verifico la autenticación de correo de mi dominio?

Usa una herramienta gratuita de búsqueda DNS que consulte tus registros SPF, DKIM y DMARC. MXHelper lo hace en un clic — introduce tu dominio y verifica los tres mecanismos de autenticación más los registros MX, con explicaciones en lenguaje claro de cualquier problema detectado.

También puedes verificar manualmente con dig o nslookup:

• SPF: dig TXT tudominio.com
• DMARC: dig TXT _dmarc.tudominio.com
• DKIM: dig TXT <selector>._domainkey.tudominio.com (el selector varía según el proveedor)

¿Por qué falla mi registro SPF?

Las cuatro razones más comunes de un fallo SPF son:

• Varios registros SPF en el mismo dominio — solo se permite uno. Fusiónalos en un único registro con varios mecanismos include:.
• Más de 10 consultas DNS — SPF tiene un límite estricto. Cada include:, a, mx, etc. cuenta. Superarlo provoca un error permanente (permerror).
• Envío desde un servidor ausente del registro — suele ocurrir al añadir nuevos servicios de correo transaccional (Mailchimp, SendGrid, etc.) sin actualizar el SPF.
• Errores de sintaxis — prefijo v=spf1 ausente, errores tipográficos en los includes o registros mal entrecomillados.

¿Qué es el límite de 10 consultas SPF?

Los registros SPF están limitados a 10 consultas DNS durante la evaluación; superar el límite hace fallar toda la verificación SPF con un «permerror». Cada mecanismo include:, a, mx, ptr y exists: de tu registro cuenta como una consulta, y los mecanismos include: anidados cuentan de forma acumulativa.

Si alcanzas este límite, las opciones incluyen: eliminar los includes que no se usan, usar servicios de aplanamiento de SPF (que expanden los includes en rangos de IP a costa de una carga de mantenimiento) o consolidar los servicios de envío.

¿Cómo configuro DMARC?

Añade un registro TXT en el subdominio _dmarc de tu dominio, con un valor como v=DMARC1; p=none; rua=mailto:[email protected].

Paso a paso:

• Inicia sesión en tu proveedor de DNS (Cloudflare, GoDaddy, Namecheap, etc.)
• Añade un nuevo registro TXT
• Host/Nombre: _dmarc (la mayoría de los proveedores añaden el dominio automáticamente)
• Valor: v=DMARC1; p=none; rua=mailto:[email protected]
• Guarda y espera la propagación DNS (normalmente menos de una hora)

Empieza con p=none solo para supervisión. Después de revisar los informes durante 2 a 4 semanas, endurece a p=quarantine o p=reject. MXHelper generará el registro exacto por ti a partir de un breve formulario.

¿Cuál es la diferencia entre p=none, p=quarantine y p=reject?

Estas tres políticas DMARC indican a los servidores de correo receptores cómo tratar los mensajes que fallan la autenticación.

• p=none — solo supervisión. Los receptores informan de los fallos pero no actúan. Úsala al desplegar DMARC por primera vez.
• p=quarantine — los mensajes que fallan van a la carpeta de spam. Úsala una vez que hayas revisado los informes y corregido los remitentes legítimos.
• p=reject — los mensajes que fallan se bloquean por completo. La protección más fuerte contra la suplantación; úsala solo cuando estés seguro de que todas tus fuentes de envío legítimas pasan la autenticación.

La mayoría de los dominios avanzan de none → quarantine → reject a lo largo de semanas o meses, a medida que aumenta la confianza.

¿Qué significan ~all y -all en SPF?

~all es un «fallo leve» — los receptores deberían aceptar el mensaje pero marcarlo como sospechoso. -all es un «fallo estricto» — los receptores deberían rechazar el mensaje por completo.

La mayoría de los dominios deberían empezar con ~all mientras adquieren la certeza de que todos los remitentes legítimos figuran en el registro. Una vez seguro, pasar a -all ofrece una mejor protección contra la suplantación. También existen ?all (neutral, sin opinión) y +all (permitir cualquier cosa, no usar nunca).

¿Qué es un selector DKIM?

Un selector DKIM es una etiqueta que identifica qué clave pública DKIM usar, lo que permite a un dominio publicar varias claves DKIM al mismo tiempo. La ubicación DNS completa de un registro DKIM es <selector>._domainkey.<dominio>, por ejemplo google._domainkey.ejemplo.com.

Los proveedores de correo usan selectores distintos:

• Google Workspace: google
• Microsoft 365: selector1 y selector2
• Zoho: configurable, a menudo zoho
• Mailgun, SendGrid, etc.: cada uno genera el suyo

Varios selectores permiten firmar el correo de varios servicios de envío sin conflicto.

¿Puedo tener varios registros SPF en un dominio?

No. El RFC 7208 prohíbe explícitamente tener más de un registro SPF por dominio, y la mayoría de los receptores tratan los registros múltiples como un permerror (haciendo fallar todas las verificaciones SPF).

Si necesitas autorizar varios servicios de envío, combínalos en un único registro SPF usando varios mecanismos include:, por ejemplo: v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net ~all.

¿Necesito los tres: SPF, DKIM y DMARC?

Sí, para una entregabilidad seria del correo deberías publicar los tres. Cada uno protege contra distintos ataques:

• SPF protege contra los servidores no autorizados que envían en nombre de tu dominio
• DKIM protege contra la modificación de los mensajes en tránsito
• DMARC los une con una política de aplicación e informes

Desde 2024, Google y Yahoo exigen los tres para los remitentes que entregan más de 5000 mensajes al día a sus usuarios. Incluso para los dominios de bajo volumen, tener los tres mejora notablemente la entregabilidad y protege contra la suplantación.

¿Qué es un registro MX?

Un registro MX (Mail Exchanger) es una entrada DNS que indica a Internet qué servidores de correo son responsables de recibir el correo de tu dominio. Cuando alguien envía un mensaje a [email protected], su servidor consulta tus registros MX para saber a dónde entregarlo.

Los registros MX tienen un valor de prioridad — los números más bajos se prefieren. Por ejemplo, Google Workspace usa registros MX como 1 aspmx.l.google.com, 5 alt1.aspmx.l.google.com, y así sucesivamente. El servidor de correo principal se intenta primero; los de respaldo solo se intentan si el principal no está disponible.

¿Cuánto tarda la propagación DNS?

Los cambios DNS suelen propagarse en 15 minutos a unas pocas horas, aunque el máximo técnico lo determina el valor TTL (tiempo de vida) de tu registro.

En la práctica:

• La mayoría de los proveedores de DNS modernos (Cloudflare, AWS Route 53, Google Cloud DNS) propagan los cambios en menos de 5 minutos
• Los registradores más antiguos con TTL más largos (1 hora, 24 horas) tardan más
• Las cachés DNS del navegador y del sistema operativo pueden conservar valores antiguos durante unas horas, sin importar el TTL
• Algunos ISP y redes corporativas almacenan el DNS en caché de forma más agresiva

Para forzar una prueba, usa un resolvedor DNS público como dig @1.1.1.1 tudominio.com para evitar las cachés locales.

¿MXHelper es gratuito?

Sí, MXHelper es completamente gratuito y no requiere registro. El sitio se financia con publicidad discreta. No hay nivel premium ni muro de pago — todas las funciones están disponibles para cada visitante.

¿MXHelper guarda los dominios que verifico?

No. No guardamos los nombres de dominio que verificas en ninguna base de datos. Las consultas pueden aparecer brevemente en los registros de acceso estándar del servidor web (lo que ocurre en todos los sitios web) y se eliminan automáticamente después de 30 días. Los usamos únicamente para el análisis global del tráfico y el diagnóstico de seguridad. Consulta nuestra política de privacidad para todos los detalles.