RFC 7208 - Sender Policy Framework (SPF)

Status: Proposed Standard
Veröffentlicht: April 2014
Stream: IETF
Ersetzt: RFC4408
Errata: Keine Errata

Grundlegende Informationen

RFC-Nummer: 7208
Titel: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email
Deutscher Titel: Absender-Richtlinien-Framework
Veröffentlichungsdatum: April 2014
Status: PROPOSED STANDARD (Vorgeschlagener Standard)
Autor: S. Kitterman

Zusammenfassung (Abstract)

SPF ermöglicht es Domaininhabern, über DNS-Einträge anzugeben, welche Mailserver zum Versenden von E-Mails für diese Domain autorisiert sind. Empfänger können SPF-Einträge abfragen, um zu überprüfen, ob E-Mails von autorisierten Servern stammen, was hilft, E-Mail-Spoofing zu erkennen und zu blockieren.

Appendices (Anhänge)

SPF-Überblick

Was ist SPF?

Definition:

SPF = Sender Policy Framework (Absender-Richtlinien-Framework)
Funktion: Verifizierung autorisierter E-Mail-Versandserver
Methode: DNS TXT-Einträge
Zweck:
✓ Verhinderung von E-Mail-Spoofing
✓ Reduzierung von Spam
✓ Verbesserung der E-Mail-Zustellbarkeit

E-Mail-Sicherheits-Trio:
1. SPF (dieser RFC) - Verifiziert Versandserver
2. DKIM (RFC 6376) - Verifiziert E-Mail-Inhalt
3. DMARC (RFC 7489) - Einheitliche Richtlinien und Berichte

Funktionsprinzip:

Absender (example.com):
1. Veröffentlicht SPF-Eintrag im DNS
   example.com. IN TXT "v=spf1 ip4:203.0.113.1 -all"
   → Nur 203.0.113.1 ist autorisiert

2. Mailserver sendet E-Mails normal
   MAIL FROM: `&lt;[email protected]&gt;`

Empfänger:
1. Extrahiert Absender-Domain
   MAIL FROM: [email protected] → Domain: example.com

2. Fragt SPF-Eintrag ab
   DNS-Abfrage: example.com TXT-Eintrag

3. Prüft Versandserver-IP
   Versandserver-IP: 203.0.113.1
   SPF-Eintrag erlaubt: ip4:203.0.113.1
   → Übereinstimmung!

4. SPF-Ergebnis:
   Pass ✓ → Autorisierter Server
   Fail ✗ → Nicht autorisierter Server

SPF vs DKIM vs DMARC

Funktionsvergleich:

SPF (RFC 7208):
- Verifiziert: Versandserver-IP
- Position: SMTP MAIL FROM
- DNS-Eintrag: TXT
- Einschränkung: Weitergeleitete E-Mails schlagen fehl

DKIM (RFC 6376):
- Verifiziert: Digitale E-Mail-Signatur
- Position: DKIM-Signature Header
- DNS-Eintrag: TXT (_domainkey)
- Einschränkung: Erfordert korrekte Schlüsselkonfiguration

DMARC (RFC 7489):
- Verifiziert: SPF + DKIM Alignment
- Position: From Header
- DNS-Eintrag: TXT (_dmarc)
- Funktion: Richtlinie + Berichte

Kombinierte Verwendung:
SPF + DKIM → DMARC bestanden → Optimaler Schutz

SPF-Eintragsformat

Grundlegende Syntax

v=spf1 &lt;mechanisms> &lt;qualifiers> &lt;modifiers>

Beispiel:
v=spf1 ip4:192.0.2.0/24 include:_spf.example.com -all

Bestandteile:
- v=spf1: Versionskennung (erforderlich, immer spf1)
- mechanisms: Matching-Mechanismen
- qualifiers: Ergebnis-Qualifizierer
- modifiers: Modifikatoren

Mechanismen (Mechanisms)

1. all:

Definition: Matcht alle IPs
Verwendung: Normalerweise als Standard-Richtlinie am Ende

Beispiele:
v=spf1 -all           Alle IPs nicht erlaubt (am strengsten)
v=spf1 ~all           Alle IPs Soft-Fail (empfohlen)
v=spf1 +all           Alle IPs erlaubt (nicht empfohlen!)

2. ip4/ip6:

Definition: Explizite IP-Adressen oder Bereiche

Beispiele:
v=spf1 ip4:203.0.113.1 -all
→ Nur 203.0.113.1 erlaubt

v=spf1 ip4:192.0.2.0/24 -all
→ Erlaubt 192.0.2.0-192.0.2.255

v=spf1 ip6:2001:db8::1 -all
→ Erlaubt IPv6-Adresse

v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.0/24 -all
→ Erlaubt mehrere Bereiche

3. a:

Definition: A/AAAA-Einträge der aktuellen Domain

Beispiele:
v=spf1 a -all
→ Erlaubt IPs aus A-Eintrag von example.com

v=spf1 a:mail.example.com -all
→ Erlaubt IPs aus A-Eintrag von mail.example.com

v=spf1 a/24 -all
→ Erlaubt /24-Netzwerk der A-Eintrag-IP von example.com

4. mx:

Definition: MX-Einträge der aktuellen Domain

Beispiele:
v=spf1 mx -all
→ Erlaubt MX-Server-IPs von example.com

v=spf1 mx:example.com -all
→ Erlaubt MX-Server-IPs von example.com

v=spf1 mx/24 -all
→ Erlaubt /24-Netzwerk der MX-Server

5. include:

Definition: Bezieht SPF-Eintrag einer anderen Domain ein

Beispiele:
v=spf1 include:_spf.google.com -all
→ Erlaubt Google Mailserver (Gmail for Business)

v=spf1 include:spf.protection.outlook.com -all
→ Erlaubt Microsoft 365 Mailserver

Mehrere includes:
v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all

Hinweis: Maximal 10 DNS-Abfragen Limit!

6. exists:

Definition: Matcht wenn die angegebene Domain einen A-Eintrag hat

Beispiel:
v=spf1 exists:%\{i}.spamhaus.example.com -all
→ Fortgeschrittene Verwendung, normalerweise für Anti-Spam-Blacklist-Prüfung

Makro-Erweiterung:
%\{i} = Versandserver-IP (umgekehrt)

7. ptr (nicht empfohlen):

Definition: Reverse-DNS-Abfrage

Beispiel:
v=spf1 ptr:example.com -all

Probleme:
❌ Schlechte Performance (erfordert Reverse-DNS-Abfrage)
❌ Geringe Zuverlässigkeit
❌ RFC empfiehlt ausdrücklich nicht zu verwenden

Alternative: Verwenden Sie ip4/ip6 oder include

Qualifizierer (Qualifiers)

Symbol | Name | Bedeutung | Empfohlene Verwendung
-------|------|-----------|----------------------
+ | Pass | Bestanden (Standard) | Autorisierte Server
- | Fail | Fehlgeschlagen | E-Mail ablehnen
~ | SoftFail | Soft-Fail | Akzeptieren aber markieren
? | Neutral | Neutral | Keine klare Richtlinie

Beispiele:
v=spf1 +ip4:203.0.113.1 -all
       ↑explizit pass    ↑explizit fail

v=spf1 ip4:203.0.113.1 ~all
       ↑Standard +       ↑soft-fail

v=spf1 ?all
       ↑neutral (entspricht keinem SPF)

Empfehlungen zur Verwendung von Qualifizierern:

+ (Pass): 
✓ Autorisierte Mailserver
Beispiel: +ip4:203.0.113.1

- (Fail):
✓ Finales -all (streng)
✓ Explizit bestimmte IPs verbieten
Beispiel: -all

~ (SoftFail):
✓ Finales ~all (locker, empfohlen anfangs)
✓ Übergangszeit verwenden
Beispiel: ~all

? (Neutral):
✗ Selten verwendet
✗ Entspricht keiner Richtlinie

Modifikatoren (Modifiers)

1. redirect:

Definition: Umleitung auf SPF-Eintrag einer anderen Domain

Beispiel:
example.com: v=spf1 redirect=_spf.example.com
_spf.example.com: v=spf1 ip4:203.0.113.1 -all

Zweck:
✓ Zentrale SPF-Verwaltung
✓ Mehrere Domains teilen sich Richtlinie

Hinweis:
- Nach redirect können keine anderen Mechanismen folgen
- Kann nicht zusammen mit all verwendet werden

2. exp:

Definition: Erklärung (Erklärungstext bei SPF-Fehler)

Beispiel:
v=spf1 -all exp=explain.example.com

explain.example.com TXT-Eintrag:
"This domain does not send email"

Zweck:
✓ Benutzerfreundliche Fehlermeldungen bereitstellen
- Wird selten tatsächlich verwendet

SPF-Eintragsbeispiele

Basiskonfigurationen

1. Nur ein Mailserver:

v=spf1 ip4:203.0.113.1 -all

Erklärung:
- Nur 203.0.113.1 darf E-Mails senden
- Andere IPs werden abgelehnt

2. Verwendung von MX-Einträgen:

v=spf1 mx -all

Erklärung:
- Erlaubt MX-Server der Domain E-Mails zu senden
- Passt sich automatisch an MX-Änderungen an

3. Mehrere IP-Bereiche:

v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.0/24 -all

Erklärung:
- Erlaubt zwei Class-C-Netzwerke
- Geeignet für Multi-Datacenter-Bereitstellung

Drittanbieter-Dienste

4. Google Workspace (Gmail for Business):

v=spf1 include:_spf.google.com -all

Erklärung:
- Verwendet Google zum E-Mail-Versand
- Bezieht Googles SPF-Eintrag ein

5. Microsoft 365:

v=spf1 include:spf.protection.outlook.com -all

6. SendGrid:

v=spf1 include:sendgrid.net -all

7. Mailchimp:

v=spf1 include:servers.mcsv.net -all

Gemischte Konfigurationen

8. Eigener Server + Drittanbieter:

v=spf1 ip4:203.0.113.1 include:_spf.google.com -all

Erklärung:
- Eigener Server: 203.0.113.1
- Google Workspace: include

9. Mehrere Drittanbieter-Dienste:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net -all

Hinweis: Jedes include zählt als eine DNS-Abfrage

10. Domain sendet keine E-Mails:

v=spf1 -all

Erklärung:
- Domain sendet keine E-Mails
- Verhindert Spoofing
- Geeignet für nur-Empfangs-Domains

Subdomains

11. Separate Subdomain-Konfiguration:

example.com: v=spf1 ip4:203.0.113.1 -all
mail.example.com: v=spf1 include:_spf.google.com -all

Erklärung:
- Hauptdomain verwendet eigenen Server
- mail-Subdomain verwendet Google

12. Subdomain-Vererbung (wenn kein SPF-Eintrag vorhanden):

Wenn mail.example.com keinen SPF-Eintrag hat:
→ Verwendet SPF-Eintrag von example.com

Wenn keine Vererbung gewünscht:
mail.example.com: v=spf1 -all

SPF-Prüfablauf

Empfänger-Verifizierungsschritte

// SPF-Verifizierungs-Pseudocode
async function checkSPF(clientIP, sender, helo) {
  // 1. Domain extrahieren
  const domain = sender.split('@')[1]; // [email protected] → example.com
  
  // 2. SPF-Eintrag abfragen
  const spfRecord = await queryDNS(domain, 'TXT', 'v=spf1');
  
  if (!spfRecord) {
    return 'none'; // Kein SPF-Eintrag
  }
  
  // 3. SPF-Eintrag parsen
  const mechanisms = parseSPF(spfRecord);
  
  // 4. Mechanismen nacheinander prüfen
  for (const mechanism of mechanisms) {
    const result = await evaluateMechanism(mechanism, clientIP, domain);
    
    if (result !== null) {
      return result; // Match gefunden, Ergebnis zurückgeben
    }
  }
  
  return 'neutral'; // Kein Match
}

// Einzelnen Mechanismus bewerten
async function evaluateMechanism(mechanism, clientIP, domain) {
  const { type, value, qualifier } = mechanism;
  
  switch (type) {
    case 'ip4':
      if (isInIPRange(clientIP, value)) {
        return mapQualifier(qualifier); // +pass, -fail, ~softfail
      }
      break;
      
    case 'a':
      const aRecords = await queryDNS(value || domain, 'A');
      if (aRecords.includes(clientIP)) {
        return mapQualifier(qualifier);
      }
      break;
      
    case 'mx':
      const mxRecords = await queryDNS(value || domain, 'MX');
      for (const mx of mxRecords) {
        const mxIPs = await queryDNS(mx, 'A');
        if (mxIPs.includes(clientIP)) {
          return mapQualifier(qualifier);
        }
      }
      break;
      
    case 'include':
      const includeResult = await checkSPF(clientIP, `user@${value}`, null);
      if (includeResult === 'pass') {
        return mapQualifier(qualifier);
      }
      break;
      
    case 'all':
      return mapQualifier(qualifier);
  }
  
  return null; // Kein Match
}

SPF-Ergebnisse

Rückgabewert       | Bedeutung            | Empfohlene Behandlung
-------------------|----------------------|----------------------
none               | Kein SPF-Eintrag     | Akzeptieren (niedrigeres Vertrauen)
neutral            | Explizit keine       | Akzeptieren
                   | Richtlinie           |
pass               | Bestanden            | Akzeptieren
fail               | Fehlgeschlagen       | Ablehnen
softfail           | Soft-Fail            | Akzeptieren aber markieren
temperror          | Temporärer Fehler    | Später erneut versuchen
permerror          | Permanenter Fehler   | Ablehnen

SMTP-Antwortbeispiele:
pass: 250 OK (SPF pass)
fail: 550 SPF check failed
softfail: 250 OK (X-SPF: softfail Header hinzufügen)

DNS-Abfragelimits

10-Abfragen-Limit

Problem:

SPF-Prüfung führt maximal 10 DNS-Abfragen durch
Überschreitung des Limits → permerror (Permanenter Fehler)

Zählt zu den 10 Abfragen:
✓ include
✓ a
✓ mx
✓ exists
✓ redirect

Zählt nicht:
✗ ip4/ip6 (direktes Matching)
✗ all (direktes Matching)

Beispiel - Limit überschritten:

v=spf1 
  include:_spf1.example.com  ← 1
  include:_spf2.example.com  ← 2
  include:_spf3.example.com  ← 3
  include:_spf4.example.com  ← 4
  include:_spf5.example.com  ← 5
  include:_spf6.example.com  ← 6
  include:_spf7.example.com  ← 7
  include:_spf8.example.com  ← 8
  include:_spf9.example.com  ← 9
  include:_spf10.example.com ← 10
  include:_spf11.example.com ← Überschritten! permerror
  -all

Wenn ein include weitere includes enthält, zählen diese auch zur Gesamtzahl!

Lösungen:

1. Verwenden Sie ip4/ip6 statt a/mx
   ❌ v=spf1 a mx -all  (2 Abfragen)
   ✓ v=spf1 ip4:203.0.113.1 ip4:198.51.100.1 -all  (0 Abfragen)

2. includes zusammenführen
   ❌ include:service1.com include:service2.com
   ✓ Eigenen SPF-Eintrag pflegen, der alle IPs enthält

3. SPF Flattening
   Regelmäßig IPs aus includes abfragen, in ip4/ip6 umwandeln

SPF Flattening Tool

// SPF Flattening Beispiel
async function flattenSPF(domain) {
  const spf = await querySPF(domain);
  const ips = [];
  
  // SPF parsen
  const mechanisms = parseSPF(spf);
  
  for (const mech of mechanisms) {
    if (mech.type === 'ip4' || mech.type === 'ip6') {
      ips.push(mech.value);
    } else if (mech.type === 'include') {
      // Rekursiv includes abfragen
      const includeIPs = await resolveInclude(mech.value);
      ips.push(...includeIPs);
    } else if (mech.type === 'a') {
      const aRecords = await queryDNS(mech.value, 'A');
      ips.push(...aRecords.map(ip => `ip4:${ip}`));
    } else if (mech.type === 'mx') {
      const mxRecords = await queryDNS(mech.value, 'MX');
      for (const mx of mxRecords) {
        const mxIPs = await queryDNS(mx, 'A');
        ips.push(...mxIPs.map(ip => `ip4:${ip}`));
      }
    }
  }
  
  // Flattened SPF generieren
  return `v=spf1 ${ips.join(' ')} -all`;
}

// Verwendung
const flatSPF = await flattenSPF('example.com');
console.log('Flattened SPF:', flatSPF);
// v=spf1 ip4:74.125.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 -all

Praktische Werkzeuge

SPF-Eintrags-Generator

class SPFBuilder {
  constructor(domain) {
    this.domain = domain;
    this.mechanisms = [];
    this.modifier = null;
  }
  
  addIP(ip) {
    if (ip.includes(':')) {
      this.mechanisms.push(`ip6:${ip}`);
    } else {
      this.mechanisms.push(`ip4:${ip}`);
    }
    return this;
  }
  
  addIPRange(cidr) {
    if (cidr.includes(':')) {
      this.mechanisms.push(`ip6:${cidr}`);
    } else {
      this.mechanisms.push(`ip4:${cidr}`);
    }
    return this;
  }
  
  useA() {
    this.mechanisms.push('a');
    return this;
  }
  
  useMX() {
    this.mechanisms.push('mx');
    return this;
  }
  
  include(domain) {
    this.mechanisms.push(`include:${domain}`);
    return this;
  }
  
  setDefault(qualifier) {
    const qualifiers = { pass: '+all', fail: '-all', softfail: '~all', neutral: '?all' };
    this.mechanisms.push(qualifiers[qualifier] || '-all');
    return this;
  }
  
  redirect(domain) {
    this.modifier = `redirect=${domain}`;
    return this;
  }
  
  build() {
    let spf = 'v=spf1';
    
    if (this.mechanisms.length > 0) {
      spf += ' ' + this.mechanisms.join(' ');
    }
    
    if (this.modifier) {
      spf += ' ' + this.modifier;
    }
    
    return spf;
  }
  
  countLookups() {
    let count = 0;
    for (const mech of this.mechanisms) {
      if (mech.startsWith('include:') || mech.startsWith('a') || 
          mech.startsWith('mx') || mech.startsWith('exists:')) {
        count++;
      }
    }
    if (this.modifier && this.modifier.startsWith('redirect=')) {
      count++;
    }
    return count;
  }
}

// Verwendungsbeispiel
const spf = new SPFBuilder('example.com')
  .addIP('203.0.113.1')
  .addIPRange('192.0.2.0/24')
  .include('_spf.google.com')
  .include('spf.protection.outlook.com')
  .setDefault('fail')
  .build();

console.log('SPF Record:', spf);
console.log('DNS Lookups:', spf.countLookups());

// Ausgabe:
// SPF Record: v=spf1 ip4:203.0.113.1 ip4:192.0.2.0/24 include:_spf.google.com include:spf.protection.outlook.com -all
// DNS Lookups: 2

SPF-Verifizierungs-Tool

const dns = require('dns').promises;

class SPFChecker {
  async check(domain, ip) {
    try {
      // SPF-Eintrag abfragen
      const records = await dns.resolveTxt(domain);
      const spfRecord = records.find(r => 
        r.join('').startsWith('v=spf1')
      );
      
      if (!spfRecord) {
        return { result: 'none', message: 'No SPF record found' };
      }
      
      const spf = spfRecord.join('');
      console.log('SPF Record:', spf);
      
      // Parsen und verifizieren
      const result = await this.evaluate(spf, ip, domain);
      
      return result;
      
    } catch (err) {
      return { result: 'temperror', message: err.message };
    }
  }
  
  async evaluate(spf, ip, domain, depth = 0) {
    if (depth > 10) {
      return { result: 'permerror', message: 'Too many DNS lookups' };
    }
    
    const parts = spf.split(/\s+/);
    
    for (const part of parts) {
      if (part === 'v=spf1') continue;
      
      // Qualifizierer extrahieren
      let qualifier = '+';
      let mechanism = part;
      
      if (['+', '-', '~', '?'].includes(part[0])) {
        qualifier = part[0];
        mechanism = part.slice(1);
      }
      
      // Mechanismus prüfen
      if (mechanism.startsWith('ip4:')) {
        const range = mechanism.slice(4);
        if (this.isIPInRange(ip, range)) {
          return this.mapResult(qualifier);
        }
      } else if (mechanism.startsWith('include:')) {
        const includeDomain = mechanism.slice(8);
        const includeRecords = await dns.resolveTxt(includeDomain);
        const includeSPF = includeRecords.find(r => 
          r.join('').startsWith('v=spf1')
        );
        
        if (includeSPF) {
          const result = await this.evaluate(
            includeSPF.join(''), 
            ip, 
            includeDomain, 
            depth + 1
          );
          
          if (result.result === 'pass') {
            return this.mapResult(qualifier);
          }
        }
      } else if (mechanism === 'all' || mechanism === '-all' || 
                 mechanism === '~all' || mechanism === '?all') {
        return this.mapResult(qualifier);
      }
      // Weitere Mechanismen können hier hinzugefügt werden...
    }
    
    return { result: 'neutral', message: 'No match found' };
  }
  
  isIPInRange(ip, range) {
    // Vereinfachte Version, Produktionsumgebung benötigt vollständige Implementierung
    if (!range.includes('/')) {
      return ip === range;
    }
    // CIDR-Matching-Implementierung ausgelassen...
    return false;
  }
  
  mapResult(qualifier) {
    const map = {
      '+': { result: 'pass', message: 'SPF pass' },
      '-': { result: 'fail', message: 'SPF fail' },
      '~': { result: 'softfail', message: 'SPF softfail' },
      '?': { result: 'neutral', message: 'SPF neutral' }
    };
    return map[qualifier] || map['+'];
  }
}

// Verwendung
const checker = new SPFChecker();
const result = await checker.check('example.com', '203.0.113.1');
console.log('SPF Check Result:', result);

Best Practices für die Bereitstellung

1. Schrittweise Bereitstellung

Phase 1: Überwachungsmodus
v=spf1 ?all
oder
v=spf1 ~all

Zweck: Daten sammeln, beobachten welche Server E-Mails senden
Dauer: 2-4 Wochen

Phase 2: Soft-Fail
v=spf1 ip4:x.x.x.x include:provider.com ~all

Zweck: Nicht autorisierte E-Mails markieren aber nicht ablehnen
Dauer: 4-8 Wochen

Phase 3: Strenger Modus
v=spf1 ip4:x.x.x.x include:provider.com -all

Zweck: Nicht autorisierte E-Mails ablehnen

2. Häufige Fehler

❌ Fehler 1: -all vergessen
v=spf1 ip4:203.0.113.1
→ Entspricht v=spf1 ip4:203.0.113.1 ?all
→ Jede IP ist neutral

✓ Korrekt:
v=spf1 ip4:203.0.113.1 -all

❌ Fehler 2: Mehrere SPF-Einträge
example.com TXT "v=spf1 ip4:203.0.113.1 -all"
example.com TXT "v=spf1 include:provider.com -all"
→ permerror

✓ Korrekt: Zu einem zusammenführen
v=spf1 ip4:203.0.113.1 include:provider.com -all

❌ Fehler 3: Mehr als 10 Abfragen
v=spf1 include:a include:b include:c ... (zu viele)

✓ Korrekt: Verwenden Sie ip4 direkt oder flattening

❌ Fehler 4: Verwendung von ptr
v=spf1 ptr:example.com -all
→ Schlechte Performance, nicht empfohlen

✓ Korrekt: Verwenden Sie ip4 oder include

3. Testen und Verifizieren

# Kommandozeilen-Test-Tools

# 1. SPF-Eintrag abfragen
dig example.com TXT | grep "v=spf1"
oder
nslookup -type=TXT example.com

# 2. Online-Tools verwenden
# - https://mxtoolbox.com/spf.aspx
# - https://www.kitterman.com/spf/validate.html

# 3. Test-E-Mail senden
# An eigene E-Mail-Adresse senden, E-Mail-Header prüfen:
# Received-SPF: pass ...

Integration mit DKIM/DMARC

Vollständige E-Mail-Sicherheitskonfiguration

1. SPF-Eintrag:
example.com. IN TXT "v=spf1 ip4:203.0.113.1 include:_spf.google.com -all"

2. DKIM-Eintrag:
default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0..."

3. DMARC-Eintrag:
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

Ergebnis:
- SPF verifiziert Versandserver ✓
- DKIM verifiziert E-Mail-Inhalt ✓
- DMARC vereinheitlicht Richtlinie ✓
→ Dreifacher Schutz!

Referenzen

SPF-bezogene RFCs:

[RFC 7208] SPF ← Dieses Dokument
[RFC 7489] DMARC
[RFC 6376] DKIM

Verwandte Ressourcen:

Zusammenfassung: SPF ist die erste Verteidigungslinie für E-Mail-Sicherheit. Durch DNS-Einträge werden Versandserver autorisiert und E-Mail-Spoofing effektiv verhindert. Kombiniert mit DKIM und DMARC entsteht ein vollständiges E-Mail-Sicherheitssystem. Denken Sie daran: Beginnen Sie mit Soft-Fail und verschärfen Sie schrittweise auf den strengen Modus, und beachten Sie die 10-DNS-Abfrage-Grenze!

1. Introduction (Einführung)

Die aktuelle E-Mail-Infrastruktur hat die Eigenschaft, dass jeder Host, der E-Mails in das System einschleust, jeden beliebigen DNS-Domainnamen in den verschiedenen Identifikatoren verwenden kann, die in [RFC5321] und [RFC5322] spezifiziert sind. Während diese Eigenschaft in einigen Fällen vorteilhaft ist, stellt sie ein Haupthindernis bei der Reduzierung unerwünschter Massen-E-Mails (UBE, Unsolicited Bulk Email, auch als Spam bekannt) dar. Darüber hinaus sind ADMDs (wie in [RFC5598] beschrieben) verständlicherweise besorgt darüber, dass andere Entitäten ihre Domainnamen leicht verwenden können, oft mit böswilliger Absicht.

Dieses Dokument definiert ein Protokoll, durch das ein ADMD Hosts autorisieren kann, seinen Domainnamen in den Identitäten "MAIL FROM" oder "HELO" zu verwenden. Konforme ADMDs veröffentlichen Sender Policy Framework (SPF)-Einträge im DNS, die angeben, welche Hosts berechtigt sind, ihre Namen zu verwenden, und konforme E-Mail-Empfänger verwenden die veröffentlichten SPF-Einträge, um die Autorisierung eines sendenden Mail Transfer Agents (MTA) zu testen, der während einer E-Mail-Transaktion eine bestimmte "HELO"- oder "MAIL FROM"-Identität verwendet.

Ein weiterer Vorteil für E-Mail-Empfänger besteht darin, dass nach der Validierung der Verwendung einer Identität lokale Richtlinienentscheidungen über E-Mails auf Basis der Domäne des Absenders und nicht auf Basis der IP-Adresse des Hosts getroffen werden können. Dies ist vorteilhaft, da die Reputation eines Domainnamens möglicherweise genauer ist als die Reputation einer Host-IP-Adresse, weil der Domainname über einen längeren Zeitraum stabiler sein könnte. Wenn die behauptete Identität nicht validiert werden kann, können lokale Richtlinien außerdem strengere Maßnahmen gegen solche E-Mails ergreifen, wie z.B. deren Ablehnung.

1.1 Terminology (Terminologie)

1.1.1 Key Words (Schlüsselwörter)

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind wie in [RFC2119] beschrieben zu interpretieren.

1.1.2 Imported Definitions (Importierte Definitionen)

ABNF (Augmented Backus-Naur Form) ist in [RFC5234] definiert, die Tokens "ALPHA", "DIGIT" und "SP" (Leerzeichen) sind ebenfalls dort definiert.

Die Tokens "Local-part", "Domain" und "Mailbox" sind in [RFC5321] definiert.

"dot-atom", "quoted-string", "comment", "CFWS" (Comment Folded White Space), "FWS" (Folded White Space) und "CRLF" (Carriage-Return/Line-Feed) sind in [RFC5322] definiert.

1.1.3 MAIL FROM Definition (MAIL FROM Definition)

Dieses Dokument befasst sich mit der Identität des E-Mail-Absenders, wie in [RFC5321] beschrieben:

Die Transaktion beginnt mit dem MAIL-Befehl, der die Absenderidentität angibt.

Da diese Identität viele andere Namen hat, ist es wichtig, einen Namen zu wählen, der:

Allgemein gebräuchlich ist
Klar definiert ist

Daher wird in diesem Dokument der Begriff "MAIL FROM" verwendet, der als die in [RFC5598] beschriebene RFC5321.MailFrom (Reverse-Path)-Identität definiert ist.

1.1.4 HELO Definition (HELO Definition)

Dieses Dokument verwendet auch die HELO/EHLO-Identität. Die "HELO"-Identität stammt vom SMTP HELO- oder EHLO-Befehl (siehe [RFC5321]). Da HELO und EHLO in vielen Fällen austauschbar verwendet werden können, werden sie in diesem Dokument üblicherweise als "HELO" bezeichnet. Dies bedeutet RFC5321.HELO/.EHLO wie in [RFC5598] definiert. Diese Befehle liefern die Identität des SMTP-Clients (sendender Host) für die SMTP-Sitzung.

1.2 check_host()

Abschnitt 4 stellt einen Algorithmus vor, der zur Bewertung der SPF-Richtlinie gegenüber einer eingehenden E-Mail-Transaktion verwendet wird. In frühen Implementierungen wurde dieser Algorithmus in einer Funktion namens check_host() kodiert. Dieser Name wird in diesem Dokument als Symbol für den SPF-Bewertungsalgorithmus verwendet, aber Implementierer müssen diesen Namen natürlich nicht verwenden.

2. Operational Overview (Betriebsübersicht)

2.1 Publishing Authorization (Veröffentlichung der Autorisierung)

SPF-konforme Domänen veröffentlichen gültige SPF-Einträge wie in Abschnitt 3 beschrieben. Diese Einträge autorisieren die darin angegebenen MTAs, den zugehörigen Domainnamen in den Identitäten "HELO" und "MAIL FROM" zu verwenden.

SPF-Ergebnisse können verwendet werden, um sowohl positive (Quelle ist autorisiert) als auch negative (Quelle ist nicht autorisiert) Bestimmungen zu treffen. Wenn ein ADMD sich dafür entscheidet, einen SPF-Eintrag zu veröffentlichen und Empfänger bei negativen Autorisierungsentscheidungen unterstützen möchte, muss es einen Eintrag veröffentlichen, der mit "-all" endet oder auf einen anderen Eintrag umleitet, der dies tut; andernfalls kann keine eindeutige Bestimmung über die Autorisierung getroffen werden. Abschnitt 10 diskutiert potenzielle Probleme und Abhilfemaßnahmen im Zusammenhang mit negativen Entscheidungen.

ADMDs, die erklären möchten, dass keine Hosts autorisiert sind, ihren DNS-Domainnamen während SMTP-Sitzungen in HELO- oder MAIL FROM-Befehlen zu verwenden, können einen solchen SPF-Eintrag für Domainnamen veröffentlichen, die weder im Domänenteil von E-Mail-Adressen verwendet werden noch voraussichtlich E-Mails senden werden.

Bei Änderungen an SPF-Einträgen muss darauf geachtet werden, dass es eine Übergangszeit gibt, während der die alte Richtlinie gültig bleibt, bis alle legitimen E-Mails vernünftigerweise überprüft worden sein können. [RFC5321] Abschnitt 4.5.4.1 diskutiert, wie lange Nachrichten sich im Transit befinden können. Während Offline-Prüfungen möglich sind, ist es wahrscheinlicher, dass ein SPF-Ergebnis erzielt wird, das mit der Absicht des sendenden ADMD zum Zeitpunkt des Sendens der Nachricht übereinstimmt, je näher die Prüfung am ursprünglichen Übertragungszeitpunkt erfolgt.

2.2 Checking Authorization (Prüfung der Autorisierung)

E-Mail-Empfänger können eine Reihe von SPF-Prüfungen für jede empfangene E-Mail durchführen. Eine SPF-Prüfung testet die Autorisierung des Client-Hosts, E-Mails mit einer bestimmten Identität zu senden. Typischerweise werden solche Prüfungen vom empfangenden MTA durchgeführt, können aber auch an anderen Stellen in der E-Mail-Verarbeitungskette durchgeführt werden, solange die erforderlichen Informationen verfügbar und zuverlässig sind. Die Identitäten "MAIL FROM" und "HELO" werden gemäß Abschnitt 2.4 bzw. 2.3 überprüft.

Es wird nicht empfohlen, andere Identitäten gegen SPF-Version-1-Einträge zu prüfen, ohne explizite Genehmigung des veröffentlichenden ADMD, da bekannt ist, dass einige Situationen falsche Ergebnisse liefern. Beispielsweise schreiben fast alle Mailinglisten die Identität "MAIL FROM" um (siehe Abschnitt 10.3), aber einige ändern keine anderen Identitäten in der Nachricht. Dokumente, die andere Identitäten definieren, müssen Methoden zur expliziten Genehmigung definieren.

E-Mail-Empfänger können SPF-Prüfungen als Teil eines größeren Test-Sets für eingehende E-Mails einbeziehen. Die Ergebnisse anderer Tests können beeinflussen, ob eine bestimmte SPF-Prüfung durchgeführt wird. Beispielsweise kann das Finden der IP-Adresse des sendenden Hosts auf einer lokalen Whitelist dazu führen, dass alle anderen Tests übersprungen werden und alle E-Mails von diesem Host akzeptiert werden.

Wenn ein E-Mail-Empfänger sich entscheidet, eine SPF-Prüfung durchzuführen, muss er die korrekt implementierte check_host()-Funktion (Abschnitt 4) verwenden und mit den richtigen Parametern auswerten. Während der gesamte Test optional ist, muss er, sobald die Entscheidung getroffen wurde, ihn durchzuführen, wie vorgeschrieben durchgeführt werden, um die korrekten Semantiken zwischen Veröffentlichern und Empfängern zu bewahren.

Um den Test durchzuführen, muss der E-Mail-Empfänger die check_host()-Funktion mit den in Abschnitt 4.1 beschriebenen Parametern bewerten.

Obwohl ungültige, fehlerhafte oder nicht existierende Domänen dazu führen, dass SPF-Prüfungen "none" zurückgeben (da kein SPF-Eintrag gefunden wird), ist es seit langem die Richtlinie vieler MTAs, E-Mails von solchen Domänen abzulehnen, insbesondere im Fall von ungültigen "MAIL FROM". Das Ablehnen der E-Mail verhindert eine Möglichkeit, SPF-Einträge zu umgehen.

Implementierungen müssen darauf achten, das <domain> korrekt aus den mit dem SMTP MAIL FROM-Befehl angegebenen Daten zu extrahieren, da viele MTAs noch Dinge wie Source Routing (siehe Anhang C von [RFC5321]), %-Hack (siehe [RFC1123]) und Bang-Pfade (siehe [RFC1983]) akzeptieren. Diese veralteten Features wurden böswillig verwendet, um Sicherheitssysteme zu umgehen.

2.3 The "HELO" Identity (Die "HELO"-Identität)

Es wird empfohlen, dass SPF-Verifizierer nicht nur die Identität "MAIL FROM" prüfen, sondern auch die Identität "HELO" separat prüfen, indem sie die check_host()-Funktion (Abschnitt 4) auf die Identität "HELO" als <domain> anwenden. Die Prüfung von "HELO" kann zu konsistenten Ergebnissen beitragen und die Nutzung von DNS-Ressourcen reduzieren. Wenn eine definitive Bestimmung über eine Nachricht auf der Grundlage der Prüfung von "HELO" getroffen werden kann, können DNS-Ressourcen zur Verarbeitung der normalerweise komplexeren "MAIL FROM" vermieden werden. Außerdem, da SPF-Einträge, die für die Identität "HELO" veröffentlicht werden, sich auf einen einzelnen Host beziehen, sind sie, wenn verfügbar, eine sehr zuverlässige Quelle für den Host-Autorisierungsstatus. Wenn beide geprüft werden sollen, wird empfohlen, zuerst "HELO" und dann "MAIL FROM" zu prüfen.

Beachten Sie, dass die Anforderungen an die Domäne, die im EHLO- oder HELO-Befehl für Absender präsentiert wird, nicht immer klar sind, und SPF-Verifizierer müssen darauf vorbereitet sein, dass die Identität ein IP-Adressliteral ist (siehe [RFC5321] Abschnitt 4.1.3) oder einfach nur fehlerhaft. Diese SPF-Prüfung kann nur durchgeführt werden, wenn die "HELO"-Zeichenfolge ein gültiger Multi-Label-Domainname ist.

2.4 The "MAIL FROM" Identity (Die "MAIL FROM"-Identität)

Wenn die "HELO"-Prüfung nicht durchgeführt wurde oder kein definitives Richtlinienergebnis erreicht wurde, muss der SPF-Verifizierer die Identität "MAIL FROM" prüfen, indem er die check_host()-Funktion auf die Identität "MAIL FROM" als <domain> anwendet.

[RFC5321] erlaubt, dass der Reverse-Path leer ist (siehe Abschnitt 4.5.5 in [RFC5321]). In diesem Fall gibt es keine explizite Absender-Mailbox, und solche Nachrichten können als Benachrichtigungsnachrichten vom E-Mail-System selbst angenommen werden. Wenn der Reverse-Path leer ist, definiert dieses Dokument die Identität "MAIL FROM" als die Mailbox, die aus dem lokalen Teil "postmaster" und der Identität "HELO" besteht (die möglicherweise zuvor separat geprüft wurde oder auch nicht).

2.5 Location of Checks (Ort der Prüfungen)

Autorisierungsprüfungen sollten während der Verarbeitung der SMTP-Transaktion durchgeführt werden, die die E-Mail empfängt. Dies reduziert die Komplexität bei der Bestimmung der korrekten IP-Adresse, die als Eingabe für check_host() verwendet wird, und ermöglicht es, Fehler durch SMTP-Antworten direkt an den sendenden MTA zurückzugeben. Anhang D von [RFC7001] bietet eine umfassendere Diskussion zu diesem Thema.

Autorisierungsprüfungen werden während der SMTP-Transaktion zum Zeitpunkt des MAIL-Befehls durchgeführt und verwenden den MAIL FROM-Wert und die Client-IP-Adresse. Die Durchführung von Prüfungen zu einem späteren Zeitpunkt oder mit anderen Eingaben kann zu folgenden Problemen führen:

Es kann schwierig sein, die erforderlichen Informationen aus potenziell gefälschten Headern genau zu extrahieren.
Legitime E-Mails können die Autorisierungsprüfung nicht bestehen, weil sich die Richtlinie des Absenders geändert hat.

Das Generieren von Unzustellbarkeitsmeldungen an gefälschte Identitäten, die die Autorisierungsprüfung nicht bestanden haben, stellt normalerweise Backscatter dar, d.h. unbrauchbare belästigende Ablehnungsbenachrichtigungen. Betreiber werden dringend aufgefordert, solche Praktiken zu vermeiden. Abschnitt 2 von [RFC3834] beschreibt Backscatter und die damit verbundenen Probleme.

2.6 Results of Evaluation (Bewertungsergebnisse)

Abschnitt 4 definiert check_host(), eine Modellfunktionsdefinition, die die oben definierten Eingaben und die im DNS veröffentlichte Absenderrichtlinie verwendet, um zu Schlussfolgerungen über die Client-Autorisierung zu gelangen. SPF-Verifizierer implementieren etwas, das semantisch äquivalent zur hier definierten Funktion ist.

Dieser Abschnitt listet auf und definiert kurz die möglichen Ausgaben dieser Funktion. Beachten Sie jedoch, dass das Protokoll keine normativen Anforderungen für die Behandlung bestimmter Ergebnisse festlegt. Behandlungsoptionen für jedes Ergebnis werden in Abschnitt 8 diskutiert.

2.6.1 None

Ein Ergebnis von "none" bedeutet, dass (a) aus der SMTP-Sitzung kein syntaktisch gültiger DNS-Domainname extrahiert werden konnte, der als <domain> zur Autorisierung verwendet werden könnte, oder (b) kein SPF-Eintrag aus dem DNS abgerufen wurde.

2.6.2 Neutral (Neutral)

Ein "neutral"-Ergebnis bedeutet, dass das ADMD ausdrücklich erklärt hat, dass es keine Aussage darüber macht, ob die IP-Adresse autorisiert ist oder nicht.

2.6.3 Pass (Bestanden)

Ein "pass"-Ergebnis ist eine explizite Aussage, dass der Client autorisiert ist, E-Mails mit der angegebenen Identität einzuschleusen.

2.6.4 Fail (Fehlgeschlagen)

Ein "fail"-Ergebnis ist eine explizite Aussage, dass der Client nicht autorisiert ist, die Domäne in der angegebenen Identität zu verwenden.

2.6.5 Softfail (Soft-Fail)

Ein "softfail"-Ergebnis ist eine schwache Aussage des veröffentlichenden ADMD, dass der Host möglicherweise nicht autorisiert ist. Es hat keine stärkere, explizitere Richtlinie veröffentlicht, die zu einem "fail" führen würde.

2.6.6 Temperror (Temporärer Fehler)

Ein "temperror"-Ergebnis bedeutet, dass der SPF-Verifizierer bei der Durchführung der Prüfung auf einen vorübergehenden (normalerweise DNS-) Fehler gestoßen ist. Ein erneuter Versuch zu einem späteren Zeitpunkt kann erfolgreich sein, ohne dass weitere Maßnahmen des DNS-Betreibers erforderlich sind.

2.6.7 Permerror (Permanenter Fehler)

Ein "permerror"-Ergebnis bedeutet, dass der veröffentlichte Eintrag der Domäne nicht korrekt interpretiert werden konnte. Dies zeigt eine Fehlerbedingung an, die definitiv ein Eingreifen des DNS-Betreibers zur Behebung erfordert.

3. SPF Records (SPF-Einträge)

Ein SPF-Eintrag ist ein DNS-Eintrag, der erklärt, welche Hosts autorisiert sind (und welche nicht), den Domainnamen in den Identitäten "HELO" und "MAIL FROM" zu verwenden. Grob gesagt teilt der Eintrag Hosts in erlaubte und nicht erlaubte Mengen ein (obwohl einige Hosts möglicherweise zu keiner der beiden Kategorien gehören).

SPF-Einträge werden als eine einzelne Textzeichenfolge dargestellt, die im RDATA eines einzelnen DNS TXT-Ressourceneintrags gefunden wird; mehrere SPF-Einträge mit demselben Eigentümernamen sind nicht erlaubt. Das Eintragsformat und der Prozess zur Auswahl von Einträgen werden im Folgenden in Abschnitt 4 beschrieben. Ein Beispiel-Eintrag ist wie folgt:

v=spf1 +mx a:colo.example.com/28 -all

Dieser Eintrag hat die Version "spf1" und enthält drei Direktiven: "+mx", "a:colo.example.com/28" (implizites "+") und "-all".

Jeder SPF-Eintrag wird im DNS-Baum am Eigentümernamen platziert, zu dem er gehört, nicht in einer Subdomain unter dem Eigentümernamen. Dies ist ähnlich wie bei SRV-Einträgen [RFC2782].

Das Beispiel in diesem Abschnitt könnte durch die folgende Zeile in einer Domain-Zonendatei veröffentlicht werden:

example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all"

Da TXT-Einträge mehrere Zwecke haben, beachten Sie andere TXT-Einträge, die dort für andere Zwecke veröffentlicht wurden. Sie können Größenbeschränkungsprobleme verursachen (siehe Abschnitt 3.4), und es muss darauf geachtet werden, sicherzustellen, dass nur SPF-Einträge für die SPF-Verarbeitung verwendet werden.

ADMDs, die SPF-Einträge veröffentlichen, sollten die Menge an DNS-Informationen, die zur Bewertung des Eintrags erforderlich ist, auf ein Minimum beschränken. Abschnitt 4.6.4 und Abschnitt 10.1.1 geben einige Hinweise zum "include"-Mechanismus und verketteten "redirect"-Modifikatoren.

3.1 DNS Resource Records (DNS-Ressourceneinträge)

SPF-Einträge müssen ausschließlich als DNS TXT (Typ 16) Ressourceneinträge (RR) [RFC1035] veröffentlicht werden. Der Zeicheninhalt des Eintrags ist als [US-ASCII] kodiert. Die SPF-Experimentierungsphase unterstützte die Verwendung eines alternativen DNS RR-Typs, aber dies wurde nun eingestellt.

Im Jahr 2003, als SPF erstmals entwickelt wurde, waren die Anforderungen für die Zuweisung eines neuen DNS RR-Typs strenger als heute. Darüber hinaus war die Unterstützung für die einfache Bereitstellung neuer DNS RR-Typen in DNS-Servern und Konfigurationssystemen nicht weit verbreitet. Daher fanden die SPF-Entwickler es einfacher und praktischer, den TXT RR-Typ zur Speicherung von SPF-Einträgen zu verwenden.

Bei der Überprüfung von [RFC4408] kam die SPFbis-Arbeitsgruppe zu dem Schluss, dass ihr Dual-RR-Typ-Übergangsmodell grundlegend fehlerhaft war, da es keinen universellen RR-Typ enthielt, den Implementierer bereitstellen und überprüfen mussten. Viele Alternativen wurden zur Lösung dieses Problems in Betracht gezogen, aber letztendlich kam die Arbeitsgruppe zu dem Schluss, dass die Wahrscheinlichkeit einer Migration zum SPF RR-Typ in absehbarer Zukunft sehr gering war und die beste Lösung für dieses Interoperabilitätsproblem darin bestand, die Unterstützung für den SPF RR-Typ aus SPF Version 1 zu entfernen. Weitere Informationen finden Sie in Anhang A von [RFC6686].

Die Umstände rund um die anfängliche Bereitstellung von SPF vor einem Jahrzehnt waren einzigartig. Wenn in Zukunft ein SPF-Update entwickelt wird, das bestehende SPF-Einträge nicht wiederverwendet, könnte es den SPF RR-Typ verwenden. Die Verwendung des TXT RR-Typs durch SPF zur Speicherung strukturierter Daten sollte keinesfalls als Präzedenzfall für zukünftige Protokolldesigner angesehen werden. Eine weitere Diskussion über Designüberlegungen bei der Verwendung neuer DNS RR-Typen finden Sie in [RFC5507].

3.2 Multiple DNS Records (Mehrere DNS-Einträge)

Ein Domainname darf niemals mehrere Einträge haben, die dazu führen würden, dass eine Autorisierungsprüfung mehrere Einträge auswählt. Siehe Abschnitt 4.5 für die Auswahlregeln.

3.3 Multiple Strings in a Single DNS Record (Mehrere Strings in einem einzelnen DNS-Eintrag)

Wie in [RFC1035] Abschnitt 3.3 und Abschnitt 3.3.14 definiert, kann ein einzelner Text-DNS-Eintrag aus mehreren Strings bestehen. Wenn ein veröffentlichter Eintrag mehrere Zeichenstrings enthält, muss der Eintrag als diese Strings behandelt werden, die ohne Hinzufügen von Leerzeichen aneinandergehängt sind. Zum Beispiel:

IN TXT "v=spf1 .... first" "second string..."

ist äquivalent zu:

IN TXT "v=spf1 .... firstsecond string..."

TXT-Einträge, die mehrere Strings enthalten, sind nützlich für den Aufbau von Einträgen, die die maximale Länge von 255 Oktetten für eine Zeichenfolge in einem einzelnen TXT-Eintrag überschreiten.

3.4 Record Size (Eintragsgröße)

SPF-Einträge, die für einen bestimmten Domainnamen veröffentlicht werden, sollten klein genug gehalten werden, damit das Abfrageergebnis in 512 Oktette passt. Andernfalls besteht die Möglichkeit, DNS-Protokollgrenzen zu überschreiten. Dieses UDP-Limit ist in [RFC1035] Abschnitt 2.3.4 definiert, obwohl es durch [RFC2671] erhöht wurde. Unter 512 Oktetten zu bleiben sollte verhindern, dass ältere DNS-Implementierungen auf TCP zurückgreifen, und ermöglicht die Verwendung von UDP ohne EDNS0 [RFC6891]-Unterstützung. Da die Antwortgröße von vielen Dingen abhängt, die außerhalb des Umfangs dieses Dokuments liegen, kann nur die folgende Anleitung gegeben werden: Wenn die Größe der DNS-Nachricht, die kombinierte Länge der DNS-Namen und des Textes aller Einträge eines bestimmten Typs weniger als 450 Oktette beträgt, sollte die DNS-Antwort in ein UDP-Paket passen. Aufgrund von Firewalls und anderen Problemen, die den DNS-Betrieb über TCP oder die Verwendung von EDNS0 stören, können Einträge, die zu lang sind, um in ein einzelnes UDP-Paket zu passen, von SPF-Validatoren stillschweigend ignoriert werden.

Beachten Sie, dass bei der Berechnung der Antwortgröße für eine TXT-Format-Abfrage alle anderen TXT-Einträge, die am Domainnamen veröffentlicht wurden, berücksichtigt werden müssen. Ebenso müssen die Antwortgrößen aller SPF-bezogenen Abfragen bewertet werden, um in ein einzelnes 512-Oktett-UDP-Paket zu passen (d.h. DNS-Nachrichtengröße begrenzt auf 450 Oktette).

