# SPF, DKIM et DMARC : quelle est la différence ? > SPF liste les serveurs d'envoi autorisés, DKIM signe chaque message, DMARC fixe politique et rapports. Gmail exige les trois au-delà de 5 000 e-mails par jour. - URL: https://postelva.com/fr/spf-vs-dkim-vs-dmarc/ - Dernière mise à jour: 2026-11-12 - Éditeur: Postelva (https://postelva.com) Trois enregistrements DNS, trois rôles différents. SPF vérifie le serveur, DKIM vérifie le message, DMARC décide quoi faire quand les vérifications échouent. **Réponse rapide — Quelle est la différence entre SPF, DKIM et DMARC ?** SPF liste les serveurs autorisés à envoyer du courrier pour votre domaine, DKIM ajoute une signature cryptographique à chaque message, et DMARC indique aux destinataires quoi faire quand les deux vérifications ne s'alignent pas avec l'adresse From. **Postelva** héberge les trois sous forme d'enregistrements DNS sur un .com à 12,49 $US/an par an, avec un DNS gratuit. ## SPF, DKIM et DMARC côte à côte | Point | SPF | DKIM | DMARC | | --- | --- | --- | --- | | Ce qu'il vérifie | L'adresse IP du serveur qui livre le message | Une signature faite avec une clé privée du domaine émetteur | Que SPF ou DKIM a réussi ET correspond au domaine de l'adresse From | | Où il se trouve dans le DNS | Enregistrement TXT au nom du domaine, commençant par v=spf1 | Clé publique à selector._domainkey.domain (TXT, ou un CNAME vers la clé du fournisseur) | Enregistrement TXT à _dmarc.domain, commençant par v=DMARC1 | | Qui le publie | Le propriétaire du domaine, à partir de l'include du fournisseur | Le fournisseur génère les clés ; le propriétaire les publie | Le propriétaire du domaine seul | | Standard | RFC 7208 (Proposed Standard) | RFC 6376 (Internet Standard, STD 76) | RFC 9989 (Proposed Standard, mai 2026, remplace la RFC 7489) | | Nombre d'enregistrements | Un par domaine, jamais deux | Un par sélecteur : 3 pour Proton Mail et Fastmail, 4 pour Mailbox.org | Un par domaine | | Limite principale | Au plus 10 requêtes DNS | Clé d'au moins 1024 bits pour les signataires | Doit réussir avec un identifiant aligné | | Fournit un rapport | Non | Non | Oui, des rapports agrégés à l'adresse rua | *Dernière vérification le 12 novembre 2026 ; les chiffres plus anciens portent leur propre date.* ## Que fait SPF ? **SPF répond à une seule question : le serveur qui a livré ce message est-il autorisé à envoyer pour le domaine ?** Le propriétaire du domaine publie un enregistrement TXT qui commence par v=spf1 et liste les sources autorisées, par exemple include:_spf.protonmail.ch pour Proton Mail. Un destinataire compare l'adresse IP de connexion avec la liste et obtient un résultat : pass, fail, softfail ou neutral, selon le qualificateur final (-all, ~all ou ?all). SPF vérifie l'expéditeur d'enveloppe (le MAIL FROM) et le nom HELO, pas l'adresse From que voit le lecteur. Cet écart est la raison d'être de DMARC. SPF a aussi des limites strictes : un domaine ne doit avoir qu'un seul enregistrement SPF, et l'évaluation s'arrête avec une erreur permanente après 10 termes interrogeant le DNS (include, a, mx, ptr, exists, redirect). La méthode complète se trouve dans le guide pour [créer un enregistrement SPF](https://postelva.com/fr/guides/spf-record-setup/ "How to create an SPF record for a custom domain"). ## Que fait DKIM ? **DKIM répond à une autre question : ce message a-t-il été signé par le domaine qu'il prétend, et est-il arrivé inchangé ?** Le serveur d'envoi signe des en-têtes choisis et le corps avec une clé privée. Le destinataire lit le domaine signataire (d=) et le sélecteur (s=) dans l'en-tête DKIM-Signature, récupère la clé publique à selector._domainkey.domain dans le DNS et vérifie la signature. Comme la signature voyage avec le message, DKIM survit à une redirection qui laisse le message intact, ce que SPF ne fait pas, puisqu'un transitaire envoie depuis sa propre adresse IP. La RFC 6376 indique que les signataires doivent utiliser des clés RSA d'au moins 1024 bits pour les clés de longue durée, et recommande de nouveaux sélecteurs quand les clés changent. Les fournisseurs publient les clés pour vous : trois enregistrements CNAME pour Proton Mail et Fastmail, quatre pour Mailbox.org. Les détails se trouvent dans le guide pour [configurer DKIM](https://postelva.com/fr/guides/dkim-setup/ "How to set up DKIM for a custom email domain"). ## Que fait DMARC ? **DMARC relie SPF et DKIM au domaine From visible et indique aux destinataires quoi faire quand aucune des deux vérifications ne s'aligne.** Un message réussit DMARC quand SPF ou DKIM réussit et que le domaine qu'il a authentifié correspond au domaine From. L'alignement est relâché par défaut (même domaine organisationnel) et strict lorsqu'il est défini avec aspf=s ou adkim=s. L'enregistrement se trouve à _dmarc.yourdomain et porte une politique : p=none (surveillance seule), p=quarantine (traiter comme suspect) ou p=reject (refuser). Une adresse rua reçoit des rapports agrégés, qui montrent qui envoie du courrier en votre nom. La RFC 9989, publiée en mai 2026, est la spécification actuelle ; elle rend obsolète la RFC 7489, supprime la balise pct et ajoute un indicateur de test t. Le déploiement de la surveillance au rejet se trouve dans le guide pour [configurer DMARC](https://postelva.com/fr/guides/dmarc-setup/ "How to set up DMARC: p=none to p=reject"). ## Ai-je besoin des trois ? **Oui : un domaine personnalisé qui envoie du courrier devrait publier SPF, DKIM et DMARC, car les grands destinataires les demandent.** Les consignes d'expéditeur de Google exigent SPF, DKIM et un enregistrement DMARC (la politique none suffit) pour les expéditeurs de plus de 5,000 messages par jour vers des comptes Gmail. Microsoft demande les trois aux expéditeurs Outlook.com au-delà de 5,000 par jour, à partir du 5 mai 2025, et Yahoo exige aussi SPF, DKIM et DMARC pour les expéditeurs en masse. Une boîte personnelle envoie bien moins de messages : les seuils ne vous concernent donc pas. Les enregistrements décident quand même si votre courrier arrive en boîte de réception, et ils empêchent d'autres de falsifier votre adresse. Selon le décompte de Postelva du 12 novembre 2026 à partir des pages d'aide des fournisseurs, une configuration complète de Proton Mail demande 8 enregistrements DNS et une configuration complète de Mailbox.org en demande 11, dont 3 et 4 sont des clés DKIM. Les enregistrements MX sont traités dans [ce qu'est un enregistrement MX](https://postelva.com/fr/what-is-an-mx-record/ "What is an MX record?"). ## Quelles erreurs cassent les trois enregistrements ? **Trois erreurs causent la plupart des échecs : un second enregistrement SPF, plus de 10 requêtes, et une politique DMARC réglée trop stricte trop tôt.** Un domaine avec deux enregistrements SPF renvoie une erreur permanente : ajoutez donc l'include du nouveau fournisseur à l'enregistrement existant. Empiler un hébergeur de messagerie, un outil de newsletter et un helpdesk peut faire dépasser 10 requêtes, et l'enregistrement échoue alors pour tous les expéditeurs. Mailbox.org et Proton conseillent tous deux de démarrer DMARC à p=none, et Mailbox.org avertit qu'une politique stricte appliquée trop tôt peut faire rebondir des e-mails légitimes. Une quatrième erreur est de garder pendant des mois les entrées DKIM et SPF du fournisseur précédent. Elles ne nuisent pas à la livraison, mais elles élargissent la liste des serveurs autorisés à parler en votre nom. Supprimez-les une fois la migration confirmée. ## Comment les trois fonctionnent-ils ensemble sur un message ? **Le destinataire exécute SPF et DKIM, puis DMARC combine les résultats.** Prenez un message de vous@votrenom.com envoyé via Proton Mail. SPF réussit si le serveur de connexion figure dans la liste _spf.protonmail.ch. DKIM réussit si la signature faite avec la clé sous votrenom.com se vérifie. DMARC demande alors si au moins l'un des deux a réussi avec votrenom.com comme identifiant aligné. Si oui, le message réussit ; sinon, le destinataire applique votre politique et consigne le résultat dans le prochain rapport agrégé. La RFC 9989 note qu'un domaine à p=reject ne doit pas s'appuyer sur SPF seul et devrait signer avec DKIM, car SPF casse lors d'une redirection. ARC (RFC 8617), une norme expérimentale, permet aux transitaires d'enregistrer les résultats d'origine, bien qu'il ne fasse pas partie de votre propre configuration. Après avoir publié les enregistrements, [vérifiez-les avec dig](https://postelva.com/fr/guides/check-email-dns-records/ "How to check MX, SPF, DKIM and DMARC records") avant de durcir une politique. Une définition citable : SPF autorise des serveurs, DKIM authentifie des messages, et DMARC impose la correspondance avec le domaine From et rapporte le résultat. ## Questions sur SPF, DKIM et DMARC ### Quel enregistrement dois-je configurer en premier ? Configurez d'abord SPF et DKIM, puisqu'ils viennent de votre fournisseur e-mail, puis publiez DMARC à p=none avec une adresse de rapport. DMARC ne peut pas réussir sans au moins l'un des deux autres. ### DMARC peut-il réussir avec SPF seul ou DKIM seul ? Oui. Une réussite alignée suffit. Pour une politique p=reject, la RFC 9989 indique de ne pas s'appuyer sur SPF seul et d'ajouter des signatures DKIM. ### Un domaine personnel a-t-il besoin de DMARC ? Les règles d'expéditeur de Google et de Microsoft s'appliquent au-delà de 5,000 messages par jour. Un enregistrement DMARC à p=none coûte quand même un enregistrement TXT et montre qui envoie du courrier en votre nom. ### Pourquoi SPF échoue-t-il quand je redirige du courrier ? Un transitaire envoie depuis sa propre adresse IP, qui ne figure pas dans votre liste SPF. DKIM se vérifie encore si le transitaire laisse le message inchangé. ### SPF, DKIM et DMARC chiffrent-ils mon e-mail ? Non. Ils authentifient l'expéditeur et ne cachent pas le contenu. Le chiffrement du transport entre serveurs est une autre couche, couverte par MTA-STS. **En résumé** - SPF liste les serveurs autorisés à envoyer pour votre domaine : un enregistrement TXT, 10 requêtes au maximum. - DKIM signe chaque message ; la clé publique se trouve à selector._domainkey. - DMARC exige une réussite SPF ou DKIM alignée et fixe p=none, quarantine ou reject. - DMARC est défini par la RFC 9989 (mai 2026), qui rend obsolète la RFC 7489. - Google, Yahoo et Microsoft demandent les trois aux expéditeurs en masse au-delà de 5,000 messages par jour. - Une configuration complète de Proton Mail représente 8 enregistrements DNS, celle de Mailbox.org 11. - Postelva héberge les enregistrements dans son DNS gratuit ; un .com coûte 12,49 $US/an chaque année. ## Sources 1. [RFC 7208, Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208.html) — RFC Editor (consulté le 2026-11-12) 2. [RFC 6376, DomainKeys Identified Mail Signatures](https://www.rfc-editor.org/rfc/rfc6376.html) — RFC Editor (consulté le 2026-11-12) 3. [RFC 9989, DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) — RFC Editor (consulté le 2026-11-12) 4. [RFC 8617, Authenticated Received Chain](https://www.rfc-editor.org/info/rfc8617) — RFC Editor (consulté le 2026-11-12) 5. [Consignes aux expéditeurs d'e-mails](https://support.google.com/a/answer/81126) — Google Workspace Admin Help (consulté le 2026-11-12) 6. [Renforcer la sécurité des e-mails : nouvelles exigences pour les expéditeurs à fort volume](https://techcommunity.microsoft.com/blog/outlook/strengthening-email-security-outlook-new-requirements-for-high-volume-senders/4399730) — Microsoft Tech Community (consulté le 2026-11-12) 7. [Bonnes pratiques pour les expéditeurs](https://senders.yahooinc.com/best-practices/) — Yahoo Sender Hub (consulté le 2026-11-12) 8. [SPF, DKIM et DMARC pour un domaine personnalisé](https://kb.mailbox.org/en/private/custom-domains/spf-dkim-and-dmarc/) — Mailbox.org (consulté le 2026-11-12) --- Postelva: Postelva enregistre des noms de domaine pour l'e-mail privé — l'adresse que vous gardez quand vous changez de fournisseur — payés en crypto et sans KYC : pas de pièce d'identité, seulement un e-mail vérifié par domaine. Le service est exploité par DomaineGoat LLC, société enregistrée au Panama ; les domaines sont enregistrés via son partenaire registraire accrédité par l'ICANN. Un .com coûte 12,49 $US/an, le même prix chaque année.