☰

Ist es möglich, die Schlüsselwörter „a“, „mx“ und „include“ zusammen in SPF zu verwenden?

tag-icon • tag-icon email spf txt-record
Ist es möglich, die Schlüsselwörter „a“, „mx“ und „include“ zusammen in SPF zu verwenden?

Ist es möglich, sie im selben SPF-Eintrag zu verwenden? Beispiel:

Wert TXT:v=spf1 mx a ptr ip4:46.16.60.0/23 a:cdmon.com mx:mail.solarmora.com include:srv.cat ~all

Antwort1

Ja, Sie können alle diese Schlüsselwörter kombinieren, achten Sie nur darauf, dass Sie das Suchlimit von maximal nicht erreichen.10 Adressdatensatz-Suchen:https://www.rfc-editor.org/rfc/rfc7208#section-4.6.4

  • Die Schlüsselwörter a und ptr führen zu einer Suche
    • Das Schlüsselwort ptr ist veraltet und sollte nicht mehr verwendet werden
  • Das Schlüsselwort mx führt zu so vielen Suchvorgängen, wie der MX-Eintrag Domänen zurückgibt
  • Die includeSchlüsselwörter enthalten den referenzierten SPF-Eintrag, nämlich:
$ dig srv.cat TXT +short
"v=spf1 a a:include"

Führt hingegen a:includezu einem Fehler, da die Domäne includenicht existiert.

Antwort2

Es ist technisch möglich, beliebige Mechanismen zu mischen, aber alles andere als die ip4und ip6Mechanismen führt zu zusätzlichen DNS-Lookups. Außerdem gibt es ein Gesamtlimit von 10 DNS-Abfragen (RFC 7208, 4.6.4). Jeder aführt zu einem zusätzlichen Lookup und jeder zu mxmehreren, abhängig von der Anzahl der dahinterliegenden MX-Server. Außerdem includekann es verkettete Mechanismen geben, die ebenfalls bis zum Limit gezählt werden.

Sie sollten sorgfältig überlegen, welche Server wirklich E-Mails aus der Domäne senden,Umschlag Absenderund beschränken Sie Ihren SPF-Eintrag so, dass er nur die erforderlichen Server enthält. Da Ihr SPF-Eintrag nun zusammengestellt ist, scheint es, als hätten Sie dieses Wissen nicht und versuchen, alles „nur für den Fall“ hinzuzufügen. Die Richtlinie endet mit ~all, wodurch alles andere nurweicher FehlerDies verhindert Missbrauch nicht wirksam. Erwägen Sie -allstattdessen die Verwendung von .

Auch,verwende nichtptr(RFC 7208, 5.5):

Hinweis: Dieser Mechanismus ist langsam, er ist bei DNS-Fehlern nicht so zuverlässig wie andere Mechanismen und er stellt eine große Belastung für die .arpa-Nameserver dar. Wenn er verwendet wird, müssen für die Hosts der Domäne entsprechende PTR-Einträge vorhanden sein und der ptrMechanismus SOLLTE einer der letzten überprüften Mechanismen sein. Nach langjähriger Erfahrung mit der Bereitstellung von SPF ist man zu dem Schluss gekommen, dass er unnötig ist und stattdessen zuverlässigere Alternativen verwendet werden sollten. Er wird jedoch immer noch als Teil des SPF-Protokolls verwendet, daher check_host() MÜSSEN konforme Implementierungen ihn unterstützen.

verwandte Informationen