SPF, DMARC et DKIM : le guide complet d'authentification des emails

Votre domaine réussit toutes les analyses de sécurité. Votre certificat SSL est valide, vos en-têtes sont serrés, votre CSP est verrouillé. Puis un e-mail de phishing arrive dans la boîte de réception d'un client, provenant de votre domaine, avec le nom de votre entreprise dans le champ "De". L'e-mail est faux, mais les dégâts sont réels.

Cela se produit parce que le courrier électronique a été conçu en 1982 sans vérification intégrée de l’expéditeur. N'importe qui pouvez définir n'importe quelle adresse « De » sur un e-mail, et sans enregistrements SPF, DMARC et DKIM sur votre domaine, les serveurs de réception n'ont aucun moyen de détecter la contrefaçon. Plus de 90 % des attaques de phishing utilisent l'usurpation d'identité de domaine et une authentification de courrier électronique mal configurée constituent la porte ouverte.

Ce guide explique ce que fait chaque enregistrement, comment ils fonctionnent ensemble et comment auditer les trois. sur n'importe quel domaine avec un seul script en utilisant le API de sécurité DNS botoi.

Comment fonctionne l'authentification par courrier électronique

Trois enregistrements DNS fonctionnent comme des couches de défense. Chacun résout un problème différent :

1. FPS réponses : "Ce serveur est-il autorisé à envoyer des e-mails pour ce domaine ?"
2. DKIM répond : "Ce message a-t-il été modifié après avoir quitté le serveur de l'expéditeur ?"
3. DMARC réponses : « Que dois-je faire si SPF ou DKIM échoue, et où puis-je envoyer des rapports ? »

Quand quelqu'un envoie un e-mail en prétendant provenir de you@example.com, la réception Le serveur vérifie ces enregistrements dans l'ordre. Si SPF et DKIM échouent tous les deux et que DMARC indique p=reject, le message est supprimé avant d'atteindre la boîte de réception. Sans tout Troisièmement, il existe des failles que les attaquants exploitent.

SPF : qui peut envoyer en votre nom

SPF (Sender Policy Framework) est un enregistrement DNS TXT à la racine de votre domaine. Il répertorie chaque Adresse IP et serveur de messagerie autorisé à envoyer des e-mails pour votre domaine. Lorsqu'un serveur de réception reçoit un e-mail de example.com, il vérifie l'enregistrement SPF pour voir si l'envoi le serveur est sur la liste approuvée.

Vérifiez l'enregistrement SPF de n'importe quel domaine avec un seul appel API :

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

Réponse:

{
  "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
  }
}

Les champs clés à vérifier :

• has_spf: Effectue un enregistrement TXT commençant par v=spf1 exister? Si faux, n'importe quel serveur peut falsifier les e-mails de votre domaine.
• valid: L'enregistrement est-il analysé sans erreurs ? Les enregistrements SPF se brisent silencieusement lorsque ils dépassent la limite de 10 recherches DNS.
• all_policy: Le mécanisme de suivi qui définit ce qui arrive aux expéditeurs non répertoriés. -all (échec difficile) les rejette. ~all (échec logiciel) les rend suspects. +all permet à tout le monde, ce qui va à l’encontre de l’objectif même.

La limite de 10 recherches

Les enregistrements SPF autorisent un maximum de 10 recherches DNS. Chaque include:, a:, mx:, et redirect: le mécanisme compte pour une recherche. Inclut imbriqué compter aussi. Une fois que vous avez ajouté Google Workspace, votre outil marketing, votre service de messagerie transactionnelle, et un CRM, vous atteignez rapidement cette limite.

Lorsque vous dépassez 10 recherches, l’intégralité de l’enregistrement SPF devient invalide. Les API valid le champ attrape ça. Corrigez-le en aplatissant les inclusions imbriquées dans des plages IP ou en consolidant fournisseurs.

DMARC : que faire en cas d'échec des contrôles

DMARC (Domain-based Message Authentication, Reporting, and Conformance) lie SPF et DKIM ensemble. Il vit à _dmarc.example.com sous forme d'enregistrement TXT et indique la réception serveurs deux choses : que faire des messages qui échouent à l'authentification et où les envoyer rapports sur ces échecs.

Vérifiez votre enregistrement DMARC :

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

Réponse:

{
  "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"
    }
  }
}

Politiques DMARC

La policy Le champ détermine ce qui arrive aux messages ayant échoué :

• none: Ne rien faire. Surveiller uniquement. Vous recevez des rapports mais des e-mails usurpés continuent accéder aux boîtes de réception.
• quarantine: déplacez les messages ayant échoué vers le spam. Le destinataire peut toujours les retrouver s'ils regardent.
• reject: Supprimez entièrement les messages défaillants. La protection la plus solide, mais une mauvaise configuration signifie une perte de courrier électronique légitime.

Stratégie de déploiement DMARC sécurisée

Aller directement à p=reject est risqué. Suivez ce chemin :

1. Commencez par p=none; rua=mailto:dmarc@example.com pour collecter des rapports pendant 2 à 4 semaines
2. Examiner les rapports. Identifiez tous les expéditeurs légitimes qui échouent à l’authentification. Corrigez leurs inclusions SPF et leurs clés DKIM.
3. Passer à p=quarantine; pct=10 mettre en quarantaine 10 % des messages ayant échoué
4. Augmenter pct à 25, 50, puis 100 au cours des prochaines semaines, à mesure que vous confirmez qu'aucun courrier légitime n'est affecté
5. Passer à p=reject; pct=100 une fois que vous avez confiance en votre configuration

La pct Le champ de la réponse de l'API vous indique où vous en êtes dans ce déploiement. Un domaine à pct=100 avec policy=reject a une protection complète.

DKIM : signatures cryptographiques sur chaque email

DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique aux en-têtes de chaque message sortant. Le serveur expéditeur signe le message avec une clé privée ; le serveur de réception le vérifie par rapport à une clé publique publiée dans votre DNS. Si le message a été modifié pendant le transport (en-têtes modifiés, corps modifié, transmis via une liste de diffusion qui réécrit le contenu), le la signature échoue.

DKIM enregistre en direct sur [selector]._domainkey.example.com. Le sélecteur est une étiquette votre fournisseur de messagerie attribue, comme google pour Google Workspace ou selector1 pour Microsoft 365.

Vérifiez un enregistrement 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"}'

Réponse:

{
  "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
  }
}

Champs clés :

• has_dkim: Une clé publique est-elle publiée pour ce sélecteur ? Si faux, DKIM la vérification échoue pour tous les messages signés avec ce sélecteur.
• public_key_length: NIST recommande un minimum de 2048 bits. Clés inférieures à 1024 les bits sont suffisamment faibles pour être pris en compte.
• key_type: RSA est la norme. Ed25519 est plus rapide et utilise des clés plus courtes mais a un support limité du fournisseur de messagerie.

DKIM et transfert d'e-mails

C'est pourquoi DKIM est important même lorsque SPF est configuré. Quand quelqu'un transfère votre e-mail, l'adresse IP du serveur de transfert ne figure pas dans votre enregistrement SPF, donc SPF échoue. Mais la signature DKIM survit au transfert (tant que le contenu n'est pas modifié). DMARC réussit si l'un ou l'autre SPF ou DKIM s'aligne, donc DKIM est votre filet de sécurité pour les messages transférés.

Comment les trois travaillent ensemble

Menace	FPS	DKIM	DMARC
E-mail usurpé provenant d'un serveur non autorisé	Détecte	Détecte (pas de signature valide)	Applique la politique
Corps du message falsifié pendant le transit	Ne détecte pas	Détecte	Applique la politique
E-mail transféré d'un expéditeur légitime	Échec (IP de serveur différente)	Laissez-passer (signature intacte)	Réussi si DKIM s'aligne
Usurpation de sous-domaine (user@fake.example.com)	Aucune protection	Aucune protection	Bloque via sp=reject
Visibilité sur les échecs d'authentification	Aucune	Aucune	Envoie des rapports globaux

Aucun enregistrement ne fournit une couverture complète. SPF sans DMARC signifie que les échecs ne sont pas appliqués. DKIM sans SPF signifie que toute personne disposant d'une clé valide peut envoyer depuis votre domaine. DMARC sans les deux SPF et DKIM n’ont rien contre quoi s’opposer.

Auditez votre domaine en 30 secondes

Ce script shell vérifie les trois enregistrements et imprime un résumé réussite/échec. Il utilise le botoi API de sécurité DNS ; aucune clé API n'est nécessaire pour un maximum de 5 requêtes par minute.

#!/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

Exécutez-le :

bash audit.sh example.com google

Le premier argument est votre domaine ; le second est votre sélecteur DKIM. Le script crée 3 API appels (dans la limite du niveau gratuit), vérifie chaque enregistrement, signale les avertissements pour les configurations faibles, et quitte avec un code différent de zéro si une vérification échoue. Déposez-le dans une tâche cron ou un pipeline CI pour une surveillance continue.

Si vous préférez JavaScript, voici le même audit qu'une fonction asynchrone :

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));

Configurations de fournisseur courantes

Chaque fournisseur de messagerie possède son propre domaine d'inclusion SPF et son propre sélecteur DKIM. Voici les valeurs pour les prestataires les plus courants :

Fournisseuse	Le SPF inclut	Sélecteur(s) DKIM
Espace de travail Google	include:_spf.google.com	google
Microsoft 365	include:spf.protection.outlook.com	selector1, selector2
AmazonSES	include:amazonses.com	Basé sur l'UUID (vérifiez la console SES)
EnvoyerGrille	include:sendgrid.net	s1, s2
Cachet de la poste	include:spf.mtasv.net	Par domaine (vérifiez les paramètres DNS Postmark)
MailChimp / Mandrill	include:servers.mcsv.net	k1

Si vous utilisez plusieurs fournisseurs, votre enregistrement SPF les inclut tous dans une seule entrée TXT. Par exemple: v=spf1 include:_spf.google.com include:sendgrid.net ~all. Regarder la limite de 10 recherches à mesure que vous ajoutez des fournisseurs.

Points clés

• FPS contrôle quels serveurs peuvent envoyer des e-mails pour votre domaine. Vérifiez-le avec le /v1/dns-security/spf-check point final. Surveillez la limite de 10 recherches et éviter +all.
• DMARC définit ce qui se passe en cas d'échec de SPF ou DKIM. Déployer progressivement à partir de p=none à p=reject en utilisant le pct champ. Toujours réglé un rua adresse pour recevoir les rapports.
• DKIM prouve l'intégrité des messages avec des signatures cryptographiques. Utiliser 2048 bits clés minimum et vérifiez que votre sélecteur est publié avec /v1/dns-security/dkim-check.
• Les trois disques fonctionnent ensemble. SPF à lui seul n’arrête pas l’usurpation d’e-mails transférés. DKIM seul ne dit pas aux récepteurs quoi faire en cas d'échec. DMARC sans SPF et DKIM n'a rien à appliquer.
• Automatisez vos contrôles. Exécutez le script d'audit selon un planning ou dans CI pour détecter la dérive DNS, le fournisseur migrations et suppressions accidentelles d’enregistrements avant qu’elles n’affectent la délivrabilité.