De fábrica, WordPress le entrega cada mensaje a la función mail() de PHP, que no firma nada, no autentica nada y da el envío por bueno tanto si el correo se entrega como si no. Por eso los restablecimientos de contraseña, los avisos de los formularios de contacto y los emails de pedido de WooCommerce acaban en spam o desaparecen sin dejar rastro. Esta guía cubre qué hace realmente wp_mail(), por qué la dirección From wordpress@ que viene por defecto rompe la alineación, qué hostings bloquean qué puertos SMTP y cómo probar un envío real con Unspam.
El núcleo de WordPress no configura DKIM en ningún momento. La librería PHPMailer que incluye sí sabe firmar, y expone DKIM_domain, DKIM_selector y DKIM_private, pero nada del núcleo llega a rellenar esos valores, así que el mensaje sale de tu servidor sin ninguna firma.
Cuando no se indica ninguna cabecera From, wp_mail() la construye a partir del host del sitio: lee el host de network_home_url(), le quita el www. inicial y le antepone wordpress@. El nombre visible que usa por defecto es WordPress. Los restablecimientos de contraseña, los avisos de usuario nuevo, la moderación de comentarios y los avisos de actualización del núcleo salen todos con esa dirección y, en la mayoría de los sitios, detrás no hay ningún buzón, así que las respuestas y los rebotes no llegan a ninguna parte. Pon una dirección real con el filtro wp_mail_from, o desde WP Mail SMTP > Settings en el campo From Email con Force From Email marcado.
Con PHP mail(), la dirección del sobre es la que produzca la configuración de tu hosting, normalmente el usuario del servidor web en el propio hostname del servidor. Los receptores evalúan el SPF contra ese dominio del sobre, así que, salvo que tu hosting fuerce una dirección de sobre en tu propio dominio (con el sendmail_from de PHP, con mail.force_extra_parameters o con una reescritura en su propio MTA), tu registro SPF no es el que se consulta y el SPF no puede alinearse con el dominio del From para DMARC.
Los hostings bloquean el SMTP saliente para contener el spam, y las reglas cambian según la plataforma. Kinsta dice que no puedes usar el puerto 25 porque su infraestructura bloquea el 25 saliente, y da como utilizables el 587, el 465 y el 2525; WP Engine dice que sus proveedores de infraestructura no permiten el correo por el puerto 25, permite el 587 y el 465, y recomienda el 2525. DigitalOcean bloquea por defecto el 25, el 465 y el 587 en los Droplets, incluido el tráfico que pasa por una Reserved IP; Google Cloud bloquea el puerto 25 hacia destinos fuera de tu VPC; y AWS limita el puerto 25 desde EC2 salvo que pidas que te retiren esa restricción. Ojo con un detalle: el propio recopilatorio de hostings de WP Mail SMTP lista a WP Engine y a Kinsta entre los que no bloquean SMTP, lo que contradice lo que ambos publican sobre el puerto 25, así que fíate de la documentación de tu hosting antes que de cualquier lista de terceros.
La configuración más habitual pone la dirección de quien envía el formulario en el campo From para poder responder de un clic. Eso significa que tu servidor manda correo diciendo que viene de gmail.com o de outlook.com, un dominio que jamás ha autorizado a tu servidor, y DMARC falla en el dominio del visitante en lugar de en el tuyo. La documentación de WPForms lo dice sin rodeos: el From Email tiene que ser válido, debería coincidir con tu dominio, y hay que evitar la dirección de quien rellena el formulario porque puede parecer un intento de phishing; esa dirección va en el Reply-To mediante una smart tag. WooCommerce dice lo mismo del correo de pedidos: una dirección From en un dominio público como @gmail.com o @yahoo.com tiene muchas papeletas de acabar en la carpeta de spam o bloqueada, precisamente por el desajuste entre el remitente declarado y el remitente real.
En un hosting compartido, PHP mail() sale por una IP que usan cientos de sitios vecinos, y basta con que una instalación de WordPress de esa máquina esté comprometida para que la IP entera acabe en una lista negra. No controlas la reputación de esa IP y, casi siempre, tampoco su DNS inverso, mientras que las directrices de Google exigen que las IP de envío tengan registros DNS directos e inversos válidos. Pasar por un proveedor te lleva a una infraestructura cuya reputación alguien cobra por defender. Hasta entonces, saca la IP de envío de las cabeceras Received de un mensaje que tu sitio haya enviado de verdad y pásala por el comprobador de listas negras bajo demanda de Unspam para ver si los vecinos ya te han salido caros.
WordPress no publica ningún registro DNS por ti y no firma nada, así que no hay ninguna identidad de envío que autenticar hasta que cambies cómo sale el correo del sitio. Primero la ruta, después los registros, en ese orden: los registros SPF y DKIM no sirven de nada mientras el mensaje siga saliendo por PHP mail() con la dirección de sobre de tu hosting.
| registro | por defecto | el problema | la solución |
|---|---|---|---|
| Sending route (SMTP plugin) | wp_mail() llama al isMail() de PHPMailer, así que cada mensaje pasa por la función mail() de PHP y por el MTA local de tu hosting. | Nada firma el mensaje y nadie es dueño de la dirección del sobre, así que no hay ninguna identidad a la que SPF, DKIM o DMARC puedan agarrarse. | La versión gratuita de WP Mail SMTP incluye SendLayer, SMTP.com, Brevo, Gmail, Elastic Email, Mailgun, Mailjet, SendGrid, Postmark, SparkPost, SMTP2GO y Other SMTP, mientras que Microsoft, Amazon SES y Zoho están marcados como Pro. |
| SPF | O no existe o da igual: con PHP mail(), el remitente del sobre lo elige tu hosting, así que tu propio registro SPF no es el que se comprueba. | Los receptores consultan el SPF del dominio del sobre, que es el hostname de tu servidor, así que tu registro no puede pasar ni alinearse con el dominio del From para DMARC. | Cuando un proveedor sea dueño del sobre, publica el include que documente en un único registro sobre el dominio de envío, por ejemplo v=spf1 include:_spf.google.com ~all para Google Workspace. Un solo registro SPF por dominio, sin excepciones. |
| DKIM | Ninguna firma, en absoluto. El núcleo incluye un PHPMailer capaz de firmar, pero nada en WordPress llega a rellenar sus propiedades de firma DKIM. | Google pide SPF o DKIM a todo el que envía, y a quienes envían en masa (5.000 mensajes al día o más a Gmail) les pide los dos más alineación. El correo sin autenticar puede marcarse como spam o rechazarse con un error 5.7.26. | Publica los registros CNAME o TXT de selector que emita el mailer que elijas y confirma después, en un envío real, que el valor d= de DKIM es tu propio dominio y no el dominio compartido del proveedor. |
| DMARC | Ninguno. Nada en WordPress publica una política ni te avisa de que falta. | Sin registro no recibes ningún informe del correo sin autenticar que sale de tu dominio. Y con p=reject publicado mientras el sitio sigue usando PHP mail(), rechazas tus propios restablecimientos de contraseña. | Publica v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com, comprueba en los informes que tu tráfico de WordPress ya aparece alineado bajo el proveedor que elegiste, y endurece después a quarantine y reject. |
Una vez actualizados estos registros, confirma que pasan con el comprobador de SPF, el comprobador de DKIM y el comprobador de DMARC gratuitos de Unspam.
La prueba integrada de WP Mail SMTP, en WP Mail SMTP > Tools > Email Test, solo te deja indicar una dirección en Send To y activar o no el HTML, y su mensaje de éxito dice que el email de prueba se envió, no dónde aterrizó. Demuestra que la conexión y las credenciales funcionan, y su Domain Check consulta el SPF, el DKIM y el DMARC del dominio From, pero no puede decirte a qué carpeta llega un aviso real. Haz un envío real en su lugar.
Inicia una prueba antispam o una prueba de Inbox Placement en Unspam y copia la dirección de prueba que genera. Las pruebas de Inbox Placement entregan en buzones de prueba de Gmail, Outlook, Yahoo y otros cinco proveedores, e informan de dónde acabó cada copia. Una prueba de Inbox Placement también genera un ID de prueba. Tienes que pegarlo en el asunto o en el cuerpo antes de enviar, o el mensaje llegará a los buzones de prueba y no se asociará nunca a tu prueba.
Cada ruta tiene su propio remitente. El correo del núcleo de WordPress usa wordpress@yourdomain.com salvo que wp_mail_from o Force From Email lo sobrescriban, WooCommerce usa la dirección From de WooCommerce > Settings > Emails, y un plugin de formularios usa el From Email de esa notificación. Probar el correo del núcleo no demuestra nada sobre el de WooCommerce si cada uno sale con una dirección distinta.
En un formulario de contacto, envíalo tú mismo con la dirección de prueba en el campo de email y el ID de prueba pegado en el campo de mensaje, para que el aviso lo lleve en el cuerpo. En WooCommerce, cada plantilla de email tiene su propio campo Subject en WooCommerce > Settings > Emails, así que añade ahí el ID de prueba mientras dure la prueba y quítalo al terminar. No lo pruebes con un restablecimiento de contraseña del núcleo: en ese mensaje no puedes meter el ID de prueba.
Envía desde el hosting de producción, no desde una instalación local ni desde una copia de staging. La IP de envío, la ruta SMTP e incluso la disponibilidad de los puertos cambian de un entorno a otro, y los plugins de staging que silencian el correo saliente dejarán todo el ejercicio en nada. Si tienes delante una capa de caché o un cortafuegos, envía el formulario como visitante sin sesión iniciada para que la petición siga el mismo camino que la de un cliente.
En Unspam, confirma que el dominio d= de DKIM es el tuyo, que el SPF pasó contra un Return-Path que reconoces y no contra el hostname de tu servidor web, y que el DMARC muestra alineación. Después mira la llegada a la bandeja de entrada por proveedor, la puntuación de spam con las reglas que ha disparado y las previsualizaciones en clientes de correo. Corrige lo que marque el informe y repite el mismo envío con un ID de prueba nuevo.
La misma prueba renderiza tu campaña en más de 50 clientes de correo reales, entre ellos Gmail, Outlook, Apple Mail, iPhone y Android, cada uno en modo claro y oscuro, mediante vistas previas en clientes de correo, para que confirmes la llegada a la bandeja de entrada y el renderizado de una sola vez.
El valor devuelto solo te dice que PHPMailer entregó el mensaje sin lanzar una excepción, lo que en la ruta de PHP mail() significa que el MTA local lo aceptó. La entrega, el filtrado y el descarte silencioso ocurren todos después de ese punto. WordPress dispara la acción wp_mail_failed con un WP_Error únicamente cuando PHPMailer lanza una excepción, así que un mensaje encolado en local y tirado a la basura sin más le parece un éxito a tu sitio.
Y duele por partida doble, porque un plugin de formularios que cuela la dirección del visitante pone en el mensaje una dirección From que no es tuya, que es justo lo que WPForms te dice que evites: usar la dirección de quien rellena el formulario hace que parezca que envías desde una dirección que no te pertenece, y puede acabar con la notificación marcada como phishing.
wp_mail() usa por defecto el tipo de contenido text/plain y deja el AltBody de PHPMailer explícitamente vacío. Cuando un plugin filtra wp_mail_content_type a text/html, PHPMailer pasa a HTML pero el cuerpo alternativo se queda vacío, así que el mensaje sale como una única parte text/html. Los filtros de contenido penalizan esa forma por sí sola: la regla MIME_HTML_ONLY de SpamAssassin salta con los mensajes que solo tienen partes MIME text/html. Usa un mailer o una plantilla que construya un multipart/alternative de verdad.
En WP Mail SMTP, Email Log, Email Reports, Email Alerts, Backup Connection, Smart Conditional Routing y Rate Limiting son todas funciones Pro. En el plan gratuito, un mailer que empiece a rechazar tus mensajes no deja ningún rastro en la administración del sitio, y la primera señal es un cliente preguntando por qué nunca le llegó su recibo. FluentSMTP incluye gratis los registros de email y las alertas de fallo a Slack, Telegram o Discord, y WooCommerce anota por su cuenta los intentos Sent, Failed, Disabled y Skipped en WooCommerce > Status > Logs.
Los problemas de entregabilidad que más sufren los remitentes de WordPress, cada uno con la solución que lo resuelve.
wp_mail() devuelve true en cuanto PHPMailer le entrega el mensaje a PHP mail() y el MTA local lo acepta. Si ese MTA no tiene salida, o si el lado receptor descarta el correo porque va sin firmar y su sobre pertenece a un servidor compartido, no hay nada en WordPress que registre la pérdida. La acción wp_mail_failed solo se dispara cuando PHPMailer lanza una excepción.
La solución Instala FluentSMTP o WP Mail SMTP, conecta un proveedor y busca ese envío concreto en el registro del plugin. Si el registro muestra una entrega y el buzón sigue vacío, el problema está en el receptor: haz un envío real a una dirección de prueba de Unspam y lee los resultados de autenticación.
Tu propio servidor de correo suele tener tu dominio o tu servidor en la lista de permitidos, así que probar en casa no te dice nada. Gmail aplica sus directrices para remitentes: SPF o DKIM como mínimo, DNS directo e inverso válidos en la IP de envío y TLS en el transporte. PHP mail() desde un hosting compartido suspende lo primero, suele suspender lo segundo y no te da visibilidad de ninguno de los dos.
La solución Enruta el correo de WooCommerce por un proveedor, pon en WooCommerce > Settings > Emails una dirección From de un buzón de tu propio dominio y confirma en un pedido real que DKIM firma con tu dominio. Nunca pruebes la entregabilidad enviando a un buzón que esté en la misma infraestructura desde la que envías.
La herramienta Email Test envía su propio mensaje con el From Email del plugin. Tu plugin de formularios fija su propia dirección From en los ajustes de la notificación, así que, salvo que Force From Email esté marcado, el aviso real sale con otro remitente, quizá uno que el proveedor no ha verificado y que tus registros DNS no cubren. El mismo sitio, dos identidades de envío distintas.
La solución Marca Force From Email en WP Mail SMTP > Settings, o pon en el From Email de la notificación del formulario esa misma dirección verificada, y mueve la dirección del visitante al Reply-To con una smart tag. Después envía el formulario de verdad con una dirección de prueba de Unspam y el ID de prueba en el campo de mensaje.
El formulario está poniendo la dirección del visitante en la cabecera From, así que tu servidor manda correo diciendo que viene de gmail.com. Los requisitos de Google para remitentes se endurecieron en febrero de 2024, y el correo sin autenticar ahora puede marcarse como spam o rechazarse directamente con un 5.7.26. En tu sitio no cambió nada; lo que subió fue el listón.
La solución Pon en el From una dirección de tu propio dominio y la de quien rellena el formulario en el Reply-To, que es lo que documentan tanto WPForms como WooCommerce. Después autentica ese dominio como es debido a través de un proveedor SMTP, para que el From que ahora usas pase de verdad la alineación de SPF o de DKIM.
La política de puertos salientes es de cada plataforma y no viaja con tus archivos. Kinsta bloquea el puerto 25 saliente y ofrece el 587, el 465 y el 2525. WP Engine no permite el puerto 25, permite el 587 y el 465, y recomienda el 2525. DigitalOcean bloquea por defecto el 25, el 465 y el 587 en los Droplets, incluido el tráfico que pasa por una Reserved IP, y AWS limita por defecto el puerto 25 desde EC2. Un puerto bloqueado se manifiesta como un tiempo de espera agotado en la conexión, no como un problema de entregabilidad.
La solución Pídele al hosting por escrito qué puertos salientes tienes abiertos en tu plan, configura en el plugin la pareja de puerto y cifrado que corresponda (TLS con el 587, o SSL con el 465) y, si está todo bloqueado, cambia a un mailer que llegue al proveedor por HTTPS en lugar de por SMTP.
Lo que molesta a los filtros no es el volumen. wp_mail() le pasa el mensaje a PHP mail(), que lo manda sin firmar, desde una dirección que no es de nadie y con un sobre que pertenece a tu servidor web en lugar de a tu dominio. Google pide a todos los remitentes, envíen lo que envíen, que configuren SPF o DKIM. Un único restablecimiento de contraseña sin autenticar suspende ese examen igual de claramente que una campaña.
Sí, en casi todos los casos. Con PHP mail(), tu registro SPF no es el que comprueban los receptores, porque el remitente del sobre es el de tu hosting, y nada en WordPress firma con tu clave DKIM. Los registros solo empiezan a funcionar cuando algo se hace dueño de la identidad de envío, que es justo lo que te dan un plugin SMTP más un proveedor. Publicar DMARC mientras sigues en PHP mail() solo sirve por los informes que genera.
Los dos sustituyen la ruta de wp_mail() por una conexión autenticada con un proveedor, y los dos se instalan gratis. FluentSMTP es completamente gratuito e incluye registros de email, alertas de fallo y enrutamiento entre varias conexiones según la dirección From. WP Mail SMTP tiene una lista de mailers gratuitos más larga, con SendLayer, Brevo, Gmail, Mailgun, SendGrid y Postmark, pero deja Email Log, Alerts, Backup Connection, Smart Conditional Routing y los mailers de Microsoft, Amazon SES y Zoho detrás de Pro. Elige según el mailer que necesites y según si quieres registros sin pagar.
Prueba primero el 587 con TLS, luego el 465 con SSL y después el 2525 si tu proveedor lo ofrece: Kinsta da como utilizables el 587, el 465 y el 2525, y WP Engine permite el 587 y el 465 mientras recomienda el 2525. Si están bloqueados todos los puertos SMTP, que es lo que hace DigitalOcean por defecto en los Droplets, usa un mailer que hable con la API del proveedor por HTTPS en vez de por SMTP. La solución que propone el propio WP Mail SMTP ante un fallo de conexión es corregir la pareja de puerto y cifrado o cambiar a un mailer basado en API.
No. Cámbiala por un buzón real y vigilado en tu dominio de envío, para que las respuestas y los avisos de rebote lleguen a una persona. Aplícala con los filtros wp_mail_from y wp_mail_from_name, o pon From Email y From Name en WP Mail SMTP con Force From Email marcado para que los plugins no la sobrescriban. Asegúrate de que sea una dirección que tu proveedor haya verificado, o el envío será rechazado.
No. Unspam no se conecta nunca a tu sitio, ni a tu hosting, ni a tu administración. Hay exactamente dos puntos de contacto: una dirección de prueba a la que envías y unas credenciales SMTP que aportas tú mismo si quieres que las pruebas automáticas se ejecuten de forma programada. Todo lo demás del informe sale del mensaje que tu sitio envió de verdad.
Los detalles de la plataforma WordPress se verificaron con la documentación disponible públicamente en agosto de 2026 y pueden haber cambiado desde entonces. WordPress es una marca comercial de su respectivo propietario. Unspam no está afiliada a WordPress ni cuenta con su respaldo.
