Correos de WordPress van a spam: SPF/DKIM/DMARC explicados y configurados

Qué ocurre realmente cuando el correo de WordPress cae en spam

Los proveedores de buzones no “odian WordPress”. Odian a los remitentes no verificables, la identidad inconsistente y los patrones de envío parecidos al spam. WordPress suele ser el mensajero, no el culpable.

Cuando haces clic en “Enviar”, intervienen al menos cuatro identidades:

• Remitente del sobre / Return-Path: donde van los rebotes. Generalmente lo controla el servidor SMTP o el proveedor.
• Header From: lo que ven los usuarios. A menudo lo establece WordPress, un plugin de formularios o una opción “From email”.
• DKIM d= dominio: el dominio que firma criptográficamente el mensaje (si se usa DKIM).
• IP de envío: el servidor que realmente entregó la transacción SMTP.

SPF evalúa la IP de envío frente al dominio del sobre. DKIM valida la firma contra una clave pública en DNS. DMARC verifica si SPF o DKIM pasan y se alinean con el dominio del Header From.

Si no controlas estas identidades deliberadamente, tu correo parecerá una falsificación aunque sea legítimo. Y los sistemas de correo están programados para desconfiar por defecto.

Consejo contundente: deja de intentar que PHP mail() se comporte. Usa SMTP autenticado o un proveedor de correo transaccional. Luego haz que tus registros DNS reflejen la realidad. Ese es todo el juego.

Guía de diagnóstico rápido (comprueba primero/segundo/tercero)

Primero: confirma qué identidad se está usando

1. Consigue un correo real que cayó en spam (o el “mostrar original” del destinatario).
2. Anota: Header From, Return-Path, DKIM d=, IP de envío, y si SPF/DKIM/DMARC pasaron.

Cuello de botella que buscas: desalineación (DMARC falla aun cuando SPF pasa) o “sin autenticación en absoluto”.

Segundo: valida que los registros DNS estén presentes, sean únicos y correctos

1. Verifica que tengas exactamente un registro SPF TXT para el dominio.
2. Comprueba que exista el TXT de DKIM para el/los selector(es) que se usan realmente.
3. Verifica que el registro DMARC exista y sea sintácticamente válido.

Cuello de botella que buscas: “permerror” por múltiples registros SPF, clave DKIM faltante, error tipográfico en DMARC o subdominio equivocado.

Tercero: confirma que WordPress está enviando por la ruta prevista

1. Si esperas SMTP: verifica que el plugin de WordPress esté configurado y que el servidor pueda alcanzar el host SMTP en el puerto correcto.
2. Si esperas MTA local: verifica que Postfix/Exim reenvíe a través de un smarthost de reputación, y no que envíe directamente desde una IP de VPS aleatoria.

Cuello de botella que buscas: arreglaste DNS para el “Proveedor A”, pero WordPress sigue enviando vía “Servidor B”. Esto es lo más común que te sabotea a ti mismo.

Hechos interesantes y un poco de historia (porque el correo es más viejo que tu CTO)

• El correo precede a la web. Los primeros sistemas de correo en red existieron a principios de los 70; la autenticación llegó décadas después, como una idea posterior.
• SPF nació como un parche pragmático. Se creó para permitir a los dueños de dominio publicar qué IPs pueden enviar, porque SMTP en sí no lo hacía.
• DKIM surgió de dos sistemas competidores. DomainKeys e Identified Internet Mail se fusionaron en DKIM—un “compromiso operativo” con criptografía.
• DMARC es básicamente pegamento de políticas. Une SPF y DKIM más reglas de alineación, y añade reportes para que veas quién te suplanta.
• La alineación existe porque los atacantes pueden pasar SPF con otro dominio. Sin alineación, un mensaje puede “autenticarse” pero mentir en el Header From visible.
• Las listas de correo son el enemigo natural de DKIM. Modificar el cuerpo del mensaje rompe las firmas DKIM; la industria creó ARC para reducir daños colaterales.
• “p=reject” no fue común hasta que los grandes proveedores lo impulsaron. DMARC existió años antes de que muchas organizaciones se atrevieran a aplicarlo.
• SPF tiene un límite de 10 búsquedas DNS. Ese límite explica por qué “añadir otro include” eventualmente explota en producción.
• Algunos proveedores tratan el correo no autenticado como sospechoso por defecto hoy en día. El listón se elevó; lo que funcionó en 2016 es una responsabilidad en 2025.

