Cómo enviar emails desde tu app (y llegar a la bandeja de entrada)

Para enviar emails desde tu app de forma fiable, usa un proveedor de envío de email 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 email transaccional (restablecimientos de contraseña, recibos, confirmaciones) del email de marketing, envía cada uno solo a quien lo espera y gestiona los rebotes y las bajas. Consigue primero la autenticación bien hecha: es la causa más habitual de que el email de una app acabe en spam.

Email transaccional frente a email de marketing

Estos dos tipos de email 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 de ese mismo flujo se resientan por ello. Un enfoque habitual son subdominios separados, por ejemplo mail.ejemplo.com para el email de cuenta y news.ejemplo.com para los boletines; algunos proveedores los separan internamente. Postmark, por ejemplo, describe sus "message streams" transaccional y de difusión como infraestructuras de envío separadas, a septiembre de 2026.

Elegir un proveedor

Tu app no debería enviar email 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; todos tienen API HTTP y acceso SMTP, y los precios y planes cambian, así que compáralos en sus propias webs.

Qué comparar:

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

Para boletines a una lista, una herramienta dedicada de newsletter o de email marketing suele encajar mejor que crear funciones de campaña 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 de terceros falla las comprobaciones de autenticación y es probable que se filtre.

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, mantiene los registros DNS del email separados de los de tu web principal.

El proveedor te dará después registros DNS que añadir donde se gestione el DNS de tu dominio. Si el DNS te resulta nuevo, 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 email en nombre de tu dominio. El receptor comprueba si el servidor que envía está en la 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 evaluarlo; cadenas largas de entradas include: pueden superar ese límite y provocar fallos.
• Muchos proveedores configuran SPF en un subdominio de retorno (return-path) 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; tú publicas la clave pública correspondiente como registro DNS (TXT o CNAME, según el proveedor). El receptor comprueba la firma para confirmar que el mensaje viene de un remitente autorizado y que no se alteró por el camino.

El paso de "verificar dominio" de tu proveedor trata sobre todo de DKIM. No lo omitas.

DMARC

DMARC une los otros dos. Es un registro TXT en _dmarc.tudominio.com que indica a los receptores:

• 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 nombre de tu dominio.

Una vía 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 finalmente a reject. Una política estricta también dificulta mucho que otros suplanten tu dominio.

Lo que exige Gmail

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

• Todos los remitentes de cuentas personales de Gmail necesitan SPF o DKIM, registros DNS directos e inversos 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 baja con un clic más un enlace visible de baja en los mensajes de marketing y de suscripción.

Tu proveedor se encarga de las partes del lado del servidor. Los registros DNS y la gestión de las bajas son tuyos. Aunque no llegues a 5.000 al día, cumplir las reglas de remitente masivo es la forma más sencilla de estar a salvo.

Integra el envío en tu app

Cuando el dominio esté verificado:

1. Guarda la clave de API como secreto 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 email tenga éxito.
3. No hagas esperar al usuario por el email. En cualquier app 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 con rebote definitivo o que te marquen como spam.

Un prompt que cubre lo básico:

Envía email transaccional con [PROVEEDOR] usando el secreto del servidor [NOMBRE_VARIABLE], desde "Acme hola@mail.acme.com". Envía un email de bienvenida tras el registro y una confirmación de reserva cuando se guarde una reserva. Guarda 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 omítelas en envíos futuros.

Los emails 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 consigue que te consideren. El comportamiento te mantiene en la bandeja de entrada.

• Envía solo lo que la gente espera. Registros confirmados, consentimiento claro para el marketing, nada de listas compradas.
• Haz que darse de baja sea fácil en todo lo que no sea estrictamente transaccional, y respétalo de inmediato.
• Calienta los dominios nuevos. Un dominio recién creado que envía miles de mensajes el primer día parece sospechoso. Empieza con tu correo transaccional y aumenta el volumen poco a poco.
• Mantén las listas limpias. Elimina los rebotes definitivos de inmediato y considera quitar a quienes llevan mucho tiempo sin abrir nada.
• Escribe como una persona. Un asunto claro, un nombre From 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 revisa de vez en cuando los informes DMARC.
• Usa una 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 cuando exista, o envía a direcciones que sean tuyas.
• En desarrollo, envía a una bandeja de pruebas catch-all en lugar de a usuarios reales; una base de datos sembrada con direcciones de aspecto real es una forma fácil de escribir a desconocidos por error.
• Revisa cada plantilla en varios clientes: Gmail en la web, una app de correo en el móvil, Outlook, y en modo oscuro.
• Mira las cabeceras de un email de prueba: muestran si SPF, DKIM y DMARC han pasado.

Aspectos legales básicos

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

Lista de comprobación del email

• 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 superados
• 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; los correos de prueba nunca llegan a usuarios reales

Enviar email desde una app de Mythex

Mythex no incluye un servicio de envío de email integrado para las apps que construyes, así que traes tu propio proveedor, como Resend, SendGrid o Postmark. Guarda su clave de API como secreto del proyecto (el agente puede pedirla mediante una tarjeta de secretos en el chat) y pide los emails que necesites con palabras sencillas. La documentación tiene un prompt de ejemplo en enviar email 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