3.5 Wildcard Records (Wildcard-Einträge)

Die Verwendung von Wildcard-Einträgen für die Veröffentlichung wird entmutigt, und wenn sie verwendet werden, muss Vorsicht walten. Wenn eine Zone Wildcard-MX-Einträge enthält, möchte sie möglicherweise eine Wildcard-Deklaration veröffentlichen, muss jedoch denselben Anforderungen und Problemen unterliegen. Insbesondere muss die Deklaration für jeden Host mit beliebigen RR-Einträgen und deren Subdomains wiederholt werden. Betrachten Sie das Beispiel aus [RFC1034] Abschnitt 4.3.3. Basierend darauf können wir Folgendes tun:

EXAMPLE.COM. MX 10 A.EXAMPLE.COM
EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"

*.EXAMPLE.COM. MX 10 A.EXAMPLE.COM
*.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"

A.EXAMPLE.COM. A 203.0.113.1
A.EXAMPLE.COM. MX 10 A.EXAMPLE.COM
A.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"

*.A.EXAMPLE.COM. MX 10 A.EXAMPLE.COM
*.A.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"

Für jeden Namen innerhalb der Zone muss der SPF-Eintrag zweimal aufgelistet werden: einmal für diesen Namen und einmal mit einem Wildcard, um den Baum unter diesem Namen abzudecken, um alle in ausgehenden E-Mails verwendeten Domains abzudecken.

4. The check_host() Function (Die check_host()-Funktion)

Diese Beschreibung ist keine Anwendungsprogrammierschnittstellen-Definition, sondern eine Funktionsbeschreibung zur Erläuterung des Algorithmus. Konforme SPF-Implementierungen müssen Ergebnisse liefern, die dieser Beschreibung semantisch äquivalent sind.

Die check_host()-Funktion ruft SPF-Einträge ab, analysiert sie und wertet sie aus, um festzustellen, ob ein bestimmter Host berechtigt ist oder nicht berechtigt ist, E-Mails mit einer bestimmten Identität zu senden. Das empfangende ADMD, das diese Überprüfung durchführt, muss die check_host()-Funktion korrekt bewerten, wie hier beschrieben.

Implementierungen können einen anderen Algorithmus als den hier definierten kanonischen Algorithmus verwenden, solange die Ergebnisse in allen Fällen identisch sind.

4.1 Arguments (Argumente)

Die check_host()-Funktion nimmt die folgenden Argumente:

<ip> - Die IP-Adresse des SMTP-Clients, der die E-Mail sendet, entweder IPv4 oder IPv6.

<domain> - Die Domain, die die gesuchten Autorisierungsinformationen bereitstellt; anfänglich der Domain-Teil der "MAIL FROM"- oder "HELO"-Identität.

<sender> - Die "MAIL FROM"- oder "HELO"-Identität.

Für rekursive Auswertungen kann sich der Domain-Teil von <sender> vom <domain>-Argument bei der ersten Auswertung von check_host() unterscheiden. In den meisten anderen Fällen wird es dasselbe sein (siehe Abschnitt 5.2 unten). Die Gesamt-DNS-Abfragebeschränkung für SPF-Terme, die in Abschnitt 4.6.4 beschrieben wird, muss als einzelnes globales Limit über alle Auswertungen hinweg verfolgt werden, nicht nur für eine einzelne rekursive Auswertungsinstanz.

Beachten Sie, dass das <domain>-Argument möglicherweise kein wohlgeformter Domain-Name ist. Wenn beispielsweise der Reverse-Path leer ist, wird die EHLO/HELO-Domain mit den damit verbundenen Problemen verwendet (siehe Abschnitt 2.3). In diesen Fällen ist check_host() in Abschnitt 4.3 so definiert, dass es ein "none"-Ergebnis zurückgibt.

4.2 Results (Ergebnisse)

Die check_host()-Funktion kann eines von mehreren Ergebnissen zurückgeben, die in Abschnitt 2.6 beschrieben sind. Die zu ergreifende Aktion basierend auf dem Ergebnis wird durch die lokale Richtlinie des Empfängers bestimmt. Dies wird in Abschnitt 8 diskutiert.

4.3 Initial Processing (Anfangsverarbeitung)

Wenn <domain> fehlerhaft formatiert ist (z.B. Label-Länge über 63 Zeichen, nicht-endende Null-Längen-Labels usw.) oder kein Multi-Label-Domain-Name ist, oder wenn die DNS-Abfrage "Name Error" (RCODE 3, auch bekannt als "NXDOMAIN" [RFC2308]) zurückgibt, gibt check_host() sofort das Ergebnis "none" zurück. DNS RCODEs sind in [RFC1035] definiert. Ein wohlgeformter Domain ist ein vollqualifizierter Domain-Name, wie in [RFC1983] definiert. Das heißt, im DNS sind sie implizit relativ zur Root qualifiziert (siehe Abschnitt 3.1 von [RFC1034]). Internationalisierte Domain-Namen müssen als A-Label kodiert werden, wie in Abschnitt 2.3 von [RFC5890] beschrieben.

Wenn <sender> keinen local-part hat, ersetzen Sie den local-part durch die Zeichenkette "postmaster".

4.4 Record Lookup (Eintragsabfrage)

Abhängig davon, wie der Eintrag veröffentlicht wird (siehe Abschnitt 3 oben), ist eine DNS-Abfrage für den <domain>-Namen erforderlich, nur für Typ TXT.

Wenn die DNS-Abfrage einen Server-Fehler (RCODE 2) oder einen anderen Fehler (RCODE nicht 0 oder 3) zurückgibt, oder wenn die Abfrage eine Zeitüberschreitung hat, terminiert check_host() sofort mit dem Ergebnis "temperror".

4.5 Selecting Records (Auswahl von Einträgen)

Einträge beginnen mit einem Versionsteil:

record = version terms *SP
version = "v=spf1"

Beginnend mit der aus der Abfrage zurückgegebenen Eintrags-Menge, verwerfen Sie Einträge, die nicht mit einem Versionsteil von genau "v=spf1" beginnen. Beachten Sie, dass der Versionsteil durch ein SP-Zeichen oder das Ende des Eintrags terminiert wird. Zum Beispiel passt ein Eintrag mit einem Versionsteil "v=spf10" nicht und wird verworfen.

Wenn die resultierende Eintrags-Menge keine Einträge enthält, liefert check_host() ein "none"-Ergebnis. Wenn die resultierende Eintrags-Menge mehrere Einträge enthält, liefert check_host() ein "permerror"-Ergebnis.

4.6 Record Evaluation (Eintragsbewertung)

Die check_host()-Funktion analysiert und interpretiert den SPF-Eintrag, um ein Ergebnis für den aktuellen Test zu finden. Zunächst wird die Syntax des Eintrags validiert, und wenn irgendwo im Eintrag Syntaxfehler vorliegen, gibt check_host() sofort das Ergebnis "permerror" zurück, ohne weitere Interpretation oder Bewertung.

4.6.1 Term Evaluation (Term-Bewertung)

Es gibt zwei Arten von Termen: Mechanismen (definiert in Abschnitt 5) und Modifikatoren (definiert in Abschnitt 6). Einträge enthalten eine geordnete Liste dieser, wie in der folgenden erweiterten Backus-Naur-Form (ABNF) angegeben.

terms = *( 1*SP ( directive / modifier ) )

directive = [ qualifier ] mechanism
qualifier = "+" / "-" / "?" / "~"
mechanism = ( all / include
            / a / mx / ptr / ip4 / ip6 / exists )
modifier = redirect / explanation / unknown-modifier
unknown-modifier = name "=" macro-string
                 ; where name is not any known modifier

name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )

Die meisten Mechanismen erlauben ein ":" oder "/" Zeichen nach dem Namen.

Modifikatoren enthalten immer ein Gleichheitszeichen ('=') unmittelbar nach dem Namen und vor jedem ":" oder "/" Zeichen, das Teil eines macro-string sein könnte.

Ein Term, der keines der Zeichen "=", ":" oder "/" enthält, ist ein Mechanismus, wie in Abschnitt 5 definiert.

Nach der ABNF-Notation, wie in [RFC5234] definiert, sind Mechanismus- und Modifikatornamen nicht case-sensitiv.

4.6.2 Mechanisms (Mechanismen)

Jeder Mechanismus wird der Reihe nach von links nach rechts betrachtet. Wenn es keine weiteren Mechanismen gibt, ist das Ergebnis das in Abschnitt 4.7 beschriebene Standardergebnis.

Wenn ein Mechanismus bewertet wird, können drei Dinge geschehen: Es kann übereinstimmen, nicht übereinstimmen oder eine Ausnahme zurückgeben.

Wenn es übereinstimmt, endet die Verarbeitung und der Qualifier-Wert wird als Ergebnis für diesen Eintrag zurückgegeben. Wenn es nicht übereinstimmt, wird mit dem nächsten Mechanismus fortgefahren. Wenn es eine Ausnahme zurückgibt, endet die Mechanismusverarbeitung und der Ausnahmewert wird zurückgegeben.

Die möglichen Qualifier und die Ergebnisse, die sie dazu veranlassen, dass check_host() zurückgibt, sind wie folgt:

"+" pass
"-" fail
"~" softfail
"?" neutral

Der Qualifier ist optional und standardmäßig "+".

Wenn der Mechanismus übereinstimmt und der Qualifier "-" ist, wird ein "fail"-Ergebnis zurückgegeben und die Erklärungszeichenkette wird berechnet, wie in Abschnitt 6.2 beschrieben.

Abschnitt 5 beschreibt die spezifischen Mechanismen.

4.6.3 Modifiers (Modifikatoren)

Modifikatoren sind keine Mechanismen. Sie geben keine Übereinstimmung oder Nicht-Übereinstimmung zurück. Stattdessen liefern sie zusätzliche Informationen. Obwohl Modifikatoren die Bewertung des Eintrags nicht direkt beeinflussen, hat der "redirect"-Modifikator nach der Bewertung aller Mechanismen eine Auswirkung.

4.6.4 DNS Lookup Limits (DNS-Abfragebeschränkungen)

Einige Mechanismen und Modifikatoren (zusammen als "Terme" bezeichnet) verursachen bei der Bewertung DNS-Abfragen, während andere dies nicht tun. Die folgenden Terme verursachen DNS-Abfragen: die Mechanismen "include", "a", "mx", "ptr" und "exists" sowie der "redirect"-Modifikator. SPF-Implementierungen müssen die Gesamtzahl dieser Terme während einer SPF-Auswertung auf 10 begrenzen, um eine unangemessene Last auf DNS zu vermeiden. Wenn dieses Limit überschritten wird, muss die Implementierung "permerror" zurückgeben. Andere Terme -- die Mechanismen "all", "ip4" und "ip6" sowie der "exp"-Modifikator -- verursachen keine DNS-Abfragen bei der SPF-Auswertung (der "exp"-Modifikator verursacht nur zu einem späteren Zeitpunkt eine Abfrage), und ihre Verwendung unterliegt nicht diesem Limit.

Bei der Bewertung des "mx"-Mechanismus ist die Anzahl der abgefragten "MX"-Ressourceneinträge in der oben genannten Gesamtbeschränkung von 10 Mechanismen/Modifikatoren enthalten, die DNS-Abfragen verursachen. Zusätzlich zu dieser Beschränkung darf die Bewertung jedes "MX"-Eintrags absolut nicht dazu führen, dass mehr als 10 Adresseinträge abgefragt werden -- "A"- oder "AAAA"-Ressourceneinträge. Wenn dieses Limit überschritten wird, muss der "mx"-Mechanismus ein "permerror"-Ergebnis liefern.

Bei der Bewertung des "ptr"-Mechanismus oder des %\{p}-Makros ist die Anzahl der abgefragten "PTR"-Ressourceneinträge in der oben genannten Gesamtbeschränkung von 10 Mechanismen/Modifikatoren enthalten, die DNS-Abfragen verursachen. Zusätzlich zu dieser Beschränkung darf die Bewertung jedes "PTR"-Eintrags absolut nicht dazu führen, dass mehr als 10 Adresseinträge abgefragt werden -- "A"- oder "AAAA"-Ressourceneinträge. Wenn dieses Limit überschritten wird, müssen alle Einträge außer den ersten 10 ignoriert werden.

Der Grund für den Unterschied ist, dass der Satz und Inhalt von MX-Einträgen unter der Kontrolle des veröffentlichenden ADMD steht, während der Satz und Inhalt von PTR-Einträgen unter der Kontrolle des Besitzers der IP-Adresse steht, die tatsächlich die Verbindung herstellt.

Diese Beschränkungen gelten pro Mechanismus oder Makro in einem Eintrag und sind zusätzlich zu den oben angegebenen Abfragebeschränkungen.

Ein MTA oder anderer Prozessor sollte eine Beschränkung der maximalen verstrichenen Zeit auferlegen, die für die Bewertung von check_host() verwendet wird. Eine solche Beschränkung sollte mindestens 20 Sekunden zulassen. Wenn eine solche Beschränkung überschritten wird, sollte das Autorisierungsergebnis "temperror" sein.

Wie am Ende von Abschnitt 11.1 erwähnt, kann es in einigen Fällen nützlich sein, die Anzahl der "Terme" zu begrenzen, die DNS-Abfragen zurückgeben, die eine positive Antwort (RCODE 0) mit einer Antwortanzahl von 0 oder eine "Name Error"-Antwort (RCODE 3) zurückgeben. Diese werden manchmal zusammen als "void lookups" bezeichnet. SPF-Implementierungen sollten "void lookups" auf zwei begrenzen. Implementierungen können wählen, ein solches Limit konfigurierbar zu machen. In diesem Fall wird empfohlen, dass der Standardwert zwei beträgt. Das Überschreiten des Limits führt zu einem "permerror"-Ergebnis.

4.7 Default Result (Standardergebnis)

Wenn keiner der Mechanismen übereinstimmt und es keinen "redirect"-Modifikator gibt, gibt check_host() das Ergebnis "neutral" zurück, so als ob "?all" als letztes Direktiv angegeben wäre. Wenn ein "redirect"-Modifikator vorhanden ist, fährt check_host() fort, wie in Abschnitt 6.1 definiert.

Es wird bevorzugt, einen "redirect"-Modifikator oder einen "all"-Mechanismus zu verwenden, um die Verarbeitung explizit zu beenden. Obwohl es ein implizites "?all" am Ende jedes Eintrags gibt, der nicht explizit terminiert, hilft es bei Debugging-Bemühungen, wenn es explizit bereitgestellt wird.

Beispiel:

v=spf1 +mx -all

Oder

v=spf1 +mx redirect=_spf.example.com

4.8 Domain Specification (Domain-Spezifikation)

Mehrere dieser Mechanismen und Modifikatoren haben einen <domain-spec>-Teil. Die Zeichenkette wird der Makroerweiterung unterzogen (siehe Abschnitt 7). Die resultierende Zeichenkette ist die übliche Darstellung eines vollqualifizierten DNS-Namens: eine Folge von Labels, die durch Punkte getrennt sind. Diese Domain wird im Rest dieses Dokuments als <target-name> bezeichnet.

Hinweis: Das Ergebnis der Makroerweiterung unterliegt keinem weiteren Escaping. Daher kann dieses Tool nicht alle Zeichen erzeugen, die in DNS-Labels legal sind (z.B. Steuerzeichen). Dieses Tool ist jedoch leistungsfähig genug, um legale Hostnamen und übliche Utility-Labels auszudrücken, die im DNS verwendet werden (z.B. "_spf").

Für mehrere Mechanismen ist <domain-spec> optional. Wenn es nicht bereitgestellt wird, wird das <domain> aus den check_host()-Argumenten (siehe Abschnitt 4.1) als <target-name> verwendet. "domain" und <target-name> sind nach der Makroerweiterung syntaktisch identisch. "domain" ist der Eingabewert für check_host(), während <target-name> von check_host() berechnet wird.

Die Bewertung von check_host() mit einer syntaktisch ungültigen Domain ist undefiniert.

Hinweis: Dieses Dokument und sein Vorgänger enthalten keine Bestimmung für die korrekte Behandlung von syntaktisch ungültigen <domain-spec> (möglicherweise das Ergebnis einer Makroerweiterung) gemäß [RFC1035]. Beispiele sind Namen mit leeren Labels wie "foo..example.com" und Labels mit einer Länge von mehr als 63 Zeichen. Einige Implementierungen wählen, solche Fehler als Nicht-Übereinstimmung zu behandeln und solche Namen daher zu ignorieren, während andere Implementierungen eine "permerror"-Ausnahme zurückgeben.

5. Mechanism Definitions (Mechanismusdefinitionen)

Dieser Abschnitt definiert zwei Arten von Mechanismen: Grundlegende Sprachrahmen-Mechanismen und Absender-spezifizierende Mechanismen.

Die grundlegenden Mechanismen erleichtern den Sprachrahmen. Sie spezifizieren keine bestimmte Art von Autorisierungsschema. Die grundlegenden Mechanismen sind wie folgt:

all
include

Die Absender-spezifizierenden Mechanismen werden verwendet, um einen Satz von <ip>-Adressen zu identifizieren, die berechtigt oder nicht berechtigt sind, E-Mails mit <domain> zu senden. Die Absender-spezifizierenden Mechanismen sind wie folgt:

a
mx
ptr (do not use)
ip4
ip6
exists

Die folgenden Konventionen gelten für alle Mechanismen, die jederzeit einen Vergleich zwischen <target-name> und einer IP-Adresse durchführen:

Wenn im Direktiv keine CIDR-Präfixlänge angegeben ist, wird <target-name> auf Gleichheit mit der IP-Adresse verglichen. (Hier ist CIDR Classless Inter-Domain Routing, beschrieben in [RFC4632].)

Wenn eine CIDR-Präfixlänge angegeben ist, wird nur die angegebene Anzahl von High-Order-Bits von <target-name> auf Gleichheit mit der IP-Adresse verglichen.

Wenn ein Mechanismus Host-Adressen abruft, um sie mit <ip> zu vergleichen, werden "A"-Einträge abgerufen, wenn <ip> IPv4 ist, und "AAAA"-Einträge werden abgerufen, wenn <ip> eine IPv6-Adresse ist. SPF-Implementierungen auf IPv6-Servern müssen sowohl "AAAA"- als auch "A"-Einträge für Clients auf IPv4-mapped IPv6-Adressen [RFC4291] verarbeiten. IPv4-Adressen werden nur im SPF-Eintrag mit dem "ip4"-Mechanismus aufgeführt.

Mehrere Mechanismen hängen von Informationen ab, die aus DNS abgerufen werden. Für diese DNS-Abfragen, sofern nicht anders angegeben, wenn der DNS-Server einen Fehler zurückgibt (RCODE nicht 0 oder 3) oder wenn die Abfrage eine Zeitüberschreitung hat, stoppt der Mechanismus und die oberste check_host() gibt "temperror" zurück. Wenn der Server "Name Error" (RCODE 3) zurückgibt, fährt die Bewertung des Mechanismus fort, als ob der Server ohne Fehler (RCODE 0) und null Antworteinträge zurückgegeben hätte.

5.1 "all"

all = "all"

Der "all"-Mechanismus ist ein Test, der immer übereinstimmt. Er wird als rechtester Mechanismus im Eintrag verwendet, um einen expliziten Standardwert bereitzustellen.

Beispiel:

v=spf1 a mx -all

Mechanismen nach "all" werden niemals getestet. Nach "all" aufgeführte Mechanismen müssen ignoriert werden. Wenn ein "all"-Mechanismus im Eintrag vorhanden ist, muss jeder "redirect"-Modifikator (Abschnitt 6.1) ignoriert werden, unabhängig von der relativen Reihenfolge der Terme.

5.2 "include"

include = "include" ":" domain-spec

Der "include"-Mechanismus löst eine rekursive Auswertung von check_host() aus.

<domain-spec> wird gemäß Abschnitt 7 erweitert.
check_host() wird mit der resultierenden Zeichenkette als <domain> bewertet. Die <ip>- und <sender>-Parameter bleiben dieselben wie in der aktuellen Bewertung von check_host().
Die rekursive Auswertung gibt Übereinstimmung, Nicht-Übereinstimmung oder Fehler zurück.
Wenn sie Übereinstimmung zurückgibt, verwendet der "include"-Mechanismus das entsprechende Ergebnis (z.B. erzeugt include oder +include ein "pass"-Ergebnis, -include erzeugt "fail").
Wenn sie Nicht-Übereinstimmung oder Fehler zurückgibt, setzt die übergeordnete check_host() die Verarbeitung gemäß der folgenden Tabelle fort und stellt den vorherigen <domain>-Wert wieder her.

Im Nachhinein war der Name "include" eine schlechte Wahl. Nur das Bewertungsergebnis des referenzierten SPF-Eintrags wird verwendet, anstatt die Mechanismen des referenzierten Eintrags im ersten Eintrag wörtlich einzuschließen. Beispielsweise beendet die Auswertung eines "-all"-Direktivs im referenzierten Eintrag nicht die Gesamtverarbeitung und führt nicht notwendigerweise zu einem allgemeinen "fail". (Bessere Namen für diesen Mechanismus wären "if-match", "on-match" usw. gewesen.)

Der "include"-Mechanismus ermöglicht es einer Domain, mehrere administrativ unabhängige Domains anzugeben. Zum Beispiel könnte die Vanity-Domain "example.net" E-Mails mit den Servern der administrativ unabhängigen Domains example.com und example.org senden.

Example.net könnte sagen

IN TXT "v=spf1 include:example.com include:example.org -all"

Dies würde check_host() anweisen, die Einträge von example.com und example.org effektiv auf ein "pass"-Ergebnis zu überprüfen. Nur wenn der Host von keiner dieser beiden Domains erlaubt ist, wäre das Ergebnis "fail".

Ob dieser Mechanismus übereinstimmt, nicht übereinstimmt oder eine Ausnahme zurückgibt, hängt vom Ergebnis der rekursiven Auswertung von check_host() ab:

+---------------------------------+---------------------------------+
| A recursive check_host() result | Causes the "include" mechanism |
| of:                             | to:                            |
+---------------------------------+---------------------------------+
| pass                            | match                          |
|                                 |                                |
| fail                            | not match                      |
|                                 |                                |
| softfail                        | not match                      |
|                                 |                                |
| neutral                         | not match                      |
|                                 |                                |
| temperror                       | return temperror               |
|                                 |                                |
| permerror                       | return permerror               |
|                                 |                                |
| none                            | return permerror               |
+---------------------------------+---------------------------------+

Der "include"-Mechanismus ist dazu gedacht, administrative Grenzen zu überschreiten. Wenn man innerhalb einer einzelnen administrativen Autorität bleibt, ist "include" in der Regel nicht die beste Wahl. Wenn zum Beispiel example.com und example.org von derselben Entität verwaltet werden und wenn der Satz erlaubter Hosts für beide Domains "mx:example.com" ist, könnte example.org "include:example.com" spezifizieren, aber es wäre besser, "redirect=example.com" oder sogar "mx:example.com" zu spezifizieren.

Mit dem "include"-Mechanismus ist es möglich, einen administrativ externen Satz von Hosts zu autorisieren, aber die Bestimmung der Absenderrichtlinie bleibt eine Funktion des SPF-Eintrags der ursprünglichen Domain (bestimmt durch den "all"-Mechanismus in diesem Eintrag). Der "redirect"-Modifikator eignet sich besser, um Autorisierung und Richtlinie in einen gemeinsamen Satz zu konsolidieren, der innerhalb eines ADMD geteilt werden soll. Redirect ist eher wie ein gemeinsames Code-Element, das zwischen Einträgen innerhalb eines einzelnen ADMD geteilt werden soll. Die autorisierten Hosts und Richtlinien einer beliebigen Anzahl von Domains können von einem einzelnen Eintrag aus gesteuert werden.

5.3 "a"

Dieser Mechanismus stimmt überein, wenn <ip> eine der IP-Adressen von <target-name> ist. Zur Klarstellung bedeutet dies, dass der "a"-Mechanismus auch mit AAAA-Einträgen übereinstimmt.

a = "a" [ ":" domain-spec ] [ dual-cidr-length ]

Es wird eine Adressabfrage für <target-name> durchgeführt, wobei der Abfragetyp (A oder AAAA) verwendet wird, der für den Verbindungstyp (IPv4 oder IPv6) geeignet ist. <ip> wird mit den zurückgegebenen Adressen verglichen. Wenn eine Adresse übereinstimmt, stimmt der Mechanismus überein.

5.4 "mx"

Dieser Mechanismus stimmt überein, wenn <ip> einer der MX-Hosts des Domainnamens ist.

mx = "mx" [ ":" domain-spec ] [ dual-cidr-length ]