SPF, DKIM, DMARC: qué son y qué no son

SPF: “Esta IP puede enviar para este dominio”

SPF es un registro TXT en DNS que lista qué IPs (o qué registros SPF de otros dominios) están autorizadas a enviar correo alegando ser de un dominio—específicamente, del dominio del remitente del sobre (Return-Path). El receptor comprueba la IP que se conecta frente a esa política.

SPF no es: cifrado, una garantía de entrega en bandeja de entrada o una garantía de que el encabezado “From:” visible sea veraz. SPF puede pasar mientras el Header From sea totalmente distinto.

Para qué sirve SPF: prevenir suplantaciones casuales y ayudar a los receptores a puntuar tu correo como legítimo cuando se combina con DKIM/DMARC.

DKIM: “Este mensaje fue firmado por un dominio con esta clave”

DKIM añade un encabezado de firma que cubre encabezados seleccionados y (usualmente) el cuerpo. El receptor obtiene una clave pública desde DNS (selector + dominio) y verifica la firma.

DKIM no es: una promesa de que el contenido es bueno, o que el Header From amigable esté alineado con el firmante. DKIM solo dice “un dominio con control de esta clave publicada en DNS firmó este contenido”.

Modos de fallo DKIM: cuerpo modificado en tránsito, selector equivocado, clave errónea en DNS, o que tu sistema de envío no firmó en absoluto.

DMARC: “Aceptar o rechazar según autenticación y alineación; envíame reportes”

DMARC vive en _dmarc.tudominio como un registro TXT. Le indica a los receptores:

• Qué hacer si el correo falla DMARC (none/quarantine/reject).
• Dónde enviar reportes agregados y forenses.
• Qué nivel de alineación exigir (relajada vs estricta).

DMARC pasa si o bien SPF pasa con alineación o DKIM pasa con alineación.

DMARC no es: un filtro anti-spam. Es un mecanismo de aplicación de identidad. Los filtros antispam siguen juzgando tu contenido y reputación.

Una verdad seca: la autenticación de correo es como un cinturón de seguridad. No evita accidentes, pero notarás cuando falta.

Cita: “La esperanza no es una estrategia.” — Gene Kranz

Broma #1: SPF es básicamente tu dominio diciendo, “Sí, esa IP está conmigo.” Es como seguridad de lista VIP, pero con más DNS y menos cuerdas de terciopelo.

Alineación: la parte que todos omiten y luego padecen

Si recuerdas una sola cosa: DMARC no se fija en que SPF o DKIM pasaron. Se fija en que pasen para el mismo dominio que los usuarios ven en From.

Alineación relajada vs estricta

• Relajada (adkim=r, aspf=r): los subdominios pueden alinearse. Ejemplo: From es example.com, el firmante DKIM mail.example.com puede alinear (dominio organizacional coincide).
• Estricta (adkim=s, aspf=s): se requiere coincidencia exacta. From es example.com, el firmante DKIM debe ser exactamente example.com.

Error común de alineación en el mundo WordPress

Envías correo “From: you@yourdomain.com” pero tu proveedor SMTP usa un dominio de rebote como bounces.provider-mail.net. SPF pasa para ese dominio del proveedor, pero no se alinea con yourdomain.com. DKIM también puede firmar como el dominio del proveedor si no configuraste DKIM personalizado.

Resultado: SPF=pass, DKIM=pass, DMARC=fail. El más confuso “todo pasó pero falló” que verás.

Qué hacer: configura al proveedor para firmar con tu dominio (DKIM personalizado) y/o usa un return-path personalizado (dominio de rebote personalizado) que se alinee con tu dominio From.

Tareas prácticas: comandos, salidas y decisiones (12+ comprobaciones reales)

Estas son las comprobaciones que realmente ejecuto cuando el correo falla. Cada una incluye: el comando, qué significa la salida y qué decisión tomar a continuación.

Tarea 1: Encuentra tu IP pública de envío (si envías directamente desde un servidor)

cr0x@server:~$ curl -s ifconfig.me
203.0.113.42

Significado: si tu MTA envía directamente, esta es probablemente la IP que ven los receptores.

