Qué hace este prompt
Le pegas los registros SPF y DMARC de un dominio y el LLM evalúa la configuración completa, detecta problemas comunes (SPF débil, DMARC demasiado permisivo, includes rotos, redirects circulares) y te dice exactamente qué cambiar y en qué orden.
El prompt
Prompt
Eres un experto en seguridad de email. Analiza la configuración SPF y DMARC del siguiente dominio y devuélveme un informe en español. ## Estado actual - **SPF**: transcribe el registro y explica cada mechanism en lenguaje humano (qué hace include:X, ip4:Y, ~all vs -all) - **DMARC**: transcribe el registro y explica cada tag (p, sp, pct, rua, ruf, adkim, aspf) ## Diagnóstico Para cada registro: - ¿Es sintácticamente válido? - ¿Está correctamente publicado (v=spf1 al inicio, v=DMARC1)? - ¿El qualifier final del SPF es adecuado? (-all fuerte, ~all suave, ?all/+all débil o roto) - ¿La política DMARC es adecuada? (p=reject fuerte, p=quarantine intermedio, p=none solo monitoreo) - ¿El alineamiento (adkim, aspf) está en modo relajado (r) o estricto (s)? - ¿Hay dirección para recibir reportes agregados (rua)? ## Problemas detectados Lista concreta priorizada: - CRÍTICO: fallos que dejan al dominio expuesto a suplantación - IMPORTANTE: mejoras significativas de seguridad - MENOR: buenas prácticas adicionales ## Plan de acción Cambios recomendados en orden. Advierte si algún cambio podría romper mail legítimo (por ejemplo, pasar de ~all a -all sin haber verificado antes que todos los emitters están en el SPF). ## Impacto Explica en 2-3 frases qué protección real gana el dominio con las mejoras. Si el estado actual ya es sólido, dilo. DATOS: <<< Registro SPF: [PEGA_AQUI_EL_SPF] Registro DMARC: [PEGA_AQUI_EL_DMARC] >>>
Variantes útiles
- Modo comité: añade "Traduce todo a lenguaje comprensible para dirección no técnica. Un párrafo. Estado: PROTEGIDO / PARCIAL / EXPUESTO, con dos ejemplos concretos del riesgo actual".
- Comparar dos dominios: pega ambos y pide "Compara qué dominio está mejor protegido y qué debe copiar el peor del mejor".
- Auditoría con DKIM: incluye también las claves DKIM encontradas y pide análisis completo de los tres (SPF+DKIM+DMARC).
Cuándo NO usarlo
- Para aplicar cambios en producción sin verificar. El LLM no conoce todos los emitters legítimos de tu dominio. Antes de subir de p=none a p=reject, monitoriza reportes RUA durante 4 semanas.
- Sin datos frescos. Los registros TXT se cachean por DNS. Si consultas después de un cambio reciente, puedes ver datos antiguos. Refresca la consulta con TTL bajo antes de analizar.