Zum Hauptinhalt springen

Appendix E. Mail Services (Maildienste)

Appendix E. Mail Services (Maildienste)​

Dieser Anhang diskutiert SPF-Implementierungsüberlegungen für verschiedene Maildienstszenarien.

E.1 Web-Based Mail Services (Webbasierte Maildienste)​

E.1.1 Dienstanbieterperspektive​

Szenario: Bereitstellung von Webmail-Diensten (wie Gmail, Yahoo Mail, Outlook.com)

SPF-Überlegungen:

1. Benutzer senden E-Mails von mehreren Domains
2. Alle E-Mails werden über Server des Dienstanbieters gesendet
3. Angemessene SPF-Einträge erforderlich

Konfigurationsbeispiel:

# Hauptdomain des Dienstanbieters
mailprovider.com IN TXT "v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.0/24 -all"

# Unterstützung für benutzerdefinierte Domains
# Benutzer müssen Dienstanbieter in ihrer Domain einbeziehen
user-domain.com IN TXT "v=spf1 include:_spf.mailprovider.com -all"
_spf.mailprovider.com IN TXT "v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.0/24 -all"

E.1.2 Konfiguration benutzerdefinierter Domains​

Benutzeranforderung: Benutzerdefinierte Domain zum Senden von E-Mails über Webmail-Dienst verwenden

Konfigurationsschritte:

  1. Domain-Eigentum verifizieren
Dienstanbieter verlangt Hinzufügen eines Verifizierungseintrags:
_verification.user-domain.com IN TXT "provider-verification-code"
  1. SPF konfigurieren
user-domain.com IN TXT "v=spf1 include:_spf.mailprovider.com -all"
  1. DKIM konfigurieren
# Dienstanbieter stellt DKIM-öffentlichen Schlüssel bereit
selector._domainkey.user-domain.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0..."
  1. DMARC konfigurieren
_dmarc.user-domain.com IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

E.2 Shared Hosting Services (Shared-Hosting-Dienste)​

E.2.1 Herausforderungen​

Problem: Mehrere Kunden teilen dieselbe IP-Adresse

hosting-provider.com: 203.0.113.10
customer1.com: Gehostet auf 203.0.113.10
customer2.com: Gehostet auf 203.0.113.10
customer3.com: Gehostet auf 203.0.113.10

SPF-Anforderung: Jede Kundendomain muss gemeinsame IP autorisieren

E.2.2 Lösungen​

Lösung 1: Einheitliche SPF-Einbeziehung

# Hosting-Anbieter stellt bereit
_spf.hosting-provider.com IN TXT "v=spf1 ip4:203.0.113.0/24 -all"

# Kundenkonfiguration
customer1.com IN TXT "v=spf1 include:_spf.hosting-provider.com -all"
customer2.com IN TXT "v=spf1 include:_spf.hosting-provider.com -all"
customer3.com IN TXT "v=spf1 include:_spf.hosting-provider.com -all"

Lösung 2: Direkte IP-Autorisierung

# Jeder Kunde konfiguriert unabhängig
customer1.com IN TXT "v=spf1 ip4:203.0.113.10 -all"
customer2.com IN TXT "v=spf1 ip4:203.0.113.10 -all"

Vorteile: Einfach, keine Abhängigkeiten Nachteile: Bei IP-Änderung müssen alle Kunden aktualisieren

Lösung 3: Dedizierte IP (empfohlen für große Kunden)

# Dedizierte IP für wichtige Kunden zuweisen
important-customer.com IN TXT "v=spf1 ip4:203.0.113.50 -all"

E.2.3 Best Practices​

Hosting-Anbieter sollten:

1. Klare SPF-Konfigurationsdokumentation bereitstellen
2. SPF-Einträge automatisch generieren (über Control Panel)
3. Kunden über IP-Adressänderungen informieren
4. SPF-Validierungstools bereitstellen

Kunden sollten:

1. Include-Methode verwenden, um SPF des Hosting-Anbieters zu referenzieren
2. SPF-Einträge regelmäßig validieren
3. E-Mail-Zustellbarkeit überwachen

E.3 Enterprise Mail Systems (Unternehmens-Mailsysteme)​

E.3.1 Komplexe Umgebung​

Typisches Unternehmensszenario:

- Mehrere Rechenzentren
- Mehrere Outbound-Mailserver
- Drittanbieter-Maildienste (Marketing, Benachrichtigungen usw.)
- Lokale Büroserver
- Cloud-Service-Integration

