Envoyez un message à une adresse jetable et 42 contrôles sont exécutés sur celui-ci. Cette page les présente tous : ce que chacun examine, ce qu’il coûte à votre score lorsqu’il échoue et la section de la norme dont il provient.
Rien ici ne relève de notre opinion présentée comme une règle. Lorsqu’un contrôle applique une exigence d’une norme, la phrase correspondante de cette norme est citée en dessous. Lorsqu’il applique plutôt une exigence de Google ou Yahoo, un lien vers leur page est fourni. Lorsqu’il relève de notre propre appréciation, cela est indiqué.
Authentification
Indique si le serveur de réception peut prouver que le message provient bien de l’endroit indiqué. C’est la moitié de la délivrabilité qui dépend uniquement du DNS, et celle que Gmail et Yahoo ont rendue obligatoire pour les expéditeurs en nombre en 2024.
Chaîne ARC auth.arc
ARC préserve le résultat de l’authentification lors du passage par un redirecteur. Sans cela, une liste de diffusion qui ajoute un pied de page invalide votre signature DKIM et la copie redirigée échoue à DMARC à l’arrivée.
En cas d’échec : Rien à faire en tant qu’expéditeur. Cela importe si vous gérez une liste ou un redirecteur, et explique pourquoi certains de vos messages échouent à DMARC après leur redirection par quelqu’un.
Coûte jusqu’à 2 points sur 100 dans notre score.
RFC 7960 §1 — Introduction
DMARC with restrictive policies causes problems for many Mailing Lists.
RFC 8617 §2.1 — Evidence
In ARC's situation, the "evidence" is a message's authentication assessment at any point along the delivery path between origination and final delivery.
Google — Sender guidelines FAQ: rules for 5,000+ messages a day
Signature DKIM auth.dkim
DKIM signe des parties du message avec une clé privée et publie la clé publique dans DNS. Nous vérifions chaque signature présente dans le message et indiquons le domaine de signature, le sélecteur et la longueur de la clé.
En cas d’échec : Activez DKIM sur votre plateforme d’envoi et publiez la clé qu’elle vous fournit. Utilisez 2048 bits : une clé de 1024 bits passe encore la vérification, mais elle peut être cassée et n’est plus sûre.
Coûte jusqu’à 18 points sur 100 dans notre score et jusqu’à 1 sur 10 dans le score classique.
RFC 6376 §3.5 — The DKIM-Signature Header Field
The signature of the email is stored in the DKIM-Signature header field.
RFC 6376 §6.1 — Extract Signatures from the Message
Verifiers MUST NOT attribute ultimate meaning to the order of multiple DKIM-Signature header fields.
RFC 8301 §3.1 — Signing and Verification Algorithms
rsa-sha1 MUST NOT be used for signing or verifying.
RFC 8463 §6 — Transition Considerations
For backward compatibility, signers can add multiple signatures that use old and new signing algorithms.
Google — Set up DKIM
Google — Sender guidelines FAQ: rules for 5,000+ messages a day
Alignement DKIM auth.dkim_alignment
Une signature valide ne suffit pas pour DMARC. Le domaine de signature doit correspondre au domaine de l’en-tête From, exactement ou au niveau du domaine organisationnel selon la politique que vous avez publiée.
En cas d’échec : Signez avec votre propre domaine plutôt qu’avec celui de votre plateforme. La plupart des plateformes le permettent et parlent de domaine d’envoi personnalisé ou authentifié.
Coûte jusqu’à 10 points sur 100 dans notre score et jusqu’à 1 sur 10 dans le score classique.
RFC 9989 §4.4.1 — DKIM-Authenticated Identifiers
A single email can contain multiple DKIM signatures, and it is considered to produce a DMARC "pass" result if any DKIM-Authenticated Identifier aligns with the Author Domain.
Google — Set up DMARC
Google — Sender guidelines FAQ: rules for 5,000+ messages a day
Résultat DMARC auth.dmarc
DMARC relie SPF et DKIM au domaine que votre lecteur voit et indique aux destinataires quoi faire lorsqu’aucun des deux n’est aligné. Nous indiquons la politique publiée et si ce message l’a respectée.
En cas d’échec : Publiez un enregistrement DMARC. Commencez avec p=none, examinez les rapports pendant quelques semaines, puis passez à quarantine une fois que vous savez quelles autres sources envoient des messages en votre nom.
Coûte jusqu’à 14 points sur 100 dans notre score.
RFC 9989 §5.3.5 — Determine DMARC "Pass" or "Fail"
If no Authenticated Identifiers exist for the domain, or none of the Authenticated Identifiers align with the Author Domain, the message is considered to fail the DMARC mechanism check.
RFC 9989 §4.7 — DMARC Policy Record Format
DMARC Policy Records follow the extensible "tag-value" syntax for DNS-based key records defined in DKIM [RFC6376].
Google — Sender guidelines FAQ: rules for 5,000+ messages a day
Yahoo — Sender requirements and recommendations
Sender ID auth.sender_id
Le même contrôle que SPF, exécuté sur le domaine de l’en-tête From plutôt que sur celui de l’enveloppe. Il répond à une question différente : le domaine que votre lecteur voit autorise-t-il le serveur qui a envoyé le message ? Un message peut réussir SPF sur son enveloppe alors que le domaine visible ne se porte garant de personne.
En cas d’échec : Publiez SPF pour le domaine de votre en-tête From, pas uniquement pour le domaine de rebond fourni par votre plateforme.
Coûte jusqu’à 5 points sur 100 dans notre score et jusqu’à 0.5 sur 10 dans le score classique.
RFC 4406 §4 — Record Selection
After the above steps, there should be one record remaining and evaluation can proceed.
SPF auth.spf
SPF est un enregistrement DNS qui répertorie les serveurs autorisés à envoyer des messages pour votre domaine. Le serveur destinataire prend l’adresse dans l’enveloppe, recherche l’enregistrement de ce domaine et vérifie si l’IP qui se connecte y figure. Nous indiquons le résultat et le nombre de recherches DNS nécessaires à l’enregistrement, car l’évaluation s’arrête à dix et tout dépassement constitue une erreur permanente plutôt qu’une réussite.
En cas d’échec : Publiez un enregistrement qui désigne votre plateforme d’envoi et rien d’autre. Si le vôtre est proche de la limite de dix recherches, aplatissez les inclusions que vous n’utilisez pas (un enregistrement qui réussit aujourd’hui commence à échouer le jour où un fournisseur ajoute sa propre inclusion).
Coûte jusqu’à 18 points sur 100 dans notre score et jusqu’à 1 sur 10 dans le score classique.
RFC 7208 §4.6.4 — DNS Lookup Limits
SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return "permerror".
RFC 7208 §2.6 — Results of Evaluation
Section 4 defines check_host(), a model function definition that uses the inputs defined above and the sender's policy published in the DNS to reach a conclusion about client authorization.
Google — Set up SPF
Google — Sender guidelines FAQ: rules for 5,000+ messages a day
Alignement SPF auth.spf_alignment
Indique si l’adresse de rebond correspond à l’adresse From que voit le lecteur. SPF autorise l’enveloppe, et DMARC ne prend en compte cette autorisation que lorsque les deux sont alignées.
En cas d’échec : Demandez à votre plateforme d’envoi un sous-domaine de rebond appartenant à votre propre domaine. Si votre DKIM est déjà aligné, ce n’est pas urgent, mais vous n’aurez aucune solution de repli si DKIM est rompu pendant le transit.
Coûte jusqu’à 5 points sur 100 dans notre score et jusqu’à 0.5 sur 10 dans le score classique.
RFC 9989 §4.4.2 — SPF-Authenticated Identifiers
Only an SPF-Authenticated Identifier that has Identifier Alignment with the Author Domain is enough to validate the authorized use of the Author Domain.
RFC 9989 §5.3.5 — Determine DMARC "Pass" or "Fail"
If one or more of the Authenticated Identifiers align with the Author Domain, the message is considered to pass the DMARC mechanism check.
Google — Set up DMARC
Google — Sender guidelines FAQ: rules for 5,000+ messages a day
Infrastructure et réputation
La machine et l’adresse depuis lesquelles le message a été envoyé, ainsi que ce que le reste d’Internet pense déjà d’elles.
Résolution du nom d’hôte d’envoi infra.a_record
Indique si le nom d’hôte annoncé lors du HELO possède un enregistrement d’adresse.
En cas d’échec : Publiez un enregistrement A pour le nom annoncé par votre serveur.
Coûte jusqu’à 5 points sur 100 dans notre score et jusqu’à 3 sur 10 dans le score classique.
RFC 5321 §5.1 — Locating the Target Host
If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.
Google — Set up MX records
Listes de blocage infra.dnsbl
Si l’IP d’envoi figure sur l’une des listes de blocage effectivement consultées par les serveurs de réception. Notre liste est vérifiée par rapport au point de test documenté de chaque zone plutôt que constituée à partir d’une recherche sur le web, car une zone inactive répond NXDOMAIN et cela est interprété comme « propre ».
En cas d’échec : Suivez la procédure de retrait sur le site de l’opérateur de la liste. Une inscription sur une zone majeure bloque immédiatement les messages, traitez-la donc avant tout autre élément de la page.
Coûte jusqu’à 25 points sur 100 dans notre score et jusqu’à 3 sur 10 dans le score classique.
RFC 5782 §2.1 — IP Address DNSxL
Each IPv4 address listed in the DNSxL has a corresponding DNS entry.
RFC 5782 §5 — Test and Contact Addresses
IPv4-based DNSxLs MUST contain an entry for 127.0.0.2 for testing purposes.
Google — Postmaster Tools: reputation and delivery errors
Google — Email sender guidelines
Nom HELO infra.helo
Le nom par lequel le serveur d’envoi s’annonce au début de la conversation SMTP. Il doit s’agir d’un domaine pleinement qualifié qui se résout.
En cas d’échec : Définissez le nom d’hôte de votre serveur de messagerie sur un nom réel de votre domaine, et non sur un identifiant de conteneur ou un nom interne.
Coûte jusqu’à 5 points sur 100 dans notre score.
RFC 5321 §4.1.1.1 — Extended HELLO (EHLO) or HELLO (HELO)
The argument clause contains the fully-qualified domain name of the SMTP client, if one is available.
Google — Email sender guidelines
Google — Sender guidelines FAQ: rules for 5,000+ messages a day
Enregistrement MX infra.mx
Indique si le domaine de votre en-tête From peut recevoir des messages. Sans cela, les réponses et les rejets n’ont nulle part où aller, et les filtres considèrent comme un mauvais signe un domaine d’envoi qui ne peut pas recevoir de messages.
En cas d’échec : Publiez un enregistrement MX pour le domaine depuis lequel vous envoyez, même s’il ne fait qu’acheminer les messages vers une boîte aux lettres que vous consultez une fois par mois.
Coûte jusqu’à 5 points sur 100 dans notre score et jusqu’à 3 sur 10 dans le score classique.
RFC 5321 §5.1 — Locating the Target Host
The lookup first attempts to locate an MX record associated with the name.
Google — Set up MX records
DNS inverse infra.rdns
Indique si l’IP d’envoi se résout en un nom d’hôte, et si ce nom d’hôte se résout à son tour vers la même IP. L’aller-retour est essentiel : un PTR pointant n’importe où est facile à créer, une paire correspondante prouve que l’adresse vous appartient.
En cas d’échec : Demandez au propriétaire de l’IP de définir le PTR sur un nom que vous contrôlez, et vérifiez que ce nom possède un enregistrement A pointant vers cette IP.
Coûte jusqu’à 12 points sur 100 dans notre score et jusqu’à 1.5 sur 10 dans le score classique.
RFC 1912 §2.1 — Inconsistent, Missing, or Bad Data
Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain.
Google — Email sender guidelines
Google — Sender guidelines FAQ: rules for 5,000+ messages a day
Chiffrement du transport infra.tls
Indique si le message est arrivé via TLS, et avec quelle suite cryptographique. Tous les systèmes modernes le négocient ; un message arrivé en clair révèle un problème dans la configuration d’envoi.
En cas d’échec : Activez STARTTLS sur le serveur d’envoi. Toutes les plateformes courantes le font déjà, donc un échec à ce niveau indique généralement la présence d’un relais auto-hébergé sur le trajet.
Coûte jusqu’à 5 points sur 100 dans notre score.
RFC 3207 §2 — STARTTLS Extension
The STARTTLS extension to SMTP is laid out as follows:
Google — Send email over a secure TLS connection
Google — Sender guidelines FAQ: rules for 5,000+ messages a day
Moteurs antispam
Ce que les filtres de contenu indépendants pensent du message. Deux moteurs plutôt qu’un, car le score d’un seul moteur représente l’opinion de ce moteur.
Juge IA spam.ai_judge
Un modèle estime comment un filtre moderne fondé sur l’apprentissage automatique traiterait le message, à partir des constats techniques et des mesures du contenu. Il voit les faits, pas le texte du corps du message.
En cas d’échec : Détail uniquement lorsqu’il est considéré séparément. Son estimation alimente le verdict combiné ci-dessous.
Affiché à titre informatif. Jamais pris en compte dans le score.
Verdict combiné spam.panel
Un seul score issu des moteurs qui ont répondu, pondéré de sorte que l’avis le plus marqué ne soit pas simplement dilué dans la moyenne. SpamAssassin et Postmark comptent comme un seul vote parce qu’ils partagent une base de règles.
En cas d’échec : Traitez les constats individuels. Cette ligne évolue lorsqu’ils évoluent.
Coûte jusqu’à 25 points sur 100 dans notre score.
Google — Why Gmail marks messages as spam
How this score is calculated
Postmark SpamCheck spam.postmark
Un troisième avis, désactivé par défaut. Son point de terminaison reçoit le message entier et nous ne pouvons en masquer aucune partie sans fausser la mesure, donc l’activer signifie accepter que chaque message testé soit copié vers un tiers.
En cas d’échec : Rien à faire. Lorsque cette vérification est désactivée, elle indique qu’elle est désactivée, ce qui n’équivaut pas à une réussite.
Affiché à titre informatif. Jamais pris en compte dans le score.
Rspamd spam.rspamd
Un second filtre, développé indépendamment. Il diverge suffisamment souvent de SpamAssassin pour qu’il soit utile de le consulter, raison pour laquelle il figure ici.
En cas d’échec : Détail uniquement. L’avis de ce moteur est intégré au verdict combiné plutôt qu’évalué séparément.
Affiché à titre informatif. Jamais pris en compte dans le score.
SpamAssassin spam.spamassassin
Le filtre classique fondé sur des règles, qui reste le moteur de la plupart des outils de test d’e-mails. Chaque règle déclenchée est répertoriée avec son poids.
En cas d’échec : Examinez les règles déclenchées plutôt que le total. La plupart sont faciles à corriger une fois que vous savez lesquelles sont concernées.
Coûte jusqu’à 3 sur 10 dans le score classique.
Google — Why Gmail marks messages as spam
Apache SpamAssassin — rule documentation
Contenu
Le message lui-même : sa structure, ses liens, ses images, les éléments qu’un filtre analyse avant de prendre sa décision.
Texte alternatif des images content.alt_attributes
Si les images comportent des attributs alt. Les clients de messagerie bloquent par défaut les images distantes, donc pendant les premières secondes, le texte alternatif constitue votre message.
En cas d’échec : Rédigez un texte alternatif qui transmet le sens, et ne laissez jamais le visuel principal sans texte alternatif.
Coûte jusqu’à 4 points sur 100 dans notre score et jusqu’à 0.5 sur 10 dans le score classique.
Google — Email sender guidelines
Disponibilité des liens content.broken_links
Si les liens du message aboutissent. Un lien mort dans une newsletter fait immédiatement perdre la confiance, et les filtres le remarquent aussi.
En cas d’échec : Corrigez-les ou supprimez-les. Vérifiez également le domaine de suivi : s’il a expiré, tous les liens cessent de fonctionner en même temps.
Coûte jusqu’à 5 points sur 100 dans notre score et jusqu’à 1 sur 10 dans le score classique.
Google — Why Gmail marks messages as spam
Script et iframe content.forbidden_tags
Si le HTML contient des balises qu’aucun client de messagerie n’exécutera. Au mieux, elles sont supprimées et, au pire, elles sont traitées comme un signal de contournement.
En cas d’échec : Supprimez script, iframe, object et embed. Tout élément interactif doit se trouver derrière un lien.
Coûte jusqu’à 10 points sur 100 dans notre score et jusqu’à 1 sur 10 dans le score classique.
Google — Email sender guidelines
Équilibre texte-HTML content.html_text_ratio
La proportion de balisage dans le message par rapport au texte lisible. Une page de balisage autour d’une seule phrase est une forme que les filtres reconnaissent.
En cas d’échec : Rédigez une partie texte qui dit la même chose que le HTML, plutôt qu’un texte de remplacement.
Coûte jusqu’à 3 points sur 100 dans notre score et jusqu’à 0.3 sur 10 dans le score classique.
RFC 2046 §5.1.4 — Alternative Subtype
Systems should recognize that the content of the various parts are interchangeable.
Google — Why Gmail marks messages as spam
Parties texte et HTML content.html_version
Si le message contient une version en texte brut en plus du HTML. Certains filtres tiennent compte de son absence, et chaque lecteur d’écran en a besoin.
En cas d’échec : Envoyez un message multipart/alternative avec une véritable version texte, et non une partie vide ou une ligne indiquant de l’afficher dans un navigateur.
Coûte jusqu’à 5 points sur 100 dans notre score.
RFC 2046 §5.1.4 — Alternative Subtype
The "multipart/alternative" type is syntactically identical to "multipart/mixed", but the semantics are different. In particular, each of the body parts is an "alternative" version of the same information.
Google — Email sender guidelines
Taille du HTML content.html_weight
La taille de la partie HTML. Gmail tronque un message au-delà d’environ 102 Ko et masque le reste derrière un lien, ce qui emporte aussi votre pied de page de désabonnement.
En cas d’échec : Réduisez le CSS en ligne et les blocs de style répétés (la plupart des modèles tiennent dans un tiers de la limite une fois les règles inutilisées supprimées).
Coûte jusqu’à 3 points sur 100 dans notre score et jusqu’à 0.3 sur 10 dans le score classique.
Google — Email sender guidelines
Poids des images content.images_weight
La taille totale des images chargées par le message. Les images lourdes ralentissent l’affichage d’un message sur un téléphone, et les messages composés uniquement d’images ont une forme que les filtres considèrent comme suspecte.
En cas d’échec : Compressez-les et assurez-vous que le message reste lisible lorsque les images sont désactivées.
Coûte jusqu’à 3 points sur 100 dans notre score et jusqu’à 0.3 sur 10 dans le score classique.
Google — Email sender guidelines
Destination des liens affichés content.link_mismatch
Compare le domaine affiché à la destination après les redirections HTTP. Un domaine de suivi intermédiaire ne prouve pas une tromperie.
En cas d’échec : Utilisez le domaine de destination ou un texte descriptif. Une destination inaccessible reste non vérifiée.
Coûte jusqu’à 3 points sur 100 dans notre score.
Google — Email sender guidelines
Réputation des liens content.malicious_links
Vérifie les URL dans les listes de menaces. Une correspondance ne signifie pas que chaque destinataire bloquera le message.
En cas d’échec : Examinez les destinations signalées et remplacez ou retirez les liens dangereux. Un historique ne prouve pas une infection actuelle.
Coûte jusqu’à 40 points sur 100 dans notre score.
Google — Why Gmail marks messages as spam
Analyse des pièces jointes content.malware
Si les pièces jointes contiennent des logiciels malveillants connus. Sur les déploiements où l’analyseur est désactivé, ce contrôle indique qu’il n’a pas été exécuté plutôt que de signaler l’absence de menace.
En cas d’échec : Si ce contrôle se déclenche, arrêtez les envois et déterminez ce qui se trouve sur la machine qui a généré le message.
Coûte jusqu’à 60 points sur 100 dans notre score.
Google — Why Gmail marks messages as spam
ClamAV — how detection works
Objet content.subject
La longueur, l’emploi des majuscules et les motifs évalués par les filtres. Nous mesurons l’objet décodé, de sorte qu’un objet en cyrillique ou en CJK est évalué comme du texte plutôt que comme son encodage.
En cas d’échec : Limitez-le à environ 60 caractères, supprimez les majuscules excessives et les points d’exclamation.
Coûte jusqu’à 3 points sur 100 dans notre score.
RFC 5322 §2.2 — Header Fields
Header fields are lines beginning with a field name, followed by a colon (":"), followed by a field body, and terminated by CRLF.
RFC 2047 §2 — Syntax of encoded-words
An 'encoded-word' is defined by the following ABNF grammar.
Google — Why Gmail marks messages as spam
Liens raccourcis content.url_shortener
Si les liens passent par un raccourcisseur public. Les raccourcisseurs masquent la destination, ce qui correspond exactement à ce dont les filtres sont entraînés à se méfier.
En cas d’échec : Utilisez un lien vers votre propre domaine, ou le domaine de suivi de votre plateforme sur l’un de vos sous-domaines.
Coûte jusqu’à 5 points sur 100 dans notre score et jusqu’à 0.5 sur 10 dans le score classique.
Google — Why Gmail marks messages as spam
Règles pour les expéditeurs en nombre
Les exigences publiées par Gmail et Yahoo pour toute personne envoyant des messages en volume. Elles s’appliquent aux envois en nombre et sont ignorées pour les messages qui ne semblent pas en faire partie.
Politique DMARC publiée compliance.dmarc_present
Indique si le domaine From publie un enregistrement DMARC, indépendamment du fait que ce message l'ait validé ou non. Gmail et Yahoo l'exigent des expéditeurs en masse.
En cas d’échec : Publiez un enregistrement. p=none suffit à satisfaire l'exigence et vous fournit des rapports sur lesquels vous appuyer.
Coûte jusqu’à 6 points sur 100 dans notre score.
RFC 9989 §4.7 — DMARC Policy Record Format
If this tag is not present in an otherwise syntactically valid DMARC Policy Record, then the record is treated as if it included "p=none".
Google — Sender guidelines FAQ: rules for 5,000+ messages a day
Yahoo — Sender requirements and recommendations
List-Unsubscribe compliance.list_unsubscribe
Indique si le message comporte un en-tête de désinscription qu'un client de messagerie peut utiliser. Gmail et Yahoo l'exigent des expéditeurs en nombre, et son absence est filtrée indépendamment de tout le reste. La règle concerne les mailings. Une lettre qui demande au destinataire de confirmer un abonnement, ou lui indique que celui-ci a bien été pris en compte, est envoyée à une seule personne au sujet d'une action qu'elle vient d'effectuer ; CAN-SPAM appelle cela un message transactionnel ou relationnel, et ni Gmail ni Yahoo n'exige d'en-tête de désinscription pour ce type de message. Ce contrôle lit donc d'abord la lettre. Une confirmation d'abonnement, une lettre de bienvenue, une lettre transactionnelle ou une notification sans en-têtes de liste n'est pas pénalisée, et le rapport indique comment la lettre a été interprétée. Une lettre de bienvenue complétée par des offres constitue en pratique le premier numéro du mailing ; sans en-têtes de liste, le contrôle ne peut pas distinguer les deux, et il ne pénalise pas sur la base d'une supposition. Si la lettre comporte List-Unsubscribe ou List-Id, vous l'avez vous-même déclarée comme courrier de liste, et le contrôle s'exécute comme il l'a toujours fait.
En cas d’échec : Ajoutez un en-tête List-Unsubscribe avec un URI HTTPS. Toutes les plateformes d'envoi peuvent le faire.
Coûte jusqu’à 10 points sur 100 dans notre score et jusqu’à 1 sur 10 dans le score classique.
RFC 2369 §3.2 — List-Unsubscribe
The List-Unsubscribe field describes the command (preferably using mail) to directly unsubscribe the user (removing them from the list).
Google — Sender guidelines FAQ: rules for 5,000+ messages a day
Yahoo — Sender requirements and recommendations
Désinscription en un clic compliance.one_click_unsubscribe
La forme la plus stricte : un URI HTTPS, un en-tête « List-Unsubscribe-Post » et une seule signature DKIM valide couvrant les deux en-têtes. Les trois sont nécessaires, sinon le destinataire n'affiche pas le bouton. Comme le contrôle List-Unsubscribe, ce contrôle s'applique aux mailings, pas à une confirmation ni à une lettre de bienvenue.
En cas d’échec : L'oubli habituel concerne la signature : les plateformes signent « List-Unsubscribe » et oublient « List-Unsubscribe-Post ». Les noms des deux en-têtes doivent apparaître dans l'attribut h= de la même signature.
Coûte jusqu’à 8 points sur 100 dans notre score.
RFC 8058 §4 — Additional Requirements
The List-Unsubscribe and List-Unsubscribe-Post headers MUST be covered by the signature and included in the "h=" tag of a valid DKIM-Signature header field.
RFC 8058 §3.1 — Mail Senders
The List-Unsubscribe header field MUST contain one HTTPS URI.
Google — Sender guidelines FAQ: rules for 5,000+ messages a day
Yahoo — Sender requirements and recommendations
TLS pour les envois en masse compliance.tls_required
Indique si le message est arrivé chiffré. Ce point est couvert par le contrôle de l'infrastructure lorsque celui-ci a déjà été exécuté.
En cas d’échec : Consultez le contrôle du chiffrement du transport ci-dessus.
Coûte jusqu’à 5 points sur 100 dans notre score.
Google — Send email over a secure TLS connection
Google — Sender guidelines FAQ: rules for 5,000+ messages a day
Recommandations
Utile à faire et jamais pris en compte dans le score. Rien dans cette section ne peut coûter de points, ce qui est une décision de produit appliquée par les tests.
BIMI advisory.bimi
Indique si le domaine publie un enregistrement BIMI, qui affiche un logo à côté de vos messages dans certains clients. Cela nécessite d'abord une politique DMARC appliquée, ainsi qu'un certificat de marque vérifiée payant.
En cas d’échec : Cela vaut la peine une fois que DMARC est défini sur quarantaine ou rejet et que le volume justifie le certificat.
Recommandation. Ne coûte rien.
BIMI — draft specification, not yet an RFC
Âge et longueur de la clé DKIM advisory.dkim_key_rotation
La longueur de la clé de signature et sa durée d’utilisation. Les clés courtes deviennent chaque année moins coûteuses à attaquer hors ligne.
En cas d’échec : Passez à 2048 bits et effectuez une rotation selon un calendrier défini. Publiez le nouveau sélecteur, utilisez-le ensuite pour la signature, puis retirez l’ancien.
Recommandation. Ne coûte rien.
RFC 8301 §3.2 — Key Sizes
Since short RSA keys more easily succumb to off-line attacks, Signers MUST use RSA keys of at least 1024 bits for all keys. Signers SHOULD use RSA keys of at least 2048 bits.
Google — Set up DKIM
Livraison des rapports DMARC advisory.dmarc_reporting
Si les adresses de votre enregistrement DMARC recevront réellement quelque chose. Si une adresse de rapport se trouve en dehors de votre propre domaine, RFC 9990 impose à ce domaine de publier d’abord sa propre autorisation, sous forme d’enregistrement TXT à l’emplacement your-domain._report._dmarc.their-domain. Sans cet enregistrement, un destinataire ignore l’adresse : aucun rejet, aucune erreur, aucun rapport. Il s’agit de la configuration habituelle plutôt que d’un cas inhabituel, car l’adresse se trouve normalement chez un fournisseur de supervision, ou sur votre domaine principal tandis que la politique se trouve sur un sous-domaine d’envoi. La même règle couvre les rapports d’échec, RFC 9991 renvoyant à la même procédure pour la balise ruf. Nous recherchons les mêmes enregistrements qu’un destinataire et vous indiquons les noms que nous avons interrogés.
En cas d’échec : Demandez à la personne qui gère le domaine de destination de publier un enregistrement TXT contenant v=DMARC1 au nom indiqué dans le constat. Les fournisseurs de supervision le font généralement pour vous une fois que vous ajoutez le domaine à leur compte. Par conséquent, si l’enregistrement est absent, le domaine n’a probablement jamais été ajouté de leur côté. Si les rapports sont plutôt envoyés vers votre propre domaine, aucune action n’est nécessaire.
Recommandation. Ne coûte rien.
RFC 9990 §4 — Verifying External Destinations
When a Mail Receiver discovers a DMARC Policy Record in the DNS, and the Organizational Domain at which that record was discovered is not identical to the Organizational Domain of the host part of the authority component of a [RFC3986] specified in the "rua" tag, the following verification steps MUST be taken:
RFC 9990 §4 — Verifying External Destinations
Where the above algorithm fails to confirm that the external reporting was authorized by the Report Consumer, the URI MUST be ignored by the Mail Receiver generating the report.
RFC 9991 §5 — Verifying External Destinations
In case of external destinations, a Mail Receiver who generates failure reports MUST use the Verifying External Destinations procedure described in Section 4 of [RFC9990], substituting the "ruf" tag where the "rua" tag appears in that procedure.
Google — Set up DMARC
DNSSEC advisory.dnssec
Indique si le domaine est signé. SPF, DKIM et DMARC se trouvent tous dans DNS, donc un attaquant capable de falsifier les réponses DNS peut falsifier les trois.
En cas d’échec : Activez-le auprès de votre bureau d’enregistrement. Il s’agit généralement d’une seule option, et le bureau d’enregistrement s’occupe du reste.
Recommandation. Ne coûte rien.
RFC 4033 §2 — Definitions of Important DNSSEC Terms
Authentication Chain: An alternating sequence of DNS public key (DNSKEY) RRsets and Delegation Signer (DS) RRsets
MTA-STS advisory.mta_sts
Indique si le domaine publie une politique demandant aux autres serveurs de refuser les livraisons non chiffrées vers votre domaine. Elle protège les messages qui vous sont envoyés plutôt que ceux que vous envoyez.
En cas d’échec : Publiez l'enregistrement TXT et le fichier de politique via HTTPS (une demi-journée de travail, et cela neutralise une attaque par rétrogradation).
Recommandation. Ne coûte rien.
RFC 8461 §3 — Policy Discovery
To discover if a recipient domain implements MTA-STS, a sender need only resolve a single TXT record.
Longueur du chemin de retour advisory.return_path_length
La longueur de l’adresse de rebond. La RFC 5321 oblige un serveur destinataire à accepter 64 octets avant le @, et indique dans la même section qu’aucune implémentation ne devrait imposer une limite qu’elle peut éviter. Beaucoup en imposent tout de même une, et un message qui dépasse la limite est refusé lors de MAIL FROM, avant même l’envoi du corps. Les plateformes d’envoi rencontrent ce problème lorsqu’elles encodent le destinataire dans le chemin de retour afin de pouvoir associer les rebonds, ce qui fait dépendre la longueur de votre destinataire plutôt que de vous.
En cas d’échec : Raccourcissez la partie fixe que votre plateforme ajoute en préfixe, ou utilisez un domaine de rebond plus court. Si vous ne pouvez modifier ni l’un ni l’autre, les adresses à risque sont celles de vos abonnés les plus longues, il est donc utile de mesurer la plus longue de votre liste plutôt qu’une moyenne.
Recommandation. Ne coûte rien.
RFC 5321 §4.5.3.1.1 — Local-part
The maximum total length of a user name or other local-part is 64 octets.
RFC 5321 §4.5.3.1 — Size Limits and Minimums
Every implementation MUST be able to receive objects of at least these sizes.
Haraka — the address parser that enforces the 64-octet local-part, and the flag that relaxes it
Rapports TLS advisory.tls_rpt
Indique si le domaine demande des rapports lorsque quelqu’un ne parvient pas à lui remettre un message via TLS. Fonctionne avec MTA-STS : sans rapports, la politique ne permet pas de savoir si elle fonctionne.
En cas d’échec : Ajoutez l’enregistrement TXT avec une adresse qui reçoit les rapports quotidiens.
Recommandation. Ne coûte rien.
RFC 8460 §3 — Reporting Policy
A domain publishes a record to its DNS indicating that it wishes to receive reports.