Por qué el correo transaccional llega a spam — y cómo arreglar la entregabilidad

El correo transaccional llega a spam casi siempre por una autenticación mal configurada o ausente — no porque la palabra "gratis" aparezca en tu recibo. Si tus restablecimientos de contraseña, confirmaciones de pedido y notificaciones del formulario de contacto caen en la carpeta de correo no deseado, la solución casi nunca es reescribir el texto; es configurar bien SPF, DKIM y DMARC, enviar desde un dominio verificado y asegurarte de que el Return-Path esté alineado. Esta es la guía práctica de entregabilidad de correo transaccional que nos habría gustado tener, basada en la configuración exacta de Resend-sobre-PHP que usamos en Amplified Creations.

Por qué el correo transaccional llega a spam

Los servidores de recepción de correo — Gmail, Outlook, Apple iCloud, tenants corporativos de Microsoft 365 — no leen tu correo y deciden que "parece spam". Primero ejecutan una serie de comprobaciones automáticas, y las más importantes son sobre quién dices que eres frente a quién eres realmente. Un recibo que falla la autenticación se trata como posible suplantación (spoofing), y la suplantación es exactamente lo que los filtros de spam existen para detener. Así que el recibo de una caja de chocolate de 40 € recibe la misma sospecha que un intento de phishing, y acaba en la carpeta de spam.

Los tres registros que transportan esa autenticación son SPF, DKIM y DMARC. Viven en el DNS, son aburridos de configurar y son lo de mayor impacto que puedes hacer por la entregabilidad. Configúralos mal y hasta el contenido perfecto cae en spam. Configúralos bien y hasta el contenido mediocre llega a la bandeja de entrada. Definamos cada uno tal como lo usa de verdad un proveedor de correo.

SPF (Sender Policy Framework)

SPF es un registro DNS TXT en tu dominio que enumera qué servidores están autorizados a enviar correo por ese dominio. Cuando un servidor de recepción recibe un mensaje que dice venir de noreply@tudominio.com, consulta el registro SPF y comprueba si la IP de envío está en la lista aprobada. Un registro típico tiene este aspecto:

tudominio.com.  TXT  "v=spf1 include:_spf.resend.com ~all"

El mecanismo include: delega en el SPF de tu propio proveedor de correo (aquí, el de Resend). El ~all al final es un "soft fail" — todo lo no listado es sospechoso pero no se rechaza de inmediato. Dos cosas pillan a la gente: solo puedes tener un registro SPF por dominio (varios registros es un error grave, debes fusionar las entradas include:), y SPF comprueba el remitente oculto del sobre (el Return-Path), no la cabecera From: que ve tu usuario. Más sobre esto abajo.

DKIM (DomainKeys Identified Mail)

DKIM añade una firma criptográfica a cada mensaje. Tu proveedor guarda una clave privada y firma el correo saliente; tú publicas la clave pública correspondiente en el DNS bajo un selector. El servidor de recepción obtiene esa clave pública, verifica la firma y confirma que el cuerpo del mensaje y las cabeceras clave no se manipularon en tránsito. El registro DNS parece una clave larga bajo un subdominio de selector:

resend._domainkey.tudominio.com.  TXT  "p=MIGfMA0GCSqGSIb3DQ...clave-publica-larga...AQAB"

La parte resend._domainkey es el selector — permite a un proveedor rotar claves y ejecutar varias en paralelo. DKIM es lo que prueba que el correo vino genuinamente de alguien que posee la clave de tu dominio, y por eso es la columna vertebral del siguiente registro.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC une SPF y DKIM y le dice a los receptores qué hacer cuando un mensaje falla. Es un registro TXT en _dmarc.tudominio.com con una política:

_dmarc.tudominio.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com; adkim=s; aspf=s"

La política p= tiene tres valores. p=none significa "solo monitorizar, entregar con normalidad pero envíame informes" — por donde se empieza. p=quarantine significa "envía los fallos a spam". p=reject significa "rechaza los fallos de inmediato" — el más fuerte, y donde acaban los remitentes serios. El concepto crucial que añade DMARC es el alineamiento: no basta con que SPF o DKIM pasen, el dominio para el que pasan debe coincidir con el dominio en la cabecera From: visible. adkim=s y aspf=s piden alineamiento estricto. Este requisito de alineamiento es justo la razón por la que ocurre lo de "se envía bien desde mi script pero Gmail lo marca" — la autenticación subyacente pasa para el dominio del proveedor, no para el tuyo.

La dirección rua= es a donde van los informes agregados. Esos informes son oro y los cubrimos al final.

Configuración de SPF DKIM DMARC: las partes que la gente se salta

Publicar tres registros es el 80% fácil. El 20% que de verdad decide si llegas a la bandeja de entrada está abajo, y es donde más horas de depuración hemos gastado.

