SPF, DMARC y DKIM: la guía completa de autenticación de correo electrónico

Su dominio pasa todos los análisis de seguridad. Su certificado SSL es válido, sus encabezados son ajustados, su CSP está bloqueado. Luego, un correo electrónico de phishing llega a la bandeja de entrada de un cliente, desde su dominio, con el nombre de su empresa en el campo "De". El correo electrónico es falso, pero el daño es real.

Esto sucede porque el correo electrónico se diseñó en 1982 sin verificación del remitente incorporada. cualquiera Puede configurar cualquier dirección "De" en un correo electrónico y sin registros SPF, DMARC y DKIM en su dominio, los servidores receptores no tienen forma de detectar la falsificación. Más del 90% de los ataques de phishing utilizan la suplantación de dominio y la autenticación de correo electrónico mal configurada son la puerta abierta.

Esta guía cubre lo que hace cada registro, cómo funcionan juntos y cómo auditar los tres. en cualquier dominio con un único script utilizando el API de seguridad DNS de botoi.

Cómo funciona la autenticación de correo electrónico

Tres registros DNS funcionan como capas de defensa. Cada uno resuelve un problema diferente:

1. FPS responde: "¿Este servidor tiene permiso para enviar correo electrónico para este dominio?"
2. DKIM responde: "¿Se modificó este mensaje después de salir del servidor del remitente?"
3. DMARC responde: "¿Qué debo hacer si falla SPF o DKIM y dónde envío informes?"

Cuando alguien envía un correo electrónico afirmando ser de you@example.com, la recepción El servidor verifica estos registros en secuencia. Si SPF y DKIM fallan y DMARC dice p=reject, el mensaje se descarta antes de llegar a la bandeja de entrada. sin todo En tercer lugar, existen lagunas que los atacantes aprovechan.

SPF: quién puede enviar en su nombre

SPF (Marco de políticas del remitente) es un registro DNS TXT en la raíz de su dominio. Enumera cada Dirección IP y servidor de correo autorizado para enviar correo electrónico para su dominio. Cuando un servidor receptor recibe un correo electrónico de example.com, comprueba el registro SPF para ver si el envío El servidor está en la lista aprobada.

Verifique el registro SPF de cualquier dominio con una sola llamada API:

curl -s -X POST https://api.botoi.com/v1/dns-security/spf-check \\
  -H "Content-Type: application/json" \\
  -d '{"domain": "example.com"}'

Respuesta:

{
  "success": true,
  "data": {
    "domain": "example.com",
    "has_spf": true,
    "record": "v=spf1 include:_spf.google.com ~all",
    "mechanisms": ["include:_spf.google.com", "~all"],
    "all_policy": "~all",
    "includes": ["_spf.google.com"],
    "valid": true
  }
}

Los campos clave para verificar:

• has_spf: ¿Tiene un registro TXT que comienza con v=spf1 ¿existir? Si es falso, cualquier servidor puede falsificar el correo electrónico de su dominio.
• valid: ¿El registro se analiza sin errores? Los registros SPF se rompen silenciosamente cuando superan el límite de búsqueda de 10 DNS.
• all_policy: el mecanismo de seguimiento que define lo que sucede con los remitentes no listados. -all (Duro fallo) Las rechaza. ~all (Soft fail) Las marca sospechosas. +all permite a todos, lo que frustra todo el propósito.

El límite de 10 búsquedas

Los registros SPF permiten un máximo de 10 búsquedas de DNS. Cada include:, a:, mx:, y redirect: El mecanismo cuenta como una búsqueda. Incluye anidado contar también. Una vez que agregues Google Workspace, tu herramienta de marketing, tu servicio de correo electrónico transaccional, y un CRM, alcanzas este límite rápidamente.

Cuando supera las 10 búsquedas, todo el registro SPF deja de ser válido. Las API valid El campo capta esto. Solucionarlo aplanando inclusiones anidadas en rangos de IP o consolidando proveedores.

DMARC: qué hacer cuando fallan las comprobaciones

DMARC (autenticación, informes y conformidad de mensajes basados en dominio) vincula SPF y DKIM juntos. vive en _dmarc.example.com como un registro TXT y le dice a la recepción servidores dos cosas: qué hacer con los mensajes que fallan en la autenticación y dónde enviarlos informes sobre esos fracasos.