Decisión: si esta IP pertenece a un rango genérico de VPS sin reputación, no envíes directo. Usa un smarthost/proveedor transaccional.

Tarea 2: Comprueba el reverse DNS (PTR) de la IP de envío

cr0x@server:~$ dig +short -x 203.0.113.42
wp01.mail.example.com.

Significado: a los receptores les gusta ver un PTR que mapee la IP a un nombre de host intencional.

Decisión: si no obtienes nada o un PTR por defecto del proveedor, corrige el PTR con tu ISP/cloud o deja de enviar directo.

Tarea 3: Verifica DNS directo-confirmado reverse DNS (FCrDNS)

cr0x@server:~$ dig +short wp01.mail.example.com A
203.0.113.42

Significado: el PTR apunta al hostname; el hostname resuelve de vuelta a la misma IP.

Decisión: si no coincide, arregla el DNS (registro A) o PTR. Algunos receptores penalizan los desajustes.

Tarea 4: Inspecciona el registro SPF (y detecta el desastre de “dos registros SPF”)

cr0x@server:~$ dig +short TXT example.com
"v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"

Significado: tienes una sola cadena SPF. Bien.

Decisión: si ves múltiples cadenas v=spf1 separadas, debes fusionarlas en un solo registro SPF.

Tarea 5: Valida sintaxis SPF y riesgo del límite de 10 búsquedas

cr0x@server:~$ python3 - <<'PY'
import dns.resolver, re
domain="example.com"
txt=[]
for r in dns.resolver.resolve(domain,"TXT"):
    s=b"".join(r.strings).decode()
    if s.startswith("v=spf1"):
        txt.append(s)
print("SPF records:", len(txt))
print(txt[0] if txt else "none")
print("includes:", len(re.findall(r'\\binclude:', txt[0])) if txt else 0)
PY
SPF records: 1
v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all
includes: 2

Significado: conteo simplista, pero señala cadenas de include descontroladas.

Decisión: si estás cerca de 10 búsquedas DNS, aplana el SPF o elimina remitentes no usados antes de que SPF devenga en permerror.

Tarea 6: Comprueba que exista y sea legible el registro DMARC

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100"

Significado: DMARC está publicado con política quarantine, alineación relajada y reportes agregados.

Decisión: si falta, publícalo. Si la política es p=none, solo estás monitorizando (aceptable temporalmente, no para siempre).

Tarea 7: Comprueba el registro del selector DKIM de tu proveedor

cr0x@server:~$ dig +short TXT s1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Significado: existe la clave pública DKIM para el selector s1.

Decisión: si está vacío/NXDOMAIN, o publicaste el selector equivocado o el proveedor aún no firma con tu dominio.

Tarea 8: Confirma qué identidad cree tener Postfix (común en WordPress autohospedado)

cr0x@server:~$ postconf -n | egrep 'myhostname|mydomain|myorigin|relayhost|inet_interfaces'
myhostname = wp01.mail.example.com
mydomain = example.com
myorigin = $mydomain
relayhost = [smtp.mailprovider.net]:587
inet_interfaces = loopback-only

Significado: el servidor está configurado para retransmitir vía un smarthost, no enviar directamente; además solo escucha en loopback (buen endurecimiento).

Decisión: si relayhost está vacío y el servidor envía directo, espera problemas de entregabilidad a menos que gestiones la reputación rigurosamente.

Tarea 9: Verifica conectividad SMTP con tu relé (comprobación de red y firewall)

cr0x@server:~$ nc -vz smtp.mailprovider.net 587
Connection to smtp.mailprovider.net 587 port [tcp/submission] succeeded!

Significado: el servidor puede alcanzar el puerto de envío SMTP.

Decisión: si falla, corrige reglas de salida del firewall, security groups o restricciones del proveedor (algunas nubes bloquean 25/587 por defecto).

Tarea 10: Envía un correo de prueba desde el servidor con remitente del sobre explícito

cr0x@server:~$ printf "Subject: SMTP test\nFrom: wp@example.com\nTo: you@example.net\n\nhello\n" | sendmail -f bounce@example.com you@example.net

Significado: esto prueba la ruta del MTA local y establece el remitente del sobre a bounce@example.com.

