Cómo conseguir reseñas en Google sin comprarlas: un sistema para pymes
Un proceso para pedir reseñas reales en Google: enlace directo, mensajes neutrales, respuestas y automatización sin incentivos.
Si te preguntas «por qué mis correos llegan a spam», revisa la autenticación, la reputación del dominio y de la IP de envío, y si los destinatarios esperan tus mensajes. SPF comprueba si el servidor está autorizado para el dominio técnico del envío; DKIM verifica la firma de las partes firmadas del mensaje; DMARC exige que SPF o DKIM pasen con un dominio alineado con el remitente visible. Pasar estas comprobaciones no garantiza la bandeja de entrada, y fallarlas no determina por sí solo que el mensaje acabe en spam.
Soy Claudiu Smeu, fundador de CreceWeb360. Administramos servidores Linux propios y de clientes, migramos buzones y configuramos el correo corporativo con SPF, DKIM y DMARC; este es el orden en el que revisamos un dominio cuando alguien nos dice «mis correos llegan a spam».
Mis correos llegan a spam: qué revisar antes del DNS
«Llegan a spam» agrupa situaciones distintas: mensajes rechazados con un aviso de error, mensajes aceptados pero clasificados como spam y mensajes de los que nadie sabe si llegaron. No los trates igual ni los atribuyas de entrada a la autenticación: a veces el fallo está en un solo sistema, o solo con un proveedor de destino.
Delimita remitente, destinatario y sistema de envío
Recoge un mensaje real que haya fallado, con su cabecera completa y, si existe, el aviso de rechazo que devolvió el servidor de destino. Anota desde qué sistema salió y hacia qué proveedor iba. En una asesoría, no es lo mismo un aviso automático que genera el programa de facturación que un correo escrito a mano desde el buzón: pueden salir por caminos distintos y autenticarse de forma distinta.
Inventaría todos los emisores legítimos
Haz una lista de todo lo que envía correo con tu dominio: los buzones del equipo, el formulario de la web, la facturación, el CRM, la herramienta de boletines y cualquier automatización de seguimiento. Para cada uno, apunta el proveedor, el dominio que usa como remitente y quién lo administra. Si tienes un flujo de seguimiento automático de contactos, también es un emisor y debe pasar las mismas comprobaciones. Incluye también los correos para pedir reseñas a tus clientes: si se envían con tu dominio, deben figurar en el inventario.
SPF, DKIM y DMARC: qué comprueba cada mecanismo
Los tres mecanismos responden a preguntas distintas. Confundirlos lleva a «arreglar» el que ya funcionaba y dejar roto el que fallaba.
| Mecanismo | Para qué sirve | Qué comprobar | Qué no significa |
|---|---|---|---|
| SPF | Autoriza qué servidores pueden enviar para el dominio técnico del envío (el del remitente de sobre, MAIL FROM o Return-Path) | Un único registro válido y todos los emisores legítimos incluidos | No autentica por sí solo el dominio visible en From |
| DKIM | Firma el mensaje con una clave del dominio; el receptor comprueba la firma con la clave pública publicada en el DNS | Dominio firmante, selector, clave publicada y resultado de la validación | No cifra el mensaje ni demuestra que sea deseado |
| DMARC | Comprueba que el dominio de From coincide (está alineado) con el que autenticó SPF o DKIM, y publica qué hacer si no | Resultado, alineación, política e informes configurados | No garantiza la bandeja de entrada |
La clave es la alineación con el remitente visible
SPF puede pasar con el dominio técnico de un proveedor sin estar alineado con el dominio visible en From. Eso no basta para que DMARC pase: necesita un resultado válido de SPF o DKIM cuyo dominio esté alineado con From. En modo estricto, los dominios deben ser idénticos; en modo relajado, pueden compartir el mismo dominio organizativo, como empresa.es y correo.empresa.es.
Conviene configurar ambos mecanismos: un reenvío puede hacer fallar SPF, mientras que DKIM puede seguir siendo válido si no se alteran las partes firmadas. Las instrucciones de DMARC de Google explican la alineación y las políticas disponibles.
Cómo comprobar la autenticación sin romper el correo
La comprobación termina en un mensaje real recibido y analizado, no en una captura del panel del DNS. Sigue el orden: leer, contrastar, cambiar, validar.
Lee el original de un mensaje recibido
Envía un correo de prueba desde el sistema que falla a un buzón de Gmail. Si se recibe, aunque sea en spam, abre Mostrar original y revisa los resultados de SPF, DKIM y DMARC. Si se rechaza, conserva el aviso de error: no tendrás un mensaje recibido que abrir en ese buzón.
Un ejemplo ilustrativo es spf=pass, dkim=pass, dmarc=fail. Puede ocurrir cuando SPF y DKIM autentican dominios que no están alineados con From; comprueba los dominios y los modos de alineación antes de concluir la causa. Si compartes cabeceras, oculta datos personales y valores sensibles. Mantén o representa de forma coherente las relaciones entre dominios para poder revisar la alineación.
Contrasta las cabeceras con los registros DNS
Con la cabecera delante, consulta el SPF del dominio de MAIL FROM y la clave DKIM correspondiente al selector y al dominio de la firma. Para DMARC, revisa la política aplicable al dominio de From: un subdominio puede heredar la del dominio organizativo si no publica una propia.
No copies un TXT «universal» de internet: las autorizaciones dependen de tus proveedores reales. La guía de Google para configurar SPF explica ese registro. Para DKIM, utiliza el selector y los valores que indique el proveedor que firma los mensajes; la guía para configurar DKIM describe el proceso.
Guarda, cambia y valida cada origen
Antes de modificar nada, guarda los registros actuales tal cual están. Cambia solo lo que corresponda al emisor que falla, espera a que el DNS se propague y vuelve a enviar mensajes de prueba desde cada sistema: buzón, formulario, facturación, automatizaciones. Vuelve a leer las cabeceras. Un cambio que arregla el buzón puede dejar fuera al formulario si se olvidó en el inventario. Las herramientas de automatización de procesos que envían correo deben superar la misma prueba aunque los mensajes escritos a mano ya funcionen.
Regla para reducir riesgos: realiza un solo cambio cada vez, guarda la configuración anterior y prueba los envíos desde cada emisor. Así será más fácil relacionar un fallo con el cambio realizado, aunque las cachés DNS y otros factores pueden complicar el diagnóstico.
Qué exigen Google y Yahoo a los remitentes
Los grandes proveedores publican requisitos para aceptar correo. Cumplirlos no garantiza la bandeja de entrada; incumplirlos puede provocar rechazos o que los mensajes se clasifiquen como spam.
Gmail: requisitos generales y reforzados
Las directrices para remitentes de Google son la referencia para los envíos a cuentas personales de Gmail, independientemente de que el remitente use Google Workspace. Distinguen requisitos generales y reforzados para remitentes masivos.
Comprueba allí los requisitos de autenticación con SPF y DKIM, DNS directo e inverso, TLS, DMARC y alineación que correspondan a tus envíos. Revisa también el umbral de remitente masivo, los límites de quejas y qué mensajes deben incluir baja en un clic: no todos los requisitos tienen el mismo alcance.
Yahoo: revisa su propio alcance
Si envías a cuentas de Yahoo, consulta sus requisitos vigentes antes de preparar envíos en volumen. Comprueba qué condiciones de autenticación, DNS y bajas afectan a tu tipo de envío. No des por hecho que el alcance o los criterios para remitentes masivos sean idénticos a los de Gmail.
Bajas y mensajes que el destinatario espera
Distingue el correo transaccional, como una factura o la confirmación de una cita, del promocional, como un boletín o una oferta. Ofrece una baja visible en los mensajes promocionales y comprueba si las directrices del receptor también exigen el mecanismo técnico de baja en un clic para tus envíos. Gestiona rebotes, bajas y quejas: insistir con destinatarios que no quieren recibir tus mensajes puede perjudicar la reputación y afectar a otros correos del mismo dominio.
Errores habituales en el correo de empresa
Estos fallos aparecen una y otra vez en dominios de pymes. Compruébalos antes de buscar causas exóticas.
SPF duplicado, firmas ausentes y rechazo precipitado
Publicar dos registros SPF en el mismo nombre DNS provoca un error permanente de SPF (permerror); no equivale a no publicar ninguno. DKIM puede firmar un mensaje aunque falte la clave pública en el DNS, pero el receptor no podrá validar esa firma. Una política DMARC de rechazo aplicada antes de alinear los emisores puede provocar el rechazo de mensajes legítimos.
Si estás implantando DMARC, empieza por observar los resultados con p=none y una dirección de informes agregados configurada en rua. Esa política no solicita cuarentena ni rechazo por fallo de DMARC. Los informes de los receptores que los envían ayudan a identificar orígenes y resultados, pero no constituyen un inventario completo. No rebajes una política existente sin evaluar antes el motivo y el riesgo.
Formularios que usan como remitente la dirección del visitante
Si el formulario usa la dirección del visitante en From, tu sistema puede estar enviando mensajes que dicen proceder de gmail.com o de otra empresa sin poder autenticar ese dominio de forma alineada. Esto puede provocar fallos de DMARC, clasificación como spam o rechazo.
Usa una dirección de tu dominio en From, con SPF o DKIM válidos y alineados, y la dirección del visitante en Reply-To. Revisa tanto la configuración del formulario de tu web corporativa como la del servicio de envío. El aviso «enviado correctamente» en pantalla no demuestra que el mensaje haya llegado.
Reenvíos y modificaciones del mensaje
Un reenvío automático (por ejemplo, del buzón del dominio a una cuenta personal) puede hacer fallar SPF, porque el servidor que reenvía no está autorizado para el dominio original. Y cualquier sistema que modifique el contenido firmado (pies de página añadidos, reescritura de enlaces) puede invalidar DKIM. Antes de volver a tocar registros, comprueba si el mensaje que falló pasó por uno de estos recorridos.
Qué hacer si crees que tu dominio está «quemado»
Que varios mensajes acaben en spam no basta para concluir que el dominio esté bloqueado. Separa qué está afectado (el dominio, la IP que envía, el proveedor compartido) y por qué (deterioro por malas prácticas, suplantación de tu dominio por terceros o una cuenta comprometida que envía spam sin que lo sepas).
Contén accesos indebidos y envíos no deseados
Si hay indicios de envíos no autorizados desde una cuenta o un servidor, pausa ese origen y revisa el incidente con quien lleva la administración del correo y del servidor. Conserva los registros y las colas para analizarlos; revisa accesos y credenciales y retira solo los mensajes que confirmes como no autorizados. No intentes tapar el problema con listas compradas, envíos de «calentamiento» artificiales ni un dominio nuevo: las causas siguen ahí.
Comprueba bloqueos reales antes de solicitar una revisión
Un aviso de rechazo del receptor es una prueba; aparecer en una lista pública de bloqueo es una pista. Ninguna herramienta externa reproduce los filtros privados de Gmail o de Microsoft. Cuando hayas corregido la causa, consulta si el receptor ofrece un procedimiento oficial de revisión. Si el bloqueo afecta a una IP compartida de tu proveedor de alojamiento, contacta con él para que revise la infraestructura y gestione las actuaciones que le correspondan.
Valida de nuevo los envíos legítimos
Repite las pruebas desde cada emisor, revisa los avisos de rechazo y las señales que ofrezca cada proveedor sobre tu dominio. Nadie puede prometerte un plazo de recuperación ni que una configuración correcta devuelva de golpe todos los mensajes a la bandeja de entrada. Mantén la autenticación correcta, envía solo mensajes que los destinatarios esperan y respeta las bajas; no fuerces una frecuencia de envío para intentar recuperar reputación.
Qué hacer esta semana si tus correos llegan a spam
- Identifica qué sistemas envían con tu dominio: buzones, formulario, facturación, CRM, boletines, automatizaciones.
- Guarda muestras anonimizadas de los mensajes afectados, con su cabecera completa y el aviso de rechazo si lo hay.
- Contrasta cabeceras y DNS antes de modificar ningún registro: SPF, DKIM y DMARC, y sobre todo la alineación con From.
- Corrige y valida cada emisor, un cambio a la vez, con una prueba real después de cada uno.
- Documenta responsables y configuración anterior, y revisa las directrices vigentes de Google y Yahoo para tu tipo de envío.
Si prefieres que lo revisemos contigo, pide una auditoría gratuita: analizamos las cabeceras, los registros de tu dominio y cada sistema que envía en tu nombre, y te decimos qué corregir primero.