Verifique su registro DMARC:

curl -s -X POST https://api.botoi.com/v1/dns-security/dmarc-check \\
  -H "Content-Type: application/json" \\
  -d '{"domain": "example.com"}'

Respuesta:

{
  "success": true,
  "data": {
    "domain": "example.com",
    "has_dmarc": true,
    "record": "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100",
    "policy": "reject",
    "subdomain_policy": null,
    "reporting": {
      "rua": ["mailto:dmarc@example.com"],
      "ruf": []
    },
    "pct": 100,
    "alignment": {
      "dkim": "r",
      "spf": "r"
    }
  }
}

Políticas DMARC

La policy El campo determina qué sucede con los mensajes fallidos:

• none: No realice ninguna acción. Monitorear únicamente. Recibes informes pero aún así envías correos electrónicos falsificados llegar a las bandejas de entrada.
• quarantine: mueve los mensajes fallidos a spam. El destinatario aún puede encontrarlos. si miran.
• reject: elimine por completo los mensajes fallidos. La protección más fuerte, pero una mala configuración significa la pérdida de un correo electrónico legítimo.

Estrategia de implementación segura de DMARC

Yendo directamente a p=reject es arriesgado. Sigue este camino:

1. Empezar con p=none; rua=mailto:dmarc@example.com para recopilar informes durante 2-4 semanas
2. Revisar informes. Identifique cualquier remitente legítimo que falle en la autenticación. Corrija sus inclusiones SPF y claves DKIM.
3. Convidar a p=quarantine; pct=10 poner en cuarentena el 10% de los mensajes fallidos
4. Aumentar pct a 25, 50 y luego 100 durante las próximas semanas, a medida que confirmes que ningún correo legítimo se ve afectado
5. Cambiar a p=reject; pct=100 una vez que tengas confianza en tu configuración

La pct El campo en la respuesta de la API le muestra dónde se encuentra en esta implementación. un dominio en pct=100 con policy=reject tiene protección total.

DKIM: firmas criptográficas en cada correo electrónico

DKIM (DomainKeys Identified Mail) agrega una firma criptográfica a los encabezados de cada mensaje saliente. El servidor emisor firma el mensaje con una clave privada; el servidor receptor lo verifica con una clave pública publicada en su DNS. Si el mensaje fue alterado en tránsito (encabezados cambiados, cuerpo modificado, reenviado a través de una lista de correo que reescribe el contenido), el la firma falla.

Registros DKIM en vivo en [selector]._domainkey.example.com. El selector es una etiqueta. su proveedor de correo electrónico asigna, como google para Google Workspace o selector1 para Microsoft 365.

Consultar un registro DKIM:

curl -s -X POST https://api.botoi.com/v1/dns-security/dkim-check \\
  -H "Content-Type: application/json" \\
  -d '{"domain": "example.com", "selector": "google"}'

Respuesta:

{
  "success": true,
  "data": {
    "domain": "example.com",
    "selector": "google",
    "has_dkim": true,
    "record": "v=DKIM1; k=rsa; p=MIIBIjANBgkq...",
    "key_type": "rsa",
    "public_key_length": 2048
  }
}

Campos clave:

• has_dkim: ¿Se publica una clave pública para este selector? Si es falso, DKIM La verificación falla en todos los mensajes firmados con este selector.
• public_key_length: NIST recomienda un mínimo de 2048 bits. Claves menores de 1024 Los bits son lo suficientemente débiles como para factorizar.
• key_type: RSA es el estándar. Ed25519 es más rápido y usa claves más cortas pero tiene soporte limitado del proveedor de correo.

DKIM y reenvío de correo electrónico

Es por eso que DKIM es importante incluso cuando se configura SPF. Cuando alguien reenvía su correo electrónico, La IP del servidor de reenvío no está en su registro SPF, por lo que el SPF falla. Pero la firma DKIM sobrevive al reenvío (siempre que el contenido no se modifique). DMARC pasa si SPF o DKIM se alinea, por lo que DKIM es su red de seguridad para los mensajes reenviados.

Cómo trabajan los tres juntos