Decisión: si vuelven rebotes o los logs muestran rechazo, examina los logs del MTA y la autenticación al relayhost.

Tarea 11: Lee los logs de correo para rechazos inmediatos (la verdad está en los logs)

cr0x@server:~$ sudo tail -n 50 /var/log/mail.log
Dec 27 10:42:11 wp01 postfix/smtp[21455]: to=, relay=smtp.mailprovider.net[198.51.100.10]:587, delay=1.2, delays=0.1/0.1/0.6/0.4, dsn=2.0.0, status=sent (250 2.0.0 queued as 9A1BC2D3)

Significado: Postfix entregó el correo al relé correctamente (2.0.0 sent).

Decisión: si ves rechazos 5xx, arregla autenticación, políticas del dominio From o estado de la cuenta del proveedor antes de tocar DNS.

Tarea 12: Comprueba que WordPress realmente usa SMTP (no cae a PHP mail)

cr0x@server:~$ grep -R "WP_MAIL_SMTP" -n /var/www/html/wp-config.php
37:define('WP_MAIL_SMTP_HOST', 'smtp.mailprovider.net');
38:define('WP_MAIL_SMTP_PORT', 587);
39:define('WP_MAIL_SMTP_AUTH', true);

Significado: la configuración existe (el método varía según el plugin). Esto sugiere que WordPress pretende usar SMTP.

Decisión: aún verifica con logs del plugin o correlacionando marcas de tiempo en mail.log. La deriva de configuración es real.

Tarea 13: Inspecciona los resultados de autenticación en un mensaje recibido (encabezados)

cr0x@server:~$ python3 - <<'PY'
import sys, re
raw = """Authentication-Results: mx.example.net;
 spf=pass smtp.mailfrom=bounce.example.com;
 dkim=pass header.d=example.com header.s=s1;
 dmarc=pass header.from=example.com
"""
print("SPF:", re.search(r"spf=\\w+", raw).group(0))
print("DKIM:", re.search(r"dkim=\\w+", raw).group(0))
print("DMARC:", re.search(r"dmarc=\\w+", raw).group(0))
PY
SPF: spf=pass
DKIM: dkim=pass
DMARC: dmarc=pass

Significado: esto es lo que “bien” parece: DMARC pasa con identidades alineadas.

Decisión: si DMARC falla, verifica la alineación: ¿es header.from diferente de smtp.mailfrom y header.d?

Tarea 14: Detecta múltiples registros SPF (específicamente)

cr0x@server:~$ dig +short TXT example.com | grep -c "v=spf1"
2

Significado: existen dos registros SPF. Eso es un permerror de SPF para muchos receptores.

Decisión: fúndelos en un único registro SPF inmediatamente. “Pero funcionó la semana pasada” no mitiga nada.

Tarea 15: Comprueba que tu dominio no haya omitido el include del proveedor

cr0x@server:~$ dig +short TXT example.com | tr ' ' '\n' | grep -E '^include:'
include:_spf.google.com
include:spf.protection.outlook.com

Significado: SPF incluye dos ecosistemas. Puede ser correcto, o legado.

Decisión: si ya no envías desde uno de ellos, elimínalo. Los includes no usados aumentan el radio de impacto y el conteo de búsquedas.

Registros DNS que realmente funcionan (ejemplos adaptables)

DNS es donde las buenas intenciones mueren. Manténlo aburrido y correcto.

SPF: un solo registro, remitentes mínimos necesarios, política explícita

Ejemplo: envías desde un proveedor transaccional más Microsoft 365. No envías directo desde tu servidor web.

cr0x@server:~$ cat spf-example.txt
example.com. 300 IN TXT "v=spf1 include:spf.protection.outlook.com include:send.mailprovider.net -all"

Qué significa: solo esos sistemas incluidos pueden enviar; todo lo demás falla de forma severa (-all).

Decisión: usa ~all solo durante transiciones. Dejar ~all para siempre es como dejar la puerta de la oficina sin cerrar porque las llaves son incómodas.

DKIM: publica las claves que usa tu remitente

Tu proveedor te dirá el selector y el valor TXT. Publícalo exactamente. No lo “formatees bonito”.

cr0x@server:~$ cat dkim-example.txt
s1._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Decisión: rota las claves periódicamente, pero no las cambies “por diversión” durante la semana de un lanzamiento de marketing.

