¿Los correos de tu app llegan a spam? SPF, DKIM y DMARC

Los correos de tu app llegan a spam casi siempre porque el servidor que los recibe no puede confirmar que de verdad salen de tu dominio. La solución es enviar con un servicio de correo serio desde tu propio dominio y publicar tres registros DNS: SPF (qué servidores pueden enviar por ti), DKIM (una firma en cada mensaje) y DMARC (qué hacer si esas pruebas fallan), con la dirección del remitente alineada con ellos. Desde 2024, Gmail y Yahoo lo exigen a quien envía en volumen.

Aquí verás por qué los correos de una app terminan en spam, qué hace cada registro, en qué orden configurarlos y cómo comprobar el arreglo antes de que te avisen tus usuarios.

¿Por qué los correos de mi app caen en spam?

Las causas habituales, más o menos de mayor a menor peso:

1. Sin autenticación. El dominio no tiene SPF ni DKIM, así que no hay forma de vincular el mensaje contigo.
2. Falta de alineación. El remitente dice hola@tuapp.com, pero el mensaje va firmado con el dominio del proveedor. DMARC solo pasa cuando SPF o DKIM autentican el mismo dominio que aparece en el From.
3. Un remitente compartido o por defecto. Muchos builders y backends traen un servicio de correo pensado para pruebas. El correo integrado de Supabase, por ejemplo, solo entrega a los miembros del equipo del proyecto y tiene un límite de 2 mensajes por hora. Para usuarios reales necesitas SMTP propio o una API de correo.
4. Todavía no hay reputación. Un dominio recién creado que manda cientos de correos el primer día parece spam, aunque esté autenticado.
5. Quejas. Cada persona que marca "Es spam" le enseña al proveedor a filtrarte. Los correos de marketing sin una forma fácil de darse de baja lo empeoran.
6. Señales del contenido. Acortadores de enlaces, enlaces a dominios que no son el tuyo, correos hechos solo de imágenes. Pesan menos que los cinco puntos anteriores.

¿Qué hacen SPF, DKIM y DMARC?

SPF y DKIM prueban que el mensaje es legítimo. DMARC los conecta con el remitente que ve la gente y le dice al receptor qué tan estricto ser.

¿Qué exigen hoy Gmail y Yahoo?

Según las pautas para remitentes de Google y las buenas prácticas de Yahoo:

• Todos deben usar SPF o DKIM, tener DNS directo e inverso válido para las IP de envío y mantener la tasa de quejas por spam por debajo de 0,3 %. Gmail además exige TLS y recomienda quedarse por debajo de 0,10 %.
• Los remitentes masivos (Gmail los define como quienes envían más de 5.000 mensajes al día a sus usuarios) deben usar SPF y DKIM a la vez, publicar una política DMARC de al menos p=none, alinear el dominio del From con SPF o DKIM y ofrecer baja con un clic en los correos de marketing. Yahoo pide además procesar las bajas en un máximo de 2 días.

Aunque envíes muy por debajo de 5.000 al día, sigue las reglas de los masivos. No cuestan nada extra y son las que mantienen los correos de recuperación de contraseña fuera de spam.

¿Cómo lo configuro paso a paso?

1. Elige un servicio de envío y verifica tu dominio

Usa un proveedor de correo transaccional (una API de correo o un servicio SMTP), no tu buzón personal. En su panel, agrega tu dominio. Muchos recomiendan un subdominio como mail.tuapp.com o send.tuapp.com, que separa la reputación de los correos de la app de la del buzón de tu equipo.

El proveedor te mostrará algunos registros DNS, normalmente uno o más de DKIM y uno de SPF o de return-path. Cópialos tal cual en tu proveedor de DNS. Si no sabes dónde está, la guía de registros DNS explicados te ayuda a encontrarlo.

2. Un solo registro SPF por nombre

Si tu dominio raíz ya tiene v=spf1 include:_spf.google.com ~all para el correo del equipo y el proveedor te pide SPF en el mismo nombre, júntalos:

v=spf1 include:_spf.google.com include:<valor del proveedor> ~all

Dos registros v=spf1 separados en el mismo nombre hacen que SPF falle.

3. Agrega un registro DMARC

Empieza en modo de observación para no bloquear nada mientras revisas:

Nombre: _dmarc
Tipo:   TXT
Valor:  v=DMARC1; p=none; rua=mailto:dmarc@tuapp.com

Los informes que llegan a esa dirección muestran qué servicios envían en nombre de tu dominio. Después de unas semanas con todo pasando, sube a p=quarantine, y más adelante a p=reject si quieres la máxima protección contra suplantación.

4. Conecta la app al nuevo remitente

Actualiza la configuración SMTP o de API de la app y usa como remitente el dominio verificado. Para los correos de Supabase Auth, es la opción de SMTP personalizado en la configuración de autenticación del proyecto. Guarda la clave de API o la contraseña SMTP como secreto del servidor, nunca en el código del frontend. Si tu proyecto está hecho con Lovable, la guía para enviar correos desde una app de Lovable muestra cómo conectarlo.

5. Calienta el dominio con calma

Si el dominio es nuevo, empieza por los correos que la gente espera (confirmación de registro, recuperación de contraseña, recibos) antes de mandar un boletín. El correo esperado se abre, y eso construye reputación.

¿Cómo compruebo que funcionó?

1. Envía un correo real desde la app a una dirección de Gmail.
2. En Gmail, ábrelo, toca el menú de tres puntos y elige Mostrar original. Deberías ver SPF, DKIM y DMARC marcados como PASS, y el dominio de DKIM debería ser el tuyo o tu subdominio.
3. Repite con Outlook o Yahoo si tus usuarios los usan.
4. Registra tu dominio en Google Postmaster Tools para seguir la tasa de spam y la reputación en el tiempo.
5. Lee los primeros informes de DMARC. Cualquier origen que no reconozcas es un servicio que olvidaste o alguien suplantándote.

Si DMARC falla mientras SPF y DKIM pasan, el problema es la alineación: el remitente usa un dominio distinto del que se está autenticando.

¿Cómo evito que vuelvan a caer en spam?

• Separa los correos transaccionales de los de marketing en subdominios o flujos distintos.
• Pon un enlace visible para darse de baja y el encabezado de baja con un clic en todo lo que no sea transaccional.
• Nunca compres listas ni importes contactos que no se registraron.
• Vigila los rebotes: si el formulario de registro deja pasar errores de tipeo, valida las direcciones antes de enviar.

Respuestas rápidas

¿Puedo enviar desde mi dirección de Gmail a través de la app? No lo hagas. Tu proveedor no puede autenticar gmail.com, así que DMARC va a fallar. Envía desde tu propio dominio.

¿Alcanza con p=none? Cumple el mínimo para remitentes masivos y te da informes. Pasa a una política más estricta cuando todos los orígenes legítimos estén aprobando.

¿Por qué nunca llegan los correos de confirmación de Supabase? El servicio por defecto solo envía a las direcciones de tu equipo y tiene un límite por hora muy bajo. Lo explicamos en la guía de Supabase no envía el correo de confirmación.

¿Cuánto tarda en mejorar la reputación? Se construye en días o semanas de correo constante y deseado. La autenticación ayuda de inmediato; la reputación lleva más tiempo.

¿Quieres que revisemos tu configuración de correo?

El correo toca a la vez el DNS, tu backend y tu proveedor de envío, y un detalle desalineado se pasa por alto fácil. Nuestro servicio de mantenimiento de software incluye configurar y verificar la autenticación del correo. Puedes empezar con el chequeo gratuito o contarnos qué pasa.