10. Effects on Infrastructure (Effets sur l'infrastructure)
La mise en œuvre de SPF peut avoir divers impacts sur l'infrastructure de messagerie et DNS. Les administrateurs doivent être conscients de ces impacts potentiels.
10.1 DNS Server Load (Charge du serveur DNS)
Les vérifications SPF nécessitent des requêtes DNS supplémentaires, ce qui peut augmenter la charge sur les serveurs DNS. Pour chaque message électronique entrant, le destinataire doit:
- Interroger l'enregistrement SPF du domaine expéditeur
- Effectuer des recherches DNS supplémentaires pour les mécanismes (A, MX, PTR, EXISTS, INCLUDE)
- Effectuer des requêtes récursives pour les mécanismes include:
Mitigation (Atténuation)
- Mise en cache DNS: Utilisation appropriée des valeurs TTL pour minimiser les requêtes redondantes
- Limites de recherche: SPF limite le nombre de recherches DNS à 10 pour éviter une charge excessive
- Conception efficace des enregistrements SPF: Minimisation du nombre de mécanismes et d'includes
10.2 Large Volume Mailing (Envoi de gros volumes)
Les organisations qui envoient de grands volumes de messages électroniques doivent s'assurer que leurs enregistrements SPF:
- Couvrent toutes les adresses IP d'envoi autorisées: Inclusion de tous les serveurs de messagerie légitimes, tiers et services cloud
- Sont correctement structurés: Éviter PermError ou trop de recherches DNS
- Sont régulièrement mis à jour: Lorsque l'infrastructure d'envoi change
Third-Party Senders (Expéditeurs tiers)
Les organisations utilisant des services de messagerie tiers (par exemple, plates-formes marketing, services cloud) doivent autoriser ces services dans leurs enregistrements SPF:
v=spf1 include:_spf.example.com include:_spf.thirdparty.com -all
10.3 Email Forwarding (Transfert de courrier électronique)
SPF peut causer des problèmes avec les scénarios de transfert de courrier électronique:
Problème: Lorsqu'un destinataire transfère un message électronique à un autre destinataire, l'adresse IP d'envoi change (maintenant le serveur de transfert), mais l'adresse MAIL FROM reste l'originale. Cela entraîne des échecs SPF.
Solutions (Solutions)
- SRS (Sender Rewriting Scheme): Réécriture de l'adresse MAIL FROM pendant le transfert
- SPF Neutral ou SoftFail: Utilisation de
~allau lieu de-allpour réduire l'impact - Intégration DMARC: Utilisation de DMARC avec DKIM pour gérer les scénarios de transfert
10.4 Mailing Lists (Listes de diffusion)
Les listes de diffusion sont confrontées à des défis similaires au transfert de courrier électronique:
- Le serveur de liste de diffusion transfère des messages d'un expéditeur d'origine à de nombreux abonnés
- L'adresse MAIL FROM reste souvent celle de l'expéditeur d'origine, mais l'IP d'envoi est le serveur de liste de diffusion
Best Practices (Meilleures pratiques)
- Réécriture MAIL FROM: Le logiciel de liste de diffusion devrait réécrire l'adresse MAIL FROM vers le domaine de la liste de diffusion
- Signature DKIM: Les listes de diffusion devraient ajouter leurs propres signatures DKIM
- En-tête List-ID: Utilisation de List-ID et d'autres en-têtes pour identifier l'origine de la liste de diffusion
10.5 IPv6 Considerations (Considérations IPv6)
SPF prend en charge à la fois IPv4 et IPv6. Les administrateurs devraient:
- Inclure des mécanismes ip6: Si l'infrastructure d'envoi prend en charge IPv6
v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::/32 -all
- Maintenir des entrées doubles: S'assurer que les plages IPv4 et IPv6 sont couvertes
- Enregistrements DNS AAAA: S'assurer que les mécanismes A et MX résolvent correctement les adresses IPv6
10.6 Subdomain Policies (Politiques de sous-domaines)
Par défaut, les sous-domaines n'héritent pas des enregistrements SPF de leur domaine parent. Chaque sous-domaine envoyant des messages électroniques a besoin de son propre enregistrement SPF, ou le domaine parent devrait publier un enregistrement générique:
*.example.com. IN TXT "v=spf1 -all"
Cela empêche les attaquants d'utiliser des sous-domaines inexistants pour l'usurpation d'identité.