Por qué los correos de tu formulario caen en spam
Una solicitud en la carpeta de spam es una solicitud perdida. La causa más común está en una sola línea de la configuración del formulario. Después vienen los tres registros DNS que todo dominio debería tener, lo que exigen Gmail y Outlook desde 2024 y la revisión de nuestro propio dominio, con hueco incluido.
Una solicitud que queda en la carpeta de spam sale más cara que una solicitud que nunca se escribió. La persona hizo el esfuerzo, está esperando respuesta y no pasa nada. La próxima vez le escribe a alguien más.
La causa más común está en una sola línea de la configuración del formulario. Después vienen tres registros en el DNS que todo dominio debería tener. Por orden.
El error que más cuesta
Muchos formularios de contacto mandan el aviso así:
De: visitante@gmail.com
Para: contacto@tu-dominio.comSe siente práctico, porque puedes responder directo desde la bandeja. Para el servidor que recibe se ve de otra forma: una máquina que pertenece a tu-dominio.com afirma estar enviando correo en nombre de gmail.com. Los servidores revisan esa afirmación desde hace años, y Google publica una política estricta para su propio dominio. El resultado va desde la etiqueta de spam hasta el rechazo.
Lo correcto es separar remitente y dirección de respuesta:
De: hola@primero.link
Responder a: visitante@gmail.comEl remitente se queda en tu dominio, por el que tu servidor sí tiene permiso de enviar. La dirección del visitante va en Responder a, y el botón de responder sigue llegando a la persona correcta. En nuestro caso eso vive en el encabezado de la página de contacto:
email:
subject: 'Solicitud vía primero.link: '
reply_to: ''En un plugin de formularios comercial la opción suele estar bajo "Remitente" y "Responder a". Si en el campo del remitente hay un marcador como {email}, ya encontraste la línea que te está costando solicitudes.
Los tres registros
| Registro | Qué responde | Dónde vive |
|---|---|---|
| SPF | ¿Qué servidores pueden enviar por este dominio? | registro TXT en el dominio |
| DKIM | ¿De verdad viene de ahí y llegó sin cambios? | registro TXT bajo selector._domainkey |
| DMARC | ¿Qué hacer cuando la revisión falla y a dónde van los reportes? | registro TXT bajo _dmarc |
Dos términos que aparecen en cualquier guía:
Alineación significa que el dominio de la línea visible del remitente coincide con el dominio que verificaron SPF o DKIM. Un envío técnicamente impecable a través de un proveedor falla en DMARC mientras la dirección visible apunte a otro lado.
Política es lo que DMARC le recomienda al receptor: p=none para observar, p=quarantine para la carpeta de spam, p=reject para rechazar. El camino habitual arranca en none, lee los reportes unas semanas y después aprieta.
Lo que exigen los buzones grandes
| Quién | Desde cuándo | Qué |
|---|---|---|
| Google, todos los remitentes | 1 de febrero de 2024 | SPF o DKIM, DNS inverso válido de la IP, TLS, tasa de spam por debajo de 0.3 por ciento |
| Google, desde 5,000 mensajes al día | 1 de febrero de 2024 | SPF y DKIM y DMARC, alineación, baja con un clic |
| Microsoft, desde 5,000 mensajes al día a outlook.com, hotmail.com, live.com | 5 de mayo de 2025 | SPF y DKIM y DMARC con al menos p=none |
Microsoft empezó en mayo de 2025 mandando esos mensajes a la carpeta de no deseados. Hoy los rechaza de plano, con un código que vale la pena memorizar:
550 5.7.515 Access denied, sending domain does not meet
the required authentication levelEl umbral de cinco mil suena lejano cuando tu formulario genera cinco solicitudes al mes. También es la cifra equivocada para vigilar: en un remitente pequeño lo que decide es la reputación del dominio, y esa reputación se construye pasando revisiones.
Novedad desde mayo de 2026
DMARC tiene edición nueva. Los RFC 9989, 9990 y 9991 de mayo de 2026 sustituyen al RFC 7489 y reparten la especificación en tres documentos. Tres cambios tocan registros que ya existen:
| Cambio | Qué significa para tu registro |
|---|---|
pct= desaparece |
La implantación por porcentaje se fue. Si traes pct=100, quítalo |
Llega t=y |
Modo de prueba: el receptor aplica el escalón inmediatamente más suave |
| Búsqueda por el árbol en vez de lista | El dominio responsable se ubica con consultas DNS, hasta ocho niveles |
Llega np= |
Regla aparte para subdominios que no existen, contra remitentes inventados |
La revisión de nuestro propio dominio
Consultado el 19 de septiembre de 2026, con las mismas tres preguntas que están abajo.
| Revisión | Resultado | Lectura |
|---|---|---|
| SPF | v=spf1 mx a include:_spf.webhosting.systems ~all |
bien. El formulario envía por la misma máquina que recibe nuestro correo, cubierta por el mecanismo mx |
| DMARC | v=DMARC1; p=quarantine; rua=…; ruf=…; fo=1; pct=100 |
política puesta y reportes llegando. pct=100 sobra desde mayo de 2026 |
| DKIM | sin respuesta bajo los selectores habituales | hueco. O falta la llave o vive bajo un selector que aquí no adivinamos |
Ese último renglón es la razón de este artículo. Un dominio en p=quarantine y sin DKIM depende por completo de SPF. Eso aguanta mientras el correo viaja directo. Se rompe en cuanto alguien reenvía un mensaje, porque el reenvío rompe SPF y deja DKIM intacto. Así que lo siguiente en nuestra lista es activar DKIM en el panel del servidor y revisar el registro. El selector se lee después en los encabezados de un mensaje realmente enviado.
El hallazgo es típico. Los paquetes de hosting suelen traer SPF preconfigurado, DMARC lo pones tú y DKIM es un interruptor en el panel que nadie movió.
Revisión en cinco minutos
dig +short TXT tu-dominio.com # SPF es la línea que empieza con v=spf1
dig +short TXT _dmarc.tu-dominio.com # DMARC
dig +short TXT default._domainkey.tu-dominio.com # DKIM, el selector varíaEl selector es el único tropiezo: se asigna al configurar y se llama default, dkim, s1 u otra cosa según el proveedor. Los encabezados de un mensaje real lo delatan: en Gmail abres "Mostrar original" y buscas DKIM-Signature, donde el s= es el selector.
Para probar la entregabilidad en sí, manda un mensaje a una dirección de Gmail y otro a una de Outlook. Lo que a ti te caiga en spam, a tus clientes también.
Lo que puedes hacer hoy
- Revisa qué trae tu formulario como remitente. Si es la dirección del visitante, cámbiala por la tuya y pasa la del visitante a Responder a.
- Haz que el formulario guarde una copia. Un registro en el servidor es la segunda huella con la que se nota una falla. Cada solicitud nuestra queda como archivo, aparte del correo.
- Corre las tres consultas de arriba.
- Pon DMARC en
p=nonecon una dirección de reportes si todavía no hay nada, lee los reportes dos semanas y después pasa aquarantine. - Manda una solicitud de prueba por tu propio formulario y mira dónde aterriza. Una vez por trimestre es buen ritmo.
Si quieres saber si las solicitudes de tu sitio están llegando de forma confiable: escríbenos con tu dominio. Revisamos los tres registros y te decimos qué falta.
Fuentes
Vigencia de este artículo
Sin cambios de fondo desde su publicación.
Preguntas frecuentes sobre entregabilidad
¿Por qué el formulario no debe usar el correo del visitante como remitente?
Porque tu servidor estaría afirmando que escribe en nombre de un dominio ajeno. El servidor que recibe revisa si tu máquina tiene permiso de enviar por ese dominio, y la respuesta es negativa. Con una política DMARC estricta del otro lado, el mensaje va a cuarentena o se rechaza. La solución es dejar tu propia dirección como remitente y poner la del visitante en Responder a. Contestar sigue siendo un clic.
¿Cuál es la diferencia entre SPF, DKIM y DMARC?
SPF enumera los servidores autorizados a enviar por tu dominio. DKIM firma cada mensaje con una llave cuya mitad pública vive en el DNS, lo que prueba el origen y que nada se alteró en el camino. DMARC une ambas con la dirección visible del remitente y le dice al receptor qué hacer cuando la revisión falla. Sin DMARC, SPF y DKIM son dos pruebas sin consecuencia.
¿Esto aplica con cinco correos al mes?
Sí, y por una razón distinta a la de quien manda boletines. Google exige desde el 1 de febrero de 2024 al menos SPF o DKIM a todo remitente. Lo que más pesa en el día a día: un dominio de bajo volumen no tiene reputación en la que el filtro pueda apoyarse, así que la autenticación cuenta más para ti que para quien manda mil mensajes diarios.
¿Qué significa la tilde de ~all en el registro SPF?
Softfail: los mensajes de servidores fuera de tu lista deben aceptarse y marcarse como sospechosos. La variante estricta -all significa hardfail, o sea rechazar. Softfail es el punto de partida habitual porque una ruta de envío olvidada sigue llegando. Cuando ya conoces todas tus rutas, pasas a -all.
¿Qué cambió en DMARC en 2026?
En mayo de 2026 aparecieron los RFC 9989, 9990 y 9991, que sustituyen al RFC 7489. Para la práctica cuentan tres cosas: la etiqueta pct= desapareció y en su lugar está t=y para el modo de prueba; el dominio responsable ahora se busca subiendo por el árbol del DNS en vez de consultar una lista; y np= permite una regla aparte para el correo que dice venir de subdominios inexistentes.
¿Cómo me doy cuenta de que se pierden solicitudes?
Lo más confiable es que el formulario guarde una copia. Si hay una solicitud en tu registro y el correo correspondiente nunca llegó, ya tienes la prueba. Sin esa segunda huella te enteras cuando un cliente pregunta por qué nadie le contestó.