check_host() führt zuerst eine MX-Abfrage für <target-name> durch. Dann führt es eine Adressabfrage für jeden zurückgegebenen MX-Namen durch. <ip> wird mit jeder zurückgegebenen IP-Adresse verglichen. Um Denial-of-Service (DoS)-Angriffe zu verhindern, müssen die in Abschnitt 4.6.4 definierten Verarbeitungsgrenzen eingehalten werden. Wenn das MX-Abfragelimit überschritten wird, wird "permerror" zurückgegeben und die Bewertung wird beendet. Wenn eine Adresse übereinstimmt, stimmt der Mechanismus überein.

Hinweis zu impliziten MX-Einträgen: Wenn <target-name> keine MX-Einträge hat, darf check_host() die implizite MX-Regel von [RFC5321] nicht anwenden, d.h. A- oder AAAA-Einträge für denselben Namen abfragen.

5.5 "ptr" (do not use) ("ptr" (nicht verwenden))

Dieser Mechanismus testet, ob die DNS-Umkehrabbildung von <ip> existiert und korrekt auf einen Domainnamen innerhalb einer bestimmten Domain zeigt. Dieser Mechanismus sollte nicht veröffentlicht werden. Weitere Informationen finden Sie in den Hinweisen am Ende dieses Abschnitts.

ptr = "ptr" [ ":" domain-spec ]

Der Name für <ip> wird mithilfe des folgenden Verfahrens nachgeschlagen:

Führen Sie eine DNS-Umkehrabbildung für <ip> durch: Suchen Sie den entsprechenden PTR-Eintrag in "in-addr.arpa.", wenn die Adresse IPv4 ist, oder in "ip6.arpa.", wenn sie IPv6 ist.
Überprüfen Sie für jeden zurückgegebenen Eintrag den Domainnamen, indem Sie seine IP-Adresse nachschlagen. Um DoS-Angriffe zu verhindern, müssen die in Abschnitt 4.6.4 definierten PTR-Verarbeitungsgrenzen angewendet werden. Wenn die Grenzen überschritten werden, beenden Sie die Verarbeitung, und der Mechanismus stimmt nicht überein.
Wenn <ip> in den zurückgegebenen IP-Adressen enthalten ist, ist dieser Domainname validiert.

Überprüfen Sie alle validierten Domainnamen, um festzustellen, ob sie mit <target-name> übereinstimmen oder Subdomains von <target-name> sind. Wenn es Übereinstimmungen gibt, stimmt dieser Mechanismus überein. Wenn keine validierten Domainnamen gefunden werden können oder wenn keine validierten Domainnamen mit <target-name> übereinstimmen oder Subdomains davon sind, kann dieser Mechanismus nicht übereinstimmen. Wenn bei der Ausführung der PTR-RR-Abfrage ein DNS-Fehler auftritt, kann dieser Mechanismus nicht übereinstimmen. Wenn bei der Ausführung einer A-RR-Abfrage ein DNS-Fehler auftritt, wird dieser Domainname übersprungen und die Suche fortgesetzt.

Dieser Mechanismus stimmt überein, wenn:

<target-name> eine Subdomain des validierten Domainnamens ist, oder
<target-name> und der validierte Domainname identisch sind.

Zum Beispiel ist "mail.example.com" innerhalb der Domain "example.com", aber "mail.bad-example.com" nicht.

Hinweis: Dieser Mechanismus ist langsam, bei DNS-Fehlern nicht so zuverlässig wie andere Mechanismen und belastet die .arpa-Nameserver stark. Bei Verwendung müssen entsprechende PTR-Einträge für die Hosts der Domain eingerichtet werden, und der "ptr"-Mechanismus sollte einer der zuletzt überprüften Mechanismen sein. Nach mehreren Jahren Erfahrung mit der SPF-Bereitstellung wurde der Schluss gezogen, dass er unnötig ist und zuverlässigere Alternativen verwendet werden sollten. Er bleibt jedoch Teil des SPF-Protokolls, sodass konforme check_host()-Implementierungen ihn unterstützen müssen.

5.6 "ip4" and "ip6" ("ip4" und "ip6")

Diese Mechanismen testen, ob <ip> in einem gegebenen IP-Netzwerk enthalten ist.

ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ]

ip4-cidr-length = "/" ("0" / %x31-39 0*1DIGIT) ; value range 0-32
ip6-cidr-length = "/" ("0" / %x31-39 0*2DIGIT) ; value range 0-128
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]

ip4-network = qnum "." qnum "." qnum "." qnum
qnum = DIGIT                      ; 0-9
     / %x31-39 DIGIT              ; 10-99
     / "1" 2DIGIT                 ; 100-199
     / "2" %x30-34 DIGIT          ; 200-249
     / "25" %x30-35               ; 250-255
     ; as per conventional dotted-quad notation, e.g., 192.0.2.0

ip6-network = &lt;as per [RFC5952], Section 4>
            ; e.g., 2001:db8::cd30

Vergleichen Sie <ip> mit dem gegebenen Netzwerk. Wenn die High-Order-Bits der CIDR-Präfixlänge übereinstimmen, stimmt der Mechanismus überein.

Wenn ip4-cidr-length weggelassen wird, wird es als "/32" behandelt. Wenn ip6-cidr-length weggelassen wird, wird es als "/128" behandelt. Es ist nicht erlaubt, Teile der IP-Adresse wegzulassen, anstatt die CIDR-Notation zu verwenden. Das heißt, verwenden Sie 192.0.2.0/24 anstatt 192.0.2.

5.7 "exists"

Dieser Mechanismus wird verwendet, um einen beliebigen Domainnamen für eine DNS-A-Eintragsabfrage zu konstruieren. Er ermöglicht komplexe Schemata, die beliebige Teile des Mail-Envelopes einbeziehen, um zu bestimmen, was erlaubt ist.

exists = "exists" ":" domain-spec

<domain-spec> wird gemäß Abschnitt 7 erweitert. Der resultierende Domainname wird für eine DNS-A-RR-Abfrage verwendet (auch wenn der Verbindungstyp IPv6 ist). Wenn A-Einträge zurückgegeben werden, stimmt dieser Mechanismus überein.

Domains können diesen Mechanismus verwenden, um beliebig komplexe Abfragen anzugeben. Angenommen, example.com veröffentlicht den Eintrag:

v=spf1 exists:%\{ir}.%\{l1r+-}._spf.%\{d} -all

<target-name> könnte sich zu "1.2.0.192.someuser._spf.example.com" erweitern. Dies ermöglicht es, feingranulare Entscheidungen auf Benutzer- und Client-IP-Adressebene zu treffen.

6. Modifier Definitions (Modifikator-Definitionen)

Modifikatoren sind Name/Wert-Paare, die zusätzliche Informationen liefern. Modifikatoren haben immer ein "=" das Name und Wert trennt.

Die in diesem Dokument definierten Modifikatoren ("redirect" und "exp") sollten am Ende des Eintrags erscheinen, nach allen Mechanismen, obwohl sie syntaktisch an jeder Stelle im Eintrag erscheinen können. Die Reihenfolge dieser beiden Modifikatoren ist irrelevant. Diese beiden Modifikatoren dürfen in einem Eintrag absolut nicht mehr als einmal erscheinen. Wenn sie es tun, beendet check_host() mit einem "permerror"-Ergebnis.

Nicht erkannte Modifikatoren müssen ignoriert werden, unabhängig davon wo oder wie oft sie erscheinen. Dies ermöglicht es Implementierungen, die diesem Dokument entsprechen, Einträge mit Modifikatoren, die in anderen Spezifikationen definiert sind, angemessen zu handhaben.

6.1 redirect: Redirected Query (redirect: Umgeleitete Abfrage)

Der "redirect"-Modifikator ist dazu gedacht, Autorisierung und Richtlinie in einen gemeinsamen Satz zu konsolidieren, der innerhalb eines einzelnen ADMD geteilt werden soll. Die autorisierten Hosts und Richtlinien einer beliebigen Anzahl von Domains können von einem einzelnen Eintrag aus gesteuert werden.

redirect = "redirect" "=" domain-spec

Wenn alle Mechanismen nicht übereinstimmen und ein "redirect"-Modifikator vorhanden ist, erfolgt die Verarbeitung wie folgt:

Der <domain-spec>-Teil des redirect-Teils wird gemäß den Makroregeln in Abschnitt 7 erweitert. Dann wird check_host() mit der resultierenden Zeichenkette als <domain> bewertet. Die <ip>- und <sender>-Parameter bleiben dieselben wie in der aktuellen Bewertung von check_host().

Das Ergebnis dieser neuen Bewertung von check_host() wird dann als Ergebnis der aktuellen Bewertung behandelt, außer dass wenn kein SPF-Eintrag gefunden wird oder wenn <target-name> fehlerhaft formatiert ist, das Ergebnis "permerror" anstatt "none" ist.

Beachten Sie, dass die Domain der neuen Abfrage selbst eine Redirect-Verarbeitung spezifizieren kann.

Dieses Tool ist für Organisationen gedacht, die denselben Eintrag auf mehrere Domains anwenden möchten. Zum Beispiel:

la.example.com. TXT "v=spf1 redirect=_spf.example.com"
ny.example.com. TXT "v=spf1 redirect=_spf.example.com"
sf.example.com. TXT "v=spf1 redirect=_spf.example.com"
_spf.example.com. TXT "v=spf1 mx:example.com -all"

In diesem Beispiel werden E-Mails von einer dieser drei Domains durch denselben Eintrag beschrieben. Dies kann administrativ vorteilhaft sein.

Hinweis: Im Allgemeinen kann Domain "A" nicht zuverlässig eine Umleitung zu einer anderen Domain "B" verwenden, die nicht unter derselben administrativen Kontrolle steht. Da <domain> unverändert bleibt, gibt es keine Garantie, dass der Eintrag bei Domain "B" für Mailboxen in Domain "A" korrekt funktioniert, insbesondere wenn Domain "B" Mechanismen verwendet, die den local-part einbeziehen. Die "include"-Direktive wäre im Allgemeinen angemessener.

Zur Klarheit sollte jeder "redirect"-Modifikator als letzter Term im Eintrag erscheinen. Wenn irgendwo im Eintrag ein "all"-Mechanismus vorhanden ist, muss jeder "redirect"-Modifikator ignoriert werden.

6.2 exp: Explanation (exp: Erklärung)

explanation = "exp" "=" domain-spec

Wenn check_host() aufgrund eines übereinstimmenden Mechanismus (wie z.B. "-all") zu "fail" führt und ein "exp"-Modifikator vorhanden ist, wird die zurückgegebene Erklärungszeichenkette wie unten beschrieben berechnet. Wenn kein "exp"-Modifikator vorhanden ist, muss entweder eine Standard-Erklärungszeichenkette oder eine leere Erklärungszeichenkette an die aufrufende Anwendung zurückgegeben werden.

<domain-spec> wird einer Makroerweiterung unterzogen (siehe Abschnitt 7) und wird zu <target-name>. Das DNS TXT RRset für <target-name> wird abgerufen.

Wenn es irgendwelche DNS-Verarbeitungsfehler gibt (beliebiger RCODE nicht 0), oder wenn keine Einträge zurückgegeben werden, oder wenn mehr als ein Eintrag zurückgegeben wird, oder wenn es Syntaxfehler in der Erklärungszeichenkette gibt, wird fortgefahren, als ob kein "exp"-Modifikator gegeben worden wäre.

Die Zeichenketten des abgerufenen TXT-Eintrags werden ohne Leerzeichen verkettet und dann als explain-string verarbeitet, der einer Makroerweiterung unterzogen wird. Dieses Endergebnis ist die Erklärungszeichenkette. Implementierungen können die Länge der resultierenden Erklärungszeichenkette begrenzen, um andere Protokollbeschränkungen und/oder vernünftige Verarbeitungsgrenzen zu berücksichtigen. Da die Erklärungszeichenkette für die Verwendung in SMTP-Antworten gedacht ist und Abschnitt 2.4 von [RFC5321] besagt, dass Antworten [US-ASCII] sind, muss die Erklärungszeichenkette auf [US-ASCII] beschränkt sein.

Software, die check_host() bewertet, kann diese Zeichenkette verwenden, um Informationen von der veröffentlichenden Domain in Form einer kurzen Nachricht oder URL zu kommunizieren. Software sollte deutlich machen, dass die Erklärungszeichenkette von einem Dritten stammt. Sie könnte beispielsweise die Makrozeichenkette "%\{o} explains: " der Erklärung voranstellen, wie im Beispiel in Abschnitt 8.4 gezeigt.

Angenommen, example.com hat diesen Eintrag:

v=spf1 mx -all exp=explain._spf.%\{d}

Hier sind einige Beispiele für mögliche Erklärungs-TXT-Einträge bei explain._spf.example.com:

"Mail from example.com should only be sent by its own servers."

-- eine einfache, konstante Nachricht

"%\{i} is not one of %\{d}'s designated mail servers."

-- eine Nachricht, die mehr Informationen enthält, einschließlich der IP-Adresse, die die Prüfung nicht bestanden hat

"See http://%\{d}/why.html?s=%\{S}&i=%\{I}"

-- ein komplexes Beispiel, das die Parameter von check_host() verwendet, um eine URL zu konstruieren, sodass eine Webseite mit detaillierten, benutzerdefinierten Anweisungen generiert werden kann

Hinweis: Während der Rekursion in einen "include"-Mechanismus darf der "exp"-Modifikator aus <target-name> absolut nicht verwendet werden. Umgekehrt darf bei der Ausführung eines "redirect"-Modifikators der "exp"-Modifikator aus der ursprünglichen Domain absolut nicht verwendet werden. Dies liegt daran, dass "include" dazu gedacht ist, administrative Grenzen zu überschreiten, und die zu liefernde Erklärung sollte die vom empfangenden ADMD sein, während "redirect" als Werkzeug zur Konsolidierung von Richtlinieneinträgen innerhalb eines ADMD gedacht ist und daher die umgeleitete Erklärung diejenige ist, die Vorrang haben sollte.

7. Macros (Makros)

Bei der Bewertung von SPF-Richtlinieneinträgen sind bestimmte Zeichenfolgen dazu gedacht, durch Parameter der Nachricht oder der Verbindung ersetzt zu werden. Diese Zeichenfolgen werden als "Makros" bezeichnet.

7.1 Formal Specification (Formale Spezifikation)

Die ABNF-Beschreibung für Makros lautet wie folgt:

domain-spec = macro-string domain-end
domain-end = ( "." toplabel [ "." ] ) / macro-expand

explain-string = *( macro-string / SP )

macro-string = *( macro-expand / macro-literal )
macro-literal = %x21-24 / %x26-7E
              ; visible characters except "%"

macro-expand = ( "%\{" macro-letter transformers *delimiter "}" )
             / "%%" / "%_" / "%-"

macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
               "c" / "r" / "t" / "v"

transformers = *DIGIT [ "r" ]
delimiter = "." / "-" / "+" / "," / "/" / "_" / "="

toplabel = ( *alphanum ALPHA *alphanum ) /
           ( 1*alphanum "-" *( alphanum / "-" ) alphanum )
           ; LDH rule plus additional TLD restrictions
           ; (see [RFC5890], Section 2.3.1)

alphanum = ALPHA / DIGIT

ALPHA = %x41-5A / %x61-7A   ; A-Z / a-z
DIGIT = %x30-39             ; 0-9

7.2 Macro Definitions (Makrodefinitionen)

Die verfügbaren Makrobuchstaben und ihre Bedeutungen sind wie folgt:

s = <sender>
l = local-part von <sender>
o = domain von <sender>
d = <domain>
i = <ip>
p = der validierte Domainname von <ip>
v = die in-addr.arpa-Zeichenkette für PTR-Abfragen, "in-addr" für ip4, "ip6" für ip6
h = HELO/EHLO-Domain

7.3 Macro Processing Details (Makroverarbeitungsdetails)

Dieser Abschnitt beschreibt den Prozess der Makroerweiterung im Detail.

Die zu erweiternde Makrozeichenkette wird in Fragmente zerlegt, die entweder mit dem "%"-Zeichen beginnen oder aus allen anderen Zeichen bestehen. Fragmente, die mit "%" beginnen, werden als "Makroerweiterungen" bezeichnet. Alle anderen Fragmente werden als "Makroliterale" bezeichnet.

Jede Makroerweiterung wird ersetzt (erweitert), um die Ergebniszeichenkette zu erzeugen. DNS-Namenslabels in dieser Ergebniszeichenkette werden durch "."-Zeichen getrennt, und jedes Label muss aus der LDH (Letter-Digit-Hyphen)-Regel bestehen: es muss vollständig aus ASCII-Kleinbuchstaben, ASCII-Ziffern und/oder Bindestrichen bestehen. Makroliterale werden im Ergebnis unverändert übernommen. Zwischen Makroerweiterungen und Makroliteralen werden keine Zeichen eingefügt.

Abgesehen von der Erweiterung wird keine Escaping- oder andere Nachverarbeitung der Ergebniszeichenkette durchgeführt; sie wird so verwendet, wie sie ist. Beachten Sie, dass dies bedeutet, dass ASCII-NUL-Zeichen nicht benötigt werden und kein Mechanismus bereitgestellt wird, um solche Zeichen in der Ergebniszeichenkette zu erzeugen.

Makrobuchstaben werden zu ihren definierten Werten erweitert, wie in Abschnitt 7.2 beschrieben, mit den folgenden Transformationen. Die Transformationssyntax wird durch die Transformers-Komponente definiert.

r transformer:

Der Buchstabe "r" gibt an, dass der Wert vor der Erweiterung umgekehrt werden soll. Für IPv6-Adressen und Domainnamen wird die Umkehrung an Punkt-Trennzeichen durchgeführt. Für IPv4-Adressen wird die Umkehrung an Punktgrenzen durchgeführt.

DIGIT transformer:

Eine oder mehrere Ziffern geben an, wie viele durch Punkte getrennte Teile vom Ende des Werts extrahiert werden sollen. Wenn Ziffern vorhanden sind, gibt dies die Anzahl der zu verwendenden Labels von rechts (höchstwertiger Wert) an.

Wenn keine Ziffer angegeben ist, werden alle Labels verwendet. Die Ziffer Null gibt an, dass eine leere Zeichenkette verwendet werden soll. Die Zeichenkette wird nach der Anwendung der Transformatoren abgeschnitten.

Delimiters:

Ein oder mehrere Trennzeichen geben an, welche Zeichen nach der Anwendung anderer Transformatoren durch das Trennzeichen "." ersetzt werden sollen. Beachten Sie, dass Trennzeichen nicht ein natürlicher Teil des Werts sind; sie werden während der Makroerweiterung angewendet. Hier sind Trennzeichen und ihre Erweiterungen:

%\{s} = <sender>
%\{o} = domain-Teil von <sender>
%\{d} = <domain>
%\{d4} = die letzten vier Labels von <domain>
%\{d4r} = die letzten vier Labels von <domain>, umgekehrt
%\{l} = local-part von <sender>
%\{l-} = local-part, "." ersetzt durch "-"
%\{lr} = local-part, umgekehrt
%\{lr-} = local-part, umgekehrt, "." ersetzt durch "-"
%\{l1r-} = der erste Teil von local-part, umgekehrt, "." ersetzt durch "-"

7.4 Expansion Examples (Erweiterungsbeispiele)

Hier sind einige Beispiele für Makroerweiterungen. Angenommen:

&lt;sender> = [email protected]
&lt;domain> = email.example.com
&lt;ip>     = 192.0.2.3

Makroerweiterungsbeispiele:

Makro	Erweiterungsergebnis
`%\{s}`	[email protected]
`%\{o}`	email.example.com
`%\{d}`	email.example.com
`%\{d4}`	email.example.com
`%\{d3}`	email.example.com
`%\{d2}`	example.com
`%\{d1}`	com
`%\{dr}`	com.example.email
`%\{d2r}`	example.email
`%\{l}`	strong-bad
`%\{l-}`	strong-bad
`%\{lr}`	strong-bad
`%\{lr-}`	strong-bad
`%\{l1r-}`	strong-bad
`%\{ir}.%\{v}._spf.%\{d2}`	3.2.0.192.in-addr._spf.example.com
`%\{lr-}.lp._spf.%\{d2}`	strong-bad.lp._spf.example.com
`%\{lr-}.lp.%\{ir}.%\{v}._spf.%\{d2}`	strong-bad.lp.3.2.0.192.in-addr._spf.example.com
`%\{ir}.%\{v}.%\{l1r-}.lp._spf.%\{d2}`	3.2.0.192.in-addr.strong-bad.lp._spf.example.com
`%\{d2}.trusted-domains.example.net`	example.com.trusted-domains.example.net

8. Result Handling (Ergebnisbehandlung)

Dieser Abschnitt diskutiert, wie SPF-Implementierungen die verschiedenen möglichen check_host()-Ergebnisse behandeln sollten. Er ist nur beratend, da lokale Site-Richtlinien für bestimmte Ergebnisse unterschiedliche Maßnahmen vorsehen können.

8.1 None

Die Rückgabe von "none" bedeutet, dass keine anwendbare Absenderrichtlinie für die abgefragte Domäne gefunden wurde. Dieses Ergebnis sollte als gleichbedeutend mit "SPF existiert nicht" behandelt werden; d.h. es gibt keine Richtlinie zur Bewertung.

Empfangende MTAs sollten E-Mails nicht aufgrund dieses Ergebnisses ablehnen. Während SPF-Prüfungsfehler zu Ablehnungen führen können, sollte das Ergebnis "none" nicht als Grundlage für eine Ablehnung dienen, da es keine Informationen über die Absenderautorisierung liefert.

8.2 Neutral

Die Rückgabe von "neutral" bedeutet, dass der Eigentümer der Domäne ausdrücklich erklärt hat, dass er nicht behauptet, ob der sendende Host autorisiert ist oder nicht. Dieses Ergebnis sollte als gleichbedeutend mit dem Ergebnis "none" behandelt werden; SPF-Verifizierung kann die Autorisierung des Hosts weder bestätigen noch verweigern.

Empfangende MTAs sollten E-Mails nicht aufgrund dieses Ergebnisses ablehnen.

8.3 Pass

Die Rückgabe von "pass" bedeutet, dass der Client den Absenderrichtlinien-Test bestanden hat. Der empfangende MTA kann mit anderen Anti-Spam-Tests fortfahren.

Empfangende MTAs sollten E-Mails definitiv nicht aufgrund dieses Ergebnisses ablehnen.

8.4 Fail

Die Rückgabe von "fail" bedeutet, dass der Client den Absenderrichtlinien-Test nicht bestanden hat. Der empfangende MTA kann die E-Mail ablehnen.

Wenn das veröffentlichende ADMD sich dafür entscheidet, eine Erklärungszeichenfolge zurückzugeben (mit dem "exp"-Modifikator), sollte diese Zeichenfolge als Teil der SMTP-Antwort zurückgegeben werden. Wenn keine Erklärungszeichenfolge angegeben ist, sollte der empfangende MTA eine generische Erklärung verwenden.

Es wird empfohlen, Informationen über die veröffentlichende Domäne sowie Kontaktinformationen für diese Domäne (falls verfügbar) in die SMTP-Antwort aufzunehmen, die an den Absender zurückgegeben wird. Dies hilft beim Debugging und kann möglicherweise helfen, legitime E-Mails vor dem Blockieren zu bewahren.

Beispiel SMTP-Antwort:

550-5.7.1 SPF MAIL FROM check failed:
550-5.7.1 The domain example.com explains:
550 5.7.1 Please see http://www.example.com/mailpolicy.html

8.5 Softfail

Die Rückgabe von "softfail" bedeutet, dass der Host möglicherweise nicht autorisiert ist, E-Mails zu senden, aber der Übergang ist noch nicht abgeschlossen.

Empfangende MTAs sollten E-Mails nicht aufgrund dieses Ergebnisses ablehnen, können sie aber auf irgendeine Weise als verdächtig markieren. Beispielsweise kann der empfangende MTA die E-Mail in einen Spam-Ordner legen oder einen Header hinzufügen.

8.6 Temperror

Die Rückgabe von "temperror" bedeutet, dass während der SPF-Bewertung ein temporärer Fehler aufgetreten ist. Der empfangende MTA sollte die E-Mail akzeptieren, möchte aber möglicherweise später die SPF-Prüfung wiederholen.

Wenn beispielsweise der DNS-Server vorübergehend nicht verfügbar ist, kann der Empfänger die E-Mail akzeptieren und die SPF-Richtlinie zu einem späteren Zeitpunkt neu bewerten.

8.7 Permerror

Die Rückgabe von "permerror" bedeutet, dass während der SPF-Bewertung ein permanenter Fehler aufgetreten ist. Dies kann auf einen Syntaxfehler im SPF-Eintrag der Domäne oder andere Konfigurationsprobleme zurückzuführen sein.

