Bevor Sie SPF ändern, ermitteln Sie die Domain, die Ihr Sendedienst für seine Envelope-From-Adresse verwendet. Diese Adresse empfängt Bounces und kann sich von der From-Adresse unterscheiden, die Ihr Empfänger sieht.
Welche Domain prüft SPF?
SPF prüft die Domain in SMTP MAIL FROM, der Envelope-From-Adresse, oder die HELO-Identität des Servers. HELO ist der Hostname, den ein sendender Server beim Aufbau der SMTP-Verbindung übermittelt.
Der Empfänger kennt die verbindende IP bereits, wenn er MAIL FROM erhält, sodass SPF vor dem Eintreffen des Nachrichtentexts laufen kann. Wenn der Envelope-Absender leer ist, wie bei MAIL FROM:<>, verwendet SPF die HELO-Identität. RFC 7208, der SPF-Standard, empfiehlt außerdem, HELO separat zu prüfen.
SPF prüft nicht die sichtbare From-Adresse. DMARC-Alignment verbindet eine authentifizierte Domain mit dieser Adresse.
Wie sieht ein SPF-Record aus?
Ein SPF-Record ist ein DNS-TXT-Record, dessen Wert mit v=spf1 beginnt, gefolgt von Autorisierungsregeln.
example.com TXT "v=spf1 include:mailprovider.example ~all"Hier autorisiert include:mailprovider.example IPs, die die SPF-Richtlinie dieses Anbieters bestehen. ~all erzeugt einen Softfail für andere IPs. Ersetzen Sie den Beispielanbieter durch die Richtlinie, die Ihr Sendedienst veröffentlicht.
Was bedeuten die Mechanismen und Modifier?
Mechanismen testen die verbindende IP gegen eine Bedingung. Der redirect-Modifier delegiert die Auswertung, wenn kein Mechanismus zutrifft.
| Begriff | Wirkung |
|---|---|
ip4, ip6 | Trifft auf eine Adresse oder ein Netzwerk zu, das direkt im Record angegeben ist. |
a | Trifft auf eine Adresse zu, die für die genannte Domain zurückgegeben wird, unter Verwendung der IP-Familie der Verbindung. |
mx | Trifft auf eine Adresse eines Mail-Exchangers der genannten Domain zu. |
include | Trifft zu, wenn die referenzierte Richtlinie für diese IP das Ergebnis pass zurückgibt. |
exists | Treffer, wenn der angegebene DNS-Name einen A-Record besitzt; Makros können diesen Namen aus der Verbindung zusammensetzen. |
redirect= | Wertet die Policy einer anderen Domain aus, wenn kein Mechanismus zutrifft; ein all-Mechanismus macht ihn wirkungslos. |
ptr | Prüft validierte Reverse-DNS-Namen; fügen Sie ihn nicht zu neuen Records hinzu, da die Abfrage langsam und unzuverlässig ist. |
all | Trifft auf jede verbleibende IP zu, wobei der Qualifier das Ergebnis bestimmt. |
Die Adressmechanismen heißen ip4 und ip6. Ein ptr-Eintrag kann in einer älteren Policy vorkommen, aber RFC 7208 rät von seiner Verwendung ab, obwohl Validatoren ihn unterstützen müssen.
Was bewirken die all-Qualifier?
Der Qualifier legt das SPF-Ergebnis für eine IP fest, die all erreicht; der Empfänger entscheidet, wie er die Nachricht behandelt.
| Endung | Ergebnis |
|---|---|
-all | Fail: Die Domain autorisiert die IP nicht. |
~all | Softfail: Die Domain stuft die IP als wahrscheinlich nicht autorisiert ein. |
?all | Neutral: Die Domain trifft keine Aussage. |
+all | Pass für jede IP; hebt die Einschränkung auf, die SPF sonst bieten würde. |
Wie werden Beispiel-Records ausgewertet?
Jedes Beispiel unten zeigt eine eigene Policy. Die IPs und Domains sind Dokumentationsbeispiele, keine Werte, die Sie für Ihren Absender veröffentlichen sollten.
| Record | Was er autorisiert |
|---|---|
v=spf1 mx ip4:192.0.2.10 ip4:198.51.100.0/24 ~all | Die Mail-Exchanger der Domain, eine IP und das angegebene Netzwerk; andere IPs erhalten Softfail. |
v=spf1 a ip4:192.0.2.0/25 ip4:198.51.100.0/26 -all | Die Adress-Records der Domain und zwei Netzwerke; andere IPs erhalten Fail. |
v=spf1 -all | Keine IPs; jede versuchte Nutzung dieser Domain führt zu SPF-Fail. |
v=spf1 +all | Jede IP, bietet also keine Versandeinschränkung. |
v=spf1 redirect=_spf.example.com | Was auch immer die Policy unter _spf.example.com autorisiert. |
v=spf1 exists:%{i}._spf.example.com ~all | IPs, deren expandierter Lookup-Name einen A-Record zurückgibt; andere IPs erhalten Softfail. |
Beim exists-Beispiel erzeugt eine Verbindung von 192.0.2.10 den Lookup-Namen 192.0.2.10._spf.example.com. Sie müssen die DNS-Records betreiben, die eine solche Policy funktionsfähig machen; das Muster allein autorisiert keinen Provider.
Wie viele DNS-Lookups kann SPF verwenden?
SPF erlaubt zehn ausgewertete DNS-abfragende Begriffe über die gesamte Policy und verschachtelte Auswertungen hinweg. Ein elfter erzeugt permerror; das Hinzufügen eines weiteren Providers kann die Auswertung also brechen, statt ihn zu autorisieren.
Die gezählten Begriffe sind include, a, mx, ptr, exists und redirect. Literale ip4-, ip6- und all-Begriffe verbrauchen dieses Kontingent nicht. Gezählt werden Begriffe, nicht einfach jedes DNS-Paket. Der Return-Path-CNAME liefert die SPF-Autorisierung von Bird, ohne ein Apex-Include hinzuzufügen.
Warum kann weitergeleitete Mail bei SPF fehlschlagen?
Ein Forwarder oder eine Mailingliste kann legitime Mail von einer IP erneut senden, die die ursprüngliche Envelope-From-Domain nicht autorisiert. Beispiel: Ein Alumni-Postfach, das an ein persönliches Postfach weiterleitet, ändert den Verbindungsserver, den der endgültige Empfänger sieht.
Wenn die Envelope-From-Adresse unverändert bleibt, wertet SPF diesen neuen Server gegen die Policy der ursprünglichen Domain aus. Ein Forwarder kann die Envelope-From-Adresse per Sender Rewriting Scheme (SRS) umschreiben, um seine eigene Domain zu authentifizieren. Das allein bringt SPF aber nicht in Einklang mit der ursprünglichen sichtbaren From-Adresse.
Eine intakte, ausgerichtete DKIM-Signatur kann weiterhin einen DMARC-Pass liefern. Authentifizierung stellt weder fest, dass eine Nachricht erwünscht ist, noch garantiert sie die Zustellung in den Posteingang.
Was sollten Sie für Bird veröffentlichen?
Sie veröffentlichen den Return-Path-CNAME, der für Ihre Sendedomain bereitgestellt wird. Er verweist auf die Bounce-Infrastruktur von Bird, die bereits die SPF-Autorisierung liefert. Sie benötigen kein zusätzliches SPF-Include an Ihrer Apex-Domain, um über Bird zu senden.
Lassen Sie einen bestehenden Apex-SPF-Record für andere Absender unverändert. Kopieren Sie den dns_records der Domain. Verifizieren Sie capabilities.return_path.status; prüfen Sie capabilities.sending.status auf Bereitschaft für alle Versandanforderungen. Beide Statusfelder verwenden diese Werte:
| Status | Bedeutung und Maßnahme |
|---|---|
pending | Die Verifizierung wurde noch nicht ausgeführt oder läuft; warten Sie auf das Ergebnis. |
verified | Die DNS-Records der Fähigkeit stimmen mit den erwarteten Werten überein. |
warning | Zuvor verifizierte Records stimmen nicht mehr überein; korrigieren Sie sie, bevor die Kulanzfrist endet. Der Versand ist noch nicht betroffen. |
failed | Ein DNS-Wert ist falsch; korrigieren Sie ihn. |
temporary_failure | Ein DNS-Lookup ist vorübergehend fehlgeschlagen; die Verifizierung wird automatisch erneut versucht. |
not_configured | Die Fähigkeit ist für diese Domain nicht eingerichtet. |
Sie verifizieren DKIM, Return-Path und DMARC vor dem Senden. Sie können den Return-Path-Hostnamen ändern. Wenn ein DNS-TXT-Wert mehrere Strings in Anführungszeichen benötigt, formatiert der DNS-Record-Splitter diese Strings, ohne das Lookup-Kontingent von SPF zu ändern.