En pymes, una caída por DNS suele tener un patrón repetido: “solo era validar un proveedor” o “solo era apuntar el dominio a otro sitio”… y de repente no entra correo, la web carga raro o directamente no carga. DNS es ese punto donde se cruzan web, email y herramientas externas, y por eso el impacto es desproporcionado.
No voy a entrar en teoría. La idea es que, en 60–90 minutos, dejes un procedimiento mínimo que puedas seguir cada vez que alguien tenga que tocar DNS: tú, tu agencia, tu informático o el proveedor de turno.
Paso 1 (15–20 min): inventario de “lo que no se puede romper”. Abre el panel de tu proveedor de dominio/DNS y apunta (en una hoja) los registros que suelen ser críticos: los de la web (normalmente el dominio principal y el “www”) y los del correo (los que suelen incluir SPF/DKIM/DMARC y el enrutado del email). No necesitas entender cada sigla: necesitas saber qué existe hoy y que, si desaparece, hay un problema.
Paso 2 (10 min): copia antes de tocar. Haz una captura o exporta la zona DNS si tu proveedor lo permite. Esto es el “plan de vuelta atrás”. El error típico es confiar en “lo cambio y si va mal lo deshago”, y luego nadie recuerda el valor anterior. Con una copia, el rollback es rápido.
Paso 3 (10–15 min): define una ventana de cambio y un responsable. Cambios de DNS no deberían hacerse “cuando alguien se acuerda”. Pon una regla simple: solo se cambia de lunes a jueves, en horario laboral, con un responsable mirando. Trade-off: pierdes algo de agilidad, pero ganas control. Para pymes, compensa.
Paso 4 (15–20 min): checklist de verificación tras el cambio. Justo después de modificar, comprueba tres cosas: 1) la web principal abre en móvil y en escritorio, 2) el formulario de contacto envía (prueba real), 3) el correo entra y sale (envía un email a un buzón externo tipo Gmail y responde). Si hay e-commerce o reservas, añade un pedido de prueba. Aquí es donde se detecta el 80% de incidencias en el momento, no al día siguiente.
Paso 5 (10–15 min): añade una alerta simple para web y correo. Para la web, una monitorización de “está arriba/está abajo” es suficiente. Para el correo, lo más práctico es un test diario automatizado: un email de prueba que llega a un buzón controlado y, si no llega, alerta. Si ya usas n8n/Make, esto se monta sin programar; si no, al menos deja el hábito manual semanal.
Errores comunes (y cómo detectarlos): 1) Borrar registros “que no suenan”. Se detecta porque tras el cambio empiezan rebotes de email o avisos de seguridad. Regla: no se borra nada sin saber para qué estaba. 2) Mezclar proveedores (DNS en un sitio, correo en otro, web en otro) sin documentarlo. Se detecta porque “nadie sabe dónde se cambia qué”. 3) No probar formularios. Se detecta cuando la web “parece bien” pero los leads dejan de entrar. Siempre prueba envío real.
Cómo medir resultado: el objetivo es muy concreto: reducir a cero las caídas “por DNS” y, si ocurre algo, detectarlo en minutos, no en horas. Mide: tiempo desde cambio a verificación completa (debería ser < 30 min) y número de incidencias por cambios (debería bajar con cada cambio documentado).
Cuándo compensa delegar: si vas a migrar correo, cambiar de proveedor de web o hacer cambios múltiples (por ejemplo, mover DNS a otro proveedor), delegaría la ejecución a alguien con experiencia, pero mantendría tú el checklist: copia, ventana de cambio, pruebas y alertas. Aunque lo haga un proveedor, el impacto es tuyo.
