Zum Hauptinhalt springen

10. Effects on Infrastructure (Auswirkungen auf die Infrastruktur)

Die Implementierung von SPF kann verschiedene Auswirkungen auf die E-Mail- und DNS-Infrastruktur haben. Administratoren sollten sich dieser potenziellen Auswirkungen bewusst sein.

10.1 DNS Server Load (DNS-Serverlast)​

SPF-Überprüfungen erfordern zusätzliche DNS-Abfragen, was die Last auf DNS-Servern erhöhen kann. Für jede eingehende E-Mail muss der Empfänger:

  • Den SPF-Eintrag der sendenden Domäne abfragen
  • Zusätzliche DNS-Lookups für Mechanismen durchführen (A, MX, PTR, EXISTS, INCLUDE)
  • Rekursive Abfragen für include:-Mechanismen durchführen

Mitigation (Minderung)​

  • DNS-Caching: Ordnungsgemäße Verwendung von TTL-Werten zur Minimierung redundanter Abfragen
  • Lookup-Limits: SPF begrenzt die Anzahl der DNS-Lookups auf 10, um übermäßige Last zu verhindern
  • Effizientes SPF-Record-Design: Minimierung der Anzahl von Mechanismen und includes

10.2 Large Volume Mailing (Versand großer Mengen)​

Organisationen, die große Mengen an E-Mails versenden, sollten sicherstellen, dass ihre SPF-Einträge:

  • Alle autorisierten sendenden IP-Adressen abdecken: Einbeziehung aller legitimen Mail-Server, Drittanbieter und Cloud-Dienste
  • Korrekt strukturiert sind: Vermeidung von PermError oder zu vielen DNS-Lookups
  • Regelmäßig aktualisiert werden: Wenn sich die Versandinfrastruktur ändert

Third-Party Senders (Drittanbieter-Versender)​

Organisationen, die Drittanbieter-E-Mail-Dienste verwenden (z.B. Marketing-Plattformen, Cloud-Dienste), müssen diese Dienste in ihren SPF-Einträgen autorisieren:

v=spf1 include:_spf.example.com include:_spf.thirdparty.com -all

10.3 Email Forwarding (E-Mail-Weiterleitung)​

SPF kann Probleme mit E-Mail-Weiterleitungsszenarien verursachen:

Problem: Wenn ein Empfänger eine E-Mail an einen anderen Empfänger weiterleitet, ändert sich die sendende IP-Adresse (jetzt der Weiterleitungsserver), aber die MAIL FROM-Adresse bleibt die ursprüngliche. Dies führt zu SPF-Fehlern.

Solutions (Lösungen)​

  • SRS (Sender Rewriting Scheme): Umschreibung der MAIL FROM-Adresse während der Weiterleitung
  • SPF Neutral oder SoftFail: Verwendung von ~all statt -all zur Reduzierung der Auswirkungen
  • DMARC-Integration: Verwendung von DMARC zusammen mit DKIM zur Handhabung von Weiterleitungsszenarien

10.4 Mailing Lists (Mailinglisten)​

Mailinglisten stehen vor ähnlichen Herausforderungen wie die E-Mail-Weiterleitung:

  • Der Mailinglisten-Server leitet Nachrichten von einem ursprünglichen Absender an viele Abonnenten weiter
  • Die MAIL FROM-Adresse bleibt oft die des ursprünglichen Absenders, aber die sendende IP ist der Mailinglisten-Server

Best Practices (Best Practices)​

  • MAIL FROM-Umschreibung: Mailinglisten-Software sollte die MAIL FROM-Adresse auf die Mailinglisten-Domäne umschreiben
  • DKIM-Signatur: Mailinglisten sollten eigene DKIM-Signaturen hinzufügen
  • List-ID-Header: Verwendung von List-ID und anderen Headers zur Identifizierung des Mailinglisten-Ursprungs

10.5 IPv6 Considerations (IPv6-Überlegungen)​

SPF unterstützt sowohl IPv4 als auch IPv6. Administratoren sollten:

  • ip6-Mechanismen einbeziehen: Wenn die Versandinfrastruktur IPv6 unterstützt
v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::/32 -all
  • Duale Einträge pflegen: Sicherstellen, dass sowohl IPv4- als auch IPv6-Bereiche abgedeckt sind
  • DNS AAAA-Einträge: Sicherstellen, dass A- und MX-Mechanismen ordnungsgemäß IPv6-Adressen auflösen

10.6 Subdomain Policies (Subdomain-Richtlinien)​

Standardmäßig erben Subdomains keine SPF-Einträge von ihrer übergeordneten Domäne. Jede Subdomain, die E-Mail sendet, benötigt ihren eigenen SPF-Eintrag, oder die übergeordnete Domäne sollte einen Wildcard-Eintrag veröffentlichen:

*.example.com. IN TXT "v=spf1 -all"

Dies verhindert, dass Angreifer nicht vorhandene Subdomains für Spoofing verwenden.

Letztes Update am