Der empfangende MTA kann die E-Mail ablehnen, sollte aber auch Informationen über den Fehler protokollieren, um bei der Diagnose des Problems zu helfen.

9. Recording the Result (Aufzeichnung des Ergebnisses)

Nachdem ein SPF-Check durchgeführt wurde, sollte der Empfangsserver das Ergebnis für nachfolgende Verarbeitung und Analyse aufzeichnen.

9.1 The Received-SPF Header Field (Das Received-SPF-Header-Feld)

Der Empfangsserver SOLLTE das Ergebnis der SPF-Überprüfung in einem Received-SPF-Header-Feld aufzeichnen. Dieses Feld wird der E-Mail-Nachricht hinzugefügt und liefert eine permanente Aufzeichnung der SPF-Auswertung.

Syntax (Syntax)

Received-SPF: result
              [comment]
              receiver=receiving-domain;
              identity=identity;
              envelope-from=&lt;sender>;
              helo=helo-identity;
              client-ip=client-ip-address;
              [receiver-policy-explanation]

Field Components (Feldkomponenten)

result: Das SPF-Prüfungsergebnis (None, Neutral, Pass, Fail, SoftFail, TempError, PermError)
receiver: Der Hostname des empfangenden Mail-Servers
identity: Welche Identität geprüft wurde (mailfrom, helo)
envelope-from: Die MAIL FROM-Adresse
helo: Die HELO/EHLO-Identität
client-ip: Die IP-Adresse des Clients

Example (Beispiel)

Received-SPF: pass (example.com: domain of [email protected]
              designates 192.0.2.1 as permitted sender)
              receiver=mail.example.com;
              identity=mailfrom;
              [email protected];
              helo=mail.example.com;
              client-ip=192.0.2.1

9.2 SPF Results in Authentication-Results (SPF-Ergebnisse in Authentication-Results)

Der Empfänger KANN auch das Authentication-Results-Header-Feld (definiert in RFC 7001) verwenden, um SPF-Ergebnisse neben anderen E-Mail-Authentifizierungsverfahren wie DKIM und DMARC aufzuzeichnen.

Example (Beispiel)

Authentication-Results: mail.example.com;
       spf=pass [email protected]

9.3 Local Policy Storage (Lokale Richtlinienspeicherung)

Empfangsserver KÖNNEN SPF-Ergebnisse zur internen Verwendung in Logs, Datenbanken oder Reputationssystemen speichern. Diese Aufzeichnungen können für:

Spam-Filterung: Verwendung von SPF-Ergebnissen als Signal für Spam-Bewertung
Berichterstattung: Generierung von SPF-Statistiken und -Trends
Reputation: Aufbau von Sender-Reputation basierend auf SPF-Einhaltung
Forensik: Analyse von E-Mail-Missbrauch und Phishing-Versuchen

verwendet werden.

9.4 Downstream Processing (Nachgelagerte Verarbeitung)

SPF-Ergebnisse sollten während des gesamten E-Mail-Übertragungswegs erhalten bleiben. Wenn ein Empfangsserver eine E-Mail an einen anderen Server weiterleitet, sollte das ursprüngliche Received-SPF-Header-Feld beibehalten werden, damit nachgelagerte Systeme das ursprüngliche SPF-Überprüfungsergebnis sehen können.

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.

11. Security Considerations (Sicherheitsüberlegungen)

SPF bietet wichtige Sicherheitsverbesserungen für E-Mail, weist aber auch bestimmte Einschränkungen und potenzielle Sicherheitsrisiken auf.

11.1 Security Strengths (Sicherheitsstärken)

SPF bietet folgende Sicherheitsvorteile:

Email Source Authentication (E-Mail-Quellenauthentifizierung)

SPF ermöglicht es Empfängern zu überprüfen, ob eine E-Mail von einem autorisierten Mail-Server für eine bestimmte Domäne stammt. Dies reduziert:

Domain-Spoofing: Verhindert, dass Angreifer vorgeben, von legitimen Domänen zu senden
Phishing: Macht es für Angreifer schwieriger, E-Mails zu erstellen, die scheinbar von vertrauenswürdigen Quellen stammen
Spam: Hilft, unerwünschte E-Mails von nicht autorisierten Sendern zu identifizieren

Lightweight and Scalable (Leicht und skalierbar)

SPF nutzt die vorhandene DNS-Infrastruktur, wodurch es einfach bereitzustellen und zu pflegen ist, ohne neue Protokolle oder Server zu benötigen.

11.2 Security Limitations (Sicherheitseinschränkungen)

SPF hat wichtige Einschränkungen, die Administratoren verstehen müssen:

Does Not Authenticate Message Content (Authentifiziert nicht den Nachrichteninhalt)

SPF validiert nur die MAIL FROM-Identität (Envelope From), nicht den From-Header, den Endbenutzer sehen. Angreifer können immer noch:

Den From-Header fälschen und eine andere Domäne im sichtbaren From-Feld verwenden
SPF umgehen, indem sie ihre eigene Domäne mit einem gültigen SPF-Eintrag verwenden

Lösung: Verwenden Sie DMARC zusammen mit SPF, um From-Header-Ausrichtung durchzusetzen.

Does Not Protect Message Integrity (Schützt nicht die Nachrichtenintegrität)

SPF bietet keine kryptografischen Signaturen oder Integritätsprüfungen für den E-Mail-Inhalt. Angreifer können den Nachrichteninhalt während der Übertragung ändern.

Lösung: Verwenden Sie DKIM für kryptografische Nachrichtensignatur und Integritätsschutz.

Forwarding Issues (Weiterleitungsprobleme)

Wie in Abschnitt 10.3 besprochen, bricht SPF bei E-Mail-Weiterleitung und Mailinglisten-Szenarien, da sich die sendende IP ändert, aber die MAIL FROM-Identität gleich bleibt.

Lösung: Verwenden Sie SRS (Sender Rewriting Scheme) oder DMARC-Richtlinienbehandlung.

11.3 DNS Security (DNS-Sicherheit)

SPF verlässt sich auf DNS, das anfällig für verschiedene Angriffe sein kann:

DNS Spoofing and Cache Poisoning (DNS-Spoofing und Cache-Poisoning)

Angreifer können versuchen, DNS-Antworten zu manipulieren, um SPF-Überprüfungen zu umgehen oder zu täuschen.

Minderung: Verwenden Sie DNSSEC zur kryptografischen Authentifizierung von DNS-Antworten.

DNS Lookup Amplification (DNS-Lookup-Verstärkung)

SPF-Einträge können so gestaltet werden, dass sie übermäßige DNS-Lookups verursachen, was zu Denial-of-Service-Angriffen (DoS) führt.

Minderung: SPF erzwingt ein Limit von 10 DNS-Lookups pro Überprüfung. Implementierungen müssen dieses Limit durchsetzen und mit PermError abbrechen, wenn es überschritten wird.

11.4 Privacy Considerations (Datenschutzüberlegungen)

SPF-Überprüfungen erfordern DNS-Abfragen, die die IP-Adresse des Absenders offenlegen:

Domänenadministratoren können DNS-Abfragen protokollieren und Informationen über sendende IPs sammeln
ISPs und DNS-Resolver können SPF-Abfrageverkehr überwachen

Diese sind im Allgemeinen keine ernsthaften Datenschutzprobleme, aber Administratoren sollten sich ihrer bewusst sein.

11.5 DoS Attacks (DoS-Angriffe)

SPF-Überprüfungen erfordern DNS-Lookups, die für DoS-Angriffe missbraucht werden können:

Excessive DNS Queries (Übermäßige DNS-Abfragen)

Angreifer können E-Mails mit komplexen SPF-Einträgen senden, die viele DNS-Lookups auslösen und die DNS-Server des Empfängers überlasten.

Minderung: Erzwingen Sie das 10-Lookup-Limit und brechen Sie die Verarbeitung mit PermError ab.

DNS Reflection Attacks (DNS-Reflection-Angriffe)

Angreifer können die SPF-Verarbeitung missbrauchen, um DNS-Reflection-Angriffe zu verstärken.

Minderung: Implementieren Sie Rate-Limiting und Überwachung für DNS-Abfragen.

11.6 Best Practices for Secure SPF Deployment (Best Practices für sichere SPF-Bereitstellung)

Um die Sicherheit von SPF-Bereitstellungen zu maximieren:

Use SPF with DKIM and DMARC (Verwenden Sie SPF mit DKIM und DMARC): Kombinieren Sie SPF mit DKIM für Nachrichtensignatur und DMARC für Richtliniendurchsetzung.
Deploy DNSSEC (DNSSEC bereitstellen): Sichern Sie DNS-Antworten mit DNSSEC zur Verhinderung von DNS-Spoofing.
Use Hard Fail Cautiously (Verwenden Sie Hard Fail mit Vorsicht): Beginnen Sie mit ~all (SoftFail) zum Testen, bevor Sie zu -all (Fail) übergehen.
Monitor and Maintain SPF Records (Überwachen und pflegen Sie SPF-Einträge): Aktualisieren Sie SPF-Einträge regelmäßig, wenn sich die Mail-Infrastruktur ändert.
Limit DNS Lookups (Begrenzen Sie DNS-Lookups): Halten Sie SPF-Einträge einfach und vermeiden Sie übermäßige include:- und redirect:-Mechanismen.
Implement Logging and Monitoring (Implementieren Sie Protokollierung und Überwachung): Verfolgen Sie SPF-Überprüfungsergebnisse und untersuchen Sie Anomalien.
Educate Users (Schulen Sie Benutzer): Informieren Sie Benutzer über Phishing und die Grenzen von SPF bei der Validierung des From-Headers.

Appendix A. Extended Examples (Erweiterte Beispiele)

Dieser Anhang bietet erweiterte Beispiele für SPF-Einträge, die verschiedene Konfigurationsszenarien und Best Practices demonstrieren.

A.1 Simple Examples (Einfache Beispiele)

A.1.1 Nur eine einzelne IP-Adresse erlauben

example.com. IN TXT "v=spf1 ip4:192.0.2.1 -all"

Erklärung: Nur die IP-Adresse 192.0.2.1 darf E-Mails im Namen von example.com senden. Alle anderen IP-Adressen führen zu einem "fail"-Ergebnis.

A.1.2 Verwendung von MX-Einträgen

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

Erklärung: Erlaubt den in den MX-Einträgen von example.com aufgeführten Mailservern, E-Mails zu senden. Dies ist eine gängige Konfiguration, da sie sich automatisch an Änderungen der MX-Einträge anpasst.

A.1.3 Verwendung von A-Einträgen

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

Erklärung: Erlaubt den IP-Adressen im A-Eintrag (oder AAAA-Eintrag für IPv6) von example.com, E-Mails zu senden.

A.1.4 Kombination mehrerer Mechanismen

example.com. IN TXT "v=spf1 mx a:mail.example.com ip4:192.0.2.0/24 -all"

Erklärung: Erlaubt E-Mails von folgenden Quellen:

MX-Server von example.com
A-Eintrag von mail.example.com
Jede IP im Netzwerk 192.0.2.0/24

A.1.5 Soft-Fail-Richtlinie

example.com. IN TXT "v=spf1 mx a ~all"

Erklärung: Verwendet Soft-Fail (~all) anstelle von Hard-Fail (-all). Dies ist nützlich während der Test- oder Migrationsphase. Empfänger können E-Mails akzeptieren, sie jedoch als verdächtig markieren.

A.2 Multiple Domain Example (Mehrfach-Domain-Beispiel)

Für Organisationen mit mehreren Domains, die dieselbe Mail-Infrastruktur verwenden:

example.com.     IN TXT "v=spf1 mx -all"
example.org.     IN TXT "v=spf1 redirect=_spf.example.com"
example.net.     IN TXT "v=spf1 redirect=_spf.example.com"
_spf.example.com. IN TXT "v=spf1 mx:example.com -all"

Erklärung:

example.com hat seinen eigenen SPF-Eintrag
example.org und example.net leiten zum gemeinsamen SPF-Eintrag um
_spf.example.com enthält die tatsächliche Richtlinie

Vorteile:

Zentralisierte Verwaltung der Mailserver-Konfiguration
Einmalige Aktualisierung betrifft mehrere Domains
Reduzierter DNS-Wartungsaufwand

A.3 DNS Blacklist (DNSBL) Style Example (DNS-Blacklist-Stil-Beispiel)

Verwendung des exists-Mechanismus zur Implementierung DNSBL-ähnlicher Funktionalität:

example.com. IN TXT "v=spf1 exists:%\{ir}.%\{l1r+-}._spf.%\{d} -all"

Erklärung:

%\{ir}: Umgekehrte IP-Adresse (z.B. wird 192.0.2.1 zu 1.2.0.192)
%\{l1r+-}: Erster Teil des local-part des Absenders, umgekehrt, "." und "+" durch "-" ersetzt
%\{d}: Domainname

Beispiel-Erweiterung:

Wenn der Absender [email protected] von 192.0.2.1 sendet:

Makro erweitert zu: 1.2.0.192.user._spf.example.com

Dann wird dieser Domainname nach A-Einträgen abgefragt. Wenn vorhanden, besteht die SPF-Prüfung.

Anwendungsfälle:

Benutzerbasierte feinkörnige Kontrolle
Integration mit Datenbank oder benutzerdefinierten Systemen
Dynamische Autorisierungsentscheidungen

A.4 Multiple Requirements Example (Beispiel für mehrere Anforderungen)

Komplexe Konfiguration, die mehrere Mechanismen und Modifikatoren kombiniert:

example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.0/24 include:_spf-servers.example.com include:_spf.google.com a:outbound.example.com mx ~all"

Erklärung:

ip4:192.0.2.0/24: Internes Mailserver-Netzwerk
ip4:198.51.100.0/24: Backup-Rechenzentrum-Netzwerk
include:_spf-servers.example.com: Zusätzliche Serverliste einbinden
include:_spf.google.com: Google Workspace verwenden
a:outbound.example.com: Spezifischer Ausgangsserver
mx: MX-Eintrags-Server einbeziehen
~all: Soft-Fail für alle anderen Fälle

Hierarchisches Design:

_spf-servers.example.com. IN TXT "v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.128/25 -all"

Dies ermöglicht die Aufteilung großer SPF-Einträge in leichter verwaltbare Teile.

A.5 Subdomain-Konfigurationsbeispiele

A.5.1 Subdomains mit unterschiedlichen Richtlinien

example.com.       IN TXT "v=spf1 mx -all"
mail.example.com.  IN TXT "v=spf1 a -all"
shop.example.com.  IN TXT "v=spf1 include:shopify.com -all"

Erklärung:

Hauptdomain verwendet MX-Einträge
mail-Subdomain verwendet nur ihren A-Eintrag
shop-Subdomain verwendet Drittanbieterdienst (Shopify)

A.5.2 Subdomains, die keine E-Mails senden

noreply.example.com. IN TXT "v=spf1 -all"
static.example.com.  IN TXT "v=spf1 -all"

Erklärung: Erklärt explizit, dass diese Subdomains keine E-Mails senden, um Fälschungen zu verhindern.

A.6 Beispiele für Drittanbieter-Dienst-Integration

A.6.1 Verwendung mehrerer E-Mail-Dienstanbieter

example.com. IN TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net -all"

Erklärung:

Google Workspace für Mitarbeiter-E-Mails
Microsoft 365 für Partner
SendGrid für Marketing-E-Mails

A.6.2 Prüfung der DNS-Abfragelimits

Das obige Beispiel verwendet 3 include-Direktiven, von denen jede zusätzliche Abfragen auslösen kann. Es muss sichergestellt werden, dass die Gesamtzahl der Abfragen 10 nicht überschreitet.

Verifizierungsmethode:

# Überprüfung des Google SPF
dig _spf.google.com TXT

# Überprüfung des Microsoft SPF
dig spf.protection.outlook.com TXT

# Überprüfung des SendGrid SPF
dig sendgrid.net TXT

Berechnen Sie die Anzahl der Mechanismen in jedem include, um sicherzustellen, dass die Gesamtzahl ≤ 10 ist.

A.7 Fehlkonfigurationsbeispiele (zu vermeiden)

A.7.1 ❌ Mehrere SPF-Einträge (Fehler)

example.com. IN TXT "v=spf1 mx -all"
example.com. IN TXT "v=spf1 a -all"

Problem: Dies führt zu "permerror". Eine Domain kann nur einen SPF-Eintrag haben.

Richtige Methode:

example.com. IN TXT "v=spf1 mx a -all"

A.7.2 ❌ Fehlendes `-all` (unsicher)

example.com. IN TXT "v=spf1 mx"

Problem: Keine explizite Standardrichtlinie, entspricht ?all (neutral), keine IP wird fehlschlagen.

Richtige Methode:

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

A.7.3 ❌ Überschreitung des DNS-Abfragelimits

example.com. IN TXT "v=spf1 include:a include:b include:c include:d include:e include:f include:g include:h include:i include:j include:k -all"

Problem: 11 include-Direktiven überschreiten das 10-Abfragen-Limit, was zu "permerror" führt.

Lösung: SPF-Flattening verwenden oder direkt ip4-Mechanismen nutzen.

A.8 IPv6-Konfigurationsbeispiel

example.com. IN TXT "v=spf1 ip6:2001:db8::/32 ip4:192.0.2.0/24 mx -all"

Erklärung: Unterstützt sowohl IPv6- als auch IPv4-Netzwerke.

A.9 Erklärungsstring-Beispiel

example.com.         IN TXT "v=spf1 mx -all exp=explain._spf.%\{d}"
explain._spf.example.com. IN TXT "E-Mail von %\{i}, aber diese IP ist nicht von %\{d} autorisiert. Bitte kontaktieren Sie postmaster@%\{d}."

Erklärung: Wenn die SPF-Prüfung fehlschlägt, kann der Empfänger den Erklärungsstring abfragen und dem Benutzer anzeigen.

Nach Makroerweiterung (angenommen von 192.0.2.99 gesendet):

"E-Mail von 192.0.2.99, aber diese IP ist nicht von example.com autorisiert. Bitte kontaktieren Sie [email protected]."

A.10 Test- und Übergangsstrategie

Phase 1: Überwachungsmodus (2-4 Wochen)

example.com. IN TXT "v=spf1 ?all"

Phase 2: Tatsächliche Sendequellen erfassen (2-4 Wochen)

example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 include:provider.com ?all"

Phase 3: Soft-Fail (4-8 Wochen)

example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 include:provider.com ~all"

Phase 4: Strikter Modus (Produktionsumgebung)

example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 include:provider.com -all"

Empfehlung: In jeder Phase SPF-Prüfergebnisse überwachen, um sicherzustellen, dass keine legitimen E-Mails blockiert werden.

Appendix B. Changes in Implementation Requirements from RFC 4408 (Änderungen der Implementierungsanforderungen gegenüber RFC 4408)

Dieser Anhang fasst die wichtigsten Änderungen von RFC 7208 gegenüber seinem Vorgänger RFC 4408 zusammen.

B.1 Hauptänderungen

B.1.1 SPF RR-Typ veraltet

RFC 4408-Anforderung:

Gleichzeitige Veröffentlichung von TXT- und SPF-Einträgen (Typ 99)
Implementierungen müssen beide Eintragstypen prüfen

RFC 7208-Änderung:

Nur TXT-Einträge verwenden (Typ 16)
SPF RR-Typ wird nicht mehr unterstützt
Vereinfachte Implementierung und Bereitstellung

Grund: Sehr geringe Adoptionsrate des SPF RR-Typs, Dual-Typ-System verursachte Interoperabilitätsprobleme.

B.1.2 Klarstellung der DNS-Abfragelimits

RFC 4408:

DNS-Abfragelimit nicht ausreichend klar beschrieben
"Void lookup"-Limit nicht definiert

RFC 7208:

Eindeutige Definition des 10-DNS-Abfragelimits
Hinzugefügtes "void lookup"-Limit (empfohlen 2)
Detaillierte Beschreibung zusätzlicher Limits für MX- und PTR-Mechanismen

Spezifische Limits:

- Gesamt-DNS-Abfragen: ≤ 10 (include, a, mx, ptr, exists, redirect)
- Pro mx-Mechanismus: ≤ 10 Adressabfragen
- Pro ptr-Mechanismus: ≤ 10 Adressabfragen
- Void lookups: ≤ 2 (empfohlen)
- Evaluierungszeit: ≥ 20 Sekunden (empfohlen)

B.1.3 Behandlung von "local-part"

RFC 4408:

local-part-Behandlung nicht ausreichend klar
Behandlung leerer local-part nicht definiert

RFC 7208:

Eindeutige Festlegung: Wenn <sender> keinen local-part hat, verwende "postmaster"
Verbesserte Behandlung leerer Reverse-Path (<>)

Beispiel:

MAIL FROM:<>
→ SPF verwendet HELO-Identität, local-part ist "postmaster"

B.1.4 Starke Ablehnung des "ptr"-Mechanismus

RFC 4408:

"ptr"-Mechanismus erlaubt, aber nicht empfohlen

RFC 7208:

Eindeutig als "do not use" (nicht verwenden) markiert
Warnung im Mechanismusnamen hinzugefügt
Betonung von Leistungs- und Zuverlässigkeitsproblemen

Gründe:

Reverse-DNS-Abfragen langsam
Abhängig von Konfiguration Dritter (IP-Adresseigentümer)
Belastung für .arpa-Nameserver

B.1.5 Korrektur der Makrosyntax

RFC 4408:

Mehrdeutige Makrosyntaxdefinition

RFC 7208:

Verbesserte ABNF-Definition
Klarstellung der Makroerweiterungsregeln
Behobene Grenzfälle

B.1.6 Sicherheitsüberlegungen zum "exp"-Modifikator

RFC 4408:

Sicherheitsüberlegungen nicht ausreichend detailliert

RFC 7208:

Sicherheitswarnungen zu externen Erklärungsstrings hinzugefügt
Empfehlung zur Begrenzung der Länge von Erklärungsstrings
Betonung der Notwendigkeit, Erklärungen als von Dritten stammend zu kennzeichnen

B.2 Änderungen der Implementierungsanforderungen

B.2.1 MUST-Änderungen (Muss implementiert werden)

Neue Anforderungen:

Implementierungen müssen nur TXT-Einträge abfragen (keine SPF RR mehr)
Implementierungen müssen die Gesamtzahl der DNS-Abfragen auf 10 begrenzen
Implementierungen müssen "void lookup"-Limit handhaben
Implementierungen müssen bei Überschreitung der Limits "permerror" zurückgeben

Entfernte Anforderungen:

Keine Unterstützung für SPF RR-Typ mehr erforderlich
Keine Konvertierungslogik für Dual-Typ-Einträge mehr erforderlich

B.2.2 SHOULD-Änderungen (Sollte implementiert werden)

Neue Empfehlungen:

Sollte Evaluierungs-Timeout implementieren (mindestens 20 Sekunden)
Sollte "void lookup" auf 2 begrenzen
Sollte sowohl HELO- als auch MAIL FROM-Identität prüfen
Sollte Prüfung während SMTP-Transaktion durchführen

B.2.3 MAY-Änderungen (Kann implementiert werden)

Neue Optionen:

Kann nicht-kanonische Algorithmen verwenden (solange Ergebnisse gleich sind)
Kann "void lookup"-Limit konfigurieren
Kann Länge der Erklärungsstrings begrenzen

B.3 Terminologieänderungen

B.3.1 Standardisierung von Identitätsnamen

RFC 4408:

Verwendete mehrere Namen: "MAIL FROM", "SMTP MAIL FROM", "reverse-path"
Inkonsistente Terminologie

RFC 7208:

Einheitliche Verwendung von "MAIL FROM"-Identität
Klare Definition als RFC5321.MailFrom
Verweis auf RFC 5598-Standardterminologie

B.3.2 Übernahme der "ADMD"-Terminologie

RFC 4408:

Verwendete "domain owner", "sending domain"

RFC 7208:

Übernahme von "ADMD" (Administrative Management Domain)
Präzisere Beschreibung der verantwortlichen Partei

B.4 Verbesserung der Sicherheitsüberlegungen

B.4.1 Neue Sicherheitsthemen

Cross-User-Fälschung (Abschnitt 11.4):
- In RFC 4408 nicht behandelt
- RFC 7208 diskutiert explizit domäneninterne Benutzerfälschungsprobleme
Datenschutzgefährdung (Abschnitt 11.6):
- Makros in DNS-Abfragen können sensible Informationen preisgeben
- Empfehlung zur vorsichtigen Verwendung von Makros mit Absenderinformationen
Nicht vertrauenswürdige Informationsquellen (Abschnitt 11.5):
- Detaillierte Diskussion der Risiken externer Header und Erklärungen
- Betonung der Wichtigkeit von Validierung und Filterung

