Resumen de IA
Una política DMARC es la instrucción en tu registro DMARC que le dice a los servidores de correo receptores qué hacer con los correos electrónicos que fallan la autenticación. Hay tres opciones: ninguna (solo monitorizar), cuarentena (enviar a spam) y rechazar (bloquear por completo). Esta única etiqueta, escrita como p= en tu registro DNS, es la diferencia entre DMARC que solo observa tu tráfico de correo electrónico y DMARC que realmente evita que los mensajes falsificados lleguen a una bandeja de entrada.
Si ya tienes un registro DMARC, la política es fácil de encontrar. Se encuentra justo después de p= en el registro:
v=DMARC1; p=quarantine; rua=mailto:[email protected]
En este ejemplo, la política es cuarentena. A continuación, desglosaré lo que hace cada una de las tres políticas, te mostraré la sintaxis exacta del registro para cada una y estableceré un cronograma realista para pasar de la monitorización a la aplicación completa.
- ¿Ya tienes configurada una política DMARC?
- Ninguna vs. cuarentena vs. rechazo de un vistazo
- p=none: monitorización sin aplicación
- p=quarantine: la política de aplicación transicional
- p=reject: aplicación completa
- Las etiquetas pct y sp
- Cuánto tiempo lleva realmente el paso de ninguna a rechazar
- Errores comunes a evitar
- Preguntas frecuentes
¿Ya tienes configurada una política DMARC?
Si no estás seguro de si tu dominio tiene un registro DMARC o qué política está utilizando, eso es lo primero que debes comprobar antes de que todo esto importe.
La forma más fácil es una herramienta gratuita de búsqueda de DMARC como MXToolbox. Introduce tu dominio y te mostrará el registro completo, incluido el valor p=, si existe. Verás una de estas tres cosas:
- No se encontró registro DMARC. Tu dominio no tiene ninguna política, lo que significa que cualquiera puede falsificar tu dominio en correos electrónicos sin ninguna consecuencia.
- Un registro con p=none. DMARC está configurado en modo de monitorización, pero aún no aplica nada.
- Un registro con p=quarantine o p=reject. DMARC está aplicando activamente una política.
Si no aparece nada, necesitarás crear un registro DMARC antes de que una política se aplique a ti. He escrito una guía completa, con capturas de pantalla para añadir el registro a través de tu proveedor de DNS, en cómo crear un registro DMARC. Esa guía cubre dónde residen los registros DNS (tu host, registrador o CDN), los campos exactos a rellenar y cómo confirmar que el registro está activo una vez que lo hayas publicado.
Mientras compruebas, también vale la pena confirmar que el correo saliente de tu sitio WordPress esté configurado para pasar SPF y DKIM en primer lugar. WP Mail SMTP te muestra el estado de autenticación de cada correo que envía tu sitio, para que no adivines si tu propio sitio es una de las fuentes que DMARC va a marcar.
Soluciona tus correos de WordPress ahora
El resto de esta publicación asume que ya tienes un registro o acabas de crear uno, y quieres entender qué política elegir y cuándo cambiarla.
Ninguna vs. cuarentena vs. rechazo de un vistazo
| p=none | p=quarantine | p=reject | |
|---|---|---|---|
| Qué sucede con el correo que falla | Entregado normalmente | Enviado a spam/correo no deseado | Bloqueado antes de la entrega |
| Nivel de protección | Ninguno (solo monitorización) | Parcial | Completo |
| Riesgo de entregabilidad si se configura incorrectamente | Ninguno | El correo legítimo puede ir a spam | El correo legítimo puede ser rechazado |
| Mejor usar cuando | Empezando, mapeando remitentes | Remitentes mayormente verificados, probando la aplicación | Todos los remitentes confirmados como válidos |
| ¿Se siguen enviando informes? | Sí | Sí | Sí |
p=none: monitorización sin aplicación
p=none es la política inicial para cada dominio que publica DMARC por primera vez. Indica a los servidores de recepción que no tomen ninguna acción sobre los correos que fallan la autenticación. Los mensajes fallidos se entregan exactamente como lo harían sin DMARC. Lo único que cambia es que empiezas a recibir informes agregados que muestran qué fuentes están enviando correos como tu dominio y si están pasando SPF y DKIM.
v=DMARC1; p=none; rua=mailto:[email protected]
¿Qué hace p=none?
- Genera visibilidad de cada servidor que envía correo en nombre de tu dominio
- No tiene ningún impacto en la entregabilidad, ya que no se toma ninguna medida de aplicación
- No requiere configuración previa de SPF o DKIM para publicarse
¿Qué no hace p=none?
- Detener intentos de phishing o suplantación de identidad que utilicen tu dominio
- Proteger tu marca o a tus destinatarios de alguna manera
- Servir como una política válida a largo plazo
Un dominio que permanece indefinidamente en p=none tiene un registro DMARC pero ninguna protección real. Este es el error más común en las implementaciones de DMARC: tratar la monitorización como la línea de meta en lugar del primer paso.
p=quarantine: la política de aplicación transicional
p=quarantine instruye a los servidores de recepción a tratar los mensajes fallidos con sospecha, típicamente enrutándolos a la carpeta de spam o correo no deseado del destinatario en lugar de la bandeja de entrada. El correo no se bloquea por completo. Todavía llega, solo que no a donde normalmente lo haría.
v=DMARC1; p=quarantine; rua=mailto:[email protected]
La forma exacta en que se maneja el "quarantine" varía ligeramente según el proveedor de correo. Algunos marcan el mensaje como sospechoso en lugar de moverlo. La mayoría, incluidos Gmail y Outlook, lo envían a spam. De cualquier manera, el efecto práctico es el mismo: el correo legítimo que falla la autenticación se vuelve más difícil de ver para el destinatario, por lo que quarantine solo debe configurarse una vez que estés seguro de que todos tus remitentes conocidos están correctamente configurados.
¿Por qué los dominios usan quarantine como un paso intermedio?
- Detecta errores de configuración antes de que se conviertan en rebotes. Si un remitente legítimo comienza a fallar DMARC, el correo llega a spam en lugar de desaparecer por completo. Puedes detectar el problema y solucionarlo.
- Genera confianza para reject. Observar que quarantine funciona correctamente durante unas semanas es la señal más clara de que estás listo para la aplicación completa.
- Se puede aplicar gradualmente. La etiqueta
pctte permite poner en cuarentena solo un porcentaje del correo fallido al principio (más sobre esto a continuación).
p=reject: aplicación completa
p=reject es la política más estricta. Instruye a los servidores de recepción a bloquear los correos que fallan la autenticación DMARC antes de que se entreguen. Ni bandeja de entrada, ni carpeta de spam. El mensaje es rechazado.
v=DMARC1; p=reject; rua=mailto:[email protected]
Hay dos formas comunes en que los servidores de recepción implementan reject:
- Rechazo en la conexión SMTP. El servidor de recepción rechaza el mensaje durante la conexión inicial, antes de que sea completamente aceptado. Este es el método más utilizado y el recomendado por la mayoría de los proveedores de correo.
- Aceptando y luego descartando. El servidor acepta el mensaje y luego lo descarta silenciosamente o lo devuelve al remitente. Esto ocurre con menos frecuencia, pero sigue siendo válido según la especificación DMARC.
El rechazo es el objetivo final de cualquier implementación seria de DMARC. También es la política donde los errores son más visibles. Si un remitente legítimo no ha sido autenticado correctamente, su correo no llegará a la carpeta de spam donde se puede encontrar. Simplemente no llegará y no habrá un fallo leve que te alerte.
Las etiquetas pct y sp
Dos etiquetas adicionales te permiten controlar cómo se aplica una política, y ambas merecen ser conocidas antes de pasar de p=none.
pct controla qué porcentaje del correo que falla recibe la política. En lugar de saltar directamente al 100% de aplicación, puedes aplicar cuarentena o rechazo a una porción menor del tráfico que falla primero.
v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]
Los mensajes fuera de ese porcentaje se tratan como si la política siguiera siendo p=none. Esto te da una rampa gradual en lugar de un interruptor de todo o nada, y es la forma más segura de pasar a la aplicación si no estás completamente seguro de que todos los remitentes están contabilizados.
sp establece una política separada para los subdominios. Sin ella, los subdominios heredan cualquier política que establezcas para el dominio principal.
v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]
Este ejemplo aplica el rechazo en el dominio raíz mientras otorga a los subdominios una política de cuarentena más suave, útil si un subdominio es administrado por un equipo diferente o aún no ha sido autenticado completamente. Omitir esta etiqueta es una brecha común: un dominio puede estar completamente bloqueado con p=reject mientras que un subdominio no supervisado permanece completamente abierto a la suplantación.
Cuánto tiempo lleva realmente el paso de ninguna a rechazar
No hay un plazo fijo en la especificación DMARC, pero apresurar la implementación es la forma más común en que el correo legítimo es bloqueado. Un ritmo defendible y comúnmente recomendado se ve así:
- Mantente en p=none durante al menos 2 a 4 semanas, y más tiempo si tu dominio envía a través de varias herramientas de terceros (plataformas de marketing, CRM, software de atención al cliente, herramientas de facturación). Usa esta ventana para revisar los informes agregados y confirmar que cada remitente legítimo está pasando SPF o DKIM.
- Pasa a p=quarantine una vez que los remitentes conocidos estén limpios, comenzando con un valor bajo de
pctcomo 25 y aumentándolo a medida que los informes se mantengan libres de tráfico legítimo atrapado. - Avanza a p=reject solo después de que la cuarentena se haya ejecutado al 100% sin que se vea afectado ningún correo legítimo. La mayoría de los dominios alcanzan esta etapa en cualquier lugar, desde unos pocos meses hasta aproximadamente un año después de comenzar, dependiendo de cuántas fuentes de envío necesiten autenticar.
Omitir pasos es donde la mayoría de las implementaciones de DMARC salen mal. Un dominio con un solo proveedor de correo electrónico podría avanzar rápidamente. Un dominio que envía a través de una docena de herramientas de marketing, soporte y transaccionales necesita más tiempo, porque cada una de esas fuentes tiene que pasar la autenticación antes de que la aplicación sea segura.
Errores comunes a evitar
- Saltar directamente al rechazo. Publicar p=reject antes de confirmar que todos los remitentes legítimos están autenticados hará que el correo real sea devuelto, a veces sin ninguna advertencia.
- Nunca dejar en p=none. Un registro DMARC sin una política de aplicación proporciona visibilidad pero no protección real contra la suplantación de identidad.
- Olvidar subdominios. Si
spno está configurado, un atacante puede dirigirse a un subdominio que no se ha bloqueado, incluso si el dominio principal está completamente aplicado. - Saltarse la rampa. Pasar de p=none al 100% de rechazo en un solo paso es más arriesgado que pasar gradualmente por los valores de
pct. - No volver a comprobar después de añadir nuevos remitentes. Una nueva herramienta de marketing o un servicio de correo electrónico transaccional necesita pasar SPF o DKIM antes de ser añadido a su mezcla de envío, o comenzará a fallar DMARC en el momento en que la aplicación esté activa.
Omitir pasos es donde la mayoría de las implementaciones de DMARC salen mal. Un dominio con un solo proveedor de correo electrónico podría avanzar rápidamente. Un dominio que envía a través de una docena de herramientas de marketing, soporte y transaccionales necesita más tiempo, porque cada una de esas fuentes tiene que pasar la autenticación antes de que la aplicación sea segura.
Si su sitio WordPress es una de esas fuentes de envío, vale la pena comprobarlo pronto. La función de correo predeterminada de WordPress envía a través de PHP mail() o lo que sea que el servidor esté configurado para usar, lo que a menudo falla la alineación SPF y DKIM incluso cuando el resto de su dominio está configurado correctamente. WP Mail SMTP enruta el correo de WordPress a través de una conexión SMTP autenticada, por lo que los correos electrónicos de su propio sitio no se convierten en el único remitente que retrasa su paso a cuarentena o rechazo.
Soluciona tus correos de WordPress ahora
Preguntas frecuentes
¿Qué significa DMARC p=none? p=none significa que DMARC está en modo de monitorización. Los correos electrónicos que fallan la autenticación todavía se entregan normalmente, pero usted recibe informes que muestran qué fuentes están enviando correos electrónicos como su dominio y si están pasando las comprobaciones.
¿Cuál es la diferencia entre cuarentena y rechazo de DMARC? Cuarentena envía los correos electrónicos fallidos a la carpeta de spam del destinatario, por lo que todavía se entregan pero son más difíciles de ver. Rechazo bloquea los correos electrónicos fallidos antes de la entrega, por lo que nunca llegan, ni siquiera al spam.
¿Cuánto tiempo debe permanecer en p=none? Al menos de 2 a 4 semanas, aunque los dominios con varios remitentes de terceros a menudo necesitan más tiempo para confirmar que todas las fuentes están autenticadas correctamente antes de pasar a la aplicación.
¿Afecta una política DMARC a la entregabilidad? p=none no tiene ningún efecto en la entregabilidad. p=quarantine y p=reject pueden afectar a la entregabilidad si algún remitente legítimo no ha sido autenticado correctamente, por lo que ambos solo deben aplicarse gradualmente y después de que la monitorización confirme que sus remitentes están limpios.
A continuación, cree un registro DMARC
Una vez que sepa qué política se ajusta a dónde se encuentra en el despliegue, publicar el registro correctamente importa tanto como elegir el correcto. Mi guía sobre cómo crear un registro DMARC detalla cómo añadir la sintaxis exacta a su DNS, paso a paso, para que no haya riesgo de que un error tipográfico rompa su aplicación.
¿Listo para arreglar tus correos electrónicos? Empieza hoy mismo con el mejor plugin SMTP de WordPress. Si no tienes tiempo para arreglar tus correos electrónicos, puedes obtener asistencia completa de configuración White Glove como compra adicional, y hay una garantía de devolución de dinero de 14 días para todos los planes de pago.
Si este artículo te ha sido útil, síguenos en Facebook y Twitter para obtener más consejos y tutoriales de WordPress.