{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiclwn246ntln7dxmskidp3ekezbode7p6ctmv322fugxspaq4e36m",
    "uri": "at://did:plc:nkxz2ojdvmieg2nhphvputvp/app.bsky.feed.post/3mmofqvxklyx2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreig5ulkm623dgpih3nkzp6od2at5watr6lv4a6ecff6vnqhvhytuum"
    },
    "mimeType": "image/png",
    "size": 635991
  },
  "description": "Ein SPF-Record legt im DNS fest, welche Server fuer eine Domain Mail verschicken duerfen. Die Mechanismen include/a/mx/ip4/ip6/all, die Qualifier +-~? und der 10-Lookup-Limit-Stolperstein in einem Praxis-Aufschrieb. Warum Hardfail (-all) meist die richtige Wahl ist.",
  "path": "/2013/12/01/spf-record-kurz-erklaert/",
  "publishedAt": "2026-05-25T11:45:58.000Z",
  "site": "https://www.kernel-error.de",
  "tags": [
    "DKIM",
    "DMARC",
    "Email",
    "Hardening",
    "InfoSec",
    "MailServer",
    "SelfHosted",
    "SPF",
    "RFC 7208",
    "kitterman.com/spf",
    "SPF Records",
    "DKIM-Signatur",
    "Einfach melden."
  ],
  "textContent": "SPF (Sender Policy Framework, RFC 7208) legt per DNS fest, welche Server für eine Domain E-Mails versenden dürfen. Empfangende Mailserver prüfen bei jeder eingehenden Mail, ob die IP-Adresse des sendenden Servers im SPF-Record der Absenderdomain steht. Steht sie nicht drin, wird die Mail je nach Policy abgewiesen oder markiert.\n\n### Aufbau eines SPF-Records\n\nEin SPF-Record ist ein TXT-Record im DNS der Domain. Ein typisches Beispiel:\n\n\n    kernel-error.de.  IN  TXT  \"v=spf1 ip4:148.251.30.205 ip6:2a01:4f8:262:4716::25 mx -all\"\n\n**Wichtig:** Der alte DNS-Record-Typ `IN SPF` ist seit RFC 7208 (2014) abgeschafft. Nur `IN TXT` verwenden.\n\n### Mechanismen\n\nJeder Mechanismus definiert eine Regel, gegen die die IP des sendenden Servers geprüft wird:\n\n**`ip4:148.251.30.205`**|  Diese IPv4-Adresse darf senden. Auch Netze möglich: `ip4:148.251.30.0/24`\n---|---\n**`ip6:2a01:4f8:...`**|  Diese IPv6-Adresse darf senden\n**`mx`**|  Alle IP-Adressen der MX-Records der Domain dürfen senden\n**`a`**|  Die IP-Adresse des A/AAAA-Records der Domain darf senden\n**`a:smtp.example.de`**|  Die IP-Adresse eines bestimmten Hosts darf senden\n**`include:example.de`**|  Die SPF-Policy einer anderen Domain mit einbeziehen (z.B. für externe Dienstleister)\n**`redirect=example.de`**|  Gesamte SPF-Policy von einer anderen Domain übernehmen\n\n**Nicht mehr verwenden:** Der `ptr`-Mechanismus ist seit RFC 7208 explizit nicht empfohlen. Er erzeugt unnötige Reverse-DNS-Abfragen und ist fehleranfällig.\n\n### Qualifier: Was passiert bei einem Treffer?\n\nVor jedem Mechanismus kann ein Qualifier stehen, der bestimmt, was mit der Mail passiert:\n\n**`+`** (Pass)| Erlaubt (Standard, wenn kein Qualifier angegeben)\n---|---\n**`-`** (Fail)| Nicht erlaubt, Mail soll abgewiesen werden\n**`~`** (SoftFail)| Nicht erlaubt, aber nicht hart ablehnen, Mail markieren\n**`?`** (Neutral)| Keine Aussage, wie kein SPF\n\n### Hardfail oder Softfail?\n\nAm Ende des SPF-Records steht der Catch-All-Mechanismus `all` mit einem Qualifier:\n\n  * `-all` (Hardfail), alle Server die nicht explizit gelistet sind, dürfen nicht senden. Empfänger soll ablehnen.\n  * `~all` (Softfail), alle nicht gelisteten Server sind verdächtig, aber nicht definitiv verboten. Mail wird zugestellt, aber markiert.\n\n\n\nIn der Praxis: `-all` ist die klare Empfehlung, wenn man weiß, welche Server für die Domain senden. `~all` war lange der konservative Ansatz, weil manche Empfänger SPF-Fails zu aggressiv behandelten. Seit DMARC den Umgang mit SPF-Ergebnissen standardisiert hat, ist das kein Argument mehr. Wer DMARC einsetzt, sollte `-all` verwenden.\n\n### Das 10-Lookup-Limit\n\nRFC 7208 erlaubt maximal 10 DNS-Abfragen pro SPF-Prüfung. Jeder `include`, `mx`, `a` und `redirect` zählt als Lookup. `ip4` und `ip6` verursachen keine Abfrage, die stehen direkt im Record.\n\nDas wird schnell zum Problem, wenn man externe Dienstleister einbindet. Ein `include:_spf.google.com` zieht allein schon 3-4 weitere Lookups nach sich. Wer Office 365, Google Workspace und einen Newsletter-Dienst kombiniert, sprengt das Limit leicht. Die Fehlermeldung:\n\n\n    PermError SPF Permanent Error: Too many DNS lookups\n\n**Lösung:** Den SPF-Record so schlank wie möglich halten. Wo möglich `ip4`/`ip6` statt `include` verwenden, das verbraucht keine Lookups. Externe Dienstleister nach IP-Ranges fragen statt blind deren Include-Ketten zu übernehmen.\n\n### SPF-Record testen\n\n\n    # SPF-Record abfragen\n    dig TXT kernel-error.de +short\n\n    # Ergebnis prüfen, sollte den v=spf1 Record zeigen\n    # Mehrere TXT-Records sind normal (SPF, DMARC, DKIM Policy etc.)\n\nFür einen vollständigen Check mit Lookup-Zählung eignen sich Online-Tools wie kitterman.com/spf oder `mxtoolbox.com`. Die zeigen auch verschachtelte Includes auf und warnen bei Überschreitung des 10-Lookup-Limits.\n\n### SPF allein reicht nicht\n\nSPF prüft die IP-Adresse gegen den **Envelope-From** (die Adresse aus dem SMTP-`MAIL FROM`-Kommando), nicht gegen den `From:`-Header, den der Empfänger sieht. Ein Angreifer kann also eine Mail mit gefälschtem `From:`-Header senden, solange der Envelope-From eine Domain ist, die er kontrolliert. Der Empfänger sieht den gefälschten Absender, SPF sagt trotzdem „Pass“.\n\nSiehe auch: SPF Records\n\nGenau dieses Problem löst DMARC: Es prüft, ob die Domain im `From:`-Header mit der SPF-Domain (Alignment) oder der DKIM-Signatur übereinstimmt. Erst SPF + DKIM + DMARC zusammen ergeben eine vollständige E-Mail-Authentifizierung. Fragen? Einfach melden.",
  "title": "SPF-Record einrichten: Wie du festlegst, wer für deine Domain Mails versenden darf"
}