DMARC: comienza con monitorización, luego aplica

DMARC es política. Trátalo así.

cr0x@server:~$ cat dmarc-monitoring.txt
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; fo=1"

Decisión: usa p=none el tiempo suficiente para aprender quién envía en tu nombre. Luego pasa a quarantine, y después a reject.

Ejemplo de aplicación de DMARC

cr0x@server:~$ cat dmarc-enforce.txt
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=r; pct=100"

Qué significa: alineación DKIM estricta, alineación SPF relajada. Patrón común cuando dependes mucho de firmas DKIM con tu dominio exacto.

Decisión: la alineación estricta no es un reto. Úsala solo cuando estés seguro de que todos los remitentes legítimos se alinean exactamente.

Estrategia de subdominios: separa correo transaccional del correo humano

Si tu plataforma de marketing, WooCommerce y los restablecimientos de contraseña comparten example.com, has combinado reputaciones. A veces está bien; otras veces es un incidente a cámara lenta.

Considera enviar correo transaccional desde mail.example.com o notify.example.com y mantener el correo humano en example.com. Aún necesitarás DMARC y alineación, pero habrás separado el radio de impacto.

Modelos de envío en WordPress: PHP mail vs SMTP vs API

Opción A: PHP mail() (por defecto). Barato. Frágil.

En muchos hosts, mail() delega a un MTA local o infraestructura compartida que no controlas. El Header From puede ser reescrito. DKIM puede faltar. SPF puede apuntar a otra cosa. Obtendrás el tipo de entregabilidad que mereces al delegar identidad al azar.

Úsalo solo si: tu host proporciona envío autenticado, firmado y alineado para tu dominio (algunos lo hacen; la mayoría no).

Opción B: SMTP autenticado mediante un plugin. La alternativa sensata por defecto.

WordPress envía al servidor SMTP que controlas o alquilas. Ese servidor firma con DKIM y gestiona rebotes. Tú estableces SPF/DMARC para el dominio. Todos están más contentos.

Decisiones clave:

• Usa el puerto 587 con STARTTLS (o 465 TLS implícito) según la guía del proveedor.
• Usa una cuenta dedicada al sitio, no el buzón personal de alguien.
• Asegúrate de que el proveedor pueda firmar DKIM como tu dominio (no como el suyo).

Opción C: API de correo (HTTP) a un proveedor transaccional. Muy fiable, menos “drama SMTP”.

Esto evita bloqueos de red SMTP y raros problemas de credenciales. El proveedor sigue enviando el correo, pero tu aplicación habla HTTPS.

Operativamente: excelente. En entregabilidad: aún requiere alineación SPF/DKIM/DMARC. Las APIs no eluden la física.

Broma #2: Enviar correo sin DKIM en 2025 es como desplegar sin copias de seguridad: técnicamente posible, espiritualmente preocupante.

Tres microhistorias corporativas desde las trincheras de entregabilidad

Microhistoria 1: El incidente causado por una suposición equivocada

Migraron su sitio WordPress desde un host gestionado a un reluciente clúster Kubernetes. La aplicación funcionó. El checkout funcionó. Los restablecimientos de contraseña funcionaron en staging. El lanzamiento en producción fue un jueves por la tarde, como dicta la tradición.

Entonces comenzaron los tickets de soporte: nadie recibía confirmaciones de pedidos. No “iban a spam”. Simplemente faltaban. El equipo de marketing reenvió campañas desde su plataforma y esas sí llegaron. Esa fue la primera pista: solo el correo transaccional originado por WordPress fallaba.

La suposición equivocada fue simple: “Nuestro dominio tiene SPF y DMARC ya, así que la autenticación de correo está hecha.” No lo estaba. Su SPF autorizaba Microsoft 365 y una herramienta de marketing. Su nueva ruta de envío era un pod de Postfix saliendo por una IP NAT que no estaba en SPF. No se configuró firma DKIM, porque el host antiguo firmaba en su nombre de forma silenciosa.

Los receptores hicieron lo que debían: SPF falló, DKIM faltó, DMARC falló, y la política del dominio era quarantine. Algunos proveedores pusieron los mensajes en spam; otros los rechazaron según la política local y señales de reputación.