Amenaza	FPS	DKIM	DMARC
Correo electrónico falsificado de un servidor no autorizado	Detecta	Detecta (no hay firma válida)	Hace cumplir la política
Cuerpo del mensaje manipulado en tránsito	No detecta	Detecta	Hace cumplir la política
Correo electrónico reenviado por un remitente legítimo	Falla (IP de servidor diferente)	Pases (firma intacta)	Pasa si DKIM se alinea
Suplantación de subdominio (usuario@fake.example.com)	Sin protección	Sin protección	Bloques vía sp=reject
Visibilidad de los fallos de autenticación	Ninguna	Ninguna	Envía informes agregados

Ningún registro proporciona una cobertura completa. SPF sin DMARC significa que las fallas no se aplican. DKIM sin SPF significa que cualquier persona con una clave válida puede enviar desde su dominio. DMARC sin ambos SPF y DKIM no tienen nada que hacer cumplir.

Audita tu dominio en 30 segundos

Este script de shell verifica los tres registros e imprime un resumen de pasa/falla. Utiliza el botoi API de seguridad DNS; no se necesita clave API para hasta 5 solicitudes por minuto.

#!/bin/bash
# Audit SPF, DMARC, and DKIM for a domain in 30 seconds
DOMAIN=\${1:-"example.com"}
DKIM_SELECTOR=\${2:-"google"}
API="https://api.botoi.com/v1/dns-security"
PASS=0
FAIL=0

echo "Auditing email authentication for \$DOMAIN"
echo "==========================================="

# SPF check
SPF=\$(curl -s -X POST "\$API/spf-check" \\
  -H "Content-Type: application/json" \\
  -d "{\\"domain\\": \\"\$DOMAIN\\"}")

HAS_SPF=\$(echo "\$SPF" | jq -r '.data.has_spf')
SPF_VALID=\$(echo "\$SPF" | jq -r '.data.valid')
SPF_RECORD=\$(echo "\$SPF" | jq -r '.data.record // "not found"')
ALL_POLICY=\$(echo "\$SPF" | jq -r '.data.all_policy // "none"')

if [ "\$HAS_SPF" = "true" ] && [ "\$SPF_VALID" = "true" ]; then
  echo "[PASS] SPF: \$SPF_RECORD"
  PASS=\$((PASS + 1))
else
  echo "[FAIL] SPF: \$SPF_RECORD"
  FAIL=\$((FAIL + 1))
fi

if [ "\$ALL_POLICY" = "+all" ]; then
  echo "  WARNING: +all allows any server to send as your domain"
fi

# DMARC check
DMARC=\$(curl -s -X POST "\$API/dmarc-check" \\
  -H "Content-Type: application/json" \\
  -d "{\\"domain\\": \\"\$DOMAIN\\"}")

HAS_DMARC=\$(echo "\$DMARC" | jq -r '.data.has_dmarc')
POLICY=\$(echo "\$DMARC" | jq -r '.data.policy // "not set"')
PCT=\$(echo "\$DMARC" | jq -r '.data.pct // 0')

if [ "\$HAS_DMARC" = "true" ]; then
  echo "[PASS] DMARC: policy=\$POLICY pct=\$PCT%"
  PASS=\$((PASS + 1))
else
  echo "[FAIL] DMARC: no record found"
  FAIL=\$((FAIL + 1))
fi

if [ "\$POLICY" = "none" ]; then
  echo "  WARNING: policy=none only monitors, does not enforce"
fi

# DKIM check
DKIM=\$(curl -s -X POST "\$API/dkim-check" \\
  -H "Content-Type: application/json" \\
  -d "{\\"domain\\": \\"\$DOMAIN\\", \\"selector\\": \\"\$DKIM_SELECTOR\\"}")

HAS_DKIM=\$(echo "\$DKIM" | jq -r '.data.has_dkim')
KEY_TYPE=\$(echo "\$DKIM" | jq -r '.data.key_type // "unknown"')
KEY_LEN=\$(echo "\$DKIM" | jq -r '.data.public_key_length // 0')

if [ "\$HAS_DKIM" = "true" ]; then
  echo "[PASS] DKIM: selector=\$DKIM_SELECTOR key_type=\$KEY_TYPE key_length=\$KEY_LEN"
  PASS=\$((PASS + 1))
else
  echo "[FAIL] DKIM: no record for selector '\$DKIM_SELECTOR'"
  FAIL=\$((FAIL + 1))
fi