Usa un dominio de envío verificado o un subdominio dedicado

Enviar "desde" un dominio que no has verificado con tu proveedor es el camino más rápido al spam, porque ninguna de las autenticaciones puede alinear. Un dominio de envío verificado significa que has demostrado el control publicando los registros DNS del proveedor y el proveedor ha confirmado que resuelven. Nosotros vamos un paso más allá y enviamos correo transaccional desde un subdominio dedicado — algo como mail.tudominio.com o send.tudominio.com — en lugar del dominio raíz. Esto aísla la reputación: si alguna vez un envío masivo de marketing o un formulario descontrolado quema la reputación del subdominio de envío, tu dominio raíz (y el correo que tus humanos envían desde Gmail) se mantiene limpio. La reputación de un subdominio es en gran medida independiente de la del padre.

Return-Path y alineamiento de sobre

Cada correo tiene en realidad dos direcciones "de". Está la cabecera From: que ve el destinatario, y está el remitente oculto del sobre — el Return-Path, también llamado MAIL FROM — que SPF comprueba de hecho y a donde van los rebotes. Cuando envías a través de un proveedor, el Return-Path a menudo toma por defecto el propio dominio del proveedor, lo que significa que SPF pasa para ellos, no para ti, y el alineamiento DMARC puede fallar aunque "SPF haya pasado". La solución es dejar que el proveedor fije un Return-Path en tu propio subdominio (Resend lo hace mediante los registros de rebote/feedback que te pide publicar). Cuando el Return-Path está en tu dominio y SPF pasa ahí, obtienes SPF alineado y DMARC queda contento.

DNS inverso, IPs compartidas y reputación

Dos hechos de infraestructura moldean la entregabilidad y en gran parte los heredas de tu proveedor. Primero, el DNS inverso (PTR): la IP de un servidor de correo bien comportado resuelve de vuelta a un nombre de host, y ese nombre de host resuelve hacia adelante a la misma IP. El correo desde una IP sin registro PTR se penaliza fuertemente. Segundo, IPs compartidas vs dedicadas: la mayoría de los remitentes, nosotros incluidos, está en un conjunto de IPs compartidas gestionado por el proveedor. Eso es bueno — el conjunto tiene reputación ya "calentada" que no podrías construir solo con poco volumen — pero también significa que un mal actor en el mismo conjunto puede dañar tu entrega. Este es el verdadero argumento a favor de un proveedor serio: vigila sus conjuntos, gestiona el PTR, calienta IPs y maneja los feedback loops para que no tengas que correr un servidor de correo en OVH y suplicarle a Microsoft que te saque de la lista negra.

Contenido y nociones básicas de disparadores de spam

El contenido importa mucho menos que la autenticación, pero no es cero. Mantén una proporción texto-imagen sensata (un correo solo de imágenes se lee como sospechoso), incluye siempre una alternativa en texto plano junto al HTML, no enlaces a acortadores ni a dominios de mala reputación, y no grites en MAYÚSCULAS con filas de signos de exclamación. Para correo genuinamente transaccional — un restablecimiento de contraseña, un recibo de pedido — esto rara vez es el problema. Pasa a serlo en el momento en que una plantilla "transaccional" empieza a llevar marketing, lo que lleva al siguiente punto.

List-Unsubscribe para todo lo masivo

En el instante en que tu correo es masivo o promocional — boletines, correos de "te echamos de menos", cualquier cosa enviada a una lista — Gmail y Yahoo exigen una cabecera List-Unsubscribe, y desde 2024 una versión de un clic (List-Unsubscribe-Post: List-Unsubscribe=One-Click). El correo puramente transaccional está exento, pero la frontera se impone por el comportamiento: si cuelas una promoción en un recibo y la gente lo marca como spam, tu flujo transaccional paga el precio de reputación. Mantén lo transaccional y lo de marketing en subdominios separados y flujos separados. Nosotros lo hacemos.

Cómo enviamos: Resend sobre PHP en Amplified Creations

Esto es lo que realmente ejecutamos, con honestidad. Amplified Creations es un pequeño estudio independiente en Leiria y Lisboa; nuestro sitio es PHP 8.3 renderizado en el servidor, en alojamiento compartido de OVH, detrás de Cloudflare, con un Cockpit CMS headless y sin paso de build. Para el correo usamos Resend con un dominio de envío verificado. La verificación en Resend es el mismo proceso descrito arriba: añades el dominio en su panel, te entrega un conjunto de registros DNS — la clave DKIM bajo un selector, un include: de SPF y los registros de Return-Path/rebote para el alineamiento de sobre — y los publicas en tu proveedor de DNS. En cuanto se ponen en verde, el correo está autenticado y alineado.

