Cloudflare Email Routing + Gmail: envío, DMARC y spam

Caso típico de un dominio propio con Cloudflare Email Routing: el correo entrante funciona, pero no se puede enviar y, cuando se consigue, cae en spam. Los dos problemas son independientes y tienen causa distinta.

Síntoma 1: error 535 al enviar

535 5.7.8 Username and Password not accepted

Gmail tiene la dirección del dominio configurada en “Enviar como” usando smtp.gmail.com:587 con una contraseña guardada que ya no es valida. Google retiro el soporte de “aplicaciones menos seguras”: ahora hace falta una contraseña de aplicación.

Pasos:

1. Activar verificación en dos pasos en la cuenta de Google.
2. Generar una contraseña de aplicación en myaccount.google.com/apppasswords (se muestra una sola vez).
3. En Gmail: Configuración - Cuentas e importación - “Enviar como” - Editar datos de la dirección del dominio.
4. Sustituir la contraseña por la de aplicación.

Parámetros:

Campo	Valor
Servidor SMTP	smtp.gmail.com
Puerto	587
Seguridad	TLS
Usuario	la cuenta de Gmail completa
Contraseña	contraseña de aplicación de 16 caracteres

Síntoma 2: los envíos caen en spam

Con DMARC en p=quarantine o p=reject, un correo enviado desde Gmail con la dirección del dominio propio no pasa la alineación:

• DKIM: lo firma Google con su propio dominio, no con el del dominio.
• SPF: el Return-Path es de Gmail, no del dominio propio.

Sin DKIM alineado ni SPF alineado, DMARC falla y el destino lo trata como sospechoso.

Solución provisional: bajar DMARC a p=none mientras no haya firma propia.

Antes: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; fo=1
Ahora: v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1

Solución real: enviar por un servicio que firme con DKIM del dominio propio (Google Workspace, Microsoft 365, SendGrid, Mailgun, Amazon SES) y solo entonces volver a p=quarantine y después a p=reject.

Diagnóstico DNS

dig +short MX example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT selector1._domainkey.example.com

Que debe verse:

Registro	Contenido esperado
MX	los hosts del proveedor de correo (en Cloudflare Email Routing, route1/2/3.mx.cloudflare.net)
TXT raiz	v=spf1 include:_spf.mx.cloudflare.net include:_spf.google.com ~all
_dmarc	política DMARC con dirección de reportes
*._domainkey	clave pública DKIM del proveedor que envía

Cloudflare Email Routing

• Solo reenvia, no envía. Es un servicio de recepción y redirección gratuito; el envío necesita un SMTP externo.
• La acción Catch-all en Drop descarta cualquier dirección sin regla explicita. Si se crean nuevas direcciones, hay que crear antes sus reglas.
• Los destinos deben verificarse por correo antes de activar la regla.
• Mantener el registro SPF con el include de Cloudflare (recepción) y el del proveedor de envío.

Comprobaciones útiles

# SPF: contarlas todas, maximo 10 busquedas DNS
 
dig +short TXT example.com
 
# DMARC agregado: llega a la direccion rua en 24-48 h
 
dig +short TXT _dmarc.example.com
 
# DKIM de un proveedor concreto
 
dig +short TXT google._domainkey.example.com
dig +short TXT cf2024-1._domainkey.example.com

Enviar un correo de prueba a una cuenta propia y mirar las cabeceras Authentication-Results: indican si SPF, DKIM y DMARC pasan y con que dominio (d=) se firmo.

Lecciones

1. Cloudflare Email Routing no envía correo: recepción y envío son servicios distintos.
2. Gmail exige contraseña de aplicación desde 2024; sin 2FA no hay contraseña de aplicación.
3. DMARC sin DKIM propio obliga a p=none. Poner quarantine antes de tiempo garantiza spam.
4. El SPF debe incluir todos los emisores. Más de 10 busquedas DNS en un SPF lo rompen.
5. No publicar nunca valores de DKIM, tokens de verificación ni direcciones de reporte personales en documentación.