Cómo enviar correos desde tu app (y que lleguen a la bandeja de entrada)

Para enviar correos desde tu app de forma fiable, usa un proveedor de envío de correo en lugar de tu propio buzón, envía desde una dirección de tu dominio y añade los registros DNS que te dé el proveedor para que SPF, DKIM y DMARC pasen todos. Mantén separado el correo transaccional —restablecimientos de contraseña, recibos, confirmaciones— del correo de marketing, envía cada tipo solo a personas que lo esperan y gestiona los rebotes y las bajas. Ante todo, asegura la autenticación: es la causa más habitual de que el correo de una app acabe en spam.

Correo transaccional frente a correo de marketing

Estos dos tipos de correo se parecen en el código, pero los proveedores de bandejas de entrada y la ley los tratan de forma muy distinta.

Sepáralos. Si una campaña de marketing recibe quejas de spam, no quieres que los restablecimientos de contraseña que salen del mismo flujo se resientan por ello. Un enfoque habitual es usar subdominios distintos, por ejemplo mail.ejemplo.com para el correo de cuenta y news.ejemplo.com para las newsletters; algunos proveedores separan ambos internamente. Postmark, por ejemplo, describe sus «message streams» transaccionales y de difusión como si funcionaran con infraestructuras de envío separadas, a septiembre de 2026.

Elegir proveedor

Tu app no debería enviar correos por sí misma desde su propio servidor. Los proveedores de envío se encargan de la infraestructura, la reputación de las IP, los reintentos y el procesamiento de rebotes. Entre las opciones conocidas están Postmark, Resend, SendGrid, Amazon SES y Mailgun; todas ofrecen una API HTTP y acceso SMTP. Los precios y los planes cambian, así que compáralos en sus propias webs.

Qué comparar:

• Enfoque. Algunos proveedores se centran en el correo transaccional; otros combinan transaccional y marketing.
• Experiencia para desarrolladores. Una API clara, librerías oficiales para tu lenguaje y registros útiles que muestren si cada mensaje se entregó, rebotó o se marcó como spam.
• Webhooks para rebotes, quejas y entregas, de modo que tu app pueda reaccionar.
• Plantillas: guardadas en el proveedor o en tu propio código. Si las guardas en el código, quedan versionadas y se pueden probar.
• Región y tratamiento de datos, si tienes requisitos sobre dónde se procesan.
• Coste según tu volumen, incluido lo que pasa cuando superas el nivel gratuito.

Para newsletters a una lista, una herramienta de newsletter o de email marketing suele encajar mejor que construir funciones de campañas dentro de tu app.

Configura tu dominio de envío

Envía desde tu propio dominio —hola@ejemplo.com, no una dirección de Gmail u Outlook—. El correo desde un buzón gratuito enviado a través de un servicio externo no supera las comprobaciones de autenticación y es probable que acabe filtrado.

Considera un subdominio solo para el envío. Resend, por ejemplo, recomienda enviar desde subdominios como actualizaciones.ejemplo.com para aislar la reputación de envío (a septiembre de 2026). Además, así los registros DNS del correo quedan separados de los de tu web principal.

Después, el proveedor te dará registros DNS que añadir donde gestiones el DNS de tu dominio. Si el DNS es nuevo para ti, cómo funcionan los dominios y el DNS explica primero los registros.

SPF

SPF (Sender Policy Framework) es un registro TXT que enumera qué servidores pueden enviar correo por tu dominio. Quien recibe el correo comprueba si el servidor que envía está en esa lista.

• Un dominio debe tener solo un registro SPF. Si añades un proveedor, incorpóralo al registro existente en lugar de añadir un segundo.
• SPF permite como máximo 10 consultas DNS al evaluarse; las cadenas largas de entradas include: pueden superar ese límite y provocar fallos.
• Muchos proveedores configuran el SPF en un subdominio de retorno que te piden crear, así que puede que no tengas que tocar tu registro SPF principal.

DKIM

DKIM (DomainKeys Identified Mail) añade una firma criptográfica a cada mensaje. El proveedor firma con una clave privada y tú publicas la clave pública correspondiente como registro DNS (TXT o CNAME, según el proveedor). Quien recibe comprueba la firma para confirmar que el mensaje procede de un remitente autorizado y que no se alteró por el camino.

El paso de «verificar dominio» de tu proveedor consiste sobre todo en DKIM. No lo saltes.

DMARC

DMARC une los otros dos. Es un registro TXT en _dmarc.tudominio.com que indica a quien recibe el correo:

• Alineación: el dominio de la dirección From visible debe coincidir con el dominio que superó SPF o DKIM.
• Política: qué hacer con el correo que falla: p=none (solo informar), p=quarantine (tratarlo como sospechoso, a menudo spam) o p=reject.
• Informes: a qué dirección enviar los informes agregados (rua=), para ver quién envía en tu nombre.

Una ruta sensata es empezar con p=none y una dirección de informes, confirmar que tu correo legítimo pasa, y después pasar a quarantine y, con el tiempo, a reject. Una política estricta también dificulta mucho que otros suplanten tu dominio.

Lo que exige Gmail

Desde septiembre de 2026, las directrices de remitentes de Google indican:

• Todos los remitentes a cuentas personales de Gmail necesitan SPF o DKIM, DNS directo e inverso válidos para los servidores de envío, TLS, y una tasa de spam en Postmaster Tools inferior al 0,3 %.
• Remitentes masivos (más de 5.000 mensajes al día a Gmail) necesitan SPF y DKIM, un registro DMARC (se admite una política p=none), alineación del dominio From y una baja de un clic, además de un enlace visible de baja en los mensajes de marketing y de suscripción.

Tu proveedor se encarga de las partes del servidor. Los registros DNS y la gestión de las bajas son cosa tuya. Aunque estés lejos de los 5.000 diarios, cumplir las reglas para remitentes masivos es la forma más sencilla de estar a salvo.

Integra el envío en tu app

Una vez verificado el dominio:

1. Guarda la clave de API como secreto del lado del servidor, nunca en el código de front-end. Consulta qué son las variables de entorno y los secretos.
2. Envía desde el servidor, después de que la acción que dispara el correo se haya completado con éxito.
3. No hagas esperar al usuario por el correo. En cualquier app que vaya más allá de lo más simple, pon el envío en cola y reintenta ante fallos temporales, para que una respuesta lenta del proveedor no ralentice el registro.
4. Registra el resultado: el ID del mensaje del proveedor y su estado, sin registrar la clave ni el cuerpo completo de los mensajes con datos personales.
5. Gestiona los webhooks de rebotes y quejas: deja de enviar a las direcciones que rebotan de forma definitiva o que te marcan como spam.

Un prompt que cubre lo básico:

Envía correo transaccional con [PROVEEDOR] usando el secreto del servidor [NOMBRE_VARIABLE], desde «Acme hola@mail.acme.com». Envía un correo de bienvenida tras el registro y una confirmación de reserva cuando se guarde una reserva. Mantén las plantillas en el código, con una versión en texto plano junto al HTML. Pon los envíos en cola y reintenta los fallos temporales hasta tres veces. Registra los fallos con el error del proveedor, pero nunca la clave de API. Añade un endpoint de webhook que marque las direcciones como no entregables tras rebotes definitivos y quejas, y omite esas direcciones en el futuro.

Los correos de cuenta —enlaces de verificación, enlaces mágicos y restablecimientos de contraseña— forman parte del inicio de sesión. Cómo añadir inicio de sesión a tu app explica cómo encajan esos flujos; haz que estos enlaces sean de un solo uso y de corta duración.

Hábitos de entregabilidad

La autenticación hace que tu correo se considere; el comportamiento hace que se quede en la bandeja de entrada.

• Envía solo lo que la gente espera. Registros confirmados, consentimiento explícito para el marketing, nada de listas compradas.
• Facilita la baja en todo lo que no sea estrictamente transaccional, y respétala de inmediato.
• Calienta los dominios nuevos. Un dominio recién estrenado que envía miles de mensajes el primer día resulta sospechoso. Empieza con tu correo transaccional y aumenta el volumen poco a poco.
• Mantén las listas limpias. Elimina de inmediato los rebotes definitivos y valora quitar a quienes no han abierto nada desde hace mucho tiempo.
• Escribe como una persona. Un asunto claro, un nombre de remitente reconocible, una parte en texto plano, pocas imágenes y enlaces a tu propio dominio. Evita los acortadores de enlaces.
• Monitoriza. Registra tu dominio en Google Postmaster Tools y lee de vez en cuando los informes DMARC.
• Usa una dirección de respuesta real que alguien lea. Las respuestas son una buena señal y una fuente útil de feedback.

Probar sin enviar spam a nadie

• Usa el modo de prueba o sandbox de tu proveedor, si lo tiene, o envía a direcciones que sean tuyas.
• En desarrollo, envía a una bandeja de pruebas que capture todo en lugar de a usuarios reales; una base de datos de prueba llena de direcciones con aspecto real es una forma fácil de escribir a desconocidos por accidente.
• Revisa cada plantilla en varios clientes —Gmail en el navegador, la app de correo del móvil, Outlook— y también en modo oscuro.
• Mira las cabeceras de un correo de prueba: muestran si SPF, DKIM y DMARC han pasado.

Nociones legales básicas

Las normas varían según el país. En líneas generales, el correo de marketing necesita consentimiento en muchos lugares, debe identificar al remitente y debe ofrecer una baja que funcione; el correo transaccional se trata de forma distinta, pero no debe usarse para colar publicidad. Si recoges direcciones desde una página de lista de espera, di qué enviarás, qué almacenarás, cuándo y cómo se registró cada persona. Ante la duda, consulta la normativa del lugar donde están tus usuarios.

Lista de comprobación del correo

• Proveedor de envío elegido; clave de API guardada como secreto del servidor
• Envío desde tu propio dominio o subdominio, no desde un buzón gratuito
• Registros SPF, DKIM y DMARC añadidos y superando las comprobaciones
• Correo transaccional y de marketing separados
• Envíos en cola con reintentos; resultados registrados
• Webhooks de rebotes y quejas gestionados
• Baja en el correo no transaccional, respetada de inmediato
• Plantillas probadas en varios clientes; el correo de prueba nunca llega a usuarios reales

Enviar correo desde una app de Mythex

Mythex no incluye un servicio de envío de correo integrado para las apps que construyes, así que aportas tu propio proveedor, como Resend, SendGrid o Postmark. Guarda su clave de API como secreto del proyecto —el agente puede pedirla con una tarjeta de secretos en el chat— y pide en lenguaje sencillo los correos que necesitas. La documentación tiene un prompt de partida en enviar correo desde tu app. Si compraste tu dominio a través de Mythex en Pro, puedes añadir los registros TXT y CNAME del proveedor en la configuración DNS del dominio; consulta dominios personalizados.

Preguntas