SPF-Konfigurationsherausforderungen:

1. DNS-Abfragelimit (10 Mal)
2. Eintragsgröße-Limit (512 Bytes)
3. Mehrere Abteilungen/Geschäftseinheiten
4. Häufige Infrastrukturänderungen

E.3.2 Unternehmens-SPF-Architektur​

Hierarchisches Design:

# Hauptdomain
company.com IN TXT "v=spf1 include:_spf-internal.company.com include:_spf-external.company.com -all"

# Interne Server
_spf-internal.company.com IN TXT "v=spf1 ip4:10.0.0.0/8 ip4:203.0.113.0/24 -all"

# Externe Dienste
_spf-external.company.com IN TXT "v=spf1 include:_spf.salesforce.com include:sendgrid.net include:mailchimp.com -all"

# Abteilungs-Subdomains
marketing.company.com IN TXT "v=spf1 include:_spf-marketing.company.com -all"
_spf-marketing.company.com IN TXT "v=spf1 include:sendgrid.net include:mailchimp.com -all"

IP-Bereichsverwaltung:

# Rechenzentrum A
_spf-dc-a.company.com IN TXT "v=spf1 ip4:203.0.113.0/25 -all"

# Rechenzentrum B
_spf-dc-b.company.com IN TXT "v=spf1 ip4:198.51.100.0/25 -all"

# Aggregation
_spf-datacenters.company.com IN TXT "v=spf1 include:_spf-dc-a.company.com include:_spf-dc-b.company.com -all"

E.3.3 SPF-Flattening-Strategie​

Problem: Überschreitung des 10-DNS-Abfragelimits

Lösung: Regelmäßiges Flattening

# Automatisierungsskript
def flatten_spf_includes():
    """
    Regelmäßig alle Include-Domain-IPs abfragen
    Flattened SPF-Eintrag generieren
    """
    includes = [
        '_spf.salesforce.com',
        'sendgrid.net',
        'mailchimp.com'
    ]
    
    ips = []
    for domain in includes:
        # SPF-Eintrag parsen und IPs extrahieren
        ips.extend(resolve_spf_ips(domain))
    
    # Neuen SPF-Eintrag generieren
    spf_record = f"v=spf1 {' '.join([f'ip4:{ip}' for ip in ips])} -all"
    
    # DNS aktualisieren (über API)
    update_dns_record('_spf-flattened.company.com', spf_record)
    
# Wöchentlich ausführen

Hinweis: Nach Flattening regelmäßig aktualisieren, da sich Drittanbieter-IPs ändern können

E.4 Email Marketing Services (E-Mail-Marketing-Dienste)​

E.4.1 Dienstkonfiguration​

Häufige Dienste:

  • SendGrid
  • Mailchimp
  • Amazon SES
  • Mailgun

SPF-Konfigurationsbeispiele:

SendGrid:

company.com IN TXT "v=spf1 include:sendgrid.net -all"

Mailchimp:

company.com IN TXT "v=spf1 include:servers.mcsv.net -all"

Amazon SES:

company.com IN TXT "v=spf1 include:amazonses.com -all"

Kombinierte Verwendung:

company.com IN TXT "v=spf1 mx include:sendgrid.net include:servers.mcsv.net -all"

E.4.2 Subdomain-Strategie​

Best Practice: Dedizierte Subdomain für Marketing-E-Mails verwenden

# Hauptdomain (für wichtige Geschäfts-E-Mails)
company.com IN TXT "v=spf1 mx -all"

# Marketing-Subdomain
marketing.company.com IN TXT "v=spf1 include:sendgrid.net -all"

# Benachrichtigungs-Subdomain
notifications.company.com IN TXT "v=spf1 include:amazonses.com -all"

Vorteile:

1. Trennung der Reputation (Marketing-E-Mails beeinflussen Hauptdomain nicht)
2. Einfachere SPF-Eintragsverwaltung
3. Bessere Überwachung und Berichterstattung
4. Entspricht DMARC-Best-Practices

E.4.3 DKIM-Konfiguration​

Mit SPF kombiniert:

# SPF
marketing.company.com IN TXT "v=spf1 include:sendgrid.net -all"

# DKIM (von SendGrid bereitgestellt)
s1._domainkey.marketing.company.com IN CNAME s1.domainkey.u12345.wl.sendgrid.net
s2._domainkey.marketing.company.com IN CNAME s2.domainkey.u12345.wl.sendgrid.net

