Ce que cela signifie simplement
Un alias appartient à la configuration du fournisseur, pas au DNS MX; Proton doit connaître chaque destination attendue.
Contrôles sans risque
- Compter les boîtes, alias, redirections et éventuels catch-all
- Décider quelles adresses doivent recevoir et lesquelles doivent aussi envoyer
- Comparer ce total à la capacité du plan Proton
- Préparer une matrice sans adresse réelle dans la documentation publique
Solution pas à pas
- Créer ou rattacher toutes les destinations nécessaires avant de changer les MX
- Conserver l'ancien fournisseur actif pendant la transition
- Tester chaque destination depuis un expéditeur non-Proton puis Proton
- Vérifier aussi l'identité utilisée lors de la réponse
Les MX ne contiennent aucune liste d’adresses
Ils indiquent seulement quel serveur doit recevoir le courrier du domaine. C’est ensuite la configuration de Proton qui décide si le destinataire existe, est un alias ou doit être rejeté.
Une ligne par destination
Attribuez à chaque boîte et alias une décision explicite : conserver, rediriger, remplacer ou abandonner. L’absence de décision ne doit jamais devenir une suppression silencieuse.
Ce qu'il ne faut surtout pas faire
- Considérer qu'un export de messages exporte aussi les alias
- Changer les MX avec une liste de destinations incomplète
- Activer un catch-all sans comprendre les adresses qu'il recevra
Quand s'arrêter et demander de l'aide
- Un alias n'a pas de propriétaire ou d'usage connu
- Le quota d'adresses ou de domaines est insuffisant
- Une application utilise une adresse non inventoriée
Comment vérifier que le problème est résolu
- Chaque destination attendue reçoit les deux types de messages de test
- Chaque réponse part avec l'identité choisie
- Aucune adresse inattendue n'est rejetée
Testé sur
- Documentation Proton et Infomaniak, vérifiée le 2026-09-01