WooCommerce falla de dos maneras que el cliente ve exactamente igual, y arreglar una no soluciona nada de la otra: o la tienda nunca llegó a enviar el email, o lo envió desde un servidor web que nadie autenticó. Esta guía separa los dos casos con el propio registro de correos transaccionales de WooCommerce, y sigue con la dirección From por defecto, que acaba poniendo tu Gmail personal en los recibos, con por qué el registro SPF de tu dominio no cubre tu servidor web y con lo que cambia de verdad un remitente SMTP. Después haces un pedido real a una dirección de prueba de Unspam y lees lo que vio la bandeja de entrada.
La documentación de WooCommerce sobre proveedores de email y SMTP describe lo que pasa a continuación: como WordPress no es un servidor de correo, delega la tarea en PHP, y PHP localiza entonces un servidor de correo local en tu servidor web para despachar el mensaje. Ahí se acaba la intervención de WooCommerce, y en todo ese recorrido no hay nada que firme el mensaje con tu dominio.
La dirección From de WooCommerce > Ajustes > Correos electrónicos (Settings > Emails) hereda por defecto el email del administrador del sitio configurado en Ajustes > Generales (Settings > General), que en la mayoría de las tiendas es una dirección personal del día de la instalación; el nombre From, por su parte, hereda el título del sitio. La documentación de WooCommerce no se anda con rodeos sobre la consecuencia: usar una dirección de un dominio público como @gmail.com o @yahoo.com hace muy probable que los emails acaben en spam o directamente bloqueados. Su guía de autenticación incluye quitar la dirección de Gmail de la cabecera From entre los requisitos para remitentes que entraron en vigor el 1 de febrero de 2024. Cámbiala por una dirección del dominio en el que corre tu tienda.
WooCommerce define Pendiente de pago (Pending payment) como un pedido recibido sin pago realizado, y sus FAQ de email dejan claro que no se dispara ningún correo mientras un pedido está en ese estado. Cuando una pasarela de pago no consigue devolver la llamada a tu sitio, los pedidos se amontonan en Pendiente de pago y los clientes no reciben nada, algo que desde fuera es indistinguible de un problema de spam. Comprueba el estado del pedido antes de tocar el DNS.
La mayoría de las tiendas publica algo parecido a v=spf1 include:_spf.google.com ~all para sus buzones de Google Workspace o de Microsoft 365. El servidor web no está en esa lista, así que un recibo con From: orders@yourstore.com enviado por PHP desde la IP del hosting falla SPF para tu dominio. Como tampoco hay firma DKIM, DMARC se queda sin ningún identificador alineado con el que pasar. Y añadir la IP del hosting a tu registro SPF no es la solución: si es una IP compartida, estarías autorizando a todos los demás sitios de esa máquina a enviar en tu nombre.
La guía de SMTP de WooCommerce dice que los entornos de hosting compartido y virtual no suelen ser los óptimos para enviar email, y su guía de autenticación pide a los dueños de tienda que confirmen con su hosting si el correo de la tienda va autenticado siquiera, en lugar de darlo por hecho.
La lista de notificaciones de WooCommerce > Ajustes > Correos electrónicos incluye ya Abandoned cart recovery (recuperación de carritos abandonados) y Review request (petición de valoración) junto a los emails de pedido, y las dos vienen desactivadas: Review request necesita que actives Customer review request (beta) en WooCommerce > Ajustes > Avanzado > Características (Advanced > Features), y los emails de carrito abandonado llegaron con WooCommerce 11.0 (4 de agosto de 2026) como función experimental que hay que habilitar antes. Activa cualquiera de las dos y los mensajes de marketing empiezan a salir por la misma ruta sin autenticar, y desde el mismo dominio, que tus restablecimientos de contraseña. Los proveedores de buzones puntúan el dominio, no el tipo de mensaje, así que las quejas que se ganan los recordatorios de carrito las paga el correo transaccional del que nadie se queja.
WooCommerce no firma nada. Pasa el mensaje ya montado a wp_mail(), PHP se lo pasa al transporte de correo que haya en el servidor web, y la autenticación acaba siendo una propiedad de la ruta, no de WooCommerce. Dos ajustes deciden todo lo que viene después: la dirección From en WooCommerce > Ajustes > Correos electrónicos, y si has puesto o no un remitente SMTP autenticado por delante de PHP.
| registro | por defecto | el problema | la solución |
|---|---|---|---|
| SPF | Tu dominio casi con toda seguridad tiene un registro SPF para tu proveedor de buzones, y ese registro no incluye el servidor en el que corre tu tienda. | El correo que envía PHP sale de una IP que tu SPF no autoriza, así que SPF falla para el dominio del From. Y si tu hosting reescribe el remitente del sobre a una dirección del dominio de la propia empresa de hosting, SPF puede pasar para ese dominio y seguir sin alinearse con tu cabecera From, que es un fallo de DMARC en cualquiera de los dos casos. | Envía a través de un proveedor SMTP autenticado y publica el include que te dé, por ejemplo v=spf1 include:_spf.google.com include:sendgrid.net ~all. Mantén exactamente un registro TXT de SPF en el dominio, porque dos se invalidan mutuamente, y no añadas nunca una IP de hosting compartido. |
| DKIM | Nada en la tienda lo firma. Ni WordPress ni WooCommerce guardan una clave de firma, así que cualquier firma tiene que venir del servidor de correo de tu hosting, y WooCommerce pide a los dueños de tienda que confirmen con el hosting si el correo de la tienda va autenticado siquiera, en lugar de darlo por hecho. | Sin firma DKIM y sin un SPF alineado, no hay nada en el mensaje que lo ate a tu dominio. La guía de autenticación de WooCommerce recuerda que todos los remitentes necesitan SPF o DKIM, y que quien envíe 5.000 mensajes al día o más a Gmail necesita los dos, confirmados por DMARC. | El DKIM lo pone el servicio de envío, así que elige un remitente SMTP, completa su verificación de dominio y publica los registros de selector que te emita (normalmente CNAME). Verificar una sola dirección de email en el proveedor no es lo mismo que verificar el dominio. Confirma en un envío real que el valor d= de DKIM es el dominio de tu tienda y no el del proveedor. |
| DMARC | La mayoría de las tiendas WooCommerce no publica ningún registro DMARC, y la tienda envía sin él. | Publicar p=quarantine o p=reject antes de tener una ruta autenticada convierte tus propias confirmaciones de pedido en spam, porque no llevan nada alineado con lo que pasar. Y dejar DMARC apagado del todo significa que nunca te enteras de cuáles de tus remitentes (la tienda, el buzón, la app de facturación, la herramienta de newsletter) están fallando. | Publica v=DMARC1; p=none; rua=mailto:dmarc@yourstore.com en _dmarc.yourstore.com, lee los informes hasta que el correo de la propia tienda aparezca con un pase alineado, y endurece la política entonces. WooCommerce pide a los dueños de tienda que confirmen SPF, DKIM y DMARC con su hosting o su proveedor de email en lugar de dar por hecho que están configurados. |
| SMTP sender | Sin configurar. WooCommerce llama a wp_mail(), que llama a PHP, que usa el transporte de correo que le toque ofrecer al servidor web. | Esta es la pieza que vive fuera del DNS y la que decide las otras tres filas. Sin un relay autenticado no hay clave con la que firmar ni IP que merezca la pena autorizar, así que no hay edición de DNS que produzca un pase alineado. | Instala un plugin SMTP que redirija wp_mail() a un proveedor. La propia lista de WooCommerce de proveedores con plugin en WordPress.org incluye MailPoet (5.000 emails al mes gratis, 500 destinatarios únicos), Mailjet (6.000 al mes gratis), Brevo (300 al día gratis) y WP Offload SES Lite sobre Amazon SES. WooCommerce también dice que se puede usar Gmail, pero avisa de que Gmail desactivará tu cuenta si envías a más de 500 destinatarios únicos en 24 horas, contando tanto tus propios envíos desde Gmail como todo lo que envíe tu sitio. |
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.
WooCommerce trae un control Send a test email en la pantalla de edición de emails, y para revisar la maquetación es genuinamente útil. No es una prueba de entregabilidad: la documentación para desarrolladores dice que la vista previa no usa los datos reales de la base de datos, sino que monta un pedido ficticio, productos ficticios y una dirección ficticia. Además se salta el cambio de estado del pedido que dispara el email en producción. Para averiguar algo de verdad, haz un pedido real dirigido a una dirección de prueba de Unspam.
Inicia una prueba antispam o una prueba de Inbox Placement en Unspam y copia la dirección de prueba que genera. Una prueba de Inbox Placement también genera un ID de prueba. Pégalo 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. En WooCommerce el sitio limpio para ponerlo es WooCommerce > Ajustes > Correos electrónicos: abre la notificación que estás probando y añade el ID de prueba al campo Asunto, o déjalo caer en Contenido adicional (Additional content). Quítalo cuando termines la prueba.
Pasa por caja en tu propia tienda, o crea el pedido desde el escritorio de WordPress, usando la dirección de prueba de Unspam como email de facturación del cliente. Usa un producto real, una moneda real y un método de envío real, porque la tabla del pedido, los totales y los enlaces forman parte de lo que se puntúa. No lo sustituyas aquí por Send a test email: eso renderiza un pedido ficticio y no te dice nada sobre el mensaje que recibe un cliente.
Pendiente de pago no dispara nada, y es a propósito. Pon el pedido en Procesando para lanzar la notificación de pedido procesándose (Processing order), o en Completado para la de pedido completado (Completed order). La notificación de administración Nuevo pedido (New order) salta en ese mismo cambio de estado y va a los destinatarios que figuren en su propia pantalla de ajustes, así que, si es ese el email que persigues, añade la dirección de prueba a su campo Destinatario(s).
Ve a WooCommerce > Estado > Registros (Status > Logs) y abre el origen transactional-emails, añadido en WooCommerce 10.9. Cada intento queda anotado como Sent, Failed, Disabled o Skipped. WooCommerce define Sent como haber entregado el email al sistema de correo de tu sitio correctamente, así que cualquier cosa que falte a partir de ahí es un problema de entregabilidad, no una prueba de que el cliente lo recibiera. Failed, Disabled o Skipped significan que nunca salió, y ningún cambio de DNS va a ayudar. Si no ves ninguna entrada, revisa WooCommerce > Estado > Registros > Ajustes: el registro respeta el umbral de nivel de tu tienda, que puede ocultar las entradas INFO y NOTICE.
Revisa la puntuación de spam y luego el bloque de autenticación: DKIM debería estar presente y firmar con el dominio de tu tienda, SPF debería pasar y alinearse, y DMARC debería mostrar un pase alineado. Después lee la llegada a la bandeja de entrada por proveedor, las previsualizaciones en clientes de correo incluido el modo oscuro, y el mapa de calor de seguimiento ocular. El asistente de correcciones con IA te señala qué cambiar antes de que salga el siguiente pedido real.
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.
La vista previa del email y su control Send a test email montan un pedido ficticio, con productos ficticios, variaciones ficticias y una dirección ficticia. La documentación para desarrolladores de WooCommerce lo dice sin rodeos: no usa los datos reales de la base de datos. Como el mensaje sí viaja por tu ruta de envío real, un fallo de autenticación que destape es real; pero una prueba que sale limpia no demuestra nada sobre el contenido, los totales ni los enlaces que recibiría un cliente.
El nombre From y la dirección From de WooCommerce > Ajustes > Correos electrónicos se aplican a los emails que envía WooCommerce. El correo del núcleo de WordPress y el de otros plugins recurren al remitente por defecto del propio WordPress, que es wordpress@ seguido del dominio de tu sitio. Así que tus recibos pueden salir como orders@yourstore.com mientras una notificación del núcleo o un mensaje de un formulario de contacto sale como wordpress@yourstore.com, y los proveedores de buzones construyen reputación para cada uno por separado.
WooCommerce puede sacar los emails transaccionales de la petición del checkout y meterlos en una cola. Se llama Deferred emails, vive en WooCommerce > Ajustes > Avanzado > Características y viene desactivada; WooCommerce la describe como enviar los emails transaccionales de forma asíncrona a través de Action Scheduler en lugar de durante la petición en curso, y desde código se puede forzar con el filtro woocommerce_defer_transactional_emails. WooCommerce documenta que Action Scheduler se apoya en WP-Cron, que a su vez depende del tráfico del sitio. En una tienda tranquila, el recibo espera a la siguiente visita. Revisa WooCommerce > Estado > Acciones programadas (Status > Scheduled Actions) por si hay acciones vencidas.
Redirigir wp_mail() a un proveedor saca tu correo del servidor web y lo pone sobre un relay autenticado, y normalmente resuelve el "no llega nada". Lo que no hace es firmar automáticamente por tu dominio. Hasta que completes la verificación de dominio del proveedor y publiques sus registros de selector, el mensaje va firmado con el dominio del proveedor, tu cabecera From sigue diciendo yourstore.com y DMARC falla exactamente igual que antes, solo que desde una IP mejor.
Los problemas de entregabilidad que más sufren los remitentes de WooCommerce, cada uno con la solución que lo resuelve.
La notificación de administración es el dominio de tu tienda escribiendo al dominio de tu propia tienda. WooCommerce la envía como orders@yourstore.com a un destinatario de yourstore.com, por PHP desde el servidor web, sin firma DKIM y desde una IP que tu registro SPF no autoriza. Un mensaje sin autenticar que dice venir de un remitente interno se trata mucho peor que ese mismo mensaje llegando a un dominio ajeno, y algunos proveedores lo retienen en la pasarela en lugar de archivarlo en la carpeta de spam, que es justo por lo que no lo encuentras en ninguna parte. El correo a clientes se cuela a duras penas; el de administración, no.
La solución Pon un remitente SMTP autenticado por delante de wp_mail(), completa la verificación de dominio del proveedor, publica los registros de selector DKIM y añade su include a tu único registro TXT de SPF. Como parche mientras lo montas, cambia el campo Destinatario(s) de WooCommerce > Ajustes > Correos electrónicos > Nuevo pedido a una dirección de otro dominio, para al menos ver los pedidos entrar. Después haz un pedido de prueba real a una dirección de prueba de Unspam, confirma que el valor d= de DKIM es el dominio de tu tienda y vuelve a poner el destinatario original.
Como PHP entrega el mensaje a un servidor de correo local y el registro de WooCommerce solo anota que entregó el email al sistema de correo correctamente, tu registro pone Sent y no hay ningún rebote en ninguna parte que puedas leer.
La solución Sal por completo de la ruta de PHP. Enruta wp_mail() a través de un proveedor SMTP autenticado, termina la verificación de dominio para que el mensaje lleve una firma DKIM del dominio de tu tienda, y añade el include SPF del proveedor. Lo segundo que te compra el proveedor es un registro de rebotes y supresiones, con lo que las caídas silenciosas dejan de ser invisibles. Lanza después una prueba de Inbox Placement y confirma que el mensaje llega de verdad a un buzón de prueba de Outlook, y no solo a uno de Gmail.
Restablecer contraseña (Reset password) es una de las notificaciones que aparecen en WooCommerce > Ajustes > Correos electrónicos, lo que significa que se puede desactivar como cualquier otra, y viaja por la misma ruta sin autenticar que todo lo demás. Es además la peor de todas para perder, porque es el único email que el cliente está esperando activamente y no hay ningún pedido en tu administración que te avise de que falló. Una notificación desactivada, un destinatario que falta y un mensaje filtrado se ven exactamente igual desde la tienda.
La solución Abre WooCommerce > Estado > Registros y filtra el origen transactional-emails. Disabled significa que la notificación está apagada en WooCommerce > Ajustes > Correos electrónicos > Restablecer contraseña; Skipped, que faltaba una condición previa, por ejemplo un destinatario; Failed, que el servicio de correo devolvió un error; y Sent, que WooCommerce lo entregó y se filtró más adelante. Si no se registra nada, mira desde dónde se pidió el restablecimiento: WooCommerce avisa de que los emails de restablecimiento de contraseña de WordPress y otros emails de administración de WordPress pueden no aparecer en ese registro, y te remite a los registros de tu proveedor SMTP. Arregla primero la ruta con un remitente SMTP que firme por tu dominio y vuelve a probar pidiendo un restablecimiento para una cuenta cuya dirección de email sea una dirección de prueba de Unspam.
El SMTP resolvió el problema de envío, no el de identidad. Ahora el proveedor retransmite tu correo desde una IP con buena reputación y bajo su propio Return-Path, así que SPF pasa contra el dominio del proveedor. Hasta que no termines la verificación de dominio, el mensaje va firmado con DKIM por el dominio del proveedor y no por el tuyo. Tu cabecera From sigue diciendo yourstore.com, no hay nada alineado con ella, y DMARC falla exactamente igual que antes, solo que desde mejor infraestructura.
La solución En el panel del proveedor, verifica el dominio y no una única dirección de remitente, y publica todos los registros DKIM que emita. Envía un email de pedido real a una dirección de prueba y lee el valor d= de DKIM: si sigue siendo el dominio del proveedor, la verificación está a medias. Mantén un único registro TXT de SPF con el include del proveedor añadido, por ejemplo v=spf1 include:_spf.google.com include:sendgrid.net ~all, en lugar de publicar un segundo registro SPF, que invalida los dos.
Esto es la cola de emails diferidos. WooCommerce puede sacar los emails transaccionales de la petición del checkout para que el cliente no espere al servidor de correo: es la función Deferred emails de WooCommerce > Ajustes > Avanzado > Características, desactivada de fábrica, y desde código también se puede forzar con el filtro woocommerce_defer_transactional_emails. La cola corre sobre Action Scheduler, y WooCommerce documenta que Action Scheduler se apoya en WP-Cron, que a su vez depende del tráfico del sitio. Una tienda con una noche tranquila no tiene ninguna visita que dispare la cola, así que el recibo espera a la siguiente.
La solución Abre WooCommerce > Estado > Acciones programadas y busca acciones vencidas; un montón de ellas con más de un día de antigüedad confirma el diagnóstico. La recomendación de WooCommerce es montar un cron propio en el servidor que ejecute WP-Cron por su cuenta y se salte la dependencia del tráfico, algo que de paso arregla los tiempos de todas las tareas programadas de la tienda, no solo del email. Y si el checkout ya iba lento antes de activar el diferido, la causa suele ser que el salto al correo ocurre dentro de la propia petición; pasar a un proveedor SMTP también elimina eso.
Abre WooCommerce > Estado > Registros y selecciona el origen transactional-emails, añadido en WooCommerce 10.9. Cada intento queda registrado como Sent, Failed, Disabled o Skipped. Sent significa que el mensaje salió de tu sitio, así que el problema es de entregabilidad. Failed, Disabled o Skipped significan que nunca salió, y ningún cambio de DNS lo va a arreglar. WooCommerce advierte además de que el registro solo confirma que wp_mail() reportó éxito, no que alguien recibiera el mensaje.
Para cualquier cosa que pase de tienda de aficionado, sí. La propia documentación de WooCommerce dice que los entornos de hosting compartido y virtual no suelen ser los óptimos para enviar email, y su guía de autenticación pide a los dueños de tienda que confirmen con su hosting si el correo de la tienda va autenticado con SPF, DKIM y DMARC. Un remitente SMTP autenticado es lo que te da una clave DKIM para tu dominio, una IP con reputación y un registro de rebotes que puedes leer. Varios de los proveedores que lista WooCommerce tienen planes gratuitos que le sobran a una tienda pequeña.
Empieza por el campo Destinatario(s) en WooCommerce > Ajustes > Correos electrónicos > Nuevo pedido, que hereda por defecto el email del administrador del sitio de Ajustes > Generales, y busca luego en WooCommerce > Estado > Registros una entrada de transactional-emails. Si el registro dice Sent y el destinatario está en el dominio de tu tienda, lo que tienes delante es tu dominio escribiéndose a sí mismo: un mensaje sin autenticar que dice venir de un remitente interno tiene la forma exacta de un intento de phishing, se filtra mucho más duro que ese mismo mensaje llegando a un dominio ajeno, y algunos proveedores lo paran en la pasarela, así que tampoco está en tu carpeta de spam. Arreglar DKIM y SPF en la ruta de envío arregla las dos direcciones.
En el estado del pedido, no en tu DNS. WooCommerce define Pendiente de pago como un pedido recibido sin pago realizado, y sus FAQ de email dicen que no se dispara ningún email mientras el pedido sigue ahí. Los pedidos se atascan en ese estado cuando la pasarela de pago no consigue comunicarse de vuelta con tu sitio. Busca pedidos en Pendiente de pago o Fallido, mira después WooCommerce > Estado > Registros, y solo entonces empieza a mirar la autenticación.
No. Unspam no se integra con WooCommerce, con WordPress ni con la API de ninguna plataforma, y nunca se conecta a tu tienda. Hay dos puntos de contacto: una dirección de prueba a la que envías tú, y unas credenciales SMTP que tú facilitas para los tests automáticos. En WooCommerce eso significa hacer un pedido real con la dirección de prueba como email de facturación, que es la única forma de probar el mensaje exacto que recibe un cliente.
Envía el correo transaccional desde el dominio de tu escaparate, porque es el dominio al que el cliente acaba de darle su tarjeta y el que sus filtros han aprendido a asociar con la compra. Si además haces campañas, mantén el marketing masivo en un subdominio aparte para que un mal envío no arrastre con él a los recibos. En cualquier caso, la dirección From tiene que estar en un dominio que controles: WooCommerce avisa de que una dirección @gmail.com o @yahoo.com en el campo From es muy probable que acabe en spam o bloqueada.
Los detalles de la plataforma WooCommerce se verificaron con la documentación disponible públicamente en agosto de 2026 y pueden haber cambiado desde entonces. WooCommerce es una marca comercial de su respectivo propietario. Unspam no está afiliada a WooCommerce ni cuenta con su respaldo.