# DMARC
_dmarc.marketing.company.com IN TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]"

E.5 Transactional Email Services (Transaktions-E-Mail-Dienste)​

E.5.1 Szenario​

Transaktions-E-Mails:

  • Registrierungsbestätigung
  • Passwort-Zurücksetzen
  • Bestellbenachrichtigungen
  • Rechnungen und Quittungen

Dienstanbieter:

  • Amazon SES
  • SendGrid
  • Mailgun
  • Postmark

E.5.2 Konfiguration​

Dedizierte Subdomain verwenden:

# Transaktions-E-Mail-Subdomain
transactional.company.com IN TXT "v=spf1 include:_spf.mailgun.org -all"

# DKIM
smtp._domainkey.transactional.company.com IN TXT "v=DKIM1; k=rsa; p=..."

Anwendungskonfiguration:

# Django-Beispiel
EMAIL_HOST = 'smtp.mailgun.org'
EMAIL_PORT = 587
EMAIL_USE_TLS = True
EMAIL_FROM = '[email protected]'

# E-Mail senden
send_mail(
    subject='Password Reset',
    message='Click here to reset...',
    from_email='[email protected]',
    recipient_list=['[email protected]']
)

E.5.3 Überwachung​

Schlüsselmetriken:

- E-Mail-Zustellrate
- Bounce-Rate
- SPF-Pass-Rate
- DKIM-Pass-Rate
- DMARC-Alignment-Rate
- Beschwerdenrate

Alarmeinstellungen:

if delivery_rate < 95%:
    alert("Delivery rate dropped below 95%")

if spf_pass_rate < 98%:
    alert("SPF configuration issue detected")

E.6 Mobile and IoT Devices (Mobile und IoT-Geräte)​

E.6.1 Herausforderungen​

Mobile Geräte:

- Dynamische IP-Adressen
- Senden über Betreibernetzwerke
- Können nicht in SPF aufgelistet werden

IoT-Geräte:

- Große Anzahl von Geräten
- Verteilt über verschiedene Netzwerke
- Direkte E-Mail-Sendung

E.6.2 Lösungen​

Lösung 1: SMTP-Relay verwenden

Gerät → SMTP-Relay → Empfänger

Konfiguration:
- Gerät verbindet sich über Authentifizierung mit Relay
- Relay-Server in SPF-Eintrag autorisiert
- Relay fügt DKIM-Signatur hinzu

SPF-Konfiguration:

iot-devices.company.com IN TXT "v=spf1 mx include:_spf-relay.company.com -all"
_spf-relay.company.com IN TXT "v=spf1 ip4:203.0.113.50 -all"

Lösung 2: API-Sendung

Geräte senden E-Mails über HTTP-API:
- Drittanbieterdienst verwenden (wie SendGrid API)
- SPF-Eintrag des Dienstanbieters abgedeckt
- Keine direkte SMTP-Sendung vom Gerät erforderlich

E.7 Best Practices Summary (Best-Practices-Zusammenfassung)​

E.7.1 Allgemeine Empfehlungen​

1. Subdomains zur Trennung verschiedener E-Mail-Typen verwenden
2. SPF + DKIM + DMARC-Dreifachschutz implementieren
3. SPF-Einträge regelmäßig überprüfen und aktualisieren
4. DNS-Abfragelimits überwachen
5. Include statt direkter Auflistung aller IPs verwenden
6. Dedizierte IPs für kritische Dienste verwenden
7. E-Mail-Authentifizierungsüberwachung implementieren
8. Incident-Response-Prozess etablieren

E.7.2 Konfigurationscheckliste​

Vor Veröffentlichung prüfen:

□ SPF-Eintragssyntax korrekt
□ DNS-Abfrageanzahl ≤ 10
□ Eintragsgröße < 512 Bytes
□ Alle Sendeserver autorisiert
□ Angemessene Qualifizierer verwenden (-all oder ~all)
□ DKIM konfiguriert
□ DMARC-Richtlinie veröffentlicht
□ Test-E-Mails gesendet und verifiziert

Kontinuierliche Überwachung:

□ DMARC-Berichte wöchentlich prüfen
□ E-Mail-Zustellbarkeit überwachen
□ SPF/DKIM-Fehler verfolgen
□ Neue Sendequellen überprüfen
□ Drittanbieterdienständerungen aktualisieren
Letztes Update am