B.4.2 Stärkung des DoS-Schutzes

RFC 4408:

Grundlegende Abfragelimits

RFC 7208:

Mehrschichtige Schutzmechanismen
Klare Grenzwerte
Timeout-Empfehlungen
"Void lookup"-Limit

B.5 Änderungen bei IANA-Registrierungen

B.5.1 SPF RR-Typ

RFC 4408:

Registrierung des SPF RR-Typs (Typ 99)

RFC 7208:

SPF RR-Typ als veraltet markiert
Empfehlung, nur TXT-Einträge zu verwenden

B.5.2 Modifikator-Registrierung

RFC 7208 neu:

Erstellung der SPF-Modifikator-Registrierung
Standardisierter Registrierungsprozess für neue Modifikatoren
Anforderung, dass unbekannte Modifikatoren ignoriert werden müssen

B.6 Interoperabilitätsverbesserungen

B.6.1 Klarstellung der Eintragsauswahl

RFC 4408:

Behandlung mehrerer Einträge unklar

RFC 7208:

Eindeutige Festlegung: Mehrere SPF-Einträge führen zu "permerror"
Verbesserte Regeln zum Abgleich von Versionsstrings
Klarstellung der Eintragsverkettungsregeln (mehrere Strings)

B.6.2 Standardisierung der Fehlerbehandlung

RFC 7208-Verbesserungen:

Alle Fehlersituationen haben eindeutige Ergebnisse
Standardisierte Behandlung von DNS-Fehlern
Verbesserte Timeout-Behandlung

B.7 Rückwärtskompatibilität

B.7.1 Kompatible Änderungen

Die meisten Änderungen sind rückwärtskompatibel:

TXT-Eintragsformat unverändert
Mechanismen- und Modifikator-Syntax im Wesentlichen gleich
Kernalgorithmus bleibt konsistent

B.7.2 Möglicherweise kompatibilitätsbeeinflussende Änderungen

Entfernung des SPF RR-Typs:
- Alte Implementierungen könnten weiterhin SPF RR abfragen
- Empfehlung: SPF RR-Einträge entfernen, nur TXT behalten
Strengere Limits:
- "Void lookup"-Limit ist neu hinzugefügt
- Einige alte Einträge könnten neue Limits überschreiten
- Empfehlung: SPF-Einträge optimieren, um Limits einzuhalten
Ablehnung des "ptr"-Mechanismus:
- Muss weiterhin unterstützt werden, wird aber stark abgelehnt
- Empfehlung: Zu anderen Mechanismen migrieren

B.8 Änderungen der Dokumentenstruktur

RFC 7208-Verbesserungen:

Klarere Kapitelorganisation
Erweiterte Beispiele hinzugefügt (Anhang A)
Implementierungsempfehlungen hinzugefügt (Anhang C-G)
Verbesserte Darstellung von ABNF-Definitionen

B.9 Migrationsanleitung

Migration von RFC 4408 zu RFC 7208:

Herausgeber:

SPF RR-Einträge entfernen, nur TXT-Einträge behalten
DNS-Abfrageanzahl prüfen und optimieren (≤ 10)
"ptr"-Mechanismus durch "ip4" oder "ip6" ersetzen
"Void lookup"-Anzahl validieren (≤ 2)
Testen, ob Einträge 512 Oktetts überschreiten

Empfänger:

Abfragen von SPF RR-Typ stoppen
Neue DNS-Abfragelimits implementieren
"Void lookup"-Limit implementieren
Fehlerbehandlungslogik aktualisieren
Erwägung der Implementierung von Evaluierungs-Timeout

Testen:

# SPF-Validierungstool zum Testen von Einträgen verwenden
# Zum Beispiel: https://www.kitterman.com/spf/validate.html

# DNS-Abfrageanzahl prüfen
dig +short example.com TXT | grep "v=spf1"

# Eintragsgröße validieren
dig example.com TXT | grep -A1 "ANSWER SECTION"

B.10 Aktualisierung der Referenzdokumente

RFC 7208 verweist auf aktualisierte Standards:

RFC 5321 (ersetzt RFC 2821)
RFC 5322 (ersetzt RFC 2822)
RFC 5234 (ABNF-Aktualisierung)
RFC 5598 (Mail-Architektur-Terminologie)
RFC 5890 (Internationalisierte Domainnamen)

Appendix C. Further Testing Advice (Weitere Testempfehlungen)

Dieser Anhang bietet detaillierte Empfehlungen zum Testen und Validieren von SPF-Implementierungen.

C.1 Testen von SPF-Einträgen

C.1.1 Grundlegende Validierung

DNS-Abfragetest:

# SPF-Eintrag abfragen
dig example.com TXT | grep "v=spf1"

# Oder nslookup verwenden
nslookup -type=TXT example.com

# Oder host verwenden
host -t TXT example.com

Validierungspunkte:

✓ Eintrag beginnt mit v=spf1
✓ Nur ein SPF-Eintrag
✓ Syntax korrekt (keine Rechtschreibfehler)
✓ Eintragsgröße < 512 Oktetts

C.1.2 Online-Validierungstools

Empfohlene Online-Tools:

Kitterman SPF Validator
- URL: https://www.kitterman.com/spf/validate.html
- Funktionen: Syntaxprüfung, DNS-Abfragezählung, Parsing-Details
MXToolbox SPF Record Check
- URL: https://mxtoolbox.com/spf.aspx
- Funktionen: Eintragsvalidierung, Warnungen und Fehlererkennung
DMARCIAN SPF Inspector
- URL: https://dmarcian.com/spf-survey/
- Funktionen: Tiefenanalyse, Optimierungsempfehlungen

Prüfpunkte:

✓ Syntax-Korrektheit
✓ DNS-Abfrageanzahl (≤ 10)
✓ Void lookup-Anzahl (≤ 2)
✓ Eintragslänge
✓ Mechanismus-Gültigkeit
✓ Include-Ketten-Tiefe

C.2 Testen der SPF-Prüfimplementierung

C.2.1 Unit-Test-Szenarien

Testfall 1: Grundlegende IP-Übereinstimmung

SPF-Eintrag: v=spf1 ip4:192.0.2.1 -all
Test-IP: 192.0.2.1
Erwartetes Ergebnis: pass

Test-IP: 192.0.2.2
Erwartetes Ergebnis: fail

Testfall 2: CIDR-Bereich

SPF-Eintrag: v=spf1 ip4:192.0.2.0/24 -all
Test-IP: 192.0.2.100
Erwartetes Ergebnis: pass

Test-IP: 192.0.3.1
Erwartetes Ergebnis: fail

Testfall 3: MX-Mechanismus

example.com MX-Eintrag: 10 mail.example.com
mail.example.com A-Eintrag: 192.0.2.10

SPF-Eintrag: v=spf1 mx -all
Test-IP: 192.0.2.10
Erwartetes Ergebnis: pass

Testfall 4: Include-Mechanismus

example.com: v=spf1 include:_spf.example.org -all
_spf.example.org: v=spf1 ip4:192.0.2.0/24 -all

Test-IP: 192.0.2.50
Erwartetes Ergebnis: pass

Testfall 5: Soft-Fail

SPF-Eintrag: v=spf1 ip4:192.0.2.1 ~all
Test-IP: 203.0.113.1
Erwartetes Ergebnis: softfail

C.2.2 Grenzfall-Tests

Leerer MAIL FROM:

MAIL FROM: <>
HELO: mail.example.com
Erwartet: HELO-Identität verwenden, local-part ist "postmaster"

Ungültiger Domainname:

MAIL FROM: [email protected]
Erwartetes Ergebnis: none (oder permerror)

DNS-Timeout:

DNS-Timeout simulieren
Erwartetes Ergebnis: temperror

Mehrere SPF-Einträge:

example.com TXT "v=spf1 mx -all"
example.com TXT "v=spf1 a -all"
Erwartetes Ergebnis: permerror

C.2.3 Limit-Tests

DNS-Abfragelimit-Test:

# Pseudocode
def test_dns_lookup_limit():
    # SPF-Eintrag mit 11 includes erstellen
    spf = "v=spf1"
    for i in range(11):
        spf += f" include:domain{i}.example.com"
    spf += " -all"
    
    result = check_spf(spf, "192.0.2.1", "[email protected]")
    assert result == "permerror"

MX-Eintrags-Limit-Test:

# Domain mit 11 MX-Einträgen erstellen
# Erwartet: mx-Mechanismus gibt permerror zurück

Void Lookup-Test:

# Include erstellen, das NXDOMAIN zurückgibt
# Zählung sollte in void lookup-Limit enthalten sein

C.3 Test-E-Mails senden

C.3.1 Testablauf

Schritt 1: Test-Domain vorbereiten

test.example.com IN TXT "v=spf1 ip4:YOUR_IP -all"

Schritt 2: Test-E-Mail senden

# swaks-Tool verwenden
swaks --to [email protected] \
      --from [email protected] \
      --server smtp.example.com

# Oder telnet verwenden
telnet smtp.recipient.com 25
HELO test.example.com
MAIL FROM:`&lt;[email protected]&gt;`
RCPT TO:`&lt;[email protected]&gt;`
DATA
Subject: SPF Test
.
QUIT

Schritt 3: E-Mail-Header prüfen

Received-SPF: pass (recipient.com: domain of [email protected]
    designates YOUR_IP as permitted sender)
    client-ip=YOUR_IP;
    [email protected];

C.3.2 Tests für verschiedene Szenarien

Szenario 1: Pass-Test

Konfiguration: Von autorisierter IP senden
Erwarteter Header: Received-SPF: pass

Szenario 2: Fail-Test

Konfiguration: Von nicht autorisierter IP senden
Erwartet: E-Mail wird abgelehnt oder markiert
Erwarteter Header: Received-SPF: fail

Szenario 3: SoftFail-Test

Konfiguration: SPF-Eintrag verwendet ~all
Von nicht autorisierter IP senden
Erwartet: E-Mail wird akzeptiert aber markiert
Erwarteter Header: Received-SPF: softfail

Szenario 4: Neutral-Test

Konfiguration: SPF-Eintrag verwendet ?all
Erwarteter Header: Received-SPF: neutral

C.4 Makro-Tests

C.4.1 Makroerweiterungs-Validierung

Testfall:

Absender: [email protected]
Client-IP: 192.0.2.100

Makro %\{s} → [email protected]
Makro %\{l} → user
Makro %\{o} → example.com
Makro %\{d} → example.com
Makro %\{i} → 192.0.2.100
Makro %\{ir} → 100.2.0.192
Makro %\{d2} → example.com
Makro %\{d1} → com

Komplexer Makro-Test:

SPF: v=spf1 exists:%\{ir}.%\{l}._spf.%\{d} -all
Absender: [email protected]
IP: 192.0.2.100

Erweitert zu: 100.2.0.192.user._spf.example.com
Validierung: A-Eintrag für diesen Domainnamen abfragen

C.4.2 Makro-Trennzeichen-Test

Absender: [email protected]

%\{l} → user+tag
%\{l-} → user-tag (+ wird durch - ersetzt)
%\{lr} → gat+resu (umgekehrt)
%\{lr-} → gat-resu (umgekehrt und ersetzt)

C.5 Leistungstests

C.5.1 Antwortzeitests

Benchmark-Test:

# DNS-Abfragezeit testen
time dig example.com TXT

# Vollständige SPF-Prüfung testen
time spf_check example.com 192.0.2.1 [email protected]

Leistungsziele:

Einfacher Eintrag (1-2 Mechanismen): < 100ms
Komplexer Eintrag (mehrere includes): < 500ms
Maximal erlaubte Zeit: 20 Sekunden

C.5.2 Lasttests

Hohe Parallelität simulieren:

import concurrent.futures
import time

def check_spf_concurrent(num_checks):
    with concurrent.futures.ThreadPoolExecutor(max_workers=100) as executor:
        futures = [
            executor.submit(check_spf, "example.com", "192.0.2.1", "[email protected]")
            for _ in range(num_checks)
        ]
        results = [f.result() for f in futures]
    return results

# 1000 parallele SPF-Prüfungen testen
start = time.time()
results = check_spf_concurrent(1000)
end = time.time()

print(f"1000 Prüfungen abgeschlossen in: {end - start} Sekunden")
print(f"Durchschnitt pro Prüfung: {(end - start) / 1000 * 1000}ms")

C.6 Regressionstests

C.6.1 Test-Suite

Minimaler Testsatz:

Grundlegende pass/fail-Szenarien
Alle 7 Mechanismen (all, include, a, mx, ptr, ip4, ip6, exists)
Alle 4 Qualifizierer (+, -, ~, ?)
Beide Modifikatoren (redirect, exp)
Makroerweiterung
Fehlerbehandlung (temperror, permerror)
Limit-Tests (DNS-Abfragen, Timeout)

RFC 7208-Test-Suite:

# Offizielle Test-Suite verwenden
git clone https://github.com/openspf/openspf.git
cd openspf/tests
./run_tests.sh

C.6.2 Continuous Integration

CI/CD-Konfigurationsbeispiel:

# .github/workflows/spf-tests.yml
name: SPF Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Run SPF Tests
        run: |
          python -m pytest tests/test_spf.py
          python tests/validate_spf_records.py

C.7 Häufige Probleme testen

C.7.1 Veraltete E-Mail-Funktionen

Source Routing:

MAIL FROM:&lt;@relay.example.com:[email protected]>
Erwartet: example.com korrekt als Domain extrahieren

%-hack:

MAIL FROM:&lt;user%[email protected]>
Erwartet: Korrekt handhaben oder ablehnen

Bang Path:

MAIL FROM:&lt;[email protected]>
Erwartet: Korrekt handhaben oder ablehnen

C.7.2 Internationalisierte Domainnamen

IDN-Test:

Domain: münchen.de
A-label: xn--mnchen-3ya.de
SPF-Eintrag: Muss A-label verwenden

Test: Sicherstellen, dass korrekt konvertiert und abgefragt wird

C.7.3 IPv6-Tests

IPv6-Adressformate:

Vollformat: 2001:0db8:0000:0000:0000:0000:0000:0001
Komprimiertes Format: 2001:db8::1
IPv4-mapped: ::ffff:192.0.2.1

SPF: v=spf1 ip6:2001:db8::/32 -all
Test: Alle Formate sollten korrekt übereinstimmen

C.8 Debug-Techniken

C.8.1 Ausführliche Protokollierung aktivieren

Sender:

# Postfix
postconf -e "smtpd_sender_login_maps = hash:/etc/postfix/sender_login"
postconf -e "smtpd_sender_restrictions = reject_sender_login_mismatch"
tail -f /var/log/mail.log

Empfänger:

# SPF-Debug-Protokollierung aktivieren
spf_debug_level = 5
tail -f /var/log/mail.log | grep SPF

C.8.2 dig-Verfolgung verwenden

SPF-Abfragen verfolgen:

# Vollständigen DNS-Auflösungsprozess anzeigen
dig +trace example.com TXT

# Include-Kette anzeigen
dig _spf.google.com TXT
dig _netblocks.google.com TXT

C.8.3 SPF-Debug-Tools verwenden

Python pyspf:

import spf

result, explanation = spf.check2(
    i='192.0.2.1',
    s='[email protected]',
    h='mail.example.com'
)

print(f"Ergebnis: {result}")
print(f"Erklärung: {explanation}")

Perl Mail::SPF:

use Mail::SPF;

my $spf_server = Mail::SPF::Server->new();
my $request = Mail::SPF::Request->new(
    versions    => [1],
    scope       => 'mfrom',
    identity    => '[email protected]',
    ip_address  => '192.0.2.1',
    helo_identity => 'mail.example.com'
);

my $result = $spf_server->process($request);
print "Ergebnis: " . $result->code . "\n";

C.9 Produktionsumgebung-Überwachung

C.9.1 Überwachungsmetriken

Schlüsselmetriken:

- SPF pass-Rate
- SPF fail-Rate
- SPF softfail-Rate
- SPF temperror-Rate (sollte sehr niedrig sein)
- SPF permerror-Rate (sollte 0 sein)
- Durchschnittliche Prüfzeit
- DNS-Timeout-Rate

C.9.2 Alarmeinstellungen

Empfohlene Alarmregeln:

- permerror-Rate > 0%: Sofortiger Alarm (SPF-Eintragsfehler)
- temperror-Rate > 5%: Warnung (DNS-Probleme)
- fail-Rate plötzlicher Anstieg > 20%: Alarm (mögliche Konfigurationsänderung oder Angriff)
- Durchschnittliche Prüfzeit > 1 Sekunde: Warnung (Leistungsproblem)

C.9.3 Protokollanalyse

SPF-Fehler analysieren:

# IP-Adressen mit SPF fail extrahieren
grep "Received-SPF: fail" /var/log/mail.log | \
  grep -oP 'client-ip=\K[0-9.]+' | \
  sort | uniq -c | sort -rn

# Absenderdomains mit fail analysieren
grep "Received-SPF: fail" /var/log/mail.log | \
  grep -oP 'envelope-from=\K[^;]+' | \
  cut -d@ -f2 | sort | uniq -c | sort -rn

Bericht generieren:

# SPF-Statistikbericht-Generator
def generate_spf_report(log_file):
    results = {
        'pass': 0, 'fail': 0, 'softfail': 0,
        'neutral': 0, 'none': 0,
        'temperror': 0, 'permerror': 0
    }
    
    with open(log_file) as f:
        for line in f:
            if 'Received-SPF:' in line:
                for result in results:
                    if f'Received-SPF: {result}' in line:
                        results[result] += 1
    
    total = sum(results.values())
    for result, count in results.items():
        percentage = (count / total * 100) if total > 0 else 0
        print(f"{result}: {count} ({percentage:.2f}%)")

Appendix D. SPF/Mediator Interactions (SPF/Vermittler-Interaktionen)

Dieser Anhang diskutiert die Interaktion zwischen SPF und E-Mail-Vermittlern (wie Mailinglisten und Weiterleitungsdienste) sowie deren Auswirkungen.

D.1 Originating ADMDs (Ursprungs-ADMD)

Das Ursprungs-ADMD ist die administrative Domain, die ursprünglich die E-Mail sendet. Bei Vorhandensein von Vermittlern muss das Ursprungs-ADMD die Weiterleitungs- und Listendienste berücksichtigen, die seine E-Mails durchlaufen können.

D.1.1 Problemidentifikation

SPF-Grundannahme:

E-Mails werden direkt von autorisierten Servern an Empfänger gesendet
MAIL FROM-Identität bleibt unverändert
Absender-IP-Adresse ist im SPF-Eintrag autorisiert

Von Vermittlern gebrochene Annahmen:

E-Mails durchlaufen Zwischensysteme
Können von einer anderen IP-Adresse erneut gesendet werden
MAIL FROM kann geändert oder unverändert bleiben

D.1.2 Optionen für Absender

Option 1: Lockere SPF-Richtlinie verwenden

example.com IN TXT "v=spf1 mx ~all"

Vorteile:

Erlaubt legitime Weiterleitung
Reduziert Fehlalarme

Nachteile:

Schwächt den SPF-Schutz
Leichter zu fälschen

Option 2: Auf andere Authentifizierungsmethoden setzen

DKIM-Signaturen veröffentlichen:
- DKIM bleibt bei Weiterleitung gültig
- Unabhängig von Absender-IP-Adresse
- Funktioniert mit DMARC zusammen

Option 3: SPF-Fehler akzeptieren

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

Akzeptieren, dass einige legitime E-Mails markiert oder abgelehnt werden können
Darauf vertrauen, dass Benutzer die richtige Sendemethode verwenden
Benutzern empfehlen, nicht weiterzuleiten, sondern "Als Kopie senden" zu verwenden

D.1.3 Best Practices

Empfohlene Konfiguration:

Strengen SPF-Eintrag veröffentlichen (-all)
Gleichzeitig DKIM-Signierung implementieren
DMARC-Richtlinie veröffentlichen
Benutzer über Weiterleitungsprobleme aufklären

DMARC-Konfigurationsbeispiel:

_dmarc.example.com IN TXT "v=DMARC1; p=quarantine; sp=quarantine; adkim=r; aspf=r; pct=100; rua=mailto:[email protected]"

Parametererklärung:

adkim=r: DKIM-Relaxed-Alignment
aspf=r: SPF-Relaxed-Alignment
p=quarantine: Bei Fehler E-Mail unter Quarantäne stellen

D.2 Mediators (Vermittler)

Vermittler sind Systeme, die E-Mails in der Übertragungskette ändern oder erneut senden. Häufige Vermittler umfassen Mailinglisten, Weiterleitungsdienste und automatische Antwortsysteme.

D.2.1 Mailinglisten

Problem:

Herkömmliche Mailinglisten behalten das ursprüngliche MAIL FROM bei:

Original: MAIL FROM:`&lt;[email protected]&gt;`
Nach Liste: MAIL FROM:`&lt;[email protected]&gt;`
Absender-IP: list-server.mailinglist.org

SPF-Prüfung:

SPF-Eintrag von example.com abfragen
IP von list-server.mailinglist.org prüfen
Ergebnis: fail (IP ist nicht im SPF-Eintrag von example.com)

D.2.2 Lösungen

Lösung 1: MAIL FROM neu schreiben (empfohlen)

Umgeschrieben: MAIL FROM:`&lt;[email protected]&gt;`
Reply-To: [email protected]

Vorteile:

SPF-Prüfung besteht
Bounces gehen an Listenserver zurück
Empfänger kann korrekt identifizieren

Nachteile:

Ändert ursprüngliche Absenderinformationen
Benutzer müssen sich an Reply-To anpassen

Implementierungsbeispiel (Mailman):

# Mailman-Konfiguration
from_is_list = 2  # Munge From, add Reply-To

Lösung 2: SRS (Sender Rewriting Scheme) verwenden

SRS ist ein komplexeres Umschreibungsschema:

Original: [email protected]
Umgeschrieben zu: [email protected]

SRS-Format:

SRS0=&lt;hash>=&lt;timestamp>=&lt;domain>=&lt;localpart>@&lt;forwarder>

Beispiel:
[email protected]

Vorteile:

Bewahrt ursprüngliche Absenderinformationen (im local-part)
SPF-Prüfung besteht
Kann nachverfolgt und verifiziert werden

Nachteile:

Komplexe Implementierung
Benötigt SRS-Datenbank
local-part wird schwer lesbar

Lösung 3: DKIM anstatt SPF verwenden

Konfiguration:

Ursprünglicher Absender verwendet DKIM-Signierung
Listenserver behält ursprüngliche Signatur bei
Listenserver fügt eigene DKIM-Signatur hinzu
Empfänger verifiziert DKIM (ignoriert SPF-Fehler)

DMARC-Konfiguration:

_dmarc.example.com IN TXT "v=DMARC1; p=none; adkim=r; aspf=r"

p=none: Keine Durchsetzung (erlaubt SPF-Fehler)
adkim=r: DKIM-Relaxed-Alignment (erlaubt Listensignatur)

D.2.3 E-Mail-Weiterleitungsdienste

Typ 1: Einfache Weiterleitung

Benutzerkonfiguration: [email protected] → [email protected]
Weiterleitungsdienst behält bei: MAIL FROM:`&lt;[email protected]&gt;`
Sendet von IP des Weiterleitungsservers

SPF-Problem:

Gmail prüft SPF von original.com
IP des Weiterleitungsservers ist nicht im SPF-Eintrag
Ergebnis: fail

Lösung A: SRS-Umschreibung

Weiterleitungsdienst verwendet SRS:
MAIL FROM:&lt;[email protected]>

Lösung B: ~all statt -all verwenden

original.com IN TXT "v=spf1 mx ~all"

Weitergeleitete E-Mails erhalten softfail statt fail, werden eher akzeptiert.

Typ 2: .forward-Datei

# ~/.forward
[email protected]

Problem identisch mit einfacher Weiterleitung.

Best Practices:

Weiterleitungsdienste sollten SRS implementieren
Ursprünglicher Absender sollte DKIM verwenden
Empfänger sollten DKIM-Ergebnisse berücksichtigen, nicht nur SPF

D.2.4 Automatische Antwort- und Benachrichtigungssysteme

Problem:

Original-E-Mail: [email protected] → [email protected]
Automatische Antwort: MAIL FROM:`&lt;[email protected]&gt;`
         (Gesendet von company.com-Server)

SPF-Prüfung wird fehlschlagen.

Lösung:

Benachrichtigungen mit leerem MAIL FROM senden:
MAIL FROM:<>
From: Mail Delivery System `&lt;[email protected]&gt;`

Oder:

Lokale Adresse verwenden:
MAIL FROM:`&lt;[email protected]&gt;`
From: Automatic Reply `&lt;[email protected]&gt;`
Reply-To: [email protected]

