El cambio en el DNS: MX, SPF, DKIM y DMARC

Módulo 4: Trasladar el correo electrónico · Tiempo de lectura: 12 minutos

Objetivo de aprendizaje: Después de esta lección podrá planificar y ejecutar el cambio de DNS para el correo electrónico en el orden correcto, de modo que no se pierda ningún mensaje, su correo saliente no caiga en la carpeta de spam y Outlook no siga llamando a escondidas al proveedor anterior.

Conceptos clave: TTL, cambio de MX, SPF (un único registro), selector DKIM, DMARC (p=none, rua), autodiscover, autoconfig, registro de verificación, dominio aceptado

Cinco registros, un único momento

Para el correo electrónico en su propio dominio hay varios registros en el DNS que, en conjunto, determinan si el correo llega y si se confía en sus mensajes:

En una mudanza, casi todo esto cambia. El arte está en el orden. Si cambia el MX mientras SPF y DKIM aún solo son válidos para Microsoft, el correo sí llegará, pero el correo que usted envía caerá en la carpeta de spam. Si cambia primero el SPF, Microsoft ya no podrá enviar correo correctamente en su nombre durante los días previos.

Esta lección trata sobre el orden. Cómo funciona exactamente cada registro puede consultarlo en el curso de DNS (lecciones 4.1 a 4.5).

Paso 1, dos días antes: bajar el TTL y hacer una copia de seguridad

Cada registro DNS tiene un TTL (time to live): cuánto tiempo pueden recordar otros servidores la respuesta. Si el TTL de su MX está en 86400 segundos (un día), algunos servidores seguirán enviando al servidor antiguo hasta un día después del cambio.

Por eso, baje con antelación, al menos el tiempo del TTL antiguo, el TTL de MX, SPF y autodiscover a 300 o 3600 segundos. Si el TTL es de un día, hágalo al menos un día antes; dos días es un margen holgado. Al mismo tiempo, haga una copia de seguridad de su zona DNS, o anote todos los registros actuales. Así siempre podrá volver atrás.

Bakkerij De Korrel ve lo siguiente:

example.com.            3600  IN  MX   0 example-com.mail.protection.outlook.com.
example.com.            3600  IN  TXT  "v=spf1 include:spf.protection.outlook.com -all"
selector1._domainkey    3600  IN  CNAME selector1-example-com._domainkey.korrel.onmicrosoft.com.
selector2._domainkey    3600  IN  CNAME selector2-example-com._domainkey.korrel.onmicrosoft.com.
_dmarc.example.com.     3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
autodiscover            3600  IN  CNAME autodiscover.outlook.com.
example.com.            3600  IN  TXT  "MS=ms12345678"

El TTL ya es de 3600 (una hora). Ponen MX y SPF en 300.

Paso 2, antes del cambio: preparar DKIM y SPF para el nuevo proveedor

Los registros que no estropean nada puede añadirlos ya de antemano:

• DKIM del nuevo proveedor. El nuevo proveedor proporciona un selector y una clave, por ejemplo x._domainkey con un registro TXT v=DKIM1; k=rsa; p=.... Como el selector se llama de forma distinta al de Microsoft (selector1 y selector2), conviven sin problema uno junto al otro. Cada destinatario solo mira el selector que figura en la firma del mensaje.
• Ampliar el SPF, no sustituirlo. Solo puede haber un registro SPF. Añada el nuevo proveedor dentro del mismo registro, de modo que durante los días de transición ambos puedan enviar correo:

"v=spf1 include:spf.protection.outlook.com include:spf.mailaanbieder.example ~all"

La panadería tenía -all. Durante la transición eligen temporalmente ~all (softfail): si aun así falta algún servidor, el correo se considera antes sospechoso que rechazado. Esto sigue la regla general: ~all si no está completamente seguro, -all cuando sepa con certeza que todos los remitentes están incluidos.

No olvide los demás remitentes de su lista de la lección 4.1: la tienda online, el servicio de boletines, la contabilidad. Estos permanecen en el registro SPF.

Paso 3, el momento del cambio: MX y autodiscover

En el momento acordado, una vez que la primera copia de los buzones esté lista (lección 4.2):

1. Sustituya los registros MX por los del nuevo proveedor. Elimine el MX antiguo; no lo deje como "reserva" con una prioridad más alta, porque entonces llegará correo al proveedor antiguo en cuanto el nuevo vaya un poco lento.
2. Ajuste autodiscover. Outlook busca su configuración a través de autodiscover.example.com. Si eso sigue apuntando a autodiscover.outlook.com, Outlook seguirá intentando iniciar sesión en Microsoft, incluso al añadir una cuenta nueva. Elimínelo o haga que apunte a lo que indique su nuevo proveedor. Algunos proveedores usan en su lugar autoconfig.example.com (Thunderbird) o registros SRV como _imaps._tcp y _submission._tcp (RFC 6186).
3. Ejecute una segunda copia de los buzones, para que se incluya también el correo de las últimas horas.

Hay una sorpresa en Microsoft 365 que pilla desprevenidas a muchas personas. Mientras example.com figure en el entorno de Microsoft 365 como dominio aceptado, Microsoft entrega el correo entre usuarios de ese mismo entorno de forma interna, sin consultar el MX. Si un compañero que todavía trabaja en Outlook conectado a Microsoft envía un correo a otro compañero, ese mensaje llegará al buzón antiguo. Por eso, cambie a todos los empleados el mismo día y, tras el periodo de transición, retire el dominio del entorno de Microsoft.

Paso 4, DMARC: observar durante la transición

DMARC indica a los destinatarios qué deben hacer si un correo no supera SPF o DKIM, y le envía informes. La panadería tenía p=quarantine. Eso está bien, pero durante un cambio resulta peligroso: si DKIM aún no está activo en el nuevo proveedor, su propio correo acabará en la carpeta de spam de sus clientes.

El enfoque seguro:

• Si todavía no tiene DMARC, empiece con p=none y una dirección rua. Así no le ocurre nada a su correo, pero recibe informes.
• Si ya tiene quarantine o reject, compruebe antes del cambio, con un correo de prueba, que el DKIM del nuevo proveedor funciona (la cabecera de un correo recibido muestra dkim=pass con d=example.com). Si tiene dudas, ponga temporalmente p=none y revise los informes durante unas semanas.
• Después, endurezca la política paso a paso: none, luego quarantine, y eventualmente reject. Según el nuevo estándar DMARC (RFC 9989), en la fase de prueba también puede usar t=y; la antigua etiqueta pct queda obsoleta.

Paso 5, después de unas semanas: limpieza

Si todo funciona correctamente durante unas semanas, elimine los registros antiguos:

• el antiguo include del SPF (y, si procede, vuelva a -all);
• los antiguos registros DKIM (selector1 y selector2);
• el registro de verificación MS=ms... y otros registros eventuales para Microsoft, como enterpriseregistration y lyncdiscover si los tenía;
• el TTL de vuelta a un valor normal, como 3600;
• el dominio fuera del antiguo entorno de Microsoft o Google.

Si deja el include antiguo, el proveedor anterior podrá seguir enviando correo en nombre de su dominio durante años. Es una puerta abierta.

En la práctica: así se ve en un proveedor

En Mi WebOké, en la pestaña DNS, encontrará la tarjeta Configurar E-Mail. Muestra MX, SPF y DMARC con un punto de color, y arriba a la derecha qué proveedor de correo reconoce según su MX. Con Configuración rápida establece de una sola vez los registros para un proveedor, y el aviso amarillo advierte de que los registros MX y SPF existentes serán sustituidos. Por eso, haga primero una copia de seguridad del DNS y compruebe después si el registro SPF todavía contiene sus otros remitentes. En la página de producto de un paquete de alojamiento encontrará la tarjeta Configurar E-Mail, que muestra por cada registro si está Correcto, Atención, Incorrecto o No encontrado, y ofrece el valor con un botón para copiarlo. Si el DNS está gestionado por otra parte, traslade allí esos mismos valores. Otros proveedores y paneles de DNS tienen resúmenes parecidos; los registros en sí son iguales en todas partes.

Resumen

• Baje el TTL con antelación, al menos el tiempo del TTL antiguo, y haga una copia de seguridad de su zona DNS.
• Prepare ya antes del cambio el DKIM del nuevo proveedor y un registro SPF ampliado (un único registro, con ambos proveedores).
• Cambie el MX y autodiscover al mismo tiempo, y pase a todos los empleados el mismo día; de lo contrario Microsoft seguirá entregando el correo interno en los buzones antiguos.
• No endurezca DMARC durante la transición más allá de lo que sepa con certeza; si todavía no tiene DMARC, empiece con p=none e informes.
• Al cabo de unas semanas, elimine el include antiguo, los registros DKIM, los registros de verificación y el dominio del entorno anterior.

Cuestionario

Ejercicio

Ejercicio A4.3: Sus registros de correo de un vistazo. Introduzca su dominio y el selector DKIM de su (nuevo) proveedor. El programa comprueba si el MX apunta a su proveedor, si existe exactamente un registro SPF, si la clave DKIM está presente en ese selector y si existe exactamente un registro DMARC. También mide el TTL de su MX en el servidor de nombres autoritativo: para un cambio planificado debe ser de 3600 o menos.

Ejercicio E4.3: Su guion de cambio. Escriba, para su propio dominio, el guion de esta lección: por cada paso, la fecha y hora, los registros antes y después (SPF antiguo y nuevo como una sola línea), quién lo realiza y qué comprueba después de cada paso.

Para saber más

Los pasos de estos artículos se aplican a los servicios de WebOké; en otros proveedores el funcionamiento es similar.

• Manual de WebOké 6.7: La tarjeta Configurar el correo (MX, SPF, DKIM, DMARC)
• Manual de WebOké 5.6: Configurar el correo rápidamente en el DNS
• Manual de WebOké 5.7: Restablecer el DNS y crear una copia de seguridad del DNS
• Manual de DirectAdmin 10.4: Después de la migración: registros MX y sus dispositivos
• Curso gratuito de DNS 4.3: SPF: ¿quién puede enviar correo en nombre de su dominio?
• Curso gratuito de DNS 4.4: DKIM: la firma de su correo
• Curso gratuito de DNS 4.5: DMARC: qué deben hacer los destinatarios con el correo falso
• Curso gratuito de DNS 6.3: El DNS en una mudanza
• RFC 7208 (SPF), RFC 6376 (DKIM), RFC 9989 (DMARC), RFC 6186 (registros SRV para programas de correo)