La solución fue también simple, pero no rápida: dejaron de enviar directo y encaminaron todo el correo transaccional a través de un proveedor transaccional con DKIM de dominio, y luego actualizaron SPF para incluirlo. Solo después de que los informes DMARC mostraran alineación limpia movieron la política hacia reject. La lección: “Tenemos DMARC” no significa “este nuevo remitente está autorizado”. Significa “este nuevo remitente será castigado si no lo está”.

Microhistoria 2: La optimización que se volvió en su contra

Una empresa decidió “reducir las búsquedas DNS” aplanando agresivamente SPF y eliminando includes. En teoría, es un objetivo válido: el límite de 10 búsquedas de SPF es real, y los includes pueden convertirse en cadenas de dependencia fuera de tu control.

El problema vino del proceso, no del principio. Aplanaron SPF usando una instantánea de los rangos IP actuales del proveedor, y luego eliminaron el mecanismo include que seguiría cambios automáticamente. Fue más rápido. Fue liviano. También quedó congelado en el tiempo.

Semanas después, su proveedor añadió nueva infraestructura de envío y comenzó a entregar desde IPs no listadas en el SPF aplanado. Algunos receptores trataron el fallo de SPF como una señal negativa fuerte, y DMARC empezó a fallar para un subconjunto de mensajes porque la firma DKIM se deshabilitó intermitentemente durante una actualización del proveedor. El resultado general parecía “problemas de entregabilidad aleatorios”, lo peor porque lanza equipos a búsquedas supersticiosas.

Terminaron reintroduciendo includes para proveedores que cambian con frecuencia y aplanando solo las partes que realmente controlaban. También añadieron una comprobación semanal que muestrea los informes agregados DMARC buscando fuentes inesperadas. La lección: optimizar controles de entregabilidad sin un mecanismo de actualización convierte tu “endurecimiento” en una bomba de tiempo.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Otra organización tenía un hábito profundamente poco sexy: cada vez que una nueva herramienta SaaS quería enviar correo “desde nuestro dominio”, pasaba por una revisión corta. Comprobaban el dominio From, si el proveedor soportaba DKIM personalizado, cuál sería el dominio return-path y si la alineación DMARC pasaría.

Un equipo de producto desplegó un plugin de formularios WordPress integrado con una herramienta de helpdesk. El comportamiento por defecto del proveedor era enviar como noreply@vendor.example con reply-to de la dirección del cliente—aceptable. Pero el equipo quería que se viera con marca: support@theircompany.com. Ahí es donde DMARC rompe sueños.

Como la revisión existía, detectaron el problema antes de producción: el proveedor no podía alinear DKIM con el dominio de la compañía a menos que configuraran un dominio de envío personalizado y publicaran claves DKIM. Sin eso, DMARC fallaría bajo su política p=reject.

Hicieron lo aburrido: crearon un subdominio support-mail.theircompany.com, publicaron DKIM, añadieron un SPF mínimo y establecieron una política DMARC dedicada para ese subdominio. El día del lanzamiento, los correos llegaron. Nadie lo notó. Ese es el mejor resultado que ha tenido operaciones.

Errores comunes: síntoma → causa raíz → solución

1) “SPF pasa pero DMARC falla”

Síntoma: Authentication-Results muestra spf=pass y dmarc=fail.

Causa raíz: SPF pasó para el dominio del sobre, pero ese dominio no se alinea con el dominio visible del Header From.

Solución: usa un return-path/bounce domain personalizado alineado con tu dominio From, o confía en DKIM alineado con tu dominio From (DKIM personalizado).

2) “DKIM falla solo para algunos destinatarios”

Síntoma: Algunos proveedores muestran DKIM pass, otros fail; o los fallos comenzaron tras añadir una lista de correo/reenviador.

Causa raíz: un intermediario modifica el cuerpo del mensaje o los encabezados cubiertos por DKIM, rompiendo la firma.

Solución: firma con canonicalización relajada (configuración del proveedor), evita sistemas que reescriban cuerpos, o confía en SPF+alineación donde corresponda. Para listas de correo, ARC puede ayudar pero no es universal.

3) “SPF permerror”

Síntoma: Los encabezados muestran spf=permerror o los receptores tratan SPF como fallido a pesar de la IP correcta.

Causa raíz: múltiples registros SPF publicados, o SPF excede el límite de búsquedas DNS.

Solución: fusiona en un solo registro SPF; aplana o poda includes; elimina servicios legacy.

4) “Todo autentica pero Gmail aún envía a spam”

Síntoma: SPF/DKIM/DMARC pasan, sin embargo la colocación en bandeja es pobre.

Causa raíz: problemas de reputación/contenido: picos súbitos de volumen, baja interacción, plantillas sospechosas, mala higiene de listas o reputación de IP de envío.

Solución: segmenta transaccional vs marketing, calienta volúmenes, reduce la tasa de quejas y asegura patrones de envío consistentes. La autenticación es la entrada, no todo el concierto.

5) “La dirección From de WordPress es @yourdomain pero envía vía host compartido”

Síntoma: Los mensajes muestran yourdomain en From, pero Return-Path es el dominio del host; DMARC falla o queda en cuarentena.

Causa raíz: el host compartido reescribe el remitente del sobre; no tienes autenticación alineada para tu dominio.

Solución: usa SMTP/API con tu propio dominio de envío y DKIM; deja de depender del envío saliente compartido.

6) “Tras habilitar p=reject, parte del correo legítimo desaparece”

Síntoma: usuarios dejan de recibir ciertos correos automatizados (CRMs, ticketing, impresoras antiguas, SaaS aleatorios).

Causa raíz: esos remitentes no estaban alineados; la aplicación de DMARC hizo exactamente lo que pediste.

Solución: inventaría remitentes vía informes DMARC; luego migra esos remitentes a envío alineado (preferible) o cambia su From a un subdominio que controles con autenticación correcta.

7) “Las respuestas de formularios van al lugar equivocado o fallan”

Síntoma: configuraste From con el email del usuario para que “responder” vaya a ellos; ahora DMARC falla.

Causa raíz: estás suplantando el dominio del remitente en From; los receptores lo detectan.

Solución: mantén From con tu dominio; pon al remitente en Reply-To. Esto es innegociable para DMARC.

8) “Microsoft 365 funciona, pero los recibos de WooCommerce no”

Síntoma: el correo humano está bien; el correo transaccional de WordPress tiene problemas.

Causa raíz: autenticaron un ecosistema de envío pero no el otro. SPF incluye 365, pero WordPress envía desde la IP del servidor o desde otro proveedor.

Solución: enruta el correo de WordPress por el mismo sistema alineado (SMTP de 365 con autenticación adecuada, o un proveedor transaccional) y actualiza SPF/DKIM en consecuencia.

Listas de verificación / plan paso a paso

Paso a paso: saca el correo transaccional de WordPress del spam de forma fiable

1. Elige una ruta de envío que puedas controlar. Prefiere un proveedor transaccional o SMTP autenticado. Evita enviar directo a MX desde un servidor web aleatorio.
2. Define la estrategia de dominio From. Decide si envías desde example.com o un subdominio como mail.example.com.
3. Configura WordPress para usar SMTP/API. Verifícalo con logs (logs del servidor de correo, logs del proveedor o encabezados de mensajes).
4. Publica DKIM para ese remitente. Asegúrate que DKIM firme como tu dominio (no como el dominio del proveedor). Confirma el selector en DNS.
5. Publica exactamente un registro SPF. Incluye solo remitentes legítimos para ese dominio/subdominio. Mantén el conteo de búsquedas sensato.
6. Publica DMARC en modo monitorización primero (si eres nuevo). Usa p=none, recopila reportes e identifica remitentes desconocidos.
7. Arregla problemas de alineación detectados en los reportes. Mueve remitentes a DKIM alineado y/o return-path alineado.
8. Aplica DMARC deliberadamente. Pasa a p=quarantine y luego a p=reject. No pongas “reject” un viernes por la tarde.
9. Separa streams de marketing y transaccional. Usa subdominios distintos si es necesario; reputaciones distintas a propósito.
10. Vuelve a probar con destinatarios reales y encabezados reales. No confíes en mensajes “la prueba del plugin fue exitosa”. Suelen significar “SMTP aceptó”, no “llegó a la bandeja”.

Checklist operacional: evita regresiones

• Cuando añadas un nuevo SaaS que envía correo, añádelo al inventario de remitentes y valida la alineación antes del lanzamiento.
• Mensualmente: verifica que SPF no haya crecido hasta convertirse en una granada de 10 búsquedas.
• Trimestralmente: rota claves DKIM si tu proveedor lo soporta de forma limpia, y confirma que los selectores antiguos se retiran con seguridad.
• Tras migraciones: verifica que la ruta de envío no haya cambiado (nueva IP, nuevo relé, nuevo proveedor por defecto).
• Mantén el buzón de reportes DMARC monitorizado. Trátalo como telemetría, no como spam.

FAQ (las preguntas que te harás a las 2 a.m.)

1) ¿Necesito SPF, DKIM y DMARC, o basta uno?

Usa los tres. SPF solo es fácil de evitar y no protege el Header From visible. DKIM solo puede romperse por intermediarios. DMARC los une y te da reportes.

2) ¿Por qué los correos funcionaban antes y ahora van a spam?

Porque las políticas de los proveedores se endurecieron, cambió tu IP de envío, cambió tu patrón de volumen, o añadiste un remitente sin actualizar SPF/DKIM. La caída “repentina” de entregabilidad suele ser reacción tardía a la deriva.

3) ¿Cuál es la política DMARC más segura para empezar?

p=none con reportes agregados, luego arregla remitentes desconocidos. Una vez limpio, pasa a quarantine, luego a reject. Saltar a reject sin visibilidad es cómo descubres que un SaaS olvidado aún envía facturas.

4) ¿Qué significa “alineación” en lenguaje llano?

El dominio que ven los usuarios en el Header From debe coincidir (o estar relacionado organizacionalmente) con el dominio probado por SPF y/o DKIM. DMARC está diseñado para aplicar esa relación.

5) ¿Debe mi formulario de contacto de WordPress poner From como el correo del visitante?

No. Eso provoca fallo DMARC para visitantes cuyos dominios aplican DMARC (cada vez más común). Pon From con tu dominio y Reply-To con el visitante.

6) ¿Puedo enviar el correo de WordPress a través de Microsoft 365 SMTP y darlo por resuelto?

Sí, si lo haces correctamente: envío autenticado, From correcto y DKIM/DMARC configurados para ese dominio. Ten cuidado con límites de tasa y credenciales de aplicación; no uses la cuenta personal de alguien.

7) ¿Por qué veo “SPF neutral” o “softfail”?

Normalmente significa que tu SPF termina con ?all (neutral) o ~all (softfail). Puede estar bien durante la transición, pero es una aplicación más débil y puede reducir señales de confianza. Ajusta a -all cuando estés listo.

8) ¿Cómo sé si mi proveedor está firmando DKIM como mi dominio?

Mira un encabezado de mensaje recibido: busca DKIM-Signature y lee el valor d=. Debe ser tu dominio (o tu subdominio de envío elegido). Si es el dominio del proveedor, no estás alineado a menos que tu From coincida con ese dominio (y no debería).

9) ¿Cuál es la diferencia entre Header From y Return-Path, y por qué importa?

Header From es lo que ven los humanos. Return-Path es donde van los rebotes y lo que comprueba SPF. La desalineación entre ambos es el escenario clásico de fallo DMARC.

10) ¿Arreglar SPF/DKIM/DMARC garantizará la entrega en bandeja?

No. Evitará que falles en las comprobaciones básicas de identidad, lo cual es obligatorio. La colocación en bandeja depende también de reputación, contenido, engagement, tasas de queja y consistencia.

Conclusión: pasos prácticos siguientes

Si el correo de WordPress va a spam, no sigas retocando asuntos como si sobornaras a un filtro. Arregla la identidad del remitente.

1. Decide cómo vas a enviar: SMTP/API a través de un proveedor de confianza, no la ruleta rusa de PHP mail.
2. Haz que la autenticación se alinee: SPF autoriza al remitente real; DKIM firma como tu dominio; DMARC hace cumplir la alineación.
3. Valida con evidencia: encabezados, consultas DNS y logs de correo. No capturas de pantalla de plugins.
4. Aplica políticas con criterio: DMARC p=none → quarantine → reject, respaldado por reportes reales y un inventario de remitentes.

Haz esto una vez, hazlo bien, y tus correos de restablecimiento de contraseña dejarán de tomarse rutas turísticas por las carpetas de spam.