D.3 Receiving ADMDs (Empfänger-ADMD)

Empfänger-ADMD muss E-Mails von Vermittlern verarbeiten und angemessene Entscheidungen treffen.

D.3.1 Erkennung von Vermittler-E-Mails

Identifikatoren:

Zwischenhops in Received-Headern
List-*-Header (Mailinglisten)
Precedence: bulk oder list
SRS-formatiertes MAIL FROM
DKIM-Signatur von bekanntem Listendienst

Beispielerkennungslogik:

def is_mailing_list(message):
    # List-*-Header prüfen
    list_headers = [
        'List-Id', 'List-Post', 'List-Unsubscribe',
        'List-Help', 'List-Subscribe', 'List-Owner'
    ]
    
    for header in list_headers:
        if message.get(header):
            return True
    
    # Precedence prüfen
    if message.get('Precedence') in ['bulk', 'list']:
        return True
    
    # SRS prüfen
    mail_from = message.get('Return-Path', '')
    if mail_from.startswith('SRS0=') or mail_from.startswith('SRS1='):
        return True
    
    return False

D.3.2 Richtlinienempfehlungen

Richtlinie 1: Lockerer Umgang mit Listen-E-Mails

if is_mailing_list(message):
    if spf_result == 'fail':
        # DKIM prüfen
        if dkim_result == 'pass':
            accept_message()
        else:
            # Listen-Reputation prüfen
            if list_is_trusted(list_id):
                accept_message()
            else:
                quarantine_message()

Richtlinie 2: Auf DMARC verlassen

if dmarc_result == 'pass':
    accept_message()
elif spf_result == 'fail' and dkim_result == 'fail':
    reject_message()
else:
    # SPF oder DKIM eins besteht
    if is_mailing_list(message):
        accept_message()
    else:
        apply_content_filtering()

Richtlinie 3: Benutzerspezifische Regeln

Benutzer können Whitelists konfigurieren:
- Vertrauenswürdige Mailinglisten
- Bekannte Weiterleitungsadressen
- Lockere Behandlung bestimmter Domains

D.3.3 Implementierungsempfehlungen

SpamAssassin-Konfiguration:

# Lockerer Umgang mit Mailinglisten
header LIST_ID exists:List-Id
score LIST_ID -0.1

# SPF fail aber mit List-Id-Header
meta SPF_FAIL_LIST (SPF_FAIL && LIST_ID)
score SPF_FAIL_LIST 0.5

# Normaler SPF fail (ohne Listenheader)
score SPF_FAIL 5.0

Postfix-Konfiguration:

# smtpd_recipient_restrictions
reject_unauth_destination,
check_policy_service unix:private/spf-policy,
permit

# SPF-Richtliniendienst kann Listen-E-Mails erkennen und entsprechend anpassen

rspamd-Konfiguration:

-- SPF-Modulkonfiguration
spf {
  -- Unterschiedliche Gewichtung für Mailinglisten anwenden
  symbol_fail = "R_SPF_FAIL";
  symbol_softfail = "R_SPF_SOFTFAIL";
  
  -- Benutzerdefinierte Regeln
  custom_symbols = {
    R_SPF_FAIL_LIST = {
      score = 2.0,
      description = "SPF failed but from mailing list",
      condition = function(task)
        local spf = task:get_symbol('R_SPF_FAIL')
        local list_id = task:get_header('List-Id')
        return spf and list_id
      end
    }
  }
}

D.4 Interoperabilitätsempfehlungen

D.4.1 Standardisierung

Standardheader verwenden:

Mailinglisten sollten hinzufügen:
- List-Id: &lt;list-name.domain.com>
- List-Post: &lt;mailto:[email protected]>
- List-Unsubscribe: &lt;mailto:[email protected]>
- Precedence: bulk

DKIM-Signierung:

Listenserver sollten:
Ursprüngliche DKIM-Signatur beibehalten (falls vorhanden)
Eigene DKIM-Signatur hinzufügen
Signierte Header nicht ändern

D.4.2 Kommunikation

Absenderbenachrichtigung:

Listendienst sollte Abonnenten informieren:
- E-Mails werden vom Listenserver erneut gesendet
- MAIL FROM wird umgeschrieben
- Empfehlung, Reply-To für Listenantworten zu verwenden

Empfängerdokumentation:

Empfängerrichtlinien dokumentieren:
- Wie Listen-E-Mails verarbeitet werden
- Whitelist-Mechanismus
- Benutzerkonfigurierbare Optionen

D.5 Zukünftige Entwicklungsrichtung

D.5.1 ARC (Authenticated Received Chain)

RFC 8617 führte ARC ein:

ARC ermöglicht Vermittlern das Hinzufügen von Authentifizierungsinformationen:
- ARC-Seal: Vermittlersignatur
- ARC-Message-Signature: Nachrichtensignatur
- ARC-Authentication-Results: Authentifizierungsergebnisse

Beispiel:

ARC-Seal: i=1; a=rsa-sha256; t=1234567890; cv=none;
    d=mailinglist.org; s=arc-seal; b=...
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
    d=mailinglist.org; s=arc-msg; h=from:to:subject; b=...
ARC-Authentication-Results: i=1; mailinglist.org;
    spf=pass [email protected];
    dkim=pass header.d=example.com

Vorteile:

Bewahrt ursprüngliche Authentifizierungsergebnisse
Ermöglicht Kettenverifizierung
Empfänger können Vermittlern vertrauen

D.5.2 Empfehlungen

Für neue Bereitstellungen:

DKIM und SPF implementieren
DMARC-Richtlinie veröffentlichen
ARC-Unterstützung in Betracht ziehen (falls Vermittler)
Interoperabilität mit gängigen Mailinglisten testen

Für bestehende Systeme:

Strenge SPF-Richtlinien überprüfen
DMARC-Berichte überwachen
Problematische Quellen identifizieren (Listen, Weiterleitungen usw.)
Richtlinien anpassen oder SRS implementieren

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:

Benutzer senden E-Mails von mehreren Domains
Alle E-Mails werden über Server des Dienstanbieters gesendet
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:

Domain-Eigentum verifizieren

Dienstanbieter verlangt Hinzufügen eines Verifizierungseintrags:
_verification.user-domain.com IN TXT "provider-verification-code"

SPF konfigurieren

user-domain.com IN TXT "v=spf1 include:_spf.mailprovider.com -all"

DKIM konfigurieren

# Dienstanbieter stellt DKIM-öffentlichen Schlüssel bereit
selector._domainkey.user-domain.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0..."

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:

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

Kunden sollten:

Include-Methode verwenden, um SPF des Hosting-Anbieters zu referenzieren
SPF-Einträge regelmäßig validieren
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:

DNS-Abfragelimit (10 Mal)
Eintragsgröße-Limit (512 Bytes)
Mehrere Abteilungen/Geschäftseinheiten
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:

Trennung der Reputation (Marketing-E-Mails beeinflussen Hauptdomain nicht)
Einfachere SPF-Eintragsverwaltung
Bessere Überwachung und Berichterstattung
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 &lt; 95%:
    alert("Delivery rate dropped below 95%")

if spf_pass_rate &lt; 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

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

E.7.2 Konfigurationscheckliste

Vor Veröffentlichung prüfen:

□ SPF-Eintragssyntax korrekt
□ DNS-Abfrageanzahl ≤ 10
□ Eintragsgröße &lt; 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

Appendix F. Test Suite (Testsuite)

Diese Appendix bietet eine umfassende Testsuite zur Validierung von SPF-Implementierungen. Die Tests decken verschiedene Szenarien ab, um sicherzustellen, dass SPF-Checker korrekt funktionieren.

F.1 Basic Tests (Grundlegende Tests)

F.1.1 Einfache IP4-Tests

Test 1: Direkte IP4-Übereinstimmung

SPF-Eintrag: v=spf1 ip4:192.0.2.1 -all
Test-IP: 192.0.2.1
Erwartetes Ergebnis: pass

Test 2: IP4-CIDR-Übereinstimmung

SPF-Eintrag: v=spf1 ip4:192.0.2.0/24 -all
Test-IP: 192.0.2.128
Erwartetes Ergebnis: pass

Test 3: IP4-Nicht-Übereinstimmung

SPF-Eintrag: v=spf1 ip4:192.0.2.0/24 -all
Test-IP: 192.0.3.1
Erwartetes Ergebnis: fail

F.1.2 Einfache IP6-Tests

Test 4: Direkte IP6-Übereinstimmung

SPF-Eintrag: v=spf1 ip6:2001:db8::1 -all
Test-IP: 2001:db8::1
Erwartetes Ergebnis: pass

Test 5: IP6-CIDR-Übereinstimmung

SPF-Eintrag: v=spf1 ip6:2001:db8::/32 -all
Test-IP: 2001:db8::dead:beef
Erwartetes Ergebnis: pass

Test 6: IP6-Nicht-Übereinstimmung

SPF-Eintrag: v=spf1 ip6:2001:db8::/32 -all
Test-IP: 2001:db9::1
Erwartetes Ergebnis: fail

F.2 Mechanism Tests (Mechanismus-Tests)

F.2.1 A-Mechanismus-Tests

Test 7: A-Mechanismus - Übereinstimmung

Domain: example.com
SPF-Eintrag: v=spf1 a -all
DNS A-Eintrag für example.com: 192.0.2.1
Test-IP: 192.0.2.1
Erwartetes Ergebnis: pass

Test 8: A-Mechanismus mit CIDR

Domain: example.com
SPF-Eintrag: v=spf1 a/24 -all
DNS A-Eintrag für example.com: 192.0.2.1
Test-IP: 192.0.2.200
Erwartetes Ergebnis: pass

Test 9: A-Mechanismus mit Domain-Spezifikation

Domain: sender.example.com
SPF-Eintrag: v=spf1 a:mail.example.com -all
DNS A-Eintrag für mail.example.com: 192.0.2.10
Test-IP: 192.0.2.10
Erwartetes Ergebnis: pass

F.2.2 MX-Mechanismus-Tests

Test 10: MX-Mechanismus - Übereinstimmung

Domain: example.com
SPF-Eintrag: v=spf1 mx -all
DNS MX-Eintrag für example.com: 10 mail.example.com
DNS A-Eintrag für mail.example.com: 192.0.2.1
Test-IP: 192.0.2.1
Erwartetes Ergebnis: pass

Test 11: MX-Mechanismus mit mehreren MX-Einträgen

Domain: example.com
SPF-Eintrag: v=spf1 mx -all
DNS MX-Einträge:
  10 mail1.example.com → 192.0.2.1
  20 mail2.example.com → 192.0.2.2
Test-IP: 192.0.2.2
Erwartetes Ergebnis: pass

Test 12: MX-Mechanismus mit CIDR

Domain: example.com
SPF-Eintrag: v=spf1 mx/24 -all
DNS MX-Eintrag: 10 mail.example.com
DNS A-Eintrag für mail.example.com: 192.0.2.1
Test-IP: 192.0.2.200
Erwartetes Ergebnis: pass

F.2.3 PTR-Mechanismus-Tests (NICHT VERWENDEN)

Test 13: PTR-Mechanismus - Übereinstimmung

Domain: example.com
SPF-Eintrag: v=spf1 ptr -all
Test-IP: 192.0.2.1
PTR-Eintrag für 192.0.2.1: mail.example.com
A-Eintrag für mail.example.com: 192.0.2.1
Erwartetes Ergebnis: pass

Hinweis: PTR-Mechanismus ist veraltet und sollte nicht verwendet werden.

F.2.4 EXISTS-Mechanismus-Tests

Test 14: EXISTS-Mechanismus - gefunden

Domain: example.com
SPF-Eintrag: v=spf1 exists:%\{i}.whitelist.example.com -all
Test-IP: 192.0.2.1
DNS A-Abfrage für 192.0.2.1.whitelist.example.com: 127.0.0.2
Erwartetes Ergebnis: pass

Test 15: EXISTS-Mechanismus - nicht gefunden

Domain: example.com
SPF-Eintrag: v=spf1 exists:%\{i}.whitelist.example.com -all
Test-IP: 192.0.2.99
DNS A-Abfrage für 192.0.2.99.whitelist.example.com: NXDOMAIN
Erwartetes Ergebnis: fail

F.2.5 INCLUDE-Mechanismus-Tests

Test 16: INCLUDE - einfache Pass-Propagierung

Domain: example.com
SPF-Eintrag: v=spf1 include:trusted.example.com -all
SPF-Eintrag für trusted.example.com: v=spf1 ip4:192.0.2.1 -all
Test-IP: 192.0.2.1
Erwartetes Ergebnis: pass

Test 17: INCLUDE - Fail wird nicht propagiert

Domain: example.com
SPF-Eintrag: v=spf1 include:trusted.example.com -all
SPF-Eintrag für trusted.example.com: v=spf1 ip4:192.0.2.1 -all
Test-IP: 192.0.2.99
Erwartetes Ergebnis: fail (nicht von include, sondern von -all)

Test 18: INCLUDE - TempError-Propagierung

Domain: example.com
SPF-Eintrag: v=spf1 include:trusted.example.com -all
DNS-Abfrage für trusted.example.com: DNS-Server nicht verfügbar
Erwartetes Ergebnis: temperror

Test 19: INCLUDE - PermError-Propagierung

Domain: example.com
SPF-Eintrag: v=spf1 include:trusted.example.com -all
SPF-Eintrag für trusted.example.com: v=spf1 ip4:192.0.2.1 ip4:192.0.2.1 -all (ungültig)
Erwartetes Ergebnis: permerror

F.2.6 ALL-Mechanismus-Tests

Test 20: ALL mit verschiedenen Qualifizierern

+all: pass
-all: fail
~all: softfail
?all: neutral

F.3 Qualifier Tests (Qualifizierer-Tests)

Test 21: Plus-Qualifizierer (+)

SPF-Eintrag: v=spf1 +ip4:192.0.2.1 -all
Test-IP: 192.0.2.1
Erwartetes Ergebnis: pass

Test 22: Minus-Qualifizierer (-)

SPF-Eintrag: v=spf1 -ip4:192.0.2.1 ~all
Test-IP: 192.0.2.1
Erwartetes Ergebnis: fail

Test 23: Tilde-Qualifizierer (~)

SPF-Eintrag: v=spf1 ~ip4:192.0.2.1 -all
Test-IP: 192.0.2.1
Erwartetes Ergebnis: softfail

Test 24: Fragezeichen-Qualifizierer (?)

SPF-Eintrag: v=spf1 ?ip4:192.0.2.1 -all
Test-IP: 192.0.2.1
Erwartetes Ergebnis: neutral

F.4 Modifier Tests (Modifizierer-Tests)

F.4.1 REDIRECT-Modifizierer-Tests

Test 25: REDIRECT - Grundlegende Umleitung

Domain: example.com
SPF-Eintrag: v=spf1 redirect=_spf.example.com
SPF-Eintrag für _spf.example.com: v=spf1 ip4:192.0.2.1 -all
Test-IP: 192.0.2.1
Erwartetes Ergebnis: pass

Test 26: REDIRECT - nach Mechanismus ignoriert

Domain: example.com
SPF-Eintrag: v=spf1 ip4:192.0.2.1 redirect=_spf.example.com
Test-IP: 192.0.2.1
Erwartetes Ergebnis: pass (Mechanismus stimmt überein, redirect ignoriert)

Test 27: REDIRECT - keine Übereinstimmung

Domain: example.com
SPF-Eintrag: v=spf1 redirect=_spf.example.com
SPF-Eintrag für _spf.example.com: v=spf1 ip4:192.0.2.1 -all
Test-IP: 192.0.2.99
Erwartetes Ergebnis: fail

F.4.2 EXP-Modifizierer-Tests

Test 28: EXP - Erklärungsstring abrufen

Domain: example.com
SPF-Eintrag: v=spf1 ip4:192.0.2.1 -all exp=explain.example.com
DNS TXT-Eintrag für explain.example.com: "Mail from %\{i} not allowed"
Test-IP: 192.0.2.99
Erwartetes Ergebnis: fail
Erwartete Erklärung: "Mail from 192.0.2.99 not allowed"

F.5 Macro Tests (Makro-Tests)

F.5.1 Grundlegende Makro-Erweiterung

Test 29: %{s} - Sender

Domain: example.com
MAIL FROM: [email protected]
SPF-Eintrag: v=spf1 exists:%\{s}.whitelist.example.com -all
Erweitert zu: exists:[email protected]

Test 30: %{l} - Lokaler Teil

Domain: example.com
MAIL FROM: [email protected]
SPF-Eintrag: v=spf1 exists:%\{l}.whitelist.example.com -all
Erweitert zu: exists:sender.whitelist.example.com

Test 31: %{o} - Domain

Domain: example.com
MAIL FROM: [email protected]
SPF-Eintrag: v=spf1 exists:%\{o}.whitelist.example.com -all
Erweitert zu: exists:example.com.whitelist.example.com

Test 32: %{d} - Aktuelle Domain

Domain: mail.example.com
SPF-Eintrag: v=spf1 exists:%\{d}.whitelist.example.com -all
Erweitert zu: exists:mail.example.com.whitelist.example.com

Test 33: %{i} - IP-Adresse

Test-IP: 192.0.2.1
SPF-Eintrag: v=spf1 exists:%\{i}.whitelist.example.com -all
Erweitert zu: exists:192.0.2.1.whitelist.example.com

Test 34: %{i} - IPv6-Adresse

Test-IP: 2001:db8::1
SPF-Eintrag: v=spf1 exists:%\{i}.whitelist.example.com -all
Erweitert zu: exists:2001.0db8.0000.0000.0000.0000.0000.0001.whitelist.example.com

F.5.2 Makro-Transformatoren

Test 35: Umkehr-Transformator (r)

Domain: mail.example.com
Makro: %\{d}
Normal: mail.example.com
Mit r: %\{dr}
Erweitert zu: com.example.mail

Test 36: Delimiter und Reverse

MAIL FROM: [email protected]
Makro: %\{or}
Erweitert zu: com.example.mail

Test 37: Ziffern-Spezifikation

Domain: mail.example.com
Makro: %\{d2}
Erweitert zu: example.com (letzte 2 Komponenten)

Test 38: Ziffern mit Reverse

Domain: mail.example.com
Makro: %\{d2r}
Erweitert zu: com.example

F.5.3 URL-Encoding in Makros

Test 39: URL-Escape-Zeichen

MAIL FROM: "test user"@example.com
Makro: %\{l}
Erweitert zu: test%20user

F.6 DNS Lookup Limit Tests (DNS-Abfragelimit-Tests)

Test 40: DNS-Abfragelimit - genau 10

SPF-Eintrag: v=spf1 mx a include:d1.example.com include:d2.example.com ...
(insgesamt 10 Mechanismen, die DNS-Abfragen erfordern)
Erwartetes Ergebnis: Erfolgreich verarbeitet

Test 41: DNS-Abfragelimit - 11 überschritten

SPF-Eintrag: v=spf1 mx a include:d1.example.com ... (11 Abfragen)
Erwartetes Ergebnis: permerror

Test 42: Verschachtelte Include-Abfragezählung

Domain: example.com
SPF: v=spf1 include:a.example.com -all (1 Abfrage)
  a.example.com: v=spf1 include:b.example.com -all (1 Abfrage)
    b.example.com: v=spf1 mx a -all (2 Abfragen)
Gesamtabfragen: 4
Erwartetes Ergebnis: pass (wenn IP übereinstimmt)

F.7 Void Lookup Tests (Leere-Abfrage-Tests)

Test 43: A-Mechanismus - keine A-Einträge

Domain: example.com
SPF-Eintrag: v=spf1 a -all
DNS A-Eintrag für example.com: (keiner)
Test-IP: 192.0.2.1
Erwartetes Ergebnis: fail (Mechanismus stimmt nicht überein)
Void-Lookups: 1

Test 44: MX-Mechanismus - keine MX-Einträge

Domain: example.com
SPF-Eintrag: v=spf1 mx -all
DNS MX-Eintrag für example.com: (keiner)
Test-IP: 192.0.2.1
Erwartetes Ergebnis: fail
Void-Lookups: 1

Test 45: Void-Lookup-Limit - überschritten

SPF-Eintrag mit 3 Mechanismen, die jeweils void lookups zurückgeben
Erwartetes Ergebnis: permerror (wenn Limit 2 ist)

F.8 Syntax Error Tests (Syntaxfehler-Tests)

Test 46: Fehlende SPF-Version

SPF-Eintrag: ip4:192.0.2.1 -all
Erwartetes Ergebnis: none (kein gültiger SPF-Eintrag)

Test 47: Ungültige IP-Adresse

SPF-Eintrag: v=spf1 ip4:999.999.999.999 -all
Erwartetes Ergebnis: permerror

Test 48: Ungültiger CIDR-Bereich

SPF-Eintrag: v=spf1 ip4:192.0.2.0/99 -all
Erwartetes Ergebnis: permerror

Test 49: Doppelte Modifizierer

SPF-Eintrag: v=spf1 redirect=a.example.com redirect=b.example.com
Erwartetes Ergebnis: permerror

Test 50: Unbekannter Modifizierer (sollte ignoriert werden)

SPF-Eintrag: v=spf1 ip4:192.0.2.1 unknown=value -all
Test-IP: 192.0.2.1
Erwartetes Ergebnis: pass (unbekannter Modifizierer ignoriert)

F.9 Integration Tests (Integrationstests)

Test 51: Komplexes realistisches Szenario

Domain: company.com
SPF-Eintrag: v=spf1 mx include:_spf.google.com include:sendgrid.net -all

Konfiguration:
- MX-Einträge: mail1.company.com (192.0.2.1), mail2.company.com (192.0.2.2)
- Google SPF umfasst mehrere IP-Bereiche
- SendGrid SPF umfasst mehrere IP-Bereiche

Testfälle:
1. IP 192.0.2.1: pass (mx-Übereinstimmung)
2. IP aus Google-Bereich: pass (include-Übereinstimmung)
3. IP aus SendGrid-Bereich: pass (include-Übereinstimmung)
4. Zufällige IP: fail (-all)

Test 52: Subdomain-Behandlung

Domain: mail.company.com
SPF-Eintrag für company.com: v=spf1 -all
SPF-Eintrag für mail.company.com: v=spf1 ip4:192.0.2.1 -all
Test-IP: 192.0.2.1
Erwartetes Ergebnis: pass (Subdomain hat eigenen SPF-Eintrag)

Test 53: Kein SPF-Eintrag

Domain: example.com
SPF-Eintrag: (keiner)
Test-IP: 192.0.2.1
Erwartetes Ergebnis: none

F.10 Edge Cases (Grenzfälle)

Test 54: Leerer lokaler Teil

MAIL FROM: <>
HELO: mail.example.com
SPF-Eintrag für mail.example.com: v=spf1 ip4:192.0.2.1 -all
Test-IP: 192.0.2.1
Erwartetes Ergebnis: pass (HELO-Identität verwendet)

Test 55: IPv4-Mapped IPv6-Adresse

SPF-Eintrag: v=spf1 ip4:192.0.2.1 -all
Test-IP: ::ffff:192.0.2.1 (IPv4-mapped IPv6)
Erwartetes Ergebnis: pass (sollte als IPv4 behandelt werden)

Test 56: CIDR /32 für IPv4

SPF-Eintrag: v=spf1 ip4:192.0.2.1/32 -all
Test-IP: 192.0.2.1
Erwartetes Ergebnis: pass

Test 57: CIDR /128 für IPv6

SPF-Eintrag: v=spf1 ip6:2001:db8::1/128 -all
Test-IP: 2001:db8::1
Erwartetes Ergebnis: pass

Test 58: Mehrere SPF-Einträge (ungültig)

Domain: example.com
SPF-Einträge:
  v=spf1 ip4:192.0.2.1 -all
  v=spf1 ip4:192.0.2.2 -all
Erwartetes Ergebnis: permerror (mehrere SPF-Einträge nicht erlaubt)

F.11 Performance Tests (Leistungstests)

Test 59: Maximale DNS-Abfrage-Tiefe

Verschachtelte includes bis zur Tiefe von 10
Verifizieren, dass alle korrekt verarbeitet werden

Test 60: Große CIDR-Bereiche

SPF-Eintrag: v=spf1 ip4:192.0.0.0/8 -all
Test-IP: 192.255.255.255
Erwartetes Ergebnis: pass

F.12 Test Result Summary Format (Testergebnis-Zusammenfassungsformat)

Für jede Testausführung sollten folgende Informationen aufgezeichnet werden:

Test-ID: F.1.1-Test1
Beschreibung: Direkte IP4-Übereinstimmung
SPF-Eintrag: v=spf1 ip4:192.0.2.1 -all
Test-IP: 192.0.2.1
Erwartetes Ergebnis: pass
Tatsächliches Ergebnis: pass
Status: BESTANDEN
DNS-Abfragen: 1
Void-Lookups: 0
Verarbeitungszeit: 45ms

