📬 Onboarding de un dominio de correo: asegúralo antes del primer buzón de usuario

El error que todos cometemos

Registras un dominio, lo añades a Microsoft 365 o Google Workspace, creas el primer buzón y empiezas a enviar correo. Funciona. Todo bien, ¿verdad?

No exactamente. Acabas de poner en producción un dominio de correo antes de configurar las dos capas de control que importan:

• Autenticación del remitente: SPF, DKIM, DMARC
• Seguridad en tránsito: MTA-STS, TLS-RPT

SPF, DKIM y DMARC ayudan a los servidores receptores a decidir si un mensaje que dice venir de ti está realmente autorizado. MTA-STS y TLS-RPT protegen la entrega SMTP hacia tu dominio.

Esta guía define la secuencia segura para poner en marcha un dominio de correo nuevo: publicar y validar los controles de autenticación del remitente y de seguridad en tránsito antes de que el primer buzón de usuario empiece a enviar correo real. No después. No “cuando tengamos tiempo”. Antes.

---

Requisitos previos

• Acceso a la cuenta del registrador del dominio
• Acceso de administrador a Microsoft 365 Admin Center o Google Workspace Admin Console
• DNS gestionado en Cloudflare (altamente recomendado - por qué Cloudflare)
• Un destino para reportes:
  • Para DMARC, una dirección de correo en un dominio que ya reciba email
  • Para TLS-RPT, un buzón dedicado para reportes o un endpoint HTTPS
• Hosting HTTPS público para https://mta-sts.tudominio.com/.well-known/mta-sts.txt si vas a habilitar MTA-STS

---

Proceso paso a paso

Paso 1. Registrar el dominio

Compra y registra el dominio en tu registrador de confianza. Mantenlo aparcado inicialmente con la configuración de seguridad para dominios aparcados aplicada desde el día uno.

Paso 2. Añadir el dominio a Cloudflare

Añade el dominio a tu cuenta de Cloudflare y configura los nameservers en el registrador para que apunten a Cloudflare. Todo el DNS se gestionará desde aquí.

Paso 3. Añadir el dominio a tu plataforma de correo

Microsoft 365:

1. Entra en Microsoft 365 Admin Center
2. Ve a Settings > Domains > Add domain
3. Microsoft te dará un registro TXT de verificación - añádelo en Cloudflare
4. Confirma la verificación en Microsoft 365

Documentación oficial: Añadir dominio a Microsoft 365

Google Workspace:

1. Entra en Google Workspace Admin Console
2. Ve a Account > Domains > Manage domains > Add a domain
3. Google te dará un registro TXT de verificación - añádelo en Cloudflare
4. Confirma la verificación en Google Admin

Documentación oficial: Verificar dominio en Google Workspace

Paso 4. Configurar MX y salir de la configuración de dominio aparcado

Si empezaste con una configuración de dominio aparcado, este es el momento de sustituirla: elimina el MX de aparcado, reemplaza el SPF de aparcado, actualiza los destinos de reportes si hace falta y elimina cualquier entrada de limpieza o revocación DKIM usada mientras el dominio no enviaba correo.

El registro MX dirige el correo entrante a los servidores de tu plataforma.

Microsoft 365:

Tipo	Nombre	Valor	Prioridad
MX	tudominio.com	tudominio-com.mail.protection.outlook.com	0

Documentación oficial: Conectar tu dominio añadiendo registros DNS

Google Workspace (cuentas creadas desde abril de 2023):

Tipo	Nombre	Valor	Prioridad
MX	tudominio.com	smtp.google.com	1

Documentación oficial: Configurar registros MX para Google Workspace

En Google Workspace, elimina cualquier otro MX del dominio. Después de publicar el nuevo MX, ve a Account > Domains > Manage domains y pulsa Activate Gmail. El reconocimiento del MX puede tardar hasta 72 horas.

Paso 5. Configurar los registros de autenticación del remitente

5.1 SPF

SPF autoriza qué servidores pueden enviar correo desde tu dominio.

Microsoft 365:

tudominio.com TXT "v=spf1 include:spf.protection.outlook.com -all"

Google Workspace:

tudominio.com TXT "v=spf1 include:_spf.google.com -all"

Si usas servicios adicionales que envían correo en tu nombre (marketing, soporte, ticketing, facturación, etc.), añádelos al mismo registro SPF con más mecanismos include:. Nunca publiques dos registros SPF.

5.2 DKIM

DKIM firma criptográficamente el correo saliente para que el receptor pueda verificar que el mensaje fue autorizado y no se modificó en tránsito.

Microsoft 365:

1. Ve a la página DKIM de Defender: security.microsoft.com/dkimv2
2. Selecciona tu dominio
3. Copia los dos destinos CNAME exactos que Microsoft muestra para tu tenant
4. Publica esos CNAME en Cloudflare
5. Activa la firma DKIM solo después de que los registros resuelvan correctamente

Tipo	Nombre	Valor
CNAME	selector1._domainkey.tudominio.com	Copia el destino exacto que muestra Microsoft
CNAME	selector2._domainkey.tudominio.com	Copia el destino exacto que muestra Microsoft

Los ejemplos publicados por Microsoft son solo ilustrativos. Los destinos reales dependen del dominio inicial onmicrosoft.com de tu tenant y de la partición de enrutamiento de Microsoft.

Documentación oficial: DKIM en Microsoft 365

Google Workspace:

1. Después de activar Gmail, espera 24-72 horas antes de generar la clave DKIM
2. En Admin Console, ve a Apps > Google Workspace > Gmail > Authenticate email
3. Genera un nuevo registro DKIM
4. Prioriza una clave de 2048 bits si tu proveedor DNS la soporta
5. Publica el TXT en Cloudflare
6. Solo cuando el TXT sea visible en DNS, pulsa Start authentication

Tipo	Nombre	Valor
TXT	google._domainkey.tudominio.com	v=DKIM1; k=rsa; p=... (la clave que te proporciona Google)

Documentación oficial: DKIM en Google Workspace

5.3 DMARC

DMARC le dice a los servidores receptores qué hacer cuando un mensaje falla la alineación de SPF o DKIM.

_dmarc.tudominio.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@tu-dominio-de-reportes.com;"

Para un dominio nuevo que controlas por completo, p=reject es un buen objetivo después de que SPF y DKIM estén bien configurados y pasen en tus pruebas. Si prefieres un despliegue más suave, empieza con p=none, valida y luego pasa a p=reject.

Si rua apunta a otro dominio, ese dominio receptor también debe publicar el TXT de autorización:

tudominio.com._report._dmarc.tu-dominio-de-reportes.com TXT "v=DMARC1"

Paso 6. Configurar la seguridad en tránsito

La autenticación del remitente y la seguridad en tránsito no son lo mismo. SPF, DKIM y DMARC protegen la identidad de tu dominio. MTA-STS y TLS-RPT protegen la entrega SMTP hacia tu dominio.

6.1 MTA-STS

MTA-STS le dice a los remitentes compatibles que el correo hacia tu dominio debe entregarse sobre TLS autenticado, usando los hosts MX que publicaste.

Despliegue recomendado:

1. Empieza en modo testing
2. Recolecta y revisa reportes durante varios días, idealmente alrededor de dos semanas
3. Pasa a enforce solo cuando la política valide limpio

Ubicación del archivo de política:

https://mta-sts.tudominio.com/.well-known/mta-sts.txt

El host que sirve este archivo debe:

• Soportar HTTPS
• Presentar un certificado confiado por autoridades raíz públicas

Archivo de política genérico:

version: STSv1
mode: testing
mx: <tu host MX del paso 4>
max_age: 604800

Ejemplos habituales:

• Microsoft 365 (directo a Exchange Online): mx: *.mail.protection.outlook.com
• Google Workspace con el MX único: mx: smtp.google.com

Registro TXT de aserción:

_mta-sts.tudominio.com TXT "v=STSv1; id=<YYYYMMDDhhmmssZ>"

Usa la fecha y hora UTC actual u otro valor único para id, y actualízalo cada vez que cambie la política, incluyendo el paso de testing a enforce.

6.2 TLS-RPT

TLS-RPT permite que los remitentes compatibles te envíen reportes diarios sobre fallos TLS y MTA-STS cuando intentan entregarte correo.

Ejemplo con mailto:

_smtp._tls.tudominio.com TXT "v=TLSRPTv1; rua=mailto:tls-reports@tu-dominio-de-reportes.com"

Ejemplo con HTTPS:

_smtp._tls.tudominio.com TXT "v=TLSRPTv1; rua=https://reports.tu-dominio-de-reportes.com/v1/tlsrpt"

mailto: y https: son URIs válidas para reportes. En un dominio nuevo, usar un buzón externo o un endpoint HTTPS evita crear un buzón de usuario solo para recibir reportes.

Paso 7. Validar en dos capas

Publicar DNS es solo la mitad del trabajo. También tienes que confirmar que la plataforma está firmando y sirviendo lo que esperas.

7.1 Comprobar que el DNS está publicado correctamente

