SPF-authenticatie: een overzicht en best practices
Bird
19 dec 2016
1 min read
Belangrijkste punten
SPF (Sender Policy Framework) is een pad-gebaseerd e-mailauthenticatieprotocol dat verifieert of de verzendende server gemachtigd is om e-mail te verzenden voor een domein.
SPF-beleid bestaat als DNS TXT-records, geformatteerd met mechanismen die bepalen welke servers, IP's of netwerken gemachtigd zijn om namens een domein te verzenden.
SPF-validatie is gekoppeld aan het Return-Path-domein (bounce-domein) of de HELO hostnaam—niet het zichtbare Van-adres.
Omdat SPF alleen het verzendpad controleert, kan het vroeg in de SMTP-transactie worden gevalideerd, wat het nuttig maakt voor het snel afwijzen van ongeautoriseerde e-mail.
SPF is effectief maar niet perfect—het is gevoelig voor false negatives, vooral bij e-mail doorsturen en mailinglijsten.
SPF-records zijn afhankelijk van mechanismen zoals
mx,a,ipv4,ipv6,include,redirect,exists, en moeten eindigen met eenallmodifier (-all,~all,?all,+all).DNS-opzoeklimieten zijn van toepassing: SPF-evaluatie kan niet meer dan 10 DNS-queries overschrijden, waardoor het plannen van records belangrijk is.
Het
ptrmechanisme wordt nu beschouwd als “niet gebruiken”, maar validators moeten het nog steeds accepteren. Sommige afzenders gebruiken het nog steeds vanwege compatibiliteitsproblemen.SPF alleen garandeert niet dat een e-mail legitiem is—alleen dat het was verzonden vanaf een geautoriseerde server. Het werkt het beste in combinatie met DKIM, DMARC, en andere anti-fraudetechnieken.
Q&A Hoogtepunten
Wat is SPF in eenvoudige termen?
SPF laat een domein aangeven welke servers gemachtigd zijn om e-mail namens het domein te verzenden. Ontvangende servers controleren dit om ongeautoriseerde afzenders te detecteren.
Waarom wordt SPF "path-based" genoemd?
Omdat SPF het pad valideert dat het bericht heeft gevolgd—specifiek het IP-adres van de verzendende server—en niet iets in de inhoud van het bericht.
Waar wordt een SPF-beleid opgeslagen?
Q: Als een DNS TXT-record, beginnend met
v=spf1, gevolgd door mechanismen die toegestane afzenders definiëren.Welke domein valideert SPF?
De Return-Path (ook wel het bounce-domein genoemd).
Als de Return-Path leeg is (NULL afzender), controleert SPF het HELO-domein in plaats daarvan.
Kan SPF vroeg in de SMTP-transactie worden gecontroleerd?
Ja. Omdat het slechts afhankelijk is van het IP en domein van de verzendende server, kan SPF worden gevalideerd voordat de berichtinhoud wordt ontvangen—wat het efficiënt maakt voor filtering.
Waarom faalt SPF soms zelfs voor legitieme e-mail?
Veelvoorkomende oorzaken zijn onder andere:
Email doorsturen (de doorstuurder staat niet in het oorspronkelijke domein's SPF-record)
Maillijsten (berichten worden opnieuw verzonden door een andere server)
Dit leidt tot valse negatieven, die inherent zijn aan padgebaseerde authenticatie.
Wat is de rol van mechanismen zoals include, redirect en exists?
include— machtig het SPF-record van een ander domein (bijv., uw ESP) goedredirect— hergebruik het SPF-beleid van een ander domeinexists— dynamisch autoriseren op basis van een DNS-lookup (nuttig voor complexe infrastructuur)
Hoe werken "all" modifiers?
-all→ alles wat niet is vermeld afwijzen (streng)~all→ softfail (accepteer maar markeer)?all→ neutraal+all→ alles doorlaten (effectief schakelt SPF uit)
Waarom wordt het ptr-mechanisme ontmoedigd?
Het is traag, onbetrouwbaar en verouderd in de moderne specificatie—maar SPF-valideerders moeten het nog steeds ondersteunen.
Is SPF op zichzelf genoeg voor e-mailauthenticatie?
Nee. SPF verifieert de verzendende infrastructuur, maar:
Het beschermt de berichtintegriteit niet
Het komt niet overeen met zichtbare From-domeinen
Het werkt niet bij doorsturen
SPF is het sterkst in combinatie met DKIM en DMARC.
Voordat we ons in de technische implementatie verdiepen, is het de moeite waard om de evolutie en verscheidenheid van beschikbare e-mailvalidatietechnieken te begrijpen. Van eenvoudige syntaxiscontrole tot moderne data-gedreven benaderingen, verschillende validatiemethoden bieden uiteenlopende niveaus van nauwkeurigheid en betrouwbaarheid.
Wanneer we spreken van “Email Authentication”, bedoelen we een techniek die bedoeld is om de ontvanger van een bericht een zekere mate van zekerheid te bieden dat het bericht daadwerkelijk afkomstig is van de beweerde bron van het bericht. Het idee is om enige bescherming te bieden tegen frauduleuze e-mail, zoals phishing en spoofing, die het vertrouwen van een ontvanger in het ontvangen van e-mail kunnen ondermijnen. Voor organisaties die behoefte hebben aan berichtversleuteling op berichtniveau, biedt S/MIME end-to-end beveiliging, met geautomatiseerde verzameling van publieke sleutels van ontvangers, waardoor implementatie schaalbaarder wordt. Dat gezegd hebbende, betekent het verzenden van geauthenticeerde e-mail op zichzelf niet dat de e-mail goed of gewenst is; het betekent alleen dat de mail zodanig is dat een reputatie voor de geauthenticeerde partij betrouwbaar kan worden vastgesteld en gebruikt bij beslissingen over e-mailacceptatie en -plaatsing.
Er zijn tegenwoordig twee primaire vormen van e-mailauthenticatie in gebruik—Sender Policy Framework (SPF) en DomainKeys Identified Mail (DKIM). In dit blogbericht zal ik uitleggen wat SPF is, en hoe het werkt.
Voordat we ons in de technische implementatie verdiepen, is het de moeite waard om de evolutie en verscheidenheid van beschikbare e-mailvalidatietechnieken te begrijpen. Van eenvoudige syntaxiscontrole tot moderne data-gedreven benaderingen, verschillende validatiemethoden bieden uiteenlopende niveaus van nauwkeurigheid en betrouwbaarheid.
Wanneer we spreken van “Email Authentication”, bedoelen we een techniek die bedoeld is om de ontvanger van een bericht een zekere mate van zekerheid te bieden dat het bericht daadwerkelijk afkomstig is van de beweerde bron van het bericht. Het idee is om enige bescherming te bieden tegen frauduleuze e-mail, zoals phishing en spoofing, die het vertrouwen van een ontvanger in het ontvangen van e-mail kunnen ondermijnen. Voor organisaties die behoefte hebben aan berichtversleuteling op berichtniveau, biedt S/MIME end-to-end beveiliging, met geautomatiseerde verzameling van publieke sleutels van ontvangers, waardoor implementatie schaalbaarder wordt. Dat gezegd hebbende, betekent het verzenden van geauthenticeerde e-mail op zichzelf niet dat de e-mail goed of gewenst is; het betekent alleen dat de mail zodanig is dat een reputatie voor de geauthenticeerde partij betrouwbaar kan worden vastgesteld en gebruikt bij beslissingen over e-mailacceptatie en -plaatsing.
Er zijn tegenwoordig twee primaire vormen van e-mailauthenticatie in gebruik—Sender Policy Framework (SPF) en DomainKeys Identified Mail (DKIM). In dit blogbericht zal ik uitleggen wat SPF is, en hoe het werkt.
Voordat we ons in de technische implementatie verdiepen, is het de moeite waard om de evolutie en verscheidenheid van beschikbare e-mailvalidatietechnieken te begrijpen. Van eenvoudige syntaxiscontrole tot moderne data-gedreven benaderingen, verschillende validatiemethoden bieden uiteenlopende niveaus van nauwkeurigheid en betrouwbaarheid.
Wanneer we spreken van “Email Authentication”, bedoelen we een techniek die bedoeld is om de ontvanger van een bericht een zekere mate van zekerheid te bieden dat het bericht daadwerkelijk afkomstig is van de beweerde bron van het bericht. Het idee is om enige bescherming te bieden tegen frauduleuze e-mail, zoals phishing en spoofing, die het vertrouwen van een ontvanger in het ontvangen van e-mail kunnen ondermijnen. Voor organisaties die behoefte hebben aan berichtversleuteling op berichtniveau, biedt S/MIME end-to-end beveiliging, met geautomatiseerde verzameling van publieke sleutels van ontvangers, waardoor implementatie schaalbaarder wordt. Dat gezegd hebbende, betekent het verzenden van geauthenticeerde e-mail op zichzelf niet dat de e-mail goed of gewenst is; het betekent alleen dat de mail zodanig is dat een reputatie voor de geauthenticeerde partij betrouwbaar kan worden vastgesteld en gebruikt bij beslissingen over e-mailacceptatie en -plaatsing.
Er zijn tegenwoordig twee primaire vormen van e-mailauthenticatie in gebruik—Sender Policy Framework (SPF) en DomainKeys Identified Mail (DKIM). In dit blogbericht zal ik uitleggen wat SPF is, en hoe het werkt.
SPF Overzicht
Sender Policy Framework (SPF), om RFC 7208 te parafraseren, is een protocol dat niet alleen een organisatie toestaat om hosts en netwerken te autoriseren om zijn domeinnamen te gebruiken bij het verzenden van e-mail, maar biedt ook een manier aan waarop een ontvangende host die autorisatie kan controleren.
Wanneer je klaar bent met het lezen van deze post, hoop ik dat je het volgende geleerd hebt:
SPF is een “pad-gebaseerd” authenticatiesysteem.
SPF-beleid wordt gedeclareerd in DNS TXT-records.
Validatie is gekoppeld aan het Return-Path domein (wat wij hier bij SparkPost de “bounce domein” noemen) of het HELO-domein.
Validatie kan vroeg in de SMTP-transactie worden uitgevoerd, dus het is een goede controle om te gebruiken om snel niet-geauthenticeerde mail te weigeren.
Het is vatbaar voor een relatief hoog percentage valse negatieven.
Sender Policy Framework (SPF), om RFC 7208 te parafraseren, is een protocol dat niet alleen een organisatie toestaat om hosts en netwerken te autoriseren om zijn domeinnamen te gebruiken bij het verzenden van e-mail, maar biedt ook een manier aan waarop een ontvangende host die autorisatie kan controleren.
Wanneer je klaar bent met het lezen van deze post, hoop ik dat je het volgende geleerd hebt:
SPF is een “pad-gebaseerd” authenticatiesysteem.
SPF-beleid wordt gedeclareerd in DNS TXT-records.
Validatie is gekoppeld aan het Return-Path domein (wat wij hier bij SparkPost de “bounce domein” noemen) of het HELO-domein.
Validatie kan vroeg in de SMTP-transactie worden uitgevoerd, dus het is een goede controle om te gebruiken om snel niet-geauthenticeerde mail te weigeren.
Het is vatbaar voor een relatief hoog percentage valse negatieven.
Sender Policy Framework (SPF), om RFC 7208 te parafraseren, is een protocol dat niet alleen een organisatie toestaat om hosts en netwerken te autoriseren om zijn domeinnamen te gebruiken bij het verzenden van e-mail, maar biedt ook een manier aan waarop een ontvangende host die autorisatie kan controleren.
Wanneer je klaar bent met het lezen van deze post, hoop ik dat je het volgende geleerd hebt:
SPF is een “pad-gebaseerd” authenticatiesysteem.
SPF-beleid wordt gedeclareerd in DNS TXT-records.
Validatie is gekoppeld aan het Return-Path domein (wat wij hier bij SparkPost de “bounce domein” noemen) of het HELO-domein.
Validatie kan vroeg in de SMTP-transactie worden uitgevoerd, dus het is een goede controle om te gebruiken om snel niet-geauthenticeerde mail te weigeren.
Het is vatbaar voor een relatief hoog percentage valse negatieven.
“Path-Based” Authenticatie
SPF wordt beschouwd als een pad-gebaseerd authenticatiesysteem omdat het uitsluitend is gekoppeld aan het pad dat het bericht volgde van zijn oorsprong naar zijn bestemming. Wanneer een verzendende server een SMTP-transactie initieert met een ontvangende server, zal de ontvangende server bepalen of de verzendende server gemachtigd is om dat bericht te verzenden op basis van het SPF-beleid van het domein. Het is uitsluitend een beslissing op basis van waar het bericht vandaan komt, zonder enige betrekking op de inhoud van het bericht.
SPF wordt beschouwd als een pad-gebaseerd authenticatiesysteem omdat het uitsluitend is gekoppeld aan het pad dat het bericht volgde van zijn oorsprong naar zijn bestemming. Wanneer een verzendende server een SMTP-transactie initieert met een ontvangende server, zal de ontvangende server bepalen of de verzendende server gemachtigd is om dat bericht te verzenden op basis van het SPF-beleid van het domein. Het is uitsluitend een beslissing op basis van waar het bericht vandaan komt, zonder enige betrekking op de inhoud van het bericht.
SPF wordt beschouwd als een pad-gebaseerd authenticatiesysteem omdat het uitsluitend is gekoppeld aan het pad dat het bericht volgde van zijn oorsprong naar zijn bestemming. Wanneer een verzendende server een SMTP-transactie initieert met een ontvangende server, zal de ontvangende server bepalen of de verzendende server gemachtigd is om dat bericht te verzenden op basis van het SPF-beleid van het domein. Het is uitsluitend een beslissing op basis van waar het bericht vandaan komt, zonder enige betrekking op de inhoud van het bericht.
Een SPF-beleid verklaren
Het SPF-beleid van een domein is gewoon een specifiek geformatteerd DNS TXT-record, dat gewoonlijk een of meer van de volgende “mechanismen” bevat:
v=spf1 – Vereist eerste token om aan te geven dat het TXT-record een SPF-record is (een domein kan meerdere TXT-records hebben)
ipv4, ipv6 – Gebruikt om IP-adressen en netwerken op te geven die bevoegd zijn om mail voor het domein te verzenden
a – Als het verzendende domein een DNS “A”-record heeft dat wordt opgelost naar het verzendende IP, is het IP toegestaan
mx – Als het verzendende IP ook een van de MX-records is voor het verzendende domein, is het IP toegestaan
all – Vereist laatste token, altijd gewijzigd:
-all – Alleen wat hier is vermeld kan slagen; mislukkingen afwijzen.
~all – Dingen die hier niet zijn moeten softfailen; accepteer het maar merk het op.
?all – Niet zeker of dingen die hier niet zijn zouden moeten slagen.
+all – We denken dat SPF nutteloos is; laat alles door.
Andere minder gebruikelijke mechanismen die nog steeds veel worden gebruikt zijn:
include – Wordt gebruikt wanneer een domein niet alleen zijn eigen servers heeft, maar ook de servers van iemand anders gebruikt. Moet zorgvuldig worden gebruikt. Elke include is een andere DNS-query en SPF-records kunnen niet meer dan tien DNS-queries vereisen om op te lossen.
redirect – Wanneer domein A en domein B eigendom zijn van dezelfde entiteit en dezelfde infrastructuur gebruiken. De eigenaren willen meestal slechts één kopie van het SPF-record voor beide beheren en B configureren om queries door te sturen naar A.
exists – Als een domein veel kleine, niet-aaneengesloten netwerkblokken heeft, kan het deze mechanisme gebruiken om zijn SPF-record op te geven, in plaats van ze allemaal op te sommen. Handig om binnen de groottebeperking (512 bytes) voor DNS-respons te blijven.
Een opmerking over het “ptr” Mechanisme
Een laatste mechanisme, “ptr” bestond in de oorspronkelijke specificatie voor SPF, maar is verklaard als “niet gebruiken” in de huidige specificatie. Het ptr-mechanisme werd gebruikt om aan te geven dat als het verzendende IP-adres een DNS PTR-record had dat oploste naar de domeinnaam in kwestie, dat IP-adres gemachtigd was om mail voor het domein te verzenden.
De huidige status van dit mechanisme is dat het niet gebruikt mag worden. Echter, sites die SPF-validatie uitvoeren moeten het accepteren als geldig.
Het SPF-beleid van een domein is gewoon een specifiek geformatteerd DNS TXT-record, dat gewoonlijk een of meer van de volgende “mechanismen” bevat:
v=spf1 – Vereist eerste token om aan te geven dat het TXT-record een SPF-record is (een domein kan meerdere TXT-records hebben)
ipv4, ipv6 – Gebruikt om IP-adressen en netwerken op te geven die bevoegd zijn om mail voor het domein te verzenden
a – Als het verzendende domein een DNS “A”-record heeft dat wordt opgelost naar het verzendende IP, is het IP toegestaan
mx – Als het verzendende IP ook een van de MX-records is voor het verzendende domein, is het IP toegestaan
all – Vereist laatste token, altijd gewijzigd:
-all – Alleen wat hier is vermeld kan slagen; mislukkingen afwijzen.
~all – Dingen die hier niet zijn moeten softfailen; accepteer het maar merk het op.
?all – Niet zeker of dingen die hier niet zijn zouden moeten slagen.
+all – We denken dat SPF nutteloos is; laat alles door.
Andere minder gebruikelijke mechanismen die nog steeds veel worden gebruikt zijn:
include – Wordt gebruikt wanneer een domein niet alleen zijn eigen servers heeft, maar ook de servers van iemand anders gebruikt. Moet zorgvuldig worden gebruikt. Elke include is een andere DNS-query en SPF-records kunnen niet meer dan tien DNS-queries vereisen om op te lossen.
redirect – Wanneer domein A en domein B eigendom zijn van dezelfde entiteit en dezelfde infrastructuur gebruiken. De eigenaren willen meestal slechts één kopie van het SPF-record voor beide beheren en B configureren om queries door te sturen naar A.
exists – Als een domein veel kleine, niet-aaneengesloten netwerkblokken heeft, kan het deze mechanisme gebruiken om zijn SPF-record op te geven, in plaats van ze allemaal op te sommen. Handig om binnen de groottebeperking (512 bytes) voor DNS-respons te blijven.
Een opmerking over het “ptr” Mechanisme
Een laatste mechanisme, “ptr” bestond in de oorspronkelijke specificatie voor SPF, maar is verklaard als “niet gebruiken” in de huidige specificatie. Het ptr-mechanisme werd gebruikt om aan te geven dat als het verzendende IP-adres een DNS PTR-record had dat oploste naar de domeinnaam in kwestie, dat IP-adres gemachtigd was om mail voor het domein te verzenden.
De huidige status van dit mechanisme is dat het niet gebruikt mag worden. Echter, sites die SPF-validatie uitvoeren moeten het accepteren als geldig.
Het SPF-beleid van een domein is gewoon een specifiek geformatteerd DNS TXT-record, dat gewoonlijk een of meer van de volgende “mechanismen” bevat:
v=spf1 – Vereist eerste token om aan te geven dat het TXT-record een SPF-record is (een domein kan meerdere TXT-records hebben)
ipv4, ipv6 – Gebruikt om IP-adressen en netwerken op te geven die bevoegd zijn om mail voor het domein te verzenden
a – Als het verzendende domein een DNS “A”-record heeft dat wordt opgelost naar het verzendende IP, is het IP toegestaan
mx – Als het verzendende IP ook een van de MX-records is voor het verzendende domein, is het IP toegestaan
all – Vereist laatste token, altijd gewijzigd:
-all – Alleen wat hier is vermeld kan slagen; mislukkingen afwijzen.
~all – Dingen die hier niet zijn moeten softfailen; accepteer het maar merk het op.
?all – Niet zeker of dingen die hier niet zijn zouden moeten slagen.
+all – We denken dat SPF nutteloos is; laat alles door.
Andere minder gebruikelijke mechanismen die nog steeds veel worden gebruikt zijn:
include – Wordt gebruikt wanneer een domein niet alleen zijn eigen servers heeft, maar ook de servers van iemand anders gebruikt. Moet zorgvuldig worden gebruikt. Elke include is een andere DNS-query en SPF-records kunnen niet meer dan tien DNS-queries vereisen om op te lossen.
redirect – Wanneer domein A en domein B eigendom zijn van dezelfde entiteit en dezelfde infrastructuur gebruiken. De eigenaren willen meestal slechts één kopie van het SPF-record voor beide beheren en B configureren om queries door te sturen naar A.
exists – Als een domein veel kleine, niet-aaneengesloten netwerkblokken heeft, kan het deze mechanisme gebruiken om zijn SPF-record op te geven, in plaats van ze allemaal op te sommen. Handig om binnen de groottebeperking (512 bytes) voor DNS-respons te blijven.
Een opmerking over het “ptr” Mechanisme
Een laatste mechanisme, “ptr” bestond in de oorspronkelijke specificatie voor SPF, maar is verklaard als “niet gebruiken” in de huidige specificatie. Het ptr-mechanisme werd gebruikt om aan te geven dat als het verzendende IP-adres een DNS PTR-record had dat oploste naar de domeinnaam in kwestie, dat IP-adres gemachtigd was om mail voor het domein te verzenden.
De huidige status van dit mechanisme is dat het niet gebruikt mag worden. Echter, sites die SPF-validatie uitvoeren moeten het accepteren als geldig.
Enkele Voorbeeld SPF Records
Hier zijn enkele voorbeeldrecords en hun betekenissen. Dit voorbeeld toont RFC 1918-adressen, maar ik erken dat dergelijke adressen nooit in echte SPF-records zullen voorkomen.
MX-record, één IP-adres, één IP-netwerk, softfail alles behalve:
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
A-record, twee IP-netwerken, weiger alles behalve:
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
We sturen geen mail:
“v=spf1 -all”
We vinden SPF stom:
“v=spf1 +all”
Het SPF-record voor het domein sparkpostmail.com (redirect mechanisme gebruikt)
“v=spf1 redirect=_spf.sparkpostmail.com”
Het SPF-record voor _spf.sparkpostmail.com (exists- en ptr-mechanismen gebruikt):
“v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”
Bij SparkPost gebruiken we momenteel het ptr-mechanisme in ons SPF-record. We hebben het noodzakelijk geacht vanwege een gebrek aan universele ondersteuning voor het valideren van het exists-mechanisme. En tot nu toe hebben we geen SPF-fouten gezien als gevolg van het gebruik van het ptr-mechanisme.
Hier zijn enkele voorbeeldrecords en hun betekenissen. Dit voorbeeld toont RFC 1918-adressen, maar ik erken dat dergelijke adressen nooit in echte SPF-records zullen voorkomen.
MX-record, één IP-adres, één IP-netwerk, softfail alles behalve:
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
A-record, twee IP-netwerken, weiger alles behalve:
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
We sturen geen mail:
“v=spf1 -all”
We vinden SPF stom:
“v=spf1 +all”
Het SPF-record voor het domein sparkpostmail.com (redirect mechanisme gebruikt)
“v=spf1 redirect=_spf.sparkpostmail.com”
Het SPF-record voor _spf.sparkpostmail.com (exists- en ptr-mechanismen gebruikt):
“v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”
Bij SparkPost gebruiken we momenteel het ptr-mechanisme in ons SPF-record. We hebben het noodzakelijk geacht vanwege een gebrek aan universele ondersteuning voor het valideren van het exists-mechanisme. En tot nu toe hebben we geen SPF-fouten gezien als gevolg van het gebruik van het ptr-mechanisme.
Hier zijn enkele voorbeeldrecords en hun betekenissen. Dit voorbeeld toont RFC 1918-adressen, maar ik erken dat dergelijke adressen nooit in echte SPF-records zullen voorkomen.
MX-record, één IP-adres, één IP-netwerk, softfail alles behalve:
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
A-record, twee IP-netwerken, weiger alles behalve:
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
We sturen geen mail:
“v=spf1 -all”
We vinden SPF stom:
“v=spf1 +all”
Het SPF-record voor het domein sparkpostmail.com (redirect mechanisme gebruikt)
“v=spf1 redirect=_spf.sparkpostmail.com”
Het SPF-record voor _spf.sparkpostmail.com (exists- en ptr-mechanismen gebruikt):
“v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”
Bij SparkPost gebruiken we momenteel het ptr-mechanisme in ons SPF-record. We hebben het noodzakelijk geacht vanwege een gebrek aan universele ondersteuning voor het valideren van het exists-mechanisme. En tot nu toe hebben we geen SPF-fouten gezien als gevolg van het gebruik van het ptr-mechanisme.
Hoe werkt SPF-authenticatie?
Hier ziet u hoe een typische SMTP-transactie eruitziet wanneer SPF is betrokken:
De verzendende server (client) maakt verbinding met de ontvangende server
De ontvangende server noteert het verbindende IP-adres van de client
Zij wisselen begroetingen uit, inclusief de HELO-hostnaam van de client
Client geeft het SMTP MAIL FROM-commando
De ontvangende server kan nu het SPF-record opzoeken voor het MAIL FROM-domein of de HELO-hostnaam om te bepalen of het verbindende IP geautoriseerd is om e-mail voor het domein te verzenden, en beslissen of het bericht geaccepteerd moet worden.
Hier ziet u hoe een typische SMTP-transactie eruitziet wanneer SPF is betrokken:
De verzendende server (client) maakt verbinding met de ontvangende server
De ontvangende server noteert het verbindende IP-adres van de client
Zij wisselen begroetingen uit, inclusief de HELO-hostnaam van de client
Client geeft het SMTP MAIL FROM-commando
De ontvangende server kan nu het SPF-record opzoeken voor het MAIL FROM-domein of de HELO-hostnaam om te bepalen of het verbindende IP geautoriseerd is om e-mail voor het domein te verzenden, en beslissen of het bericht geaccepteerd moet worden.
Hier ziet u hoe een typische SMTP-transactie eruitziet wanneer SPF is betrokken:
De verzendende server (client) maakt verbinding met de ontvangende server
De ontvangende server noteert het verbindende IP-adres van de client
Zij wisselen begroetingen uit, inclusief de HELO-hostnaam van de client
Client geeft het SMTP MAIL FROM-commando
De ontvangende server kan nu het SPF-record opzoeken voor het MAIL FROM-domein of de HELO-hostnaam om te bepalen of het verbindende IP geautoriseerd is om e-mail voor het domein te verzenden, en beslissen of het bericht geaccepteerd moet worden.
MAIL FROM of HELO – Welke te controleren?
De SPF-specificatie bepaalt dat ontvangende sites SPF MOETEN controleren voor het MAIL FROM-domein, en AANBEVOLEN wordt om het te controleren voor de HELO-hostnaam. In de praktijk vindt de controle alleen plaats op het MAIL FROM-domein, behalve misschien voor die keren dat het MAIL FROM-adres de NULL-afzender is (d.w.z. "<>"), in welk geval de HELO-hostnaam de enige beschikbare identiteit is.
De SPF-specificatie bepaalt dat ontvangende sites SPF MOETEN controleren voor het MAIL FROM-domein, en AANBEVOLEN wordt om het te controleren voor de HELO-hostnaam. In de praktijk vindt de controle alleen plaats op het MAIL FROM-domein, behalve misschien voor die keren dat het MAIL FROM-adres de NULL-afzender is (d.w.z. "<>"), in welk geval de HELO-hostnaam de enige beschikbare identiteit is.
De SPF-specificatie bepaalt dat ontvangende sites SPF MOETEN controleren voor het MAIL FROM-domein, en AANBEVOLEN wordt om het te controleren voor de HELO-hostnaam. In de praktijk vindt de controle alleen plaats op het MAIL FROM-domein, behalve misschien voor die keren dat het MAIL FROM-adres de NULL-afzender is (d.w.z. "<>"), in welk geval de HELO-hostnaam de enige beschikbare identiteit is.
SPF Is Niet Waterdicht
Hoewel het een relatief eenvoudige manier lijkt om e-mail te verifiëren, is SPF kwetsbaar voor fouten in de vorm van valse negatieven. Deze fouten kunnen vaker voorkomen dan velen prettig vinden.
Hier zijn twee veelvoorkomende scenario's waarin volkomen legitieme e-mail kan falen bij SPF-validatie en dus frauduleus kan lijken:
Geautomatiseerd doorsturen, waarbij een bericht verzonden naar jsmith@alumni.university.edu, een mailbox die is ingesteld om alle mail automatisch door te sturen naar jsmith@isp.com
Mailinglijsten, waarbij mail verzonden naar talk-about-stuff@listserv.foo.com wordt 'ontploft' en naar elke abonnee gestuurd
In beide gevallen, als het Return-Path ongewijzigd blijft sinds het origineel, kan de e-mail SPF-controles niet doorstaan (afhankelijk van de modifier die is gebruikt met het ‘all’ mechanisme). Dit komt omdat het op zijn uiteindelijke bestemming aankomt van een tussenliggende server, niet de oorspronkelijke, en die tussenliggende server zal waarschijnlijk niet in het SPF-record van het domein staan. Een techniek genaamd “Sender Rewriting Scheme” of “SRS” kan dit risico verminderen, en sommige grotere sites hebben het geadopteerd, maar het is niet universeel.
Hoewel het een relatief eenvoudige manier lijkt om e-mail te verifiëren, is SPF kwetsbaar voor fouten in de vorm van valse negatieven. Deze fouten kunnen vaker voorkomen dan velen prettig vinden.
Hier zijn twee veelvoorkomende scenario's waarin volkomen legitieme e-mail kan falen bij SPF-validatie en dus frauduleus kan lijken:
Geautomatiseerd doorsturen, waarbij een bericht verzonden naar jsmith@alumni.university.edu, een mailbox die is ingesteld om alle mail automatisch door te sturen naar jsmith@isp.com
Mailinglijsten, waarbij mail verzonden naar talk-about-stuff@listserv.foo.com wordt 'ontploft' en naar elke abonnee gestuurd
In beide gevallen, als het Return-Path ongewijzigd blijft sinds het origineel, kan de e-mail SPF-controles niet doorstaan (afhankelijk van de modifier die is gebruikt met het ‘all’ mechanisme). Dit komt omdat het op zijn uiteindelijke bestemming aankomt van een tussenliggende server, niet de oorspronkelijke, en die tussenliggende server zal waarschijnlijk niet in het SPF-record van het domein staan. Een techniek genaamd “Sender Rewriting Scheme” of “SRS” kan dit risico verminderen, en sommige grotere sites hebben het geadopteerd, maar het is niet universeel.
Hoewel het een relatief eenvoudige manier lijkt om e-mail te verifiëren, is SPF kwetsbaar voor fouten in de vorm van valse negatieven. Deze fouten kunnen vaker voorkomen dan velen prettig vinden.
Hier zijn twee veelvoorkomende scenario's waarin volkomen legitieme e-mail kan falen bij SPF-validatie en dus frauduleus kan lijken:
Geautomatiseerd doorsturen, waarbij een bericht verzonden naar jsmith@alumni.university.edu, een mailbox die is ingesteld om alle mail automatisch door te sturen naar jsmith@isp.com
Mailinglijsten, waarbij mail verzonden naar talk-about-stuff@listserv.foo.com wordt 'ontploft' en naar elke abonnee gestuurd
In beide gevallen, als het Return-Path ongewijzigd blijft sinds het origineel, kan de e-mail SPF-controles niet doorstaan (afhankelijk van de modifier die is gebruikt met het ‘all’ mechanisme). Dit komt omdat het op zijn uiteindelijke bestemming aankomt van een tussenliggende server, niet de oorspronkelijke, en die tussenliggende server zal waarschijnlijk niet in het SPF-record van het domein staan. Een techniek genaamd “Sender Rewriting Scheme” of “SRS” kan dit risico verminderen, en sommige grotere sites hebben het geadopteerd, maar het is niet universeel.
Afronden
Dus dat is SPF-authenticatie, hoe het werkt, hoe een SPF-beleid te declareren en wat de valkuilen zijn bij het gebruik van SPF. SPF was het eerste e-mailauthenticatieschema dat op grote schaal werd geaccepteerd, maar het is niet de enige die er is. SPF-authenticatie is het meest effectief wanneer het wordt ingezet in combinatie met andere anti-fraude technieken.
Dus dat is SPF-authenticatie, hoe het werkt, hoe een SPF-beleid te declareren en wat de valkuilen zijn bij het gebruik van SPF. SPF was het eerste e-mailauthenticatieschema dat op grote schaal werd geaccepteerd, maar het is niet de enige die er is. SPF-authenticatie is het meest effectief wanneer het wordt ingezet in combinatie met andere anti-fraude technieken.
Dus dat is SPF-authenticatie, hoe het werkt, hoe een SPF-beleid te declareren en wat de valkuilen zijn bij het gebruik van SPF. SPF was het eerste e-mailauthenticatieschema dat op grote schaal werd geaccepteerd, maar het is niet de enige die er is. SPF-authenticatie is het meest effectief wanneer het wordt ingezet in combinatie met andere anti-fraude technieken.
