Evaluación inicial sin contraseñas Presupuesto antes de intervenir Especialista responsable de principio a fin

Localizar Fallo Mensaje

El formulario envía a Gmail, pero no al correo de la empresa

Descubre por qué un formulario llega a Gmail pero no al dominio empresarial revisando aceptación, gateway, alias y autenticación.

Que llegue a Gmail demuestra que una ruta funcionó, no que el dominio empresarial aceptara el mismo mensaje. El buzón corporativo puede usar otro gateway, cuarentena, reglas de transporte o una política de autenticación más estricta.

Mantén estable la configuración mientras comparas dos destinatarios con el mismo mensaje.

Realiza una comparación justa

Envía una prueba única y no sensible a Gmail y a la dirección empresarial usando los mismos campos, From y ventana temporal. Anota destinatarios y hora exacta.

Confirma que el formulario generó notificaciones para ambas direcciones. Una condición, dominio mal escrito o token inválido puede impedir crear la notificación empresarial.

Conserva la entrada de prueba hasta terminar el rastreo.

Lee las evidencias de WordPress y SMTP

Consulta un mail log con destinatario, asunto, hora y resultado sin exponer el contenido. El éxito de WordPress indica normalmente que entregó al transporte, no que llegó al buzón.

Después busca el destinatario corporativo en el proveedor: accepted, deferred, bounced, suppressed o no enviado. Un código de respuesta aporta más que cambiar de plugin. Conserva la respuesta redactada para el administrador de correo.

Compara también el Return-Path, el dominio firmante DKIM y el servidor que recibió cada intento. Si el proveedor abrió una transacción SMTP independiente para cada destino, el código asociado al buzón empresarial permite distinguir un rechazo de dominio, una limitación temporal y una dirección inexistente.

Comprueba el gateway empresarial

Pide al administrador autorizado que busque por destinatario, hora, remitente y message ID. Puede estar en cuarentena del gateway aunque no aparezca en Spam.

Si el dominio usa Microsoft 365, Google Workspace o un filtro anterior, identifica primero qué sistema posee los registros MX. Buscar únicamente en el buzón final deja fuera el tramo que pudo rechazar el mensaje antes de entregarlo.

Revisa allow/block globales, reglas de transporte, protección contra suplantación y políticas de adjuntos. Un buzón compartido, alias o grupo puede rechazar externos o exigir membresía.

No permitas globalmente la IP web ni desactives antispam. Aplica el cambio más estrecho demostrado.

Verifica autenticación y alineación

El dominio From visible debe estar autorizado por el proveedor. En el mensaje recibido por Gmail, comprueba SPF, DKIM y DMARC. El gateway corporativo puede imponer el fallo con mayor rigor.

Usa un buzón del dominio como From y al visitante en Reply-To. No envíes como Gmail, Outlook o dominio del cliente.

Si cambias DNS, conserva un único SPF y publica el selector DKIM exacto. Espera la propagación antes de evaluar.

Inspecciona rebotes y supresiones

Busca non-delivery reports en el Return-Path autenticado y en los logs. Rebotes históricos pueden incluir la dirección en una suppression list y descartar intentos posteriores.

Confirma que el buzón está bien escrito, activo y con cuota. Si es alias o grupo, prueba el buzón subyacente solo con aprobación.

No elimines una supresión antes de reparar su causa.

Separa routing y contenido

Si llega una notificación plana pero no la normal, compara enlaces, adjuntos, asunto y HTML. Los filtros pueden poner en cuarentena ejecutables, archivos protegidos o URLs sospechosas.

No evadas el filtrado ofuscando. Retira contenido innecesario de riesgo y utiliza transferencia segura aprobada para uploads.

Prueba después una consulta normal y el flujo de adjuntos.

Demuestra la entrega y monitoriza

La verificación completa muestra entrada, notificación generada, aceptación del proveedor y entrega empresarial. Guarda message ID y resultados de autenticación.

Repite tras cambios de DNS o gateway y confirma que Gmail sigue funcionando. Monitoriza eventos sin retener el contenido más tiempo del necesario.

Cuándo solicitar ayuda urgente

Pide ayuda si los logs del proveedor y gateway discrepan o existen leads en riesgo. Comparte horas y códigos redactados, nunca credenciales o consultas reales.

El cierre debe demostrar la entrega al buzón de negocio, no solo a un destinatario fácil.

ANTES DE ENVIAR LA SOLICITUD

Preguntas frecuentes.

¿Pedís contraseñas en el formulario?+

No. El formulario público nunca solicita accesos. Los datos seguros se piden únicamente después de aprobar el alcance y el presupuesto.

¿Quién revisa la incidencia?+

La solicitud llega a Jordi Ensenyat, fundador de Code Barcelona y especialista WordPress con más de 15 años de experiencia.

¿Se cambia algo antes del presupuesto?+

No. Primero se revisan los síntomas visibles y se define el alcance. La intervención empieza tras la aprobación y con una vía de vuelta preparada.

¿Trabajáis con webs en inglés y fuera de España?+

Sí. WP Repair atiende incidencias WordPress y WooCommerce en inglés y español, con servicio remoto.

Evaluar mi incidencia