SPF (Sender Policy Framework): Unterschied zwischen den Versionen

Aus Wikizone
Wechseln zu: Navigation, Suche
 
(6 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
 
SPF wird von vielen IT-lern als in der Praxis unwirksam angesehen. Wenn man Weiterleitungen über Newsletterdienstleister oder auch manuelle in der Praxis einbezieht, kann man praktisch nicht mehr hart blockieren (-all). Es kann allerdings als Beweis dafür gelten, das die Mail original ist, wenn sie tatsächlich über den Original-Server versendet wurde. Das ist aber nur dann sinnvoll, wenn dem Empfänger der Absender bekannt ist. Als reiner Schutz gegen Spam funktioniert das nicht, da auch ein Spammer sich eine Domain mit SPF Eintrag billig und Anonym zulegen kann.
 
SPF wird von vielen IT-lern als in der Praxis unwirksam angesehen. Wenn man Weiterleitungen über Newsletterdienstleister oder auch manuelle in der Praxis einbezieht, kann man praktisch nicht mehr hart blockieren (-all). Es kann allerdings als Beweis dafür gelten, das die Mail original ist, wenn sie tatsächlich über den Original-Server versendet wurde. Das ist aber nur dann sinnvoll, wenn dem Empfänger der Absender bekannt ist. Als reiner Schutz gegen Spam funktioniert das nicht, da auch ein Spammer sich eine Domain mit SPF Eintrag billig und Anonym zulegen kann.
 +
 +
Update 2023: Inzwischen schaut es so aus, dass man SPF oftmals einsetzen muss. Wenn man Mails über eine WebApp per PHP versendet und kein Postfach verwenden möchte / kann. Werden E-Mails oft aussortiert. Das kommt z.b. dann vor wenn die E-Mails über Microsoft Exchange versendet werden sollen.
  
 
Alternative [[DKIM]]
 
Alternative [[DKIM]]
Zeile 5: Zeile 7:
 
Siehe auch
 
Siehe auch
 
== Links ==
 
== Links ==
 +
E-Mail Probleme beheben
 +
https://dmarcian.com/spf-survey/ (Test Tool)
 +
https://dmarcian.com/spf-syntax-table/
 +
https://www.kitterman.com/spf/validate.html? (Validation Test Tool)
 +
https://wiki.stephanschlegel.de/index.php?title=E-Mail_Probleme_beheben#Beispiele
 +
https://all-inkl.com/wichtig/anleitungen/kas/tools/dns-werkzeuge/spf_482.html
 +
https://dmarcian.com/create-spf-record/
 
  https://www.youtube.com/watch?v=T1d7wTgBi28
 
  https://www.youtube.com/watch?v=T1d7wTgBi28
 
  https://switchie.ch/was-bedeutet-spf-sender-policy-framework/# (Quelle dieses Artikels / Zugriff: 2018-01)
 
  https://switchie.ch/was-bedeutet-spf-sender-policy-framework/# (Quelle dieses Artikels / Zugriff: 2018-01)
 +
 
== Beispiel erklärt ==
 
== Beispiel erklärt ==
 
=== Problem ===
 
=== Problem ===
Zeile 19: Zeile 29:
 
  mx -> Server die auch als MX-Recrds definiert sind dürfen verschicken
 
  mx -> Server die auch als MX-Recrds definiert sind dürfen verschicken
 
  ?all -> Keine Aussage was andere Server dürfen (-all = kein anderer Server darf versenden, +all = alle anderen dürfen sind dann halt nicht verifiziert)
 
  ?all -> Keine Aussage was andere Server dürfen (-all = kein anderer Server darf versenden, +all = alle anderen dürfen sind dann halt nicht verifiziert)
 +
=== Beispiel ===
 +
Ein typischer Eintrag wie er z.B. in den all-inkl Accounts angelegt ist.
 +
v=spf1 mx a ?all
 +
Server die im A und MX Record stehen dürfen versenden
  
 
== Hinweise ==
 
== Hinweise ==
Zeile 88: Zeile 102:
 
     Klicken Sie auf „speichern“, um den SPF-Eintrag für Ihre DOMAIN einzutragen und zu aktivieren.
 
     Klicken Sie auf „speichern“, um den SPF-Eintrag für Ihre DOMAIN einzutragen und zu aktivieren.
  
−
===Wie kann ein bestehender SPF-Eintrag geändert werden ? ===
+
== SPF Allgemein ==
 +
Understanding SPF Syntax
 +
 
 +
We have developed this comprehensive guide to increase your SPF understanding and help troubleshoot issues our application might have brought to your attention. Having a valid, accurate, and aligned SPF record will lead to improved authentication coverage, deliverability and help promote your desired level of security for your domains.
 +
 
 +
Don’t have a dmarcian account? You can still query the contents of your SPF record using our SPF Survey tool.
 +
 
 +
Additional information about SPF can be found in the linked articles at the bottom of this document. If you are new to SPF, we show you how to How to Create and Add an SPF Record.
 +
 
 +
Create a free account now to have dmarcian monitor your SPF, DKIM and DMARC records for you automatically.  Get instant visibility into delivery errors, phishing and impersonation attempts with dmarcian’s SaaS Platform.
 +
Mechanisms:
 +
Modifiers:
 +
Mechanisms
 +
 
 +
Mechanisms can be used to describe the set of hosts which are designated outbound mailers for the domain and can be prefixed with one of four qualifiers:
 +
 
 +
+ Pass
 +
 
 +
~ SoftFail
 +
 
 +
- Fail
 +
 
 +
? Neutral
 +
 
 +
If a mechanism results in a hit, its qualifier value is used. The default qualifier is “+“, i.e. “Pass”. Mechanisms are evaluated in order. If no mechanism or modifier matches, the default result is “Neutral”.
 +
More in-depth information on the differences between “~” and “–” can be found here
 +
 
 +
If a domain has no SPF record at all, the result is “None”. If a domain has a temporary error during DNS processing, you get the result “TempError” (called “error” in earlier drafts). If a syntax or evaluation error occurs (eg. the domain specifies an unrecognized mechanism) the result is “PermError” (formerly “unknown”).
 +
Examples:
 +
 
 +
v=spf1 -all
 +
 
 +
v=spf1 a -all
 +
 
 +
v=spf1 a mx -all
 +
 
 +
v=spf1 +a +mx -all
 +
Evaluation of an SPF record can return any of these results:
 +
The "all" mechanism
 +
 
 +
This mechanism always matches. It should always go at the end of the SPF record.
 +
Examples:
 +
 
 +
V=SPF1 MX ~ALL
 +
Allow domain’s MXs to send mail for the domain, prohibit all others.
 +
 
 +
V=SPF1 ~ALL
 +
The domain sends no mail at all.
 +
 
 +
V=SPF1 +ALL
 +
The domain allows all IP address on the internet to send mail. Though ‘valid’, this is not recommended.
 +
The "ip4" mechanism
 +
 
 +
ip4:<ip4-address>
 +
 
 +
ip4:<ip4-network>/<prefix-length>
 +
 
 +
The argument to the “ip4:” mechanism is an IPv4 network range. If no prefix-length is given, /32 is assumed (singling out an individual host address). Be careful to include a prefix-length greater than /16, as delivery to some smaller receivers may be impacted.
 +
Examples:
 +
 
 +
v=spf1 ip4:192.168.0.1/16 ~all
 +
Allow any IP address between 192.168.0.1 and 192.168.255.255.
 +
The "ip6" mechanism
 +
 
 +
ip6:<ip6-address>
 +
 
 +
ip6:<ip6-network>/<prefix-length>
 +
 
 +
The argument to the “ip6:” mechanism is an IPv6 network range. If no prefix-length is given, /128 is assumed (singling out an individual host address).
 +
Examples:
 +
 
 +
v=spf1 ip6:1080::8:800:200C:417A/96 ~all
 +
Allow any IPv6 address between 1080::8:800:0000:0000 and 1080::8:800:FFFF:FFFF.
 +
 
 +
v=spf1 ip6:1080::8:800:68.0.3.1/96 ~all
 +
Allow any IPv6 address between 1080::8:800:0000:0000 and 1080::8:800:FFFF:FFFF.
 +
The "a" mechanism
 +
 
 +
a
 +
 
 +
a/<prefix-length>
 +
 
 +
a:<domain>
 +
 
 +
a:<domain>/<prefix-length>
 +
 
 +
All the A records for domain are tested. If the client IP is found among them, this mechanism matches. If the connection is made over IPv6, then an AAAA lookup is performed instead.
 +
 
 +
If domain is not specified, the current domain is used.
 +
 
 +
The A records have to match the client IP exactly, unless a prefix-length is provided, in which case each IP address returned by the A lookup will be expanded to its corresponding CIDR prefix, and the client IP will be sought within that subnet.
 +
Examples:
 +
 
 +
v=spf1 a ~all
 +
The current domain is used.
 +
 
 +
v=spf1 a:example.com ~all
 +
Equivalent if the current domain is example.com.
 +
 
 +
v=spf1 a:mailers.example.com ~all
 +
Perhaps example.com has chosen to explicitly list all the outbound mailers in a special A record under mailers.example.com.
 +
 
 +
v=spf1 a/24 a:offsite.example.com/24 ~all
 +
If example.com resolves to 192.0.2.1, the entire class C of 192.0.2.0/24 would be searched for the client IP. Similarly for offsite.example.com. If more than one A record were returned, each one would be expanded to a CIDR subnet.
 +
The "mx" mechanism
 +
 
 +
mx
 +
 
 +
mx/<prefix-length>
 +
 
 +
mx:<domain>
 +
 
 +
mx:<domain>/<prefix-length>
 +
 
 +
All the A records for all the MX records for domain are tested in order of MX priority. If the client IP is found among them, this mechanism matches.
 +
 
 +
If domain is not specified, the current domain is used.
 +
 
 +
The A records have to match the client IP exactly, unless a prefix-length is provided, in which case each IP address returned by the A lookup will be expanded to its corresponding CIDR prefix, and the client IP will be sought within that subnet.
 +
Examples:
 +
 
 +
v=spf1 mx mx:deferrals.domain.com ~all
 +
Perhaps a domain sends mail through its MX servers plus another set of servers whose job is to retry mail for deferring domains.
 +
 
 +
v=spf1 mx/24 mx:offsite.domain.com/24 ~all
 +
Perhaps a domain’s MX servers receive mail on one IP address, but send mail on a different but nearby IP address.
 +
The "ptr" mechanism
 +
 
 +
The hostname or hostnames for the client IP are looked up using PTR queries. The hostnames are then validated: at least one of the A records for a PTR hostname must match the original client IP. Invalid hostnames are discarded. If a valid hostname ends in domain, this mechanism matches.
 +
 
 +
If domain is not specified, the current domain is used.
 +
 
 +
If possible, you should avoid using this mechanism in your SPF record, because it will result in a larger number of expensive DNS lookups.
 +
Examples:
 +
 
 +
v=spf1 ptr ~all
 +
A domain which directly controls all its machines (unlike a dialup or broadband ISP) allows all its servers to send mail. For example, hotmail.com or paypal.com might do this.
 +
 
 +
v=spf1 ptr:otherdomain.com ~all
 +
Any server whose hostname ends in otherdomain.com is designated.
 +
The "exists" mechanism
 +
 
 +
Perform an A query on the provided domain. If a result is found, this constitutes a match. It doesn’t matter what the lookup result is – it could be 127.0.0.2.
 +
 
 +
When you use macros with this mechanism, you can perform RBL-style reversed-IP lookups, or set up per-user exceptions.
 +
Examples:
 +
 
 +
In the following example, the client IP is 1.2.3.4 and the current domain is example.com.
 +
 
 +
v=spf1 exists:example.com ~all
 +
 
 +
If example.com does not resolve, the result is fail. If it does resolve, this mechanism results in a match.
 +
The "include" mechanism
 +
 
 +
The specified domain is searched for a match. If the lookup does not return a match or an error, processing proceeds to the next directive. Warning: If the domain does not have a valid SPF record, the result is a permanent error. Some mail receivers will reject based on a PermError.
 +
Examples:
 +
 
 +
In the following example, the client IP is 1.2.3.4 and the current domain is example.com.
 +
 
 +
v=spf1 include:example.com ~all
 +
 
 +
If example.com has no SPF record, the result is PermError.
 +
Suppose example.com’s SPF record were v=spf1 a ~all.
 +
Look up the A record for example.com. If it matches 1.2.3.4, return Pass.
 +
If there is no match, other than the included domain’s “~all”, the include as a whole fails to match; the eventual result is still Fail from the outer directive set in this example
 +
 
 +
Trust Relationships – The “include:” mechanism is meant to cross administrative boundaries. Great care is needed to ensure that “include:” mechanisms do not place domains at risk for giving SPF Pass results to messages that result from cross user forgery. Unless technical mechanisms are in place at the specified other domain to prevent cross user forgery, “include:” mechanisms should give a Neutral rather than Pass result. This is done by adding “?” in front of “include:”.
 +
Examples:
 +
 
 +
v=spf1 ?include:example.com ~all
 +
 
 +
Modifiers
 +
 
 +
Modifiers are optional. A modifier may appear only once per record. Unknown modifiers are ignored.
 +
The "redirect" mechanism
 +
 
 +
The SPF record for domain replaces the current record. The macro-expanded domain is also substituted for the current domain in those lookups.
 +
 
 +
If a ‘redirect’ modifier is used, the SPF record should not also include the ‘all’ mechanism. If both are present, the ‘redirect’ modifier is ignored. Any ‘redirect’ modifiers beyond the first will be ignored.
 +
Examples:
 +
 
 +
For example, this SPF record is published on example.com:
 +
 
 +
v=spf1 redirect=example.com
 +
 
 +
If example.com has no SPF record, that is an error; the result is unknown.
 +
Suppose example.com’s SPF record was v=spf1 a ~all.
 +
Look up the A record for example.com. If it matches 1.2.3.4, return Pass.
 +
If there is no match, the exec fails to match, and the ~all value is used.
 +
The "exp" mechanism
 +
 
 +
If an SMTP receiver rejects a message, it can include an explanation. An SPF publisher can specify the explanation string that senders see. This way, an ISP can direct nonconforming users to a web page that provides further instructions about how to configure SASL.
 +
 
 +
The domain is expanded; a TXT lookup is performed. The result of the TXT query is then macro-expanded and shown to the sender. Other macros can be used to provide a customized explanation.
 +
 
 +
The exp modifier may only contain printable ASCII characters.
 +
Examples:
 +
 
 +
For example, this SPF record is published on example.com:
 +
 
 +
v=spf1 mx -all exp=explain._spf.%{d}
 +
 
 +
and there is a TXT record at explain._spf.example.com with this string:
 +
 
 +
Emails from example.com must only be sent by its own mail servers.
 +
 
 +
Too many lookups?
 +
 
 +
Over the past decade, it has become increasingly easier to send email.  Countless Sources have entered the marketplace, each providing a specialized toolset tailored to address modern day needs of marketers, developers, and small businesses.  Along with this expansion, email authentication, specifically SPF, has become an increasingly complex matter to navigate.
 +
 
 +
Within the SPF RFC specification (essentially internet law) there lies a practical limit of how many “DNS-querying mechanisms” a single SPF record can contain. That limit is ten. The ten maximum lookup states that a domain administrator (that’s you!) will not require the likes of Gmail or other receivers to conduct more than ten consecutive DNS lookups to see if you authorize a particular IP address to send mail on your behalf.
 +
 
 +
As it has become somewhat commonplace for any single organization to authorize a large number of disparate netblocks (due to the outsourced nature of email infrastructure), there remains what seems like the constant and unnecessary encroachment on the ten maximum lookup.  This limit however remains entirely practical and should be observed to ensure timely delivery and favorable inbox rates.  Further, the solution to avoid the limit is squarely addressed by other mainstream email best practices, long encouraged by major inbound receivers such as Gmail and Yahoo.
 +
 
 +
The single most practical solution to avoid the ‘too many lookups’ issue is to make use of sub-domains.  As each discrete sub.domain is afforded its own ten lookup maximum, SPF is effectively boundless.  Example:  hello.com is permitted ten lookups + sub.hello.com is permitted ten lookups.  Plainly put, you should never run in to the ten maximum lookup condition if you are correctly segmenting different mail streams (eg. transactional, corporate, marketing, etc.) on to discrete name space.
 +
 
 +
In this sub section “delivery tips’ of the Gmail postmaster site, it is recommended to;
 +
 
 +
    Use separate email addresses
 +
    Send mail from different domains and/or IP addresses
  
−
Loggen Sie sich auf www.switchplus.ch in Ihr Benutzerkonto ein und klicken Sie links in der Navigationsleiste auf „Grundkonfiguration“. Gehen Sie anschliessend rechts am Zeilenende der jeweiligen DOMAIN auf das Editierungssymbol und wählen Sie „Nameserver editieren“. In der Folge-Maske finden Sie alle Records. Beim bestehenden SPF-Record können Sie nun die gewünschten Einstellungen vornehmen in dem Sie auf das Auflistungs-Symbol klicken.
+
In summary, you should not run in to the 10 lookup maximum. If you do, we’ve outlined some additional strategies and knowledge-base materials on how to navigate.
−
Der SPF-Assistent erzeugt einen korrekten SPF-Eintrag, den Sie nach Belieben ändern können. Sie sollten dies jedoch nur dann machen, wenn Sie SPF und seine Parameter wirklich kennen. Der SPF-Eintrag wird aber immer auf Korrektheit überprüft. Sollten Sie daher Fehler bei der individuellen Eingabe machen, werden Sie über die Fehler informiert und der Eintrag wird nicht aktiviert.
 

Aktuelle Version vom 13. Dezember 2024, 21:18 Uhr

SPF wird von vielen IT-lern als in der Praxis unwirksam angesehen. Wenn man Weiterleitungen über Newsletterdienstleister oder auch manuelle in der Praxis einbezieht, kann man praktisch nicht mehr hart blockieren (-all). Es kann allerdings als Beweis dafür gelten, das die Mail original ist, wenn sie tatsächlich über den Original-Server versendet wurde. Das ist aber nur dann sinnvoll, wenn dem Empfänger der Absender bekannt ist. Als reiner Schutz gegen Spam funktioniert das nicht, da auch ein Spammer sich eine Domain mit SPF Eintrag billig und Anonym zulegen kann.

Update 2023: Inzwischen schaut es so aus, dass man SPF oftmals einsetzen muss. Wenn man Mails über eine WebApp per PHP versendet und kein Postfach verwenden möchte / kann. Werden E-Mails oft aussortiert. Das kommt z.b. dann vor wenn die E-Mails über Microsoft Exchange versendet werden sollen.

Alternative DKIM

Siehe auch

Links[Bearbeiten]

E-Mail Probleme beheben
https://dmarcian.com/spf-survey/ (Test Tool)
https://dmarcian.com/spf-syntax-table/
https://www.kitterman.com/spf/validate.html? (Validation Test Tool)
https://wiki.stephanschlegel.de/index.php?title=E-Mail_Probleme_beheben#Beispiele
https://all-inkl.com/wichtig/anleitungen/kas/tools/dns-werkzeuge/spf_482.html
https://dmarcian.com/create-spf-record/
https://www.youtube.com/watch?v=T1d7wTgBi28
https://switchie.ch/was-bedeutet-spf-sender-policy-framework/# (Quelle dieses Artikels / Zugriff: 2018-01)

Beispiel erklärt[Bearbeiten]

Problem[Bearbeiten]

Absender können gefälscht werden. Es darf jeder alles verschicken.

Lösung ???[Bearbeiten]

TXT (SPF) DNS Eintrag gibt vor wer versenden darf. 

heinlein-support.de. IN TXT "v=spf1 ip4:213.203.238.0/25 ip4:195.10.208.0/24 mx include:jpberlin.de ?all"

Hier wird quasi hinterlegt wer versenden darf 

v=spf1 -> Version (SPF-Record Version 1)
ip4:xxx:xxx:xxx:xxx/xx -> IP Bereich
include:... -> Ein SPF-Reord einer anderen Domain wird included
mx -> Server die auch als MX-Recrds definiert sind dürfen verschicken
?all -> Keine Aussage was andere Server dürfen (-all = kein anderer Server darf versenden, +all = alle anderen dürfen sind dann halt nicht verifiziert)

Beispiel[Bearbeiten]

Ein typischer Eintrag wie er z.B. in den all-inkl Accounts angelegt ist. 

v=spf1 mx a ?all

Server die im A und MX Record stehen dürfen versenden

Hinweise[Bearbeiten]

  • Die Einstellung TXT statt SPF ist wichtig, da TXT seit rfc7208 der einzig standardkonforme Record für SPF ist! Der dedizierte SPF-Record ist damit obsolet und wird daher nicht breitflächig unterstützt.

Übersicht von switcher.ch[Bearbeiten]

SPF (Sender Policy Framework) ist ein Protokoll, mit dem ein Halter einer DOMAIN festlegen kann, welche IP-Adressen E-Mails im Namen seiner DOMAINs verschicken dürfen und steht für „Sender Policy Framework“. Wenn jemand also eine E-Mail erhält, die behauptet von der DOMAIN ihr-unternehmen.ch versendet worden zu sein, so kann man mittels SPF prüfen, ob dies wirklich der Fall ist. Wenn die entsprechende IP-Adresse nicht durch den SPF-Eintrag autorisiert wurde, so ist die Wahrscheinlichkeit sehr gross, dass die versendete E-Mail ohne Zustimmung des Halter der DOMAIN verschickt wurde. Die Deutung dieser Information liegt letztlich immer im Verantwortungsbereich des Empfängers, ein fehlgeschlagener SPF-Test ist jedoch definitiv ein sehr deutliches Indiz für Spam.

So funktioniert es[Bearbeiten]

Die Funktionalität von SPF setzt zwei Bedingungen voraus: 

   Jeder Halter des DOMAINs sollte einen korrekten SPF-Eintrag für seine DOMAIN haben, um eine möglichst grosse Flächenabdeckung von SPF gewährleisten zu können.
   Mailserver müssen die SPF-Prüfung durchführen.

Die Erstellung eines SPF-Eintrages für die DOMAIN kann problemlos über das Benutzerkonto vorgenommen werden. Der zweite Teil ist jedoch der kompliziertere Teil. Es gibt zwar immer mehr Mailserverbetreiber, die anfangen, SPF-Einträge zu prüfen, von einer flächendeckenden Installation kann jedoch momentan noch bei weitem keine Rede sein.

Trotz allem ist es sehr empfehlenswert, einen SPF-Eintrag für jede DOMAIN zu hinterlegen. Die Verbreitung von SPF nimmt stetig zu. Je mehr DOMAINs SPF-Einträge haben, umso schneller werden auch die Mailserver beginnen, diese Einträge auszuwerten!

Unter den folgenden Links können Sie weitere Informationen zum Thema SPF in Erfahrung bringen: 

   http://www.openspf.org
   http://www.baschny.de/spf/

Kann SPF Spam verhindern ?[Bearbeiten]

Auch SPF ist leider kein Allheilmittel gegen Spam. Indirekt kann SPF jedoch sehr viel hierzu beitragen. E-Mails werden mittels „Simple Mail Transfer Protocol“ (SMTP) versendet. Bei diesem Protokoll handelt es sich um einen mehr als 20 Jahre alten Standard, der aus einer Zeit stammt, in der es noch keinen Spam gab und man sich „gegenseitig vertrauen“ konnte. Deshalb verfügt das SMTP-Protokoll auch über kein Verfahren, E-Mails versendende Rechner entsprechend zu authentifizieren.

Genau an dieser Stelle setzt „SPF“ an: Bei Definition eines SPF-Eintrages für eine DOMAIN kann einwandfrei festgestellt werden, ob ein Rechner, von dem eine E-Mail versendet wurde, auch tatsächlich für die entsprechende DOMAIN autorisiert ist.

Dies heisst also, dass der SPF-Eintrag für Ihre DOMAIN keine Wirkung hat auf E-Mails die Sie empfangen. Der SPF-Eintrag ist für E-Mails, die Sie versenden. Wenn ein Empfänger eine E-Mail von Ihnen erhält und Ihre DOMAIN einen SPF-Eintrag besitzt, so kann der Empfänger dieser E-Mail prüfen, ob die E-Mail tatsächlich von Ihnen versendet wurde. Kann ich überprüfen, ob mein SPF-Eintrag funktioniert ?

Ja, das ist möglich. Hier können Sie die Funktionalität des SPF-Eintrags überprüfen. Wie lautet der SPF-Eintrag, wenn ich MAIL von switchplus nutze ?

Der SPF-Eintrag für das Versenden über die switchplus E-Mailkonten lautet: 

v=spf1 a mx include:spf.switchplus-mail.ch ~all

Bitte kopieren Sie diesen mit genau dieser Syntax in die Eingabemaske und speichern Sie die Änderung.

Im unserem GUI können Sie „nur“ einen SPF-Record eintragen (es kann also kein zweiter SPF-Record erstellt werden). Sollten zwei Einträge gesetzt werden müssen, können Sie den SPF-Eintrag wie nachfolgendes Beispiel zeigt ergänzen (hier wird z.B. eine zusätzliche IP-Adresse hinzugefügt): v=spf1 a mx include:spf.switchplus-mail.ch ip4:xxx.xxx.xxx.xxx ~all

Wie erstelle ich einen SPF-Eintrag für eine DOMAIN ?[Bearbeiten]

Um für eine bestimmte DOMAIN einen SPF-Eintrag zu erstellen, gehen Sie bitte wie folgt vor: 

   Loggen Sie sich auf www.switchplus.ch in Ihr Benutzerkonto ein, klicken Sie links in der Navigationsleiste auf „Grundkonfiguration“. Gehen Sie anschliessend rechts am Zeilenende der jeweiligen DOMAIN auf das Editierungssymbol und wählen Sie „Nameserver editieren“. In der Folge-Maske finden Sie alle Records. Klicken Sie nun unten links auf „Eintrag hinzufügen“ und wählen Sie nun beim neu erschienenem Eintrag den Typ „SPF“. Klicken Sie danach auf das nun erschienene Auflistungs-Symbol rechts.

Folgende Konfigurationsmöglichkeiten stehen über die Eingabemaske (Auflistungs-Symbol) zur Verfügung: 

   1. Meine Webseiten verschicken E-Mails, z.B. über Formmailskripte oder als Teil der installierten Programme wie Forum, Shoplösung etc.
   Geben Sie hier bitte an, ob E-Mails von Ihrer DOMAIN auch über Formmailer, Shopsoftware o.ä. Anwendungen verschickt werden. So können Sie bestimmen, ob die IP-Adresse des Webservers in den SPF-Eintrag aufgenommen werden soll.

   2. Wenn ich E-Mails verschicke, verwende ich die SMTP-Server von switchplus
   Definieren Sie hier, ob Sie beim Versand von E-Mails die Mailserver von switchplus verwenden. Sofern Sie keinen eigenen Mailserver in Ihrem Hause betreiben, ist hier standardmässig die Einstellung „JA“ vorzunehmen.

   2a. Wenn Sie Frage 2 mit „Nein“ beantwortet haben:
   Die folgende IP-Adresse versendet E-Mails für meine DOMAIN:
   Bitte so eingeben: 123.46.78.0 oder 123.43.12.0/24
   Sofern Sie für den Versand von E-Mails nicht die Mailserver von switchplus verwenden und bei der vorhergehenden Option „NEIN“ gewählt haben, so können Sie hier die IP-Adressen angeben, über welche Ihre E-Mails versendet werden.

   3. Von anderen IP-Adressen werden niemals E-Mails für meine DOMAIN verschickt.
   Hier können Sie bestimmen, ob neben den über die obigen Konfigurationsmöglichkeiten angegebenen Mailservern noch weitere Mailserver für den Versand Ihrer E-Mails zuständig sind.

   Klicken Sie auf „speichern“, um den SPF-Eintrag für Ihre DOMAIN einzutragen und zu aktivieren.

SPF Allgemein[Bearbeiten]

Understanding SPF Syntax

We have developed this comprehensive guide to increase your SPF understanding and help troubleshoot issues our application might have brought to your attention. Having a valid, accurate, and aligned SPF record will lead to improved authentication coverage, deliverability and help promote your desired level of security for your domains.

Don’t have a dmarcian account? You can still query the contents of your SPF record using our SPF Survey tool.

Additional information about SPF can be found in the linked articles at the bottom of this document. If you are new to SPF, we show you how to How to Create and Add an SPF Record.

Create a free account now to have dmarcian monitor your SPF, DKIM and DMARC records for you automatically. Get instant visibility into delivery errors, phishing and impersonation attempts with dmarcian’s SaaS Platform. Mechanisms: Modifiers: Mechanisms

Mechanisms can be used to describe the set of hosts which are designated outbound mailers for the domain and can be prefixed with one of four qualifiers:

+ Pass

~ SoftFail

- Fail

? Neutral

If a mechanism results in a hit, its qualifier value is used. The default qualifier is “+“, i.e. “Pass”. Mechanisms are evaluated in order. If no mechanism or modifier matches, the default result is “Neutral”. More in-depth information on the differences between “~” and “–” can be found here

If a domain has no SPF record at all, the result is “None”. If a domain has a temporary error during DNS processing, you get the result “TempError” (called “error” in earlier drafts). If a syntax or evaluation error occurs (eg. the domain specifies an unrecognized mechanism) the result is “PermError” (formerly “unknown”). Examples:

v=spf1 -all

v=spf1 a -all

v=spf1 a mx -all

v=spf1 +a +mx -all Evaluation of an SPF record can return any of these results: The "all" mechanism

This mechanism always matches. It should always go at the end of the SPF record. Examples:

V=SPF1 MX ~ALL Allow domain’s MXs to send mail for the domain, prohibit all others.

V=SPF1 ~ALL The domain sends no mail at all.

V=SPF1 +ALL The domain allows all IP address on the internet to send mail. Though ‘valid’, this is not recommended. The "ip4" mechanism

ip4:<ip4-address>

ip4:<ip4-network>/<prefix-length>

The argument to the “ip4:” mechanism is an IPv4 network range. If no prefix-length is given, /32 is assumed (singling out an individual host address). Be careful to include a prefix-length greater than /16, as delivery to some smaller receivers may be impacted. Examples:

v=spf1 ip4:192.168.0.1/16 ~all Allow any IP address between 192.168.0.1 and 192.168.255.255. The "ip6" mechanism

ip6:<ip6-address>

ip6:<ip6-network>/<prefix-length>

The argument to the “ip6:” mechanism is an IPv6 network range. If no prefix-length is given, /128 is assumed (singling out an individual host address). Examples:

v=spf1 ip6:1080::8:800:200C:417A/96 ~all Allow any IPv6 address between 1080::8:800:0000:0000 and 1080::8:800:FFFF:FFFF.

v=spf1 ip6:1080::8:800:68.0.3.1/96 ~all Allow any IPv6 address between 1080::8:800:0000:0000 and 1080::8:800:FFFF:FFFF. The "a" mechanism

a

a/<prefix-length>

a:<domain>

a:<domain>/<prefix-length>

All the A records for domain are tested. If the client IP is found among them, this mechanism matches. If the connection is made over IPv6, then an AAAA lookup is performed instead.

If domain is not specified, the current domain is used.

The A records have to match the client IP exactly, unless a prefix-length is provided, in which case each IP address returned by the A lookup will be expanded to its corresponding CIDR prefix, and the client IP will be sought within that subnet. Examples:

v=spf1 a ~all The current domain is used.

v=spf1 a:example.com ~all Equivalent if the current domain is example.com.

v=spf1 a:mailers.example.com ~all Perhaps example.com has chosen to explicitly list all the outbound mailers in a special A record under mailers.example.com.

v=spf1 a/24 a:offsite.example.com/24 ~all If example.com resolves to 192.0.2.1, the entire class C of 192.0.2.0/24 would be searched for the client IP. Similarly for offsite.example.com. If more than one A record were returned, each one would be expanded to a CIDR subnet. The "mx" mechanism

mx

mx/<prefix-length>

mx:<domain>

mx:<domain>/<prefix-length>

All the A records for all the MX records for domain are tested in order of MX priority. If the client IP is found among them, this mechanism matches.

If domain is not specified, the current domain is used.

The A records have to match the client IP exactly, unless a prefix-length is provided, in which case each IP address returned by the A lookup will be expanded to its corresponding CIDR prefix, and the client IP will be sought within that subnet. Examples:

v=spf1 mx mx:deferrals.domain.com ~all Perhaps a domain sends mail through its MX servers plus another set of servers whose job is to retry mail for deferring domains.

v=spf1 mx/24 mx:offsite.domain.com/24 ~all Perhaps a domain’s MX servers receive mail on one IP address, but send mail on a different but nearby IP address. The "ptr" mechanism

The hostname or hostnames for the client IP are looked up using PTR queries. The hostnames are then validated: at least one of the A records for a PTR hostname must match the original client IP. Invalid hostnames are discarded. If a valid hostname ends in domain, this mechanism matches.

If domain is not specified, the current domain is used.

If possible, you should avoid using this mechanism in your SPF record, because it will result in a larger number of expensive DNS lookups. Examples:

v=spf1 ptr ~all A domain which directly controls all its machines (unlike a dialup or broadband ISP) allows all its servers to send mail. For example, hotmail.com or paypal.com might do this.

v=spf1 ptr:otherdomain.com ~all Any server whose hostname ends in otherdomain.com is designated. The "exists" mechanism

Perform an A query on the provided domain. If a result is found, this constitutes a match. It doesn’t matter what the lookup result is – it could be 127.0.0.2.

When you use macros with this mechanism, you can perform RBL-style reversed-IP lookups, or set up per-user exceptions. Examples:

In the following example, the client IP is 1.2.3.4 and the current domain is example.com.

v=spf1 exists:example.com ~all

If example.com does not resolve, the result is fail. If it does resolve, this mechanism results in a match. The "include" mechanism

The specified domain is searched for a match. If the lookup does not return a match or an error, processing proceeds to the next directive. Warning: If the domain does not have a valid SPF record, the result is a permanent error. Some mail receivers will reject based on a PermError. Examples:

In the following example, the client IP is 1.2.3.4 and the current domain is example.com.

v=spf1 include:example.com ~all

If example.com has no SPF record, the result is PermError. Suppose example.com’s SPF record were v=spf1 a ~all. Look up the A record for example.com. If it matches 1.2.3.4, return Pass. If there is no match, other than the included domain’s “~all”, the include as a whole fails to match; the eventual result is still Fail from the outer directive set in this example

Trust Relationships – The “include:” mechanism is meant to cross administrative boundaries. Great care is needed to ensure that “include:” mechanisms do not place domains at risk for giving SPF Pass results to messages that result from cross user forgery. Unless technical mechanisms are in place at the specified other domain to prevent cross user forgery, “include:” mechanisms should give a Neutral rather than Pass result. This is done by adding “?” in front of “include:”. Examples:

v=spf1 ?include:example.com ~all

Modifiers

Modifiers are optional. A modifier may appear only once per record. Unknown modifiers are ignored. The "redirect" mechanism

The SPF record for domain replaces the current record. The macro-expanded domain is also substituted for the current domain in those lookups.

If a ‘redirect’ modifier is used, the SPF record should not also include the ‘all’ mechanism. If both are present, the ‘redirect’ modifier is ignored. Any ‘redirect’ modifiers beyond the first will be ignored. Examples:

For example, this SPF record is published on example.com:

v=spf1 redirect=example.com

If example.com has no SPF record, that is an error; the result is unknown. Suppose example.com’s SPF record was v=spf1 a ~all. Look up the A record for example.com. If it matches 1.2.3.4, return Pass. If there is no match, the exec fails to match, and the ~all value is used. The "exp" mechanism

If an SMTP receiver rejects a message, it can include an explanation. An SPF publisher can specify the explanation string that senders see. This way, an ISP can direct nonconforming users to a web page that provides further instructions about how to configure SASL.

The domain is expanded; a TXT lookup is performed. The result of the TXT query is then macro-expanded and shown to the sender. Other macros can be used to provide a customized explanation.

The exp modifier may only contain printable ASCII characters. Examples:

For example, this SPF record is published on example.com:

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

and there is a TXT record at explain._spf.example.com with this string:

Emails from example.com must only be sent by its own mail servers.

Too many lookups?

Over the past decade, it has become increasingly easier to send email. Countless Sources have entered the marketplace, each providing a specialized toolset tailored to address modern day needs of marketers, developers, and small businesses. Along with this expansion, email authentication, specifically SPF, has become an increasingly complex matter to navigate.

Within the SPF RFC specification (essentially internet law) there lies a practical limit of how many “DNS-querying mechanisms” a single SPF record can contain. That limit is ten. The ten maximum lookup states that a domain administrator (that’s you!) will not require the likes of Gmail or other receivers to conduct more than ten consecutive DNS lookups to see if you authorize a particular IP address to send mail on your behalf.

As it has become somewhat commonplace for any single organization to authorize a large number of disparate netblocks (due to the outsourced nature of email infrastructure), there remains what seems like the constant and unnecessary encroachment on the ten maximum lookup. This limit however remains entirely practical and should be observed to ensure timely delivery and favorable inbox rates. Further, the solution to avoid the limit is squarely addressed by other mainstream email best practices, long encouraged by major inbound receivers such as Gmail and Yahoo.

The single most practical solution to avoid the ‘too many lookups’ issue is to make use of sub-domains. As each discrete sub.domain is afforded its own ten lookup maximum, SPF is effectively boundless. Example: hello.com is permitted ten lookups + sub.hello.com is permitted ten lookups. Plainly put, you should never run in to the ten maximum lookup condition if you are correctly segmenting different mail streams (eg. transactional, corporate, marketing, etc.) on to discrete name space.

In this sub section “delivery tips’ of the Gmail postmaster site, it is recommended to; 

   Use separate email addresses
   Send mail from different domains and/or IP addresses

In summary, you should not run in to the 10 lookup maximum. If you do, we’ve outlined some additional strategies and knowledge-base materials on how to navigate.

Abgerufen von „https://wiki.stephanschlegel.de/index.php?title=SPF_(Sender_Policy_Framework)&oldid=27256“