Eine vollständige SPF-Implementierung sollte alle Tests in dieser Suite bestehen, um als RFC 7208-konform zu gelten.

Appendix G. Acknowledgements (Danksagungen)

Die Entwicklung des Sender Policy Framework (SPF) war ein kollaborativer Aufwand, an dem viele Personen und Organisationen aus der Internet-Community beteiligt waren.

G.1 Original Contributors (Ursprüngliche Mitwirkende)

SPF basiert auf den Ideen mehrerer früherer E-Mail-Authentifizierungsvorschläge:

Designated Mailers Protocol (DMP): Von Gordon Fecyk vorgeschlagen
Reverse MX (RMX): Von Hadmut Danisch vorgeschlagen
Sender Permitted From (SPF): Von Meng Weng Wong vorgeschlagen

Meng Weng Wong spielte eine entscheidende Rolle bei der Vereinigung dieser verschiedenen Ansätze in ein einheitliches Framework und leitete die frühe Entwicklung von SPF.

G.2 RFC 4408 Contributors (RFC 4408-Mitwirkende)

RFC 4408, die ursprüngliche SPF-Spezifikation, wurde von Meng Weng Wong und Mark Lentczner verfasst. Viele andere trugen zu ihrer Entwicklung bei:

Technische Mitwirkende und Gutachter:

Stuart Cheshire
Claus Färber
Mark Lentczner
Wayne Schlitt
Julian Mehnle
Scott Kitterman

Working Group-Teilnehmer: Die IETF MARID (MTA Authorization Records in DNS) Working Group leistete erhebliche Beiträge zur frühen Entwicklung und Diskussion von SPF-Konzepten.

G.3 RFC 7208 Contributors (RFC 7208-Mitwirkende)

Diese aktuelle Spezifikation (RFC 7208) wurde von Scott Kitterman verfasst und basiert auf RFC 4408. Die folgenden Personen trugen zu dieser Aktualisierung bei:

Hauptmitwirkende:

Scott Kitterman (Hauptautor)
Murray S. Kucherawy (Mitwirkender und Gutachter)

Technische Gutachter und Mitwirkende:

Alessandro Vesely
Barry Leiba
Bron Gondwana
Franck Martin
John Levine
Michael Hammer
Pete Resnick
Steve Atkins
Stuart Cheshire

G.4 Community Contributions (Community-Beiträge)

Die SPF-Community hat aktiv zur Weiterentwicklung, Implementierung und Bereitstellung von SPF beigetragen:

Implementierer: Zahlreiche Entwickler haben SPF-Bibliotheken und -Tools in verschiedenen Programmiersprachen erstellt, darunter:

Perl
Python
Java
C/C++
PHP
Ruby
Go

Dienstanbieter: Große E-Mail-Dienstanbieter haben SPF weithin eingeführt und bei der Verfeinerung der Spezifikation basierend auf realen Erfahrungen geholfen:

Google (Gmail)
Microsoft (Outlook.com, Office 365)
Yahoo
AOL
Andere wichtige E-Mail-Anbieter

DNS-Anbieter: DNS-Dienstanbieter haben SPF-Management-Tools entwickelt und Dokumentationen zur Erleichterung der SPF-Einführung erstellt.

G.5 IETF Working Groups (IETF-Arbeitsgruppen)

Mehrere IETF-Arbeitsgruppen trugen zur Entwicklung von SPF bei:

MARID (MTA Authorization Records in DNS) Working Group:

Fokussierte sich auf E-Mail-Authentifizierung über DNS
Diskutierte verschiedene Ansätze zur Absendervalidierung
Stellte Forum für frühe SPF-Entwicklung bereit

ASRG (Anti-Spam Research Group):

Bewertete SPF im Kontext von Anti-Spam-Technologien
Lieferte Feedback zu Sicherheits- und Datenschutzüberlegungen

DKIM Working Group:

Arbeitete an komplementären E-Mail-Authentifizierungstechnologien
Gewährleistete, dass SPF und DKIM gut zusammenarbeiten

DMARC Working Group:

Entwickelte DMARC, das SPF und DKIM integriert
Half bei der Definition, wie SPF-Ergebnisse bei E-Mail-Authentifizierungsrichtlinien verwendet werden

G.6 Tool and Library Developers (Tool- und Bibliotheksentwickler)

Die folgenden Open-Source-Projekte und -Entwickler haben erheblich zum SPF-Ökosystem beigetragen:

SPF-Bibliotheken:

libspf2 (C-Bibliothek) von der libspf2-Projektgruppe
Mail::SPF (Perl-Modul) von Julian Mehnle und anderen
pyspf (Python-Bibliothek) von Stuart Gathman und Terence Way
spf4j (Java-Bibliothek) von verschiedenen Mitwirkenden

SPF-Validierungstools:

Online-SPF-Checker von verschiedenen Anbietern
Kommandozeilen-SPF-Tester
DNS-Analyse-Tools

E-Mail-Server-Implementierungen:

Postfix SPF-Integration
Exim SPF-Unterstützung
Sendmail SPF-Integration
Microsoft Exchange SPF-Implementierung

G.7 Documentation Contributors (Dokumentationsmitwirkende)

Viele Personen haben zur SPF-Dokumentation, Tutorials und Best Practices beigetragen:

OpenSPF.org: Community-gepflegte SPF-Dokumentation und -Ressourcen
IETF Mailinglisten: Ausführliche technische Diskussionen und Klarstellungen
Blog-Autoren und Technische Schriftsteller: Die SPF für ein breiteres Publikum erklärt haben
DNS-Anbieter-Dokumentationen: Die praktische SPF-Implementierungsleitfäden bereitgestellt haben

G.8 Testing and Deployment (Tests und Bereitstellung)

Organisationen und Einzelpersonen, die bei groß angelegten Tests und Bereitstellungen geholfen haben:

Frühanwender:

Große E-Mail-Dienstanbieter, die SPF in ihren Netzwerken getestet haben
Unternehmensorganisationen, die SPF-Validierung implementiert haben
ISPs, die SPF als Spam-Filter-Komponente hinzugefügt haben

Interoperabilitätstests:

Entwickler, die Cross-Implementierungstests durchgeführt haben
Organisationen, die SPF-Testsuiten gehostet haben
Mitwirkende, die Fehler und Interoperabilitätsprobleme gemeldet haben

G.9 Special Thanks (Besonderer Dank)

Besonderer Dank an:

Meng Weng Wong: Für die ursprüngliche SPF-Konzeption und seine unermüdliche Arbeit bei der Zusammenführung der Community zur Entwicklung des Standards
Mark Lentczner: Für Co-Autorenschaft der ursprünglichen RFC 4408-Spezifikation
Scott Kitterman: Für die Leitung des Aktualisierungsprozesses von RFC 4408 auf RFC 7208 und weiterhin aktive Wartung der SPF-Community
Wayne Schlitt: Für umfangreiche technische Beiträge und Implementierungserfahrung
Julian Mehnle: Für die Entwicklung wichtiger SPF-Bibliotheken und Klarstellung der Spezifikation

Die Internet-Community: An alle, die SPF verwendet, implementiert, darüber diskutiert und zur Verbesserung der E-Mail-Authentifizierung beigetragen haben.

G.10 Ongoing Work (Laufende Arbeiten)

Die Entwicklung von SPF setzt sich fort durch:

Spezifikations-Klarstellungen: Laufende Diskussionen zur Klärung von Randfällen
Bibliotheksaktualisierungen: Aktive Wartung von SPF-Implementierungen
Best-Practices-Entwicklung: Sich weiterentwickelnde Leitfäden für SPF-Bereitstellung
Integration mit anderen Standards: Koordination mit DKIM, DMARC und anderen E-Mail-Sicherheitstechnologien

Die SPF-Community bleibt aktiv und setzt sich für die Verbesserung der E-Mail-Authentifizierung und -Sicherheit im Internet ein.

Abschließende Anmerkung: Diese Spezifikation und das SPF-Protokoll wären ohne die Bemühungen unzähliger Freiwilliger nicht möglich gewesen, die ihre Zeit, Expertise und Ressourcen zur Verbesserung der E-Mail-Sicherheit für alle beigetragen haben.

Grundlegende Informationen
Zusammenfassung (Abstract)
Contents
Appendices (Anhänge)
SPF-Überblick
- Was ist SPF?
- SPF vs DKIM vs DMARC
SPF-Eintragsformat
- Grundlegende Syntax
- Mechanismen (Mechanisms)
- Qualifizierer (Qualifiers)
- Modifikatoren (Modifiers)
SPF-Eintragsbeispiele
- Basiskonfigurationen
- Drittanbieter-Dienste
- Gemischte Konfigurationen
- Subdomains
SPF-Prüfablauf
- Empfänger-Verifizierungsschritte
- SPF-Ergebnisse
DNS-Abfragelimits
- 10-Abfragen-Limit
- SPF Flattening Tool
Praktische Werkzeuge
- SPF-Eintrags-Generator
- SPF-Verifizierungs-Tool
Best Practices für die Bereitstellung
- 1. Schrittweise Bereitstellung
- 2. Häufige Fehler
- 3. Testen und Verifizieren
Integration mit DKIM/DMARC
- Vollständige E-Mail-Sicherheitskonfiguration
Referenzen
1. Introduction (Einführung)
- 1.1 Terminology (Terminologie)
- 1.2 check_host()
2. Operational Overview (Betriebsübersicht)
- 2.1 Publishing Authorization (Veröffentlichung der Autorisierung)
- 2.2 Checking Authorization (Prüfung der Autorisierung)
- 2.3 The "HELO" Identity (Die "HELO"-Identität)
- 2.4 The "MAIL FROM" Identity (Die "MAIL FROM"-Identität)
- 2.5 Location of Checks (Ort der Prüfungen)
- 2.6 Results of Evaluation (Bewertungsergebnisse)
3. SPF Records (SPF-Einträge)
- 3.1 DNS Resource Records (DNS-Ressourceneinträge)
- 3.2 Multiple DNS Records (Mehrere DNS-Einträge)
- 3.3 Multiple Strings in a Single DNS Record (Mehrere Strings in einem einzelnen DNS-Eintrag)
- 3.4 Record Size (Eintragsgröße)
- 3.5 Wildcard Records (Wildcard-Einträge)
4. The check_host() Function (Die check_host()-Funktion)
- 4.1 Arguments (Argumente)
- 4.2 Results (Ergebnisse)
- 4.3 Initial Processing (Anfangsverarbeitung)
- 4.4 Record Lookup (Eintragsabfrage)
- 4.5 Selecting Records (Auswahl von Einträgen)
- 4.6 Record Evaluation (Eintragsbewertung)
- 4.7 Default Result (Standardergebnis)
- 4.8 Domain Specification (Domain-Spezifikation)
5. Mechanism Definitions (Mechanismusdefinitionen)
- 5.1 "all"
- 5.2 "include"
- 5.3 "a"
- 5.4 "mx"
- 5.5 "ptr" (do not use) ("ptr" (nicht verwenden))
- 5.6 "ip4" and "ip6" ("ip4" und "ip6")
- 5.7 "exists"
6. Modifier Definitions (Modifikator-Definitionen)
- 6.1 redirect: Redirected Query (redirect: Umgeleitete Abfrage)
- 6.2 exp: Explanation (exp: Erklärung)
7. Macros (Makros)
- 7.1 Formal Specification (Formale Spezifikation)
- 7.2 Macro Definitions (Makrodefinitionen)
- 7.3 Macro Processing Details (Makroverarbeitungsdetails)
- 7.4 Expansion Examples (Erweiterungsbeispiele)
8. Result Handling (Ergebnisbehandlung)
- 8.1 None
- 8.2 Neutral
- 8.3 Pass
- 8.4 Fail
- 8.5 Softfail
- 8.6 Temperror
- 8.7 Permerror
9. Recording the Result (Aufzeichnung des Ergebnisses)
- 9.1 The Received-SPF Header Field (Das Received-SPF-Header-Feld)
- 9.2 SPF Results in Authentication-Results (SPF-Ergebnisse in Authentication-Results)
- 9.3 Local Policy Storage (Lokale Richtlinienspeicherung)
- 9.4 Downstream Processing (Nachgelagerte Verarbeitung)
10. Effects on Infrastructure (Auswirkungen auf die Infrastruktur)
- 10.1 DNS Server Load (DNS-Serverlast)
- 10.2 Large Volume Mailing (Versand großer Mengen)
- 10.3 Email Forwarding (E-Mail-Weiterleitung)
- 10.4 Mailing Lists (Mailinglisten)
- 10.5 IPv6 Considerations (IPv6-Überlegungen)
- 10.6 Subdomain Policies (Subdomain-Richtlinien)
11. Security Considerations (Sicherheitsüberlegungen)
- 11.1 Security Strengths (Sicherheitsstärken)
- 11.2 Security Limitations (Sicherheitseinschränkungen)
- 11.3 DNS Security (DNS-Sicherheit)
- 11.4 Privacy Considerations (Datenschutzüberlegungen)
- 11.5 DoS Attacks (DoS-Angriffe)
- 11.6 Best Practices for Secure SPF Deployment (Best Practices für sichere SPF-Bereitstellung)
Appendix A. Extended Examples (Erweiterte Beispiele)
- A.1 Simple Examples (Einfache Beispiele)
- A.2 Multiple Domain Example (Mehrfach-Domain-Beispiel)
- A.3 DNS Blacklist (DNSBL) Style Example (DNS-Blacklist-Stil-Beispiel)
- A.4 Multiple Requirements Example (Beispiel für mehrere Anforderungen)
- A.5 Subdomain-Konfigurationsbeispiele
- A.6 Beispiele für Drittanbieter-Dienst-Integration
- A.7 Fehlkonfigurationsbeispiele (zu vermeiden)
- A.8 IPv6-Konfigurationsbeispiel
- A.9 Erklärungsstring-Beispiel
- A.10 Test- und Übergangsstrategie
Appendix B. Changes in Implementation Requirements from RFC 4408 (Änderungen der Implementierungsanforderungen gegenüber RFC 4408)
- B.1 Hauptänderungen
- B.2 Änderungen der Implementierungsanforderungen
- B.3 Terminologieänderungen
- B.4 Verbesserung der Sicherheitsüberlegungen
- B.5 Änderungen bei IANA-Registrierungen
- B.6 Interoperabilitätsverbesserungen
- B.7 Rückwärtskompatibilität
- B.8 Änderungen der Dokumentenstruktur
- B.9 Migrationsanleitung
- B.10 Aktualisierung der Referenzdokumente
Appendix C. Further Testing Advice (Weitere Testempfehlungen)
- C.1 Testen von SPF-Einträgen
- C.2 Testen der SPF-Prüfimplementierung
- C.3 Test-E-Mails senden
- C.4 Makro-Tests
- C.5 Leistungstests
- C.6 Regressionstests
- C.7 Häufige Probleme testen
- C.8 Debug-Techniken
- C.9 Produktionsumgebung-Überwachung
Appendix D. SPF/Mediator Interactions (SPF/Vermittler-Interaktionen)
- D.1 Originating ADMDs (Ursprungs-ADMD)
- D.2 Mediators (Vermittler)
- D.3 Receiving ADMDs (Empfänger-ADMD)
- D.4 Interoperabilitätsempfehlungen
- D.5 Zukünftige Entwicklungsrichtung
Appendix E. Mail Services (Maildienste)
- E.1 Web-Based Mail Services (Webbasierte Maildienste)
- E.2 Shared Hosting Services (Shared-Hosting-Dienste)
- E.3 Enterprise Mail Systems (Unternehmens-Mailsysteme)
- E.4 Email Marketing Services (E-Mail-Marketing-Dienste)
- E.5 Transactional Email Services (Transaktions-E-Mail-Dienste)
- E.6 Mobile and IoT Devices (Mobile und IoT-Geräte)
- E.7 Best Practices Summary (Best-Practices-Zusammenfassung)
Appendix F. Test Suite (Testsuite)
- F.1 Basic Tests (Grundlegende Tests)
- F.2 Mechanism Tests (Mechanismus-Tests)
- F.3 Qualifier Tests (Qualifizierer-Tests)
- F.4 Modifier Tests (Modifizierer-Tests)
- F.5 Macro Tests (Makro-Tests)
- F.6 DNS Lookup Limit Tests (DNS-Abfragelimit-Tests)
- F.7 Void Lookup Tests (Leere-Abfrage-Tests)
- F.8 Syntax Error Tests (Syntaxfehler-Tests)
- F.9 Integration Tests (Integrationstests)
- F.10 Edge Cases (Grenzfälle)
- F.11 Performance Tests (Leistungstests)
- F.12 Test Result Summary Format (Testergebnis-Zusammenfassungsformat)
Appendix G. Acknowledgements (Danksagungen)
- G.1 Original Contributors (Ursprüngliche Mitwirkende)
- G.2 RFC 4408 Contributors (RFC 4408-Mitwirkende)
- G.3 RFC 7208 Contributors (RFC 7208-Mitwirkende)
- G.4 Community Contributions (Community-Beiträge)
- G.5 IETF Working Groups (IETF-Arbeitsgruppen)
- G.6 Tool and Library Developers (Tool- und Bibliotheksentwickler)
- G.7 Documentation Contributors (Dokumentationsmitwirkende)
- G.8 Testing and Deployment (Tests und Bereitstellung)
- G.9 Special Thanks (Besonderer Dank)
- G.10 Ongoing Work (Laufende Arbeiten)

Grundlegende Informationen​

Zusammenfassung (Abstract)​

Contents​

Appendices (Anhänge)​

SPF-Überblick​

Was ist SPF?​

SPF vs DKIM vs DMARC​

SPF-Eintragsformat​

Grundlegende Syntax​

Mechanismen (Mechanisms)​

Qualifizierer (Qualifiers)​

Modifikatoren (Modifiers)​

SPF-Eintragsbeispiele​

Basiskonfigurationen​

Drittanbieter-Dienste​

Gemischte Konfigurationen​

Subdomains​

SPF-Prüfablauf​

Empfänger-Verifizierungsschritte​

SPF-Ergebnisse​

DNS-Abfragelimits​

10-Abfragen-Limit​

SPF Flattening Tool​

Praktische Werkzeuge​

SPF-Eintrags-Generator​

SPF-Verifizierungs-Tool​

Best Practices für die Bereitstellung​

1. Schrittweise Bereitstellung​

2. Häufige Fehler​

3. Testen und Verifizieren​

Integration mit DKIM/DMARC​

Vollständige E-Mail-Sicherheitskonfiguration​

Referenzen​

1. Introduction (Einführung)​

1.1 Terminology (Terminologie)​

1.1.1 Key Words (Schlüsselwörter)​

1.1.2 Imported Definitions (Importierte Definitionen)​

1.1.3 MAIL FROM Definition (MAIL FROM Definition)​

1.1.4 HELO Definition (HELO Definition)​

1.2 check_host()​

2. Operational Overview (Betriebsübersicht)​

2.1 Publishing Authorization (Veröffentlichung der Autorisierung)​

2.2 Checking Authorization (Prüfung der Autorisierung)​

2.3 The "HELO" Identity (Die "HELO"-Identität)​

2.4 The "MAIL FROM" Identity (Die "MAIL FROM"-Identität)​

2.5 Location of Checks (Ort der Prüfungen)​

2.6 Results of Evaluation (Bewertungsergebnisse)​

2.6.1 None​

2.6.2 Neutral (Neutral)​

2.6.3 Pass (Bestanden)​

2.6.4 Fail (Fehlgeschlagen)​

2.6.5 Softfail (Soft-Fail)​

2.6.6 Temperror (Temporärer Fehler)​

2.6.7 Permerror (Permanenter Fehler)​

3. SPF Records (SPF-Einträge)​

3.1 DNS Resource Records (DNS-Ressourceneinträge)​

3.2 Multiple DNS Records (Mehrere DNS-Einträge)​

3.3 Multiple Strings in a Single DNS Record (Mehrere Strings in einem einzelnen DNS-Eintrag)​

3.4 Record Size (Eintragsgröße)​

3.5 Wildcard Records (Wildcard-Einträge)​

4. The check_host() Function (Die check_host()-Funktion)​

4.1 Arguments (Argumente)​

4.2 Results (Ergebnisse)​

4.3 Initial Processing (Anfangsverarbeitung)​

4.4 Record Lookup (Eintragsabfrage)​

4.5 Selecting Records (Auswahl von Einträgen)​

4.6 Record Evaluation (Eintragsbewertung)​

4.6.1 Term Evaluation (Term-Bewertung)​

4.6.2 Mechanisms (Mechanismen)​

4.6.3 Modifiers (Modifikatoren)​

4.6.4 DNS Lookup Limits (DNS-Abfragebeschränkungen)​

4.7 Default Result (Standardergebnis)​

4.8 Domain Specification (Domain-Spezifikation)​

5. Mechanism Definitions (Mechanismusdefinitionen)​

5.1 "all"​

5.2 "include"​

5.3 "a"​

5.4 "mx"​

5.5 "ptr" (do not use) ("ptr" (nicht verwenden))​

5.6 "ip4" and "ip6" ("ip4" und "ip6")​

Grundlegende Informationen

Zusammenfassung (Abstract)

Contents

Appendices (Anhänge)

SPF-Überblick

Was ist SPF?

SPF vs DKIM vs DMARC

SPF-Eintragsformat

Grundlegende Syntax

Mechanismen (Mechanisms)

Qualifizierer (Qualifiers)

Modifikatoren (Modifiers)

SPF-Eintragsbeispiele

Basiskonfigurationen

Drittanbieter-Dienste

Gemischte Konfigurationen

Subdomains

SPF-Prüfablauf

Empfänger-Verifizierungsschritte

SPF-Ergebnisse

DNS-Abfragelimits

10-Abfragen-Limit

SPF Flattening Tool

Praktische Werkzeuge

SPF-Eintrags-Generator

SPF-Verifizierungs-Tool

Best Practices für die Bereitstellung

1. Schrittweise Bereitstellung

2. Häufige Fehler

3. Testen und Verifizieren

Integration mit DKIM/DMARC

Vollständige E-Mail-Sicherheitskonfiguration

Referenzen

1. Introduction (Einführung)

1.1 Terminology (Terminologie)

1.1.1 Key Words (Schlüsselwörter)

1.1.2 Imported Definitions (Importierte Definitionen)

1.1.3 MAIL FROM Definition (MAIL FROM Definition)

1.1.4 HELO Definition (HELO Definition)

1.2 check_host()

2. Operational Overview (Betriebsübersicht)

2.1 Publishing Authorization (Veröffentlichung der Autorisierung)

2.2 Checking Authorization (Prüfung der Autorisierung)

2.3 The "HELO" Identity (Die "HELO"-Identität)

2.4 The "MAIL FROM" Identity (Die "MAIL FROM"-Identität)

2.5 Location of Checks (Ort der Prüfungen)

2.6 Results of Evaluation (Bewertungsergebnisse)

2.6.1 None

2.6.2 Neutral (Neutral)

2.6.3 Pass (Bestanden)

2.6.4 Fail (Fehlgeschlagen)

2.6.5 Softfail (Soft-Fail)

2.6.6 Temperror (Temporärer Fehler)

2.6.7 Permerror (Permanenter Fehler)

3. SPF Records (SPF-Einträge)

3.1 DNS Resource Records (DNS-Ressourceneinträge)

3.2 Multiple DNS Records (Mehrere DNS-Einträge)

3.3 Multiple Strings in a Single DNS Record (Mehrere Strings in einem einzelnen DNS-Eintrag)

3.4 Record Size (Eintragsgröße)

3.5 Wildcard Records (Wildcard-Einträge)

4. The check_host() Function (Die check_host()-Funktion)

4.1 Arguments (Argumente)

4.2 Results (Ergebnisse)

4.3 Initial Processing (Anfangsverarbeitung)

4.4 Record Lookup (Eintragsabfrage)

4.5 Selecting Records (Auswahl von Einträgen)

4.6 Record Evaluation (Eintragsbewertung)

4.6.1 Term Evaluation (Term-Bewertung)

4.6.2 Mechanisms (Mechanismen)

4.6.3 Modifiers (Modifikatoren)

4.6.4 DNS Lookup Limits (DNS-Abfragebeschränkungen)

4.7 Default Result (Standardergebnis)

4.8 Domain Specification (Domain-Spezifikation)

5. Mechanism Definitions (Mechanismusdefinitionen)

5.1 "all"

5.2 "include"

5.3 "a"

5.4 "mx"

5.5 "ptr" (do not use) ("ptr" (nicht verwenden))

5.6 "ip4" and "ip6" ("ip4" und "ip6")