if [ "\$HAS_DKIM" = "true" ] && [ "\$KEY_LEN" -lt 2048 ] 2>/dev/null; then
  echo "  WARNING: DKIM key is \$KEY_LEN bits (2048 recommended)"
fi

# Summary
echo ""
echo "Results: \$PASS passed, \$FAIL failed"
[ "\$FAIL" -eq 0 ] && echo "All checks passed." || exit 1

Ejecútelo:

bash audit.sh example.com google

El primer argumento es tu dominio; el segundo es su selector DKIM. El script crea 3 API. llamadas (dentro del límite del nivel gratuito), verifica cada registro, señala advertencias sobre configuraciones débiles, y sale con un código distinto de cero si falla alguna verificación. Colóquelo en una tarea cron o canalización de CI para un seguimiento continuo.

Si prefiere JavaScript, aquí tiene la misma auditoría que una función asíncrona:

async function auditEmailAuth(domain, dkimSelector = "google") {
  const api = "https://api.botoi.com/v1/dns-security";
  const headers = { "Content-Type": "application/json" };

  const [spf, dmarc, dkim] = await Promise.all([
    fetch(\`\${api}/spf-check\`, {
      method: "POST",
      headers,
      body: JSON.stringify({ domain }),
    }).then((r) => r.json()),

    fetch(\`\${api}/dmarc-check\`, {
      method: "POST",
      headers,
      body: JSON.stringify({ domain }),
    }).then((r) => r.json()),

    fetch(\`\${api}/dkim-check\`, {
      method: "POST",
      headers,
      body: JSON.stringify({ domain, selector: dkimSelector }),
    }).then((r) => r.json()),
  ]);

  return {
    domain,
    spf: {
      exists: spf.data.has_spf,
      valid: spf.data.valid,
      record: spf.data.record,
      allPolicy: spf.data.all_policy,
    },
    dmarc: {
      exists: dmarc.data.has_dmarc,
      policy: dmarc.data.policy,
      pct: dmarc.data.pct,
      reporting: dmarc.data.reporting?.rua || [],
    },
    dkim: {
      exists: dkim.data.has_dkim,
      selector: dkimSelector,
      keyType: dkim.data.key_type,
      keyLength: dkim.data.public_key_length,
    },
  };
}

// Usage
const report = await auditEmailAuth("example.com", "google");
console.log(JSON.stringify(report, null, 2));

Configuraciones de proveedores comunes

Cada proveedor de correo electrónico tiene su propio dominio incluido SPF y selector DKIM. Aqui estan los valores para los proveedores más comunes:

Proveedora	SPF incluye	Selectores DKIM
Espacio de trabajo de Google	include:_spf.google.com	google
microsoft 365	include:spf.protection.outlook.com	selector1, selector2
Amazon SES	include:amazonses.com	Basado en UUID (consulte la consola SES)
EnviarGrid	include:sendgrid.net	s1, s2
Matasellos	include:spf.mtasv.net	Por dominio (verifique la configuración DNS del matasellos)
Mailchimp / Mandril	include:servers.mcsv.net	k1

Si utiliza varios proveedores, su registro SPF los incluye a todos en una única entrada TXT. Por ejemplo: v=spf1 include:_spf.google.com include:sendgrid.net ~all. ver el límite de 10 búsquedas a medida que agrega proveedores.

Puntos clave

• FPS controla qué servidores pueden enviar correo electrónico para su dominio. Compruébalo con el /v1/dns-security/spf-check punto final. Esté atento al límite de 10 búsquedas y evitar +all.
• DMARC define lo que sucede cuando falla SPF o DKIM. Despliegue gradualmente desde p=none a p=reject usando el pct campo. Siempre configurado un rua Dirección para recibir informes.
• DKIM demuestra la integridad del mensaje con firmas criptográficas. Utilice 2048 bits claves mínimas y verifique que su selector esté publicado con /v1/dns-security/dkim-check.
• Los tres registros funcionan juntos. El SPF por sí solo no detiene la suplantación de correo electrónico reenviado. DKIM solo no les dice a los receptores qué hacer en caso de falla. DMARC sin SPF y DKIM no tiene nada que hacer cumplir.
• Automatiza tus controles. Ejecute el script de auditoría según una programación o en CI para detectar la desviación de DNS, proveedor migraciones y eliminaciones accidentales de registros antes de que afecten la capacidad de entrega.