DMARC de p=none a p=reject: paso a paso sin bloquear su propio correo
Se pasa de p=none a p=reject en cuatro etapas: primero semanas recopilando informes, después poner en orden a cada remitente que envía en nombre de su dominio, a continuación cuarentena sobre un porcentaje pequeño y solo al final rechazar. Quien se salta un paso suele bloquear su propio programa de contabilidad o su tienda online. Cuente con unos meses, no con una tarde.
Por qué no ir directamente a reject
DMARC indica al destinatario qué hacer con el correo que se hace pasar por su dominio pero no supera la comprobación. El problema es que «no superar la comprobación» vale también para su propio correo legítimo mientras no esté correctamente alineado. Un módulo de facturación que envía por un servidor antiguo, un formulario de contacto de la web, un proveedor que envía una encuesta en su nombre: todos fallan hasta que los resuelva. Si pone hoy p=reject, ese correo desaparecerá mañana sin que a usted le llegue ningún error.
Paso 1: p=none con informes
Publique un registro DMARC con política none y una dirección de informes. Esto no bloquea nada; solo hace que los destinatarios le comuniquen a diario quién envió en nombre de su dominio y si tuvo éxito. No use un buzón personal como dirección de informes: los informes son archivos XML y serán muchos. Haga que los procese una herramienta que los resuma por fuente de envío.
Paso 2: lea al menos cuatro semanas
Deje el registro un mes. La facturación es mensual, algunos recordatorios son trimestrales, y quiere verlos todos. Haga una lista de cada fuente que aparezca en los informes y decida por fuente: ¿es nuestra y, si lo es, quién la gestiona? Casi siempre encontrará más de las que pensaba. Un formulario antiguo de la web, un sistema de caja en la sucursal, un CRM que un empleado conectó en su día.
Paso 3: ponga en orden cada fuente legítima
Por fuente hay tres posibilidades. O añade la fuente a su registro SPF y se asegura de que el dominio del remitente coincide. O hace que la fuente firme con DKIM para su dominio, lo que es más robusto porque sobrevive al reenvío. O traslada la fuente a un relay SMTP donde ambas cosas ya están resueltas y donde cada aplicación recibe credenciales propias. Esta última vía suele ser la más corta, sobre todo para sistemas cuyo acceso ya nadie conoce. Lo que no reconozca como legítimo, déjelo fallar: para eso sirve justamente DMARC.
Vigile en SPF el límite de diez consultas DNS. Quien añade a ciegas a cada proveedor lo supera, y entonces SPF falla para todos. Pode lo que ya no se usa.
Paso 4: cuarentena sobre un porcentaje pequeño
En cuanto los informes muestren durante unas semanas solo fuentes legítimas correctas, ponga la política en quarantine con un porcentaje de, por ejemplo, diez. Solo una décima parte del correo que falle acabará en el spam. Si nadie nota nada, súbalo a cincuenta y después a cien. Siga leyendo los informes: una fuente que solo envía una vez por trimestre puede aparecer justo ahora.
Paso 5: reject
Cuando la cuarentena al cien por cien lleve unas semanas sin quejas, ponga la política en reject. El correo que falle se rechazará en lugar de ir al spam. No olvide sus subdominios: sin un ajuste propio heredan la política del dominio principal, que suele ser lo que quiere, pero compruebe que no haya entre ellos un subdominio de envío que todavía no esté en orden.
Qué seguir haciendo después
Seguir leyendo los informes, con menos frecuencia pero de forma regular. Cada nuevo proveedor que envíe en su nombre debe pasar primero por la autenticación y solo después a producción. Incluya eso en la lista de comprobación al conectar un sistema nuevo; de lo contrario la historia vuelve a empezar. Quien quiera entender los informes encontrará en nuestra página sobre entregabilidad qué significan las cifras.
Preguntas frecuentes
¿Cuánto dura todo el recorrido?
En una empresa pequeña con tres sistemas de envío, de dos a tres meses. En una organización con muchos departamentos y proveedores, más. El tiempo no está en los cambios de DNS, sino en averiguar quién envía.
¿Y si un proveedor no puede firmar con DKIM para mi dominio?
Entonces queda SPF, con la salvedad de que el correo reenviado fallará. Plantéese en ese caso que el proveedor envíe desde un subdominio aparte, para que su dominio principal pueda seguir siendo estricto.
¿No basta con p=quarantine?
Para muchos usos sí. Pero solo con reject sabe con certeza que el correo falsificado no acaba ni siquiera en una carpeta de spam, y algunas aplicaciones, como el logotipo en la bandeja de entrada, exigen aplicación estricta.