Configurer SPF, DKIM et DMARC dans AWS Route 53

AWS Route 53 est un endroit rapide et fiable pour publier les trois enregistrements DNS qui authentifient vos e-mails — SPF, DKIM et DMARC — mais sa console comporte quelques conventions qui déroutent : les noms d'enregistrement pleinement qualifiés et l'obligation d'entourer de guillemets chaque valeur TXT. Les enregistrements eux-mêmes sont identiques à ce que vous publieriez chez n'importe quel hébergeur DNS ; seul l'éditeur change. Ce guide vous montre exactement où, dans la console Route 53, ajouter chaque enregistrement, ce qu'il faut saisir dans le champ « Nom d'enregistrement » pour le domaine racine, pour _dmarc et pour votre sélecteur DKIM, ainsi que la seule particularité de guillemets qui casse silencieusement les longues clés DKIM si vous la manquez.

La réponse en bref#

Les trois enregistrements sont de simples enregistrements TXT au sein de votre zone hébergée Route 53. Ce qui diffère d'un hébergeur à l'autre, ce n'est que la convention de nommage et le format de saisie :

• SPF — un enregistrement TXT à la racine de votre domaine. Dans Route 53, vous laissez le champ « Nom d'enregistrement » vide, et l'enregistrement s'applique à l'apex de la zone.
• DKIM — un enregistrement TXT à <selector>._domainkey.yourdomain.com. Vous saisissez uniquement la partie <selector>._domainkey dans le champ « Nom d'enregistrement » ; le sélecteur et la longue valeur de clé proviennent tous deux de votre fournisseur d'e-mail.
• DMARC — un enregistrement TXT à _dmarc.yourdomain.com. Vous saisissez _dmarc dans le champ « Nom d'enregistrement » et Route 53 ajoute la zone pour vous.

Les valeurs sont propres à chaque fournisseur, ne les rédigez donc pas à la main. Générez votre ligne SPF avec le générateur d'enregistrement SPF, votre ligne de politique avec le générateur d'enregistrement DMARC, et copiez votre clé DKIM directement depuis le tableau de bord de votre plateforme d'e-mail. Pour les concepts derrière chaque enregistrement, l'explication de SPF, DKIM et DMARC détaille leur rôle et leur importance.

Comment SPF, DKIM et DMARC correspondent aux enregistrements Route 53#

Route 53 organise le DNS autour d'une zone hébergée — une zone par domaine. Au sein d'une zone, chaque enregistrement porte un nom pleinement qualifié relatif à l'apex de la zone, et la console le rend explicite : à côté de la case « Nom d'enregistrement », elle affiche le suffixe de votre domaine, et tout ce que vous saisissez y est ajouté en préfixe. Ce seul détail explique l'emplacement des trois enregistrements.

Où ajouter les enregistrements dans la console Route 53#

Le chemin est le même pour les trois enregistrements. Ouvrez la console Route 53, choisissez Zones hébergées dans la navigation de gauche, et cliquez sur la zone du domaine depuis lequel vous envoyez du courrier. Cliquez sur Créer un enregistrement, et si la console propose un choix entre « Création rapide » et « Assistant », la création rapide est la voie la plus simple pour une seule entrée TXT.

Dans le formulaire de création d'enregistrement, vous renseignez trois éléments : le Nom d'enregistrement (le préfixe, selon le tableau ci-dessus), le Type d'enregistrement (TXT pour les trois), et la Valeur. Laissez la politique de routage sur la valeur par défaut « Routage simple » — ce sont de simples enregistrements informatifs, pas du routage de trafic. Le TTL peut rester à sa valeur par défaut (300 ou 3600 secondes conviennent) ; un TTL plus court signifie simplement que les modifications se propagent plus vite pendant vos tests.

Publier votre enregistrement SPF au domaine racine#

SPF autorise quels serveurs peuvent envoyer du courrier au nom de votre domaine. Créez un enregistrement TXT, laissez le nom d'enregistrement vide pour qu'il se place sur le domaine racine, et collez votre valeur SPF. Une valeur type ressemble à ceci :

"v=spf1 include:amazonses.com include:_spf.google.com ~all"

Notez les guillemets doubles qui l'entourent — Route 53 attend que les valeurs TXT soient entre guillemets, et la console les ajoute généralement si vous les oubliez, mais il est plus propre de les inclure vous-même. Le ~all à la fin est un soft-fail ; -all est un hard-fail qui indique aux destinataires de rejeter purement et simplement les expéditeurs non autorisés.

Deux règles comptent plus que tout le reste ici. Premièrement, publiez exactement un seul enregistrement SPF. Si un second enregistrement TXT à la racine commence lui aussi par v=spf1, le SPF devient invalide et toutes les vérifications échouent — donc si vous envoyez déjà via un autre service, fusionnez tous les mécanismes include: en une seule ligne plutôt que d'ajouter un nouvel enregistrement. Deuxièmement, restez sous la barre des dix résolutions DNS ; chaque include: compte, et dépasser cette limite provoque une erreur SPF permanente. Le générateur d'enregistrement SPF construit une seule ligne valide à partir des fournisseurs que vous utilisez réellement et signale pour vous la limite de résolutions.

Ajouter votre enregistrement DKIM au sélecteur#

DKIM publie la moitié publique d'une clé de signature pour que les destinataires puissent vérifier que vos messages n'ont été ni falsifiés ni altérés. Votre fournisseur d'e-mail vous donne deux choses : un sélecteur (une courte étiquette comme s1, google, ou une chaîne aléatoire) et la longue valeur de clé publique. Vous publiez cette clé sous forme d'enregistrement TXT à <selector>._domainkey.

Créez un enregistrement TXT, saisissez le sélecteur suivi de ._domainkey dans le champ « Nom d'enregistrement » — par exemple s1._domainkey — et collez la valeur fournie par votre fournisseur. La valeur ressemble à ceci :

"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

Ne modifiez pas et n'inventez pas cette valeur — copiez-la telle quelle depuis les paramètres d'authentification de votre plateforme d'e-mail, car la clé publique doit correspondre exactement à la clé privée qui effectue la signature. Certains fournisseurs (Amazon SES parmi eux) émettent trois enregistrements DKIM basés sur des CNAME au lieu d'un unique enregistrement TXT ; dans ce cas, créez trois enregistrements CNAME avec les noms et cibles qu'ils vous fournissent, en suivant la même règle « saisissez le préfixe, Route 53 ajoute la zone ». Quelle que soit la forme utilisée par votre fournisseur, les valeurs viennent de lui, jamais de vous.

Publier votre enregistrement DMARC à _dmarc#

DMARC relie SPF et DKIM à l'adresse « De » visible, indique aux destinataires quoi faire du courrier qui échoue, et vous envoie des rapports. Créez un enregistrement TXT, saisissez _dmarc dans le champ « Nom d'enregistrement », et collez une politique de départ :

"v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Commencez à p=none. C'est le mode surveillance — il ne change rien à la manière dont votre courrier est traité, mais il active les rapports agrégés quotidiens qui rendent un déploiement sûr possible. Ce n'est qu'une fois que les rapports confirment que chaque flux légitime s'authentifie en alignement que vous devriez resserrer vers p=quarantine puis p=reject. Publier p=reject dès le premier jour est le moyen le plus rapide d'envoyer votre propre courrier au spam. Le générateur d'enregistrement DMARC construit une politique syntaxiquement correcte, et le guide complet de déploiement DMARC étape par étape détaille la séquence surveiller-puis-appliquer ; une fois que les rapports commencent à arriver, la lecture des rapports agrégés DMARC explique comment en tirer parti.

La particularité des guillemets qui casse les longues clés DKIM#

Voilà le détail propre à Route 53 sur lequel il vaut la peine de ralentir, car il échoue silencieusement. Une seule chaîne TXT DNS est limitée à 255 caractères. Les valeurs courtes — votre ligne SPF, votre politique DMARC — tiennent confortablement dans une seule chaîne entre guillemets. Mais une clé publique DKIM de 2048 bits dépasse 255 caractères, elle ne peut donc pas tenir dans une seule chaîne.

La réponse de Route 53 consiste à fractionner la valeur en plusieurs chaînes entre guillemets, chacune de 255 caractères ou moins, placées ensemble dans la même valeur d'enregistrement. Les résolveurs DNS reconcatènent les chaînes en une seule clé. Dans la case « Valeur » de la console, cela ressemble à deux chaînes entre guillemets adjacentes :

"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...up-to-255-chars"
"...the-remaining-characters-of-the-public-key"

Le piège : les deux chaînes se concatènent en une seule clé continue sans espace entre elles, donc n'ajoutez pas de caractères à l'endroit du fractionnement, et gardez les deux chaînes dans une seule valeur d'enregistrement TXT plutôt que de les laisser devenir deux enregistrements distincts. Si votre vérification DKIM échoue juste après la configuration et que la clé semble complète, un fractionnement incorrect est le coupable habituel. Collez la clé entière, laissez la console ou votre outillage gérer le découpage là où c'est possible, et vérifiez le résultat plutôt que de lui faire confiance.

Gérer les enregistrements sous forme de code#

Route 53 est un favori des équipes qui exploitent l'infrastructure sous forme de code, et vous n'êtes pas obligé d'utiliser la console du tout. La CLI AWS publie les enregistrements avec aws route53 change-resource-record-sets, en passant un lot de modifications JSON qui spécifie le nom, le type TXT, le TTL et la valeur. Dans Terraform, chaque enregistrement est une ressource aws_route53_record :

resource "aws_route53_record" "dmarc" {
  zone_id = aws_route53_zone.primary.zone_id
  name    = "_dmarc.example.com"
  type    = "TXT"
  ttl     = 3600
  records = ["v=DMARC1; p=none; rua=mailto:dmarc@example.com"]
}

Les mêmes règles se reportent : un enregistrement SPF à l'apex, la valeur DKIM directement issue de votre fournisseur, DMARC démarrant à p=none. La limite de 255 caractères par chaîne s'applique ici aussi — une longue clé DKIM doit toujours être découpée en plusieurs chaînes au sein de la valeur d'enregistrement, alors appliquez l'enregistrement et vérifiez le résultat publié.

Vérifiez avant d'appliquer#

Les modifications DNS dans Route 53 se propagent généralement en une minute ou deux, même si votre TTL et les caches en aval peuvent allonger ce délai. Une fois les enregistrements en ligne, confirmez que les trois se résolvent et s'analysent correctement avec le vérificateur SPF, DKIM et DMARC — il signale un enregistrement SPF manquant ou en double, une clé DKIM fractionnée ou collée de travers, et une politique DMARC comportant une erreur de syntaxe, qui sont les trois choses les plus susceptibles de mal tourner sur Route 53. Ce n'est qu'une fois le vérificateur au vert que vous devriez commencer à faire progresser la politique DMARC de none vers reject.

Publier les trois et les faire passer, c'est ce qui satisfait les exigences des expéditeurs de Google et Yahoo pour les expéditeurs en masse. Mais gardez la frontière à l'esprit : l'authentification prouve qui vous êtes, pas que vous êtes un bon expéditeur. Un message parfaitement authentifié adressé à une liste pleine d'adresses mortes atterrit tout de même dans le spam. Le guide de délivrabilité des e-mails couvre le travail de réputation et d'hygiène de liste qui transforme une identité de confiance en placement en boîte de réception.

Foire aux questions#

Que dois-je saisir dans le champ « Nom d'enregistrement » de Route 53 pour l'enregistrement SPF racine ?#

Laissez-le vide. Route 53 applique un enregistrement au nom vide à l'apex de la zone — le domaine racine lui-même — c'est-à-dire précisément là où doit se trouver l'enregistrement TXT SPF. Réglez le type sur TXT et collez votre unique valeur v=spf1 .... Ne saisissez pas @ ni le nom de votre domaine dans le champ ; un nom d'enregistrement vide est la manière dont Route 53 exprime la racine.

Pourquoi mon enregistrement DKIM échoue-t-il dans Route 53 alors que la clé semble correcte ?#

Presque toujours à cause de la limite de 255 caractères par chaîne. Une clé DKIM de 2048 bits est trop longue pour une seule chaîne TXT, si bien que Route 53 exige de la fractionner en plusieurs chaînes entre guillemets que les résolveurs concatènent. Si le fractionnement ajoute un espace parasite, supprime un caractère, ou si les morceaux finissent en deux enregistrements distincts au lieu d'une seule valeur, la clé ne sera pas validée. Recollez la clé entière, conservez-la comme une valeur d'enregistrement unique, et vérifiez-la avec un outil de contrôle DKIM.

Dois-je saisir _dmarc ou le nom complet _dmarc.example.com dans le nom d'enregistrement ?#

Saisissez uniquement _dmarc. Route 53 affiche le suffixe de votre domaine à côté du champ et l'ajoute automatiquement, si bien que _dmarc devient _dmarc.example.com. Saisir le nom complet produirait un doublon _dmarc.example.com.example.com, qu'aucun destinataire n'interrogera jamais. La même règle de préfixage s'applique à votre sélecteur DKIM.

Puis-je gérer SPF, DKIM et DMARC dans Route 53 avec Terraform ou la CLI ?#

Oui. Chaque enregistrement est une ressource aws_route53_record dans Terraform ou un lot de modifications pour aws route53 change-resource-record-sets dans la CLI. Les noms, types et valeurs des enregistrements sont identiques à ce que vous saisiriez dans la console, et le même fractionnement à 255 caractères pour les longues clés DKIM s'applique. Générez d'abord les valeurs, puis validez-les dans votre code et vérifiez le résultat publié.

Route 53 rend les trois enregistrements simples une fois que vous connaissez ses conventions de nommage et de guillemets — mais l'authentification n'est que le ticket d'entrée vers la boîte de réception. Construisez vos enregistrements avec les outils gratuits, puis nettoyez la liste qui se trouve derrière eux avec le vérificateur d'e-mails gratuit : il détecte les domaines morts, les fautes de frappe et les pièges à spam avant qu'ils ne rebondissent, car une identité de confiance ne mérite un placement que lorsque la liste pour laquelle elle signe est propre.