Esa única configuración alimenta dos cosas. La primera es el formulario de contacto del sitio: un envío dispara un pequeño handler PHP que llama a la API de Resend para avisarnos. La segunda es el correo transaccional de clientes — los mensajes de ciclo de vida que envían nuestras aplicaciones. El ejemplo más claro es la suite de Stripe que construimos para Delicious Diamonds, una chocolatería de lujo en Leiria. Su tienda gestiona pedidos puntuales, pedidos a medida, ediciones limitadas numeradas a mano y suscripciones mensuales con pausa, cancelación y cambio de nivel — todo movido por webhooks de ciclo de vida de Stripe. Cada uno de esos eventos que necesita llegar a un humano — una confirmación de pedido, una suscripción en pausa, un pago que requiere atención — sale por el mismo dominio Resend autenticado. Más allá de la tienda, nuestro trabajo va de recomendadores de machine learning (Jofit) a captura 3D y VR accesible y médica, pero los principios del correo son idénticos en todas partes: autenticar bien, alinear el Return-Path y mantener los flujos separados.

Monitorización con informes agregados DMARC

En cuanto p=none está activo con una dirección rua=, los receptores empiezan a enviarte a diario informes agregados en XML. Son ilegibles en crudo, así que aliméntalos a un panel de DMARC (hay niveles gratuitos). Cada informe te dice, por fuente de envío, cuánto correo pasó SPF, pasó DKIM y alineó para DMARC. Así descubres el plugin de WordPress olvidado o el CRM que aún envía como tu dominio y falla el alineamiento — lo que silenciosamente hundiría tu reputación. Solo cuando los informes muestran que tus fuentes legítimas están 100% alineadas aprietas la política: p=none a p=quarantine, observa un par de semanas, luego p=reject. Aprieta antes de estar limpio y empezarás a bloquear tus propios recibos.

Versión corta

• Autenticación, no palabras. El correo transaccional cae en spam porque SPF, DKIM o DMARC fallaron — arregla eso primero.
• SPF: un registro TXT que enumera los remitentes autorizados; comprueba el Return-Path del sobre, no el From: visible.
• DKIM: una firma criptográfica; publica la clave pública bajo un selector como resend._domainkey.
• DMARC: política p=none → quarantine → reject; exige alineamiento entre el dominio de autenticación y el dominio From:.
• Dominio verificado + subdominio dedicado aísla la reputación y permite que los tres alineen.
• Return-Path debe estar en tu dominio, o SPF pasa para el proveedor y DMARC falla.
• List-Unsubscribe (un clic) es obligatorio para todo lo masivo; mantén transaccional y marketing separados.
• Lee tus informes agregados DMARC antes de apretar a p=reject.

Preguntas frecuentes

¿Por qué mi correo transaccional llega a spam aunque el contenido esté bien?

Porque la entregabilidad se decide por la autenticación antes de que se lea siquiera el contenido. Si SPF, DKIM o DMARC fallan — o pasan pero no alinean con tu dominio From: visible — el servidor de recepción trata el mensaje como posible suplantación y lo archiva como spam sin importar lo que diga. Arregla primero la autenticación y el alineamiento.

¿Necesito los tres, SPF, DKIM y DMARC?

Sí. SPF y DKIM prueban cada uno un aspecto de la autenticidad, y DMARC los une con una regla de alineamiento y le dice a los receptores qué hacer ante un fallo. Gmail y Yahoo ahora exigen en la práctica los tres para cualquier volumen significativo, así que trátalos como un conjunto, no como un menú.

¿Cuál es la diferencia entre el Return-Path y la cabecera From?

La cabecera From: es la dirección que ve el destinatario; el Return-Path (remitente del sobre) es la dirección oculta que SPF comprueba y a donde vuelven los rebotes. Pueden diferir, y ese desajuste es la razón por la que "SPF pasó" puede aun así fallar DMARC — el alineamiento exige que el dominio del Return-Path coincida con el dominio del From:. Configura tu proveedor para que fije el Return-Path en tu propio dominio.

¿Cómo funciona la verificación de dominio en Resend?

Añades tu dominio en el panel de Resend y te da registros DNS para publicar: una clave pública DKIM bajo un selector, un include: de SPF y registros de Return-Path/rebote para el alineamiento. En cuanto resuelven y Resend marca el dominio como verificado, tu correo está firmado y alineado. Usamos exactamente esta configuración para nuestro formulario de contacto y para el correo transaccional de clientes.

¿Deben el correo transaccional y el de marketing usar el mismo dominio?

No — usa subdominios separados para que la reputación quede aislada. Si una campaña de marketing recibe quejas de spam, no quieres que arrastre consigo tus restablecimientos de contraseña y recibos. Un subdominio transaccional dedicado mantiene ese flujo crítico limpio y te permite aplicarle una política DMARC más estricta.