Domaines, DNS et e-mail transactionnel

Pourquoi

Jusqu'ici, Signalements était joignable par l'adresse IP de son répartiteur, et un enregistrement DNS créé à la main chez le registraire de la métropole pointait vers elle. Deux incidents ont montré les limites de cet arrangement. Le premier : en changeant de répartiteur, l'équipe a dû demander par ticket à la métropole de modifier l'enregistrement, et a attendu trois jours. Le second : les e-mails de notification, envoyés par l'instance avec le serveur SMTP d'un ancien prestataire, arrivaient dans les courriers indésirables des agents, quand ils arrivaient.

Le nom et le courrier sont deux faces de la même question : qui a autorité sur un nom de domaine, et comment le monde entier peut-il le vérifier. Le DNS dit où joindre un service ; le même DNS publie les preuves qui permettent à un serveur de messagerie de croire qu'un e-mail vient bien de vous. Cette leçon confie la zone DNS de Signalements à Scaleway, l'automatise, et utilise Transactional Email pour envoyer les notifications avec ces preuves.

Les concepts

Le fonctionnement du DNS (résolution récursive, serveurs faisant autorité, cache) fait l'objet du cours DNS en profondeur ; voici ce qu'il faut pour cette leçon.

Enregistrer un domaine, héberger sa zone

Deux métiers différents, souvent confondus parce qu'un même fournisseur fait les deux :