nslookup -type=MX tudominio.com
nslookup -type=TXT tudominio.com
nslookup -type=TXT _dmarc.tudominio.com
nslookup -type=TXT _mta-sts.tudominio.com
nslookup -type=TXT _smtp._tls.tudominio.com
nslookup -type=CNAME selector1._domainkey.tudominio.com   # Microsoft 365
nslookup -type=CNAME selector2._domainkey.tudominio.com   # Microsoft 365
nslookup -type=TXT google._domainkey.tudominio.com        # Google Workspace

Herramientas online útiles:

• MXToolbox - verificación general de DNS
• Hardenize - postura general de correo y TLS
• MTA-STS Validator - valida hosting y sintaxis de MTA-STS
• Check your email security - auditoría del NCSC (UK)

7.2 Comprobar que el comportamiento real de la plataforma funciona

Microsoft 365:

• Cuando los CNAME de DKIM resuelvan, activa DKIM en Defender
• Envía un mensaje de prueba a un buzón externo
• Inspecciona las cabeceras y confirma que la firma DKIM existe y pasa

Google Workspace:

• Cuando el TXT de DKIM esté publicado, pulsa Start authentication
• Envía un mensaje de prueba a alguien que use Gmail o Google Workspace
• No valides enviando el mensaje a ti mismo en el mismo dominio
• En Gmail, abre Show original y confirma que las cabeceras muestran DKIM=pass

MTA-STS:

• Confirma que el archivo de política carga en la URL HTTPS correcta
• Ejecuta un validador externo
• Si tu plataforma ofrece una vista de salud o seguridad para MTA-STS, revísala

DMARC y TLS-RPT:

• Confirma que los reportes están llegando al destino elegido
• Si no llega nada de inmediato, recuerda que la cadencia depende del soporte de los remitentes y del volumen de tráfico

Paso 8. Crear el primer buzón de usuario

Solo cuando los pasos 1-7 estén completos y tus mensajes de prueba se comporten correctamente, el primer buzón de usuario debería empezar a enviar correo en producción.

---

Checklist de validación

Item	Estado
Dominio verificado en la plataforma	⬜
Configuración de dominio aparcado sustituida	⬜
MX configurado y MX antiguo eliminado	⬜
SPF publicado como un solo registro	⬜
DKIM publicado y firma activa	⬜
DMARC publicado y destino de reportes funcionando	⬜
Política MTA-STS publicada, accesible por HTTPS y validada	⬜
TLS-RPT publicado	⬜
El primer mensaje de prueba pasa las comprobaciones de autenticación	⬜
Primer buzón de usuario creado	⬜

---

Tabla de referencia rápida - Registros DNS

Microsoft 365

Tipo	Nombre	Valor
MX	tudominio.com	tudominio-com.mail.protection.outlook.com
TXT (SPF)	tudominio.com	v=spf1 include:spf.protection.outlook.com -all
CNAME (DKIM)	selector1._domainkey.tudominio.com	Copia el destino exacto que muestra Defender o PowerShell
CNAME (DKIM)	selector2._domainkey.tudominio.com	Copia el destino exacto que muestra Defender o PowerShell
TXT (DMARC)	_dmarc.tudominio.com	v=DMARC1; p=reject; rua=mailto:dmarc-reports@tu-dominio-de-reportes.com;
TXT (MTA-STS)	_mta-sts.tudominio.com	v=STSv1; id=
TXT (TLS-RPT)	_smtp._tls.tudominio.com	v=TLSRPTv1; rua=mailto:tls-reports@tu-dominio-de-reportes.com

Google Workspace

Tipo	Nombre	Valor
MX	tudominio.com	smtp.google.com (prioridad 1)
TXT (SPF)	tudominio.com	v=spf1 include:_spf.google.com -all
TXT (DKIM)	google._domainkey.tudominio.com	v=DKIM1; k=rsa; p=(clave proporcionada por Google)
TXT (DMARC)	_dmarc.tudominio.com	v=DMARC1; p=reject; rua=mailto:dmarc-reports@tu-dominio-de-reportes.com;
TXT (MTA-STS)	_mta-sts.tudominio.com	v=STSv1; id=
TXT (TLS-RPT)	_smtp._tls.tudominio.com	v=TLSRPTv1; rua=mailto:tls-reports@tu-dominio-de-reportes.com

---

Lectura relacionada:

• Dominios aparcados: 4 acciones DNS para que nadie los use en tu contra - si el dominio todavía no envía correo
• MTA-STS: protege el correo de tu dominio en tránsito - implementación detallada de MTA-STS

---

Por: Cesar Rosa Polanco - Basado en un caso real, con IA usada como apoyo editorial.