DKIM, SPF & DMARC

L'authentification email est la façon dont les serveurs de messagerie destinataires déterminent si un message provient réellement de votre domaine. Chaque enregistrement DNS que vous publiez pour un domaine d'envoi prouve une chose précise. DKIM prouve que le message a été signé par vous. Le return-path prouve que les rebonds transitent par une adresse alignée avec votre domaine. DMARC indique aux destinataires ce qu'ils doivent faire lorsque ces vérifications échouent. Cette page décrit chaque enregistrement que nous vous demandons de publier et ce qu'il prouve. Si vous n'avez pas encore ajouté de domaine d'envoi, commencez par Domaines d'envoi.

Ouvrez Email > Domains, puis sélectionnez votre domaine pour afficher les enregistrements à publier. Le API renvoie les mêmes enregistrements dans dns_records.

Trois enregistrements conditionnent l'envoi : DKIM, le CNAME return-path et DMARC. Le CNAME de tracking optionnel ne conditionne que le suivi de marque des ouvertures/clics et n'a aucun effet sur l'envoi.

DKIM est votre preuve de propriété et de signature. Nous générons une clé de signature pour votre organisation et signons chaque message que vous envoyez avec celle-ci ; la moitié publique est publiée sous forme d'enregistrement TXT sous un sélecteur unique à votre organisation. Les destinataires récupèrent la clé publique à partir de ce sélecteur et vérifient la signature, ce qui prouve que le message a été envoyé par quelqu'un ayant le contrôle du DNS de votre domaine. Et comme chaque organisation dispose de son propre sélecteur et de sa propre clé, votre preuve DKIM vous appartient exclusivement, même si un autre client envoie depuis le même domaine.

Le sélecteur et la clé publique sont générés pour vous ; copiez le host et la valeur exacts depuis le tableau de bord ou le API plutôt que de les construire manuellement. Nous détectons votre fournisseur DNS et formatons la valeur de la façon attendue par ce fournisseur, donc collez-la telle quelle. Si votre fournisseur rejette une longue valeur TXT sous forme de chaîne unique, le découpeur d'enregistrements DNS la divise en segments entre guillemets qu'il accepte.

L'enregistrement return-path définit votre domaine envelope-from (rebond). Les rebonds et les retours de livraison de vos messages sont adressés à ce nom d'hôte, et le faire pointer vers nous nous permet de les traiter pour vous. L'enregistrement fournit également l'alignement SPF. Les destinataires évaluent SPF par rapport au domaine envelope-from. Comme ce nom d'hôte résout vers notre infrastructure de rebond, SPF passe et s'aligne avec votre domaine sans aucun enregistrement à votre apex (voir Où est SPF ?).

Le host par défaut est send. sous votre domaine d'envoi, mais vous pouvez choisir un autre nom d'hôte. La valeur dépend de la région depuis laquelle votre espace de travail envoie ; copiez-la depuis le tableau de bord. Le guide du domaine de rebond explique comment personnaliser et modifier cet enregistrement.

DMARC publie votre politique : il indique aux destinataires ce qu'ils doivent faire des messages qui échouent à l'alignement DKIM ou SPF (p=none pour surveiller uniquement, p=quarantine ou p=reject pour appliquer), et où envoyer les rapports agrégés (rua). Nous exigeons qu'un enregistrement DMARC existe avant que le domaine puisse envoyer, et nous le vérifions en résolvant directement votre DNS. Un enregistrement sur le domaine lui-même ou un enregistrement hérité d'un domaine parent sont tous deux valides.

La valeur d'exemple est notre recommandation : p=none est une politique de départ sûre, et l'adresse rua achemine les rapports agrégés vers nous. Vous pouvez utiliser votre propre politique et adresse de rapport, puisque la condition exige seulement qu'un enregistrement DMARC valide existe ; le générateur de politique DMARC peut vous aider à en rédiger une. Si vous avez déjà un enregistrement DMARC, ou un enregistrement sur un domaine parent, vous n'avez pas besoin de le modifier. Si vous acheminez les rapports rua vers votre propre boîte de réception, l'analyseur de rapports DMARC transforme le XML brut en quelque chose de lisible.

L'enregistrement de tracking vous fournit un nom d'hôte de marque pour le suivi des ouvertures et des clics. Lorsque le suivi des clics est activé, les liens dans vos messages sont réécrits vers ce nom d'hôte au lieu d'un domaine partagé générique, ce qui est plus professionnel pour les destinataires et lie la réputation des liens à votre marque. Ce paramètre appartient à la configuration du domaine de votre espace de travail.

Cet enregistrement ne fait pas partie des conditions d'envoi : un domaine dont DKIM, le return-path et DMARC sont vérifiés peut envoyer même si l'enregistrement de tracking est absent. Il conditionne uniquement la disponibilité du suivi de marque des ouvertures/clics. Le guide du domaine de tracking explique comment le personnaliser et quels paramètres activent le suivi.

Vous n'avez pas besoin de publier un enregistrement SPF à l'apex de votre domaine (example.com), et le tableau de bord ne vous en demande pas. SPF est évalué par rapport au domaine envelope-from plutôt qu'à l'adresse From visible. Votre envelope-from est le nom d'hôte du return-path (send.example.com), et le CNAME return-path vérifié le fait pointer vers notre infrastructure de rebond, qui dispose déjà d'une autorisation SPF configurée. SPF passe, et s'aligne avec votre domaine parce que le return-path est un sous-domaine de celui-ci.

Ajouter une entrée include: à votre apex n'autorise pas les messages envoyés via nous. L'évaluation SPF limite le nombre de termes nécessitant une requête DNS à 10, évitez donc d'ajouter une recherche inutile. Si vous avez un enregistrement SPF existant à l'apex pour d'autres expéditeurs, ne le modifiez pas.

Nous vérifions votre DNS automatiquement après l'enregistrement du domaine, revérifions chaque domaine quotidiennement, et indiquons le statut par enregistrement sur la ressource domaine et le tableau de bord. Le cycle de vie complet, incluant les statuts, les revérifications à la demande et les règles de grâce qui empêchent une interruption DNS transitoire d'interrompre l'envoi, est couvert dans Domaines d'envoi § Cycle de vie de la vérification.