• Le registraire (registrar) enregistre le domaine auprès du registre de son extension (l'Afnic pour .fr, par exemple). C'est lui qui inscrit dans la zone parente quels serveurs font autorité pour votre domaine : les enregistrements NS.
• L'hébergeur DNS fait tourner ces serveurs, qui répondent avec le contenu de votre zone DNS : la liste des enregistrements (A, AAAA, CNAME, MX, TXT...) de votre domaine.

Scaleway Domains and DNS fait les deux, et distingue dans sa documentation :

• les domaines internes, enregistrés chez Scaleway, dont il est registraire ;
• les domaines externes, enregistrés ailleurs, dont vous confiez seulement la zone à Scaleway.

Pour un domaine externe, la procédure documentée se fait en deux temps : prouver que vous contrôlez le domaine en ajoutant, chez votre hébergeur DNS actuel, un enregistrement TXT nommé _scaleway-challenge avec un jeton fourni par Scaleway ; puis, une fois la preuve validée, remplacer chez votre registraire les serveurs de noms par ceux de Scaleway, ns0.dom.scw.cloud et ns1.dom.scw.cloud. La documentation donne quatorze jours pour aller au bout, et précise que le jeton doit être en place sous quarante-huit heures. Changer les serveurs de noms s'appelle une délégation.

Zones et sous-zones

Une zone peut être découpée : la zone example.com peut déléguer signalements.example.com à d'autres serveurs, par des enregistrements NS sur ce nom. Chez Scaleway, une zone gérée peut aussi contenir des sous-zones (scw dns zone create), chacune avec ses enregistrements, ce qui permet de donner à une équipe la gestion d'une partie du domaine.

Un cas fréquent n'est pas décrit par la documentation de Scaleway au 5 octobre 2026 : confier à Scaleway seulement un sous-domaine (signalements.example.com) d'un domaine dont la zone reste chez un autre hébergeur. Le mécanisme DNS le permet (des NS dans la zone parente), mais le parcours de Scaleway porte sur le domaine entier. Si la métropole veut garder sa zone, la solution documentée la plus simple est qu'elle crée les quelques enregistrements nécessaires chez elle, pointant vers des noms que vous maîtrisez.

TTL : la durée pendant laquelle on vous croit

Chaque enregistrement a un TTL (time to live), en secondes : la durée pendant laquelle un résolveur peut garder la réponse en cache sans redemander. La CLI de Scaleway propose 3 600 secondes par défaut.

La pratique : des TTL longs au quotidien, et un abaissement avant un changement prévu. Pour déplacer signalements.example.com vers un nouveau répartiteur, on passe le TTL à 300 secondes au moins un ancien TTL avant la bascule, on bascule, on vérifie, puis on remonte le TTL.

Les enregistrements qui comptent ici

• A et AAAA : un nom vers une adresse IPv4 ou IPv6.
• CNAME : un nom vers un autre nom. Il ne peut pas coexister avec d'autres enregistrements sur le même nom, ce qui l'interdit à l'apex de la zone (example.com lui-même). Scaleway propose un type ALIAS, qui se comporte comme un CNAME résolu côté serveur, utilisable à l'apex.
• MX : les serveurs qui reçoivent le courrier du domaine, avec une priorité.
• TXT : du texte libre, utilisé par SPF, DKIM, DMARC et les preuves de contrôle de domaine.
• CAA (RFC 8659) : les autorités de certification autorisées à émettre des certificats pour le domaine. Une autorité qui respecte la norme refuse d'émettre si elle n'est pas listée.

Les enregistrements dynamiques

Scaleway ajoute à A et AAAA (et pour certains à CNAME et ALIAS) quatre comportements, documentés dans la page de gestion des enregistrements :

Ce sont des outils de répartition par le DNS. Ils n'ont pas la finesse d'un répartiteur de charge : le client garde la réponse le temps du TTL, et un résolveur partagé par des milliers d'utilisateurs leur donne la même réponse. Une adresse retirée par la vérification de santé continue donc d'être utilisée par ceux qui l'ont en cache. On s'en sert pour basculer entre deux répartiteurs, pas pour remplacer un répartiteur (leçon 12).

DNSSEC

Le DNS d'origine n'authentifie rien : un attaquant capable d'injecter une fausse réponse dans le cache d'un résolveur détourne tous ses utilisateurs. DNSSEC (RFC 4033 à 4035) fait signer les enregistrements d'une zone par une clé ; le résolveur vérifie la signature, et remonte la chaîne de confiance grâce à un enregistrement DS publié dans la zone parente, jusqu'à la racine.

Chez Scaleway, le guide de la documentation décrit l'activation de DNSSEC pour les domaines internes, en un clic dans la console, l'enregistrement DS étant publié par Scaleway en tant que registraire. Pour un domaine externe dont la zone est chez Scaleway, le guide ne dit rien, mais la description de l'appel d'API correspondant (EnableDomainDNSSEC, commande scw domain domain enable-dnssec) précise qu'il faut alors publier vous-même l'enregistrement DS chez votre registraire. Désactiver DNSSEC peut prendre jusqu'à quarante-huit heures pour se propager, selon la même documentation : une désactivation mal ordonnée (retirer les signatures avant le DS) rend le domaine injoignable pour les résolveurs qui valident.

Prouver qu'un e-mail vient de vous

Le protocole SMTP laisse n'importe qui écrire n'importe quelle adresse d'expéditeur. Trois mécanismes, publiés dans le DNS, permettent aux serveurs destinataires de vérifier :

• SPF (RFC 7208) : un enregistrement TXT qui liste les serveurs autorisés à envoyer pour le domaine de l'enveloppe (v=spf1 include:_spf.tem.scaleway.com -all).
• DKIM (RFC 6376) : l'expéditeur signe chaque e-mail avec une clé privée ; la clé publique est publiée dans un TXT sous un nom de la forme <sélecteur>._domainkey.example.com. La signature prouve que le message n'a pas été modifié et qu'il vient de quelqu'un qui détient la clé.
• DMARC (RFC 7489) : un TXT sur _dmarc.example.com qui dit au destinataire quoi faire quand SPF et DKIM échouent ou ne correspondent pas à l'adresse visible (p=none, quarantine, reject), et où envoyer des rapports (rua).

DMARC ajoute la notion qui manquait aux deux autres : l'alignement. SPF vérifie le domaine de l'enveloppe, que le destinataire humain ne voit pas ; DMARC exige que SPF ou DKIM valide un domaine aligné avec celui de l'adresse From: affichée.

Transactional Email

Transactional Email (TEM) est le service d'envoi de Scaleway pour les e-mails déclenchés par une application : confirmation, réinitialisation de mot de passe, notification. Ce n'est pas un service de lettres d'information. Ses caractéristiques documentées au 5 octobre 2026 :

• disponible dans la seule région fr-par ;
• deux formules : Essential, à l'usage, avec un seul webhook par domaine ; Scale, forfaitaire, avec une adresse IP dédiée et un engagement de trente jours pour la « chauffer » ;
• un quota par défaut de 10 000 e-mails par mois, relevable par le support ; 10 destinataires et 10 pièces jointes par e-mail ; 2 Mo par e-mail par l'API, 50 Mo par SMTP ;
• chaque destinataire compte pour un e-mail : un message à une personne avec trois en copie est facturé quatre fois ;
• l'include récursif dans SPF n'est pas pris en charge ;
• le chiffrement de la connexion SMTP est obligatoire (STARTTLS sur 587, TLS direct sur 465 ou 2465).

En pratique

Confier la zone à Scaleway

Ajoutez le domaine comme domaine externe dans la console (Domains and DNS, puis Manage as external), récupérez le jeton, et créez chez votre hébergeur DNS actuel l'enregistrement de preuve :

_scaleway-challenge.example.com.  300  IN  TXT  "<jeton fourni par Scaleway>"

Avant de changer les serveurs de noms, recréez toute la zone actuelle chez Scaleway, sinon le domaine perd ses enregistrements au moment de la délégation (site, courrier, preuves diverses). Si votre hébergeur actuel sait exporter la zone au format standard de BIND, importez-la :

$ scw dns zone import example.com bind-source.content=@example.com.zone
$ scw dns record list example.com

Comparez la liste avec l'ancienne zone, enregistrement par enregistrement. Puis seulement, chez le registraire, remplacez les serveurs de noms par ns0.dom.scw.cloud et ns1.dom.scw.cloud. Le changement se propage au rythme du TTL des enregistrements NS dans la zone parente, souvent un à deux jours.

Les enregistrements de Signalements

$ scw dns record add example.com name=signalements type=A data=203.0.113.10 ttl=3600
$ scw dns record add example.com name=signalements type=AAAA data=2001:db8::10 ttl=3600
$ scw dns record add example.com name=signalements type=CAA \
    data='0 issue "letsencrypt.org"' ttl=3600

• Les deux premières commandes associent le nom au répartiteur de charge, en IPv4 et en IPv6 (adresses de documentation).
• L'enregistrement CAA n'autorise que Let's Encrypt à émettre des certificats pour ce nom : c'est l'autorité qu'utilise le répartiteur de charge de Scaleway pour ses certificats automatiques (leçon 6 du cours Le cloud : les fondamentaux). Un certificat frauduleux demandé ailleurs serait refusé par les autorités qui respectent la norme. Si Edge Services (leçon 11) ou un autre service émet des certificats pour ce nom, vérifiez quelle autorité il utilise et ajoutez-la, sinon l'émission échouera.

La commande set remplace les enregistrements d'un nom et d'un type ; bulk-update regroupe plusieurs changements en une seule opération, utile dans un script qui ne doit pas laisser la zone à moitié modifiée.

Revenir en arrière

Chaque modification crée une version de la zone. La CLI permet de les lister, de les comparer et de restaurer :

$ scw dns version list example.com
$ scw dns version diff <id-de-version>
$ scw dns version restore <id-de-version>

C'est le premier réflexe après une erreur de saisie, plus rapide que de recréer à la main. D'après la description de l'API, une zone garde au plus 100 versions, la plus ancienne étant supprimée à chaque nouvelle modification : un script qui fait des centaines de petits changements efface vite l'historique. Gardez aussi une copie hors de Scaleway :

$ scw dns zone export example.com format=bind > .tmp/example.com.zone

Le format BIND est un format texte standard que tout hébergeur DNS sait importer : c'est votre plan de sortie (voir le cours Cloud souverain).

Un enregistrement avec vérification de santé

Signalements a deux répartiteurs, un par zone (leçon 12). On veut que le nom ne réponde que les répartiteurs en bonne santé :

$ scw dns record add example.com name=signalements-ha type=A data=203.0.113.10 ttl=60 \
    http-service-config.ips.0=203.0.113.10 \
    http-service-config.ips.1=203.0.113.20 \
    http-service-config.url=https://signalements-ha.example.com/sante \
    http-service-config.must-contain=ok \
    http-service-config.strategy=random

• http-service-config.ips : les adresses à tester ; le service les contacte chacune par leur adresse, avec l'URL donnée.
• must-contain=ok : une adresse est saine si la réponse contient cette chaîne. Choisissez une chaîne qui n'apparaît que dans une réponse réellement saine (la route /sante de Signalements renvoie un état ; un message d'erreur qui contiendrait « ok » ferait passer le test).
• strategy=random : une adresse saine au hasard à chaque requête ; hashed donne toujours la même au même demandeur ; all les renvoie toutes, dans un ordre aléatoire.
• ttl=60 : sans TTL court, la bascule serait vue au bout d'une heure.
• data sert d'adresse de repli, renvoyée si aucune adresse n'est saine. Le tableau de la documentation précise le cas extrême : si ni la liste ni l'adresse de repli ne répondent, le service renvoie l'une ou l'autre.

Le domaine d'envoi

Pour les e-mails, on utilise un sous-domaine dédié, notifications.example.com. Si sa réputation est un jour abîmée (un envoi en masse par erreur, une clé volée), celle du domaine principal, qui sert au courrier des personnes, n'est pas touchée.

$ scw tem domain create domain-name=notifications.example.com autoconfig=true region=fr-par

autoconfig=true demande à Scaleway de créer lui-même les enregistrements SPF, DKIM, DMARC et MX, ce que la documentation propose quand la zone est hébergée chez Scaleway. Sinon, récupérez les valeurs à publier :

$ scw tem domain get <id-du-domaine> region=fr-par -o json \
    | jq '{spf: .records.spf, dkim: .records.dkim, dmarc: .records.dmarc, mx: .records.mx}'

Le champ records de la structure Domain du SDK donne, pour chacun, le nom et la valeur de l'enregistrement. À publier dans la zone :

Deux points méritent attention :

• Le -all de SPF dit « tout autre serveur est illégitime ». Si le domaine envoie aussi par un autre service, ajoutez son include dans le même enregistrement : un nom ne doit avoir qu'un seul enregistrement SPF.
• Le MX « trou noir » : la documentation recommande, si vous n'avez pas de serveur de réception, d'utiliser blackhole.tem.scaleway.com, parce que certains serveurs rejettent le courrier d'un domaine sans MX. Comme son nom l'indique, tout ce qui y est envoyé est perdu sans recours : une réponse d'un agent à une notification disparaît. Si les réponses doivent arriver quelque part, publiez votre propre MX et mettez une adresse Reply-To lisible.

Vérifiez ensuite l'état :

$ scw tem domain check <id-du-domaine> region=fr-par
$ scw tem domain get-last-status <id-du-domaine> region=fr-par

La seconde commande affiche, d'après son aide, l'état de SPF, DKIM, DMARC et MX et les erreurs éventuelles. La vérification peut prendre jusqu'à quarante-huit heures selon la documentation.

Commencer DMARC en observation

p=none ne demande rien aux destinataires, sauf de vous envoyer des rapports agrégés à l'adresse rua. On commence ainsi pour découvrir tous les services qui envoient au nom du domaine, puis on durcit (p=quarantine, puis p=reject) quand les rapports ne montrent plus que des envois alignés. Passer directement en reject fait disparaître sans bruit le courrier d'un outil oublié.

Envoyer : API ou SMTP

L'envoi par la CLI (et donc par l'API) est direct :

$ scw tem email create \
    from.email=ne-pas-repondre@notifications.example.com from.name="Signalements" \
    to.0.email=agent.voirie@example.com \
    subject="Nouveau signalement 4812 : lampadaire éteint" \
    text="Rue des Lilas, signalé à 21 h 04. Détails : https://signalements.example.com/s/4812" \
    region=fr-par

Dans l'application, deux possibilités :

• SMTP, sur smtp.tem.scaleway.com, port 587 avec STARTTLS ou 465 avec TLS. D'après la documentation, l'identifiant SMTP est l'identifiant du projet et le mot de passe la clé secrète d'une clé d'API. Tout logiciel qui sait envoyer par SMTP fonctionne sans changement.
• L'API REST, qui renvoie un identifiant par e-mail et permet de suivre son statut.

Dans les deux cas, la clé d'API doit appartenir à une application IAM dédiée, avec le seul jeu de permissions d'envoi : la liste des jeux de permissions de Scaleway contient TransactionalEmailEmailSmtpCreate et TransactionalEmailEmailApiCreate, distincts de ceux qui gèrent les domaines. La leçon 7 du cours précédent explique comment créer une telle application et sa politique.

Suivre les rebonds

Un e-mail envoyé n'est pas un e-mail reçu. TEM tient une liste de blocage (blocklist) : une adresse qui n'existe pas ou dont la boîte est pleine y est ajoutée automatiquement, et les envois suivants vers elle sont bloqués avant d'être tentés. Pour réagir côté application (signaler à l'administrateur de la métropole qu'un agent a une adresse erronée), TEM peut publier ses événements (livré, différé, rejeté, signalé comme indésirable...) sur un sujet de Topics and Events (leçon 9) : la documentation précise que les webhooks de TEM passent exclusivement par ce service, et qu'ils demandent, au moment de sa dernière validation, un quota accordé par la page des bêtas de Scaleway. Vérifiez leur statut avant d'en dépendre.

Sous le capot

Ce que fait un résolveur. Pour signalements.example.com, un résolveur sans cache interroge un serveur racine, qui le renvoie aux serveurs de .com, qui le renvoient aux serveurs désignés par les NS de example.com, ici ns0.dom.scw.cloud et ns1.dom.scw.cloud, qui répondent. La délégation chez le registraire est donc le seul lien entre votre domaine et les serveurs de Scaleway ; une erreur à cet endroit rend toute la zone invisible, quelle que soit sa qualité.

Pourquoi le TTL bloque une bascule. Le résolveur d'un fournisseur d'accès a gardé l'ancienne adresse ; il ne redemandera qu'à l'expiration du TTL. Aucune action de votre part ne vide le cache des résolveurs du monde entier. D'où l'abaissement préventif.

Comment le destinataire vérifie un e-mail. Le serveur qui reçoit un message de ne-pas-repondre@notifications.example.com lit l'adresse IP de l'expéditeur et vérifie qu'elle figure dans le SPF du domaine de l'enveloppe ; il lit l'en-tête DKIM-Signature, demande la clé publique <sélecteur>._domainkey.notifications.example.com dans le DNS, et vérifie la signature ; il lit enfin _dmarc.notifications.example.com pour savoir quoi faire si rien ne s'aligne avec le From:. Tout passe par le DNS : une zone mal tenue fait échouer le courrier, sans que le service d'envoi y soit pour rien.

Pourquoi la réputation compte autant. Les grands fournisseurs de messagerie décident de livrer, de classer en indésirable ou de rejeter selon la réputation de l'adresse IP et du domaine, construite sur l'historique : volume, taux de rebonds, plaintes. La documentation de TEM décrit des alertes quand le taux de rejet atteint 7 %, et un verrouillage du domaine quand sa réputation devient trop basse. Une adresse IP partagée (formule Essential) porte la réputation de tous ses utilisateurs ; une adresse dédiée (formule Scale) ne porte que la vôtre, mais doit être chauffée progressivement.

Pièges courants

Déléguer avant d'avoir recopié la zone. Le site répond, mais plus le courrier : les MX n'avaient pas été recréés. Toujours importer, comparer, puis déléguer.

Un CNAME à l'apex. example.com CNAME autre.example.net est interdit par la norme et refusé ou mal servi. Utilisez A/AAAA, ou le type ALIAS de Scaleway.

Deux enregistrements SPF. Ajouter un second TXT v=spf1 pour TEM à côté de l'ancien rend le SPF du domaine invalide (la RFC 7208 traite ce cas comme une erreur permanente). On fusionne dans un seul enregistrement.

Un include imbriqué. TEM ne prend pas en charge l'include récursif : un SPF qui inclut un enregistrement qui inclut celui de TEM peut faire échouer la vérification de domaine. Mettez include:_spf.tem.scaleway.com directement dans l'enregistrement du domaine d'envoi.

DMARC en reject dès le premier jour. Les e-mails d'un outil oublié (la facturation, l'outil de tickets) sont rejetés sans que personne ne le sache. Commencez par p=none et lisez les rapports.

Un enregistrement CAA qui bloque son propre certificat. Ajouter CAA 0 issue "letsencrypt.org" alors qu'un autre service émet ses certificats auprès d'une autre autorité fait échouer le renouvellement de celui-ci, parfois des semaines plus tard. Inventoriez les émetteurs avant de restreindre.

Compter les e-mails comme des messages. Une notification à un agent avec quatre collègues en copie compte cinq e-mails, dans le quota comme sur la facture.

Sécurité

• Le compte du registraire et celui de l'hébergeur DNS sont des actifs critiques. Qui peut modifier les NS ou la zone peut détourner le site, obtenir un certificat valide pour votre nom (les autorités vérifient le contrôle du domaine par le DNS ou par HTTP), et envoyer du courrier qui passe SPF et DKIM. Second facteur, droits IAM limités (jeux de permissions sur les domaines réservés à peu de personnes), et verrouillage du transfert du domaine (scw domain domain lock-transfer) pour un domaine interne.
• DNSSEC protège contre l'empoisonnement des caches, pas contre une modification légitime de la zone par quelqu'un qui a les droits. Les deux protections se complètent.
• Ne publiez pas d'informations internes dans une zone publique : des noms comme vpn-admin ou bdd-prod renseignent un attaquant. Les vues permettent de répondre différemment aux résolveurs internes ; elles ne rendent pas confidentiel ce qui est servi publiquement.
• Les e-mails de notification ne contiennent pas de données personnelles inutiles : un lien vers le signalement plutôt que le nom et le téléphone de l'habitant. Un e-mail sort de votre contrôle dès qu'il est envoyé.
• La clé d'envoi est un secret : une clé volée envoie de l'indésirable à votre nom et ruine la réputation du domaine. Application IAM limitée à l'envoi, rangée dans Secret Manager (leçon 8).

En production

• La zone est du code. Une fois la zone stabilisée, on la décrit dans Terraform (cours Terraform et OpenTofu : les fondamentaux), relue et versionnée, et l'on n'édite plus à la main. En attendant, l'export BIND régulier sert de sauvegarde et de journal.
• Surveillez l'expiration des domaines internes et activez le renouvellement automatique : un domaine expiré coupe le site, le courrier et la preuve de contrôle pour les certificats.
• Surveillez la délivrabilité : le rapport hebdomadaire et les alertes de TEM, les rapports DMARC, et les outils des grands fournisseurs (Google Postmaster, cité par la documentation de Scaleway). Cockpit fournit aussi un tableau de bord pour TEM (leçon 14).
• Faites relever le quota avant une ouverture : 10 000 e-mails par mois suffisent pour une métropole ; plusieurs, avec des copies, les dépassent vite. La documentation indique que les quotas sont relevés au cas par cas, selon l'usage et la réputation.
• Chez Lyneko, les applications publiques sont exposées par l'ingress Traefik du cluster Kapsule, et ce sont des enregistrements A vers son adresse publique qui les rendent joignables : le même schéma, avec un TTL abaissé avant chaque changement d'adresse.

Exercices

1. Préparer une bascule (niveau 200). Signalements doit passer de l'adresse 203.0.113.10 à 203.0.113.30 jeudi à 22 h. L'enregistrement A a un TTL de 86 400 secondes. Écrivez le plan, avec les commandes et les horaires.

2. Le SPF qui casse tout (niveau 200). La zone de example.com contient v=spf1 include:spf.protection.outlook.com -all. Un collègue ajoute un second enregistrement TXT v=spf1 include:_spf.tem.scaleway.com -all pour envoyer les notifications depuis le domaine principal. Qu'arrive-t-il, et que proposez-vous ?

3. Vérification de santé et TTL (niveau 200). L'enregistrement signalements-ha est configuré avec vérification de santé et un TTL de 3 600 secondes. Le répartiteur de la zone fr-par-1 tombe. Combien de temps des utilisateurs peuvent-ils encore être envoyés vers lui, et pourquoi ?

Récapitulatif

• Le registraire inscrit dans la zone parente les serveurs qui font autorité ; l'hébergeur DNS sert la zone. Scaleway fait les deux (domaines internes) ou seulement le second (domaines externes, délégués vers ns0.dom.scw.cloud et ns1.dom.scw.cloud après une preuve TXT).
• On recopie la zone avant de déléguer, on garde des TTL longs au quotidien et on les abaisse avant une bascule.
• scw dns record gère les enregistrements ; les versions de zone permettent de revenir en arrière ; l'export BIND est la sauvegarde et le plan de sortie.
• Les enregistrements dynamiques (pondération, vérification de santé, géolocalisation, vues) répartissent par le DNS, avec la limite du cache.
• DNSSEC signe la zone ; pour un domaine externe, c'est à vous de publier l'enregistrement DS chez le registraire.
• SPF, DKIM et DMARC prouvent l'origine d'un e-mail ; DMARC exige l'alignement avec le From: et se déploie d'abord en p=none.
• Transactional Email envoie en SMTP ou par API depuis fr-par, avec un quota par défaut de 10 000 e-mails par mois, un e-mail facturé par destinataire, un domaine d'envoi dédié et une clé d'API limitée à l'envoi.

Pour aller plus loin

• La page de gestion des enregistrements de Scaleway, pour le détail des enregistrements dynamiques.
• La RFC 7489 (DMARC), en particulier ses sections sur l'alignement et les rapports agrégés.
• La page de Scaleway sur la protection de la réputation d'un domaine d'envoi.
• Le cours DNS en profondeur, pour la résolution, les caches, DNSSEC et le diagnostic avec dig.
• La leçon 11, qui place un service en amont du répartiteur, et la leçon 12, qui rend le répartiteur résistant à la perte d'une zone.