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 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.
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 record van een domein is gewoon een specifiek geformatteerd DNS TXT-record, dat vaak een of meer van de volgende "mechanismen" bevat:
v=spf1 – Vereiste 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 toestemming hebben om e-mail te verzenden voor het domein
a – Als het verzendende domein een DNS "A"-record heeft dat naar het verzendende IP vertaalt, is het IP toegestaan
mx – Als het verzendende IP ook een van de MX-records voor het verzendende domein is, is het IP toegestaan
all – Vereiste laatste token, altijd aangepast:
-all – Alleen wat hier vermeld is kan doorgaan; afwijzen mislukkingen.
~all – Zaken die niet hier zijn moeten softfail; accepteren maar noteren.
?all – Niet zeker of zaken die hier niet zijn moeten doorgaan.
+all – Wij denken dat SPF nutteloos is; alles doorlaten.
Andere minder voorkomende mechanismen die nog steeds wijdverspreid worden gebruikt zijn:
include – Gebruikt wanneer een domein niet alleen zijn eigen servers heeft, maar ook iemand anders servers gebruikt. Moet zorgvuldig worden gebruikt. Elke include is een andere DNS-zoekopdracht, en SPF-records kunnen niet meer dan tien DNS-zoekopdrachten vereisen om op te lossen.
redirect – Wanneer domein A en domein B eigendom zijn van dezelfde entiteit en dezelfde infrastructuur gebruiken. De eigenaren willen doorgaans slechts één kopie van het SPF-record voor beide onderhouden, en configureren B om zoekopdrachten naar A door te verwijzen.
exists – Als een domein veel kleine, niet-aaneengesloten netwerkblokken heeft, kan het dit mechanisme gebruiken om zijn SPF-record op te geven, in plaats van ze allemaal op te sommen. Handig om binnen de grootte limiet (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 in de huidige specificatie als "niet te gebruiken" verklaard. Het ptr-mechanisme werd gebruikt om te verklaren dat als het verzendende IP-adres een DNS PTR-record had dat naar de domeinnaam in kwestie vertaald, dan dat IP-adres gemachtigd was om mail voor het domein te verzenden.
De huidige status van dit mechanisme is dat het niet moet worden gebruikt. Echter, sites die SPF-validatie uitvoeren moeten het als geldig accepteren.
Mechanism | What It Does | Notes / Usage Guidance |
|---|---|---|
v=spf1 | Verklaart dat het TXT-record een SPF-beleid is | Vereiste eerste token |
ipv4 / ipv6 | Specifieke IP's of CIDR-blokken autoriseren | Meest expliciete en betrouwbare autorisatiemethode |
a | IP's autoriseren die overeenkomen met het A-record van het domein | Geschikt voor eenvoudige infrastructuur |
mx | IP's autoriseren die in de MX-records van het domein zijn vermeld | Handig wanneer MX-servers ook mail verzenden |
include | Het SPF-beleid van een ander domein importeren | Telt mee voor de limiet van 10-DNS-opzoekingen; gebruik spaarzaam |
redirect | SPF-beleid delegeren aan een ander domein | Gebruikt wanneer meerdere domeinen één SPF-definitie delen |
exists | Autorisatie via een aangepaste DNS-opzoekingsregel | Nuttig voor grote, gefragmenteerde IP-bereiken; validator moet het ondersteunen |
ptr | Autoriseren op basis van reverse DNS-mapping | Verouderd ("niet te gebruiken") maar moet nog steeds worden gehonoreerd door validators |
all | Bepaalt hoe alles wat niet expliciet is toegestaan moet worden behandeld | Varianten: -all afwijzen, ~all softfail, ?all neutraal, +all alles toestaan (niet aanbevolen) |
Het SPF-beleid record van een domein is gewoon een specifiek geformatteerd DNS TXT-record, dat vaak een of meer van de volgende "mechanismen" bevat:
v=spf1 – Vereiste 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 toestemming hebben om e-mail te verzenden voor het domein
a – Als het verzendende domein een DNS "A"-record heeft dat naar het verzendende IP vertaalt, is het IP toegestaan
mx – Als het verzendende IP ook een van de MX-records voor het verzendende domein is, is het IP toegestaan
all – Vereiste laatste token, altijd aangepast:
-all – Alleen wat hier vermeld is kan doorgaan; afwijzen mislukkingen.
~all – Zaken die niet hier zijn moeten softfail; accepteren maar noteren.
?all – Niet zeker of zaken die hier niet zijn moeten doorgaan.
+all – Wij denken dat SPF nutteloos is; alles doorlaten.
Andere minder voorkomende mechanismen die nog steeds wijdverspreid worden gebruikt zijn:
include – Gebruikt wanneer een domein niet alleen zijn eigen servers heeft, maar ook iemand anders servers gebruikt. Moet zorgvuldig worden gebruikt. Elke include is een andere DNS-zoekopdracht, en SPF-records kunnen niet meer dan tien DNS-zoekopdrachten vereisen om op te lossen.
redirect – Wanneer domein A en domein B eigendom zijn van dezelfde entiteit en dezelfde infrastructuur gebruiken. De eigenaren willen doorgaans slechts één kopie van het SPF-record voor beide onderhouden, en configureren B om zoekopdrachten naar A door te verwijzen.
exists – Als een domein veel kleine, niet-aaneengesloten netwerkblokken heeft, kan het dit mechanisme gebruiken om zijn SPF-record op te geven, in plaats van ze allemaal op te sommen. Handig om binnen de grootte limiet (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 in de huidige specificatie als "niet te gebruiken" verklaard. Het ptr-mechanisme werd gebruikt om te verklaren dat als het verzendende IP-adres een DNS PTR-record had dat naar de domeinnaam in kwestie vertaald, dan dat IP-adres gemachtigd was om mail voor het domein te verzenden.
De huidige status van dit mechanisme is dat het niet moet worden gebruikt. Echter, sites die SPF-validatie uitvoeren moeten het als geldig accepteren.
Mechanism | What It Does | Notes / Usage Guidance |
|---|---|---|
v=spf1 | Verklaart dat het TXT-record een SPF-beleid is | Vereiste eerste token |
ipv4 / ipv6 | Specifieke IP's of CIDR-blokken autoriseren | Meest expliciete en betrouwbare autorisatiemethode |
a | IP's autoriseren die overeenkomen met het A-record van het domein | Geschikt voor eenvoudige infrastructuur |
mx | IP's autoriseren die in de MX-records van het domein zijn vermeld | Handig wanneer MX-servers ook mail verzenden |
include | Het SPF-beleid van een ander domein importeren | Telt mee voor de limiet van 10-DNS-opzoekingen; gebruik spaarzaam |
redirect | SPF-beleid delegeren aan een ander domein | Gebruikt wanneer meerdere domeinen één SPF-definitie delen |
exists | Autorisatie via een aangepaste DNS-opzoekingsregel | Nuttig voor grote, gefragmenteerde IP-bereiken; validator moet het ondersteunen |
ptr | Autoriseren op basis van reverse DNS-mapping | Verouderd ("niet te gebruiken") maar moet nog steeds worden gehonoreerd door validators |
all | Bepaalt hoe alles wat niet expliciet is toegestaan moet worden behandeld | Varianten: -all afwijzen, ~all softfail, ?all neutraal, +all alles toestaan (niet aanbevolen) |
Het SPF-beleid record van een domein is gewoon een specifiek geformatteerd DNS TXT-record, dat vaak een of meer van de volgende "mechanismen" bevat:
v=spf1 – Vereiste 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 toestemming hebben om e-mail te verzenden voor het domein
a – Als het verzendende domein een DNS "A"-record heeft dat naar het verzendende IP vertaalt, is het IP toegestaan
mx – Als het verzendende IP ook een van de MX-records voor het verzendende domein is, is het IP toegestaan
all – Vereiste laatste token, altijd aangepast:
-all – Alleen wat hier vermeld is kan doorgaan; afwijzen mislukkingen.
~all – Zaken die niet hier zijn moeten softfail; accepteren maar noteren.
?all – Niet zeker of zaken die hier niet zijn moeten doorgaan.
+all – Wij denken dat SPF nutteloos is; alles doorlaten.
Andere minder voorkomende mechanismen die nog steeds wijdverspreid worden gebruikt zijn:
include – Gebruikt wanneer een domein niet alleen zijn eigen servers heeft, maar ook iemand anders servers gebruikt. Moet zorgvuldig worden gebruikt. Elke include is een andere DNS-zoekopdracht, en SPF-records kunnen niet meer dan tien DNS-zoekopdrachten vereisen om op te lossen.
redirect – Wanneer domein A en domein B eigendom zijn van dezelfde entiteit en dezelfde infrastructuur gebruiken. De eigenaren willen doorgaans slechts één kopie van het SPF-record voor beide onderhouden, en configureren B om zoekopdrachten naar A door te verwijzen.
exists – Als een domein veel kleine, niet-aaneengesloten netwerkblokken heeft, kan het dit mechanisme gebruiken om zijn SPF-record op te geven, in plaats van ze allemaal op te sommen. Handig om binnen de grootte limiet (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 in de huidige specificatie als "niet te gebruiken" verklaard. Het ptr-mechanisme werd gebruikt om te verklaren dat als het verzendende IP-adres een DNS PTR-record had dat naar de domeinnaam in kwestie vertaald, dan dat IP-adres gemachtigd was om mail voor het domein te verzenden.
De huidige status van dit mechanisme is dat het niet moet worden gebruikt. Echter, sites die SPF-validatie uitvoeren moeten het als geldig accepteren.
Mechanism | What It Does | Notes / Usage Guidance |
|---|---|---|
v=spf1 | Verklaart dat het TXT-record een SPF-beleid is | Vereiste eerste token |
ipv4 / ipv6 | Specifieke IP's of CIDR-blokken autoriseren | Meest expliciete en betrouwbare autorisatiemethode |
a | IP's autoriseren die overeenkomen met het A-record van het domein | Geschikt voor eenvoudige infrastructuur |
mx | IP's autoriseren die in de MX-records van het domein zijn vermeld | Handig wanneer MX-servers ook mail verzenden |
include | Het SPF-beleid van een ander domein importeren | Telt mee voor de limiet van 10-DNS-opzoekingen; gebruik spaarzaam |
redirect | SPF-beleid delegeren aan een ander domein | Gebruikt wanneer meerdere domeinen één SPF-definitie delen |
exists | Autorisatie via een aangepaste DNS-opzoekingsregel | Nuttig voor grote, gefragmenteerde IP-bereiken; validator moet het ondersteunen |
ptr | Autoriseren op basis van reverse DNS-mapping | Verouderd ("niet te gebruiken") maar moet nog steeds worden gehonoreerd door validators |
all | Bepaalt hoe alles wat niet expliciet is toegestaan moet worden behandeld | Varianten: -all afwijzen, ~all softfail, ?all neutraal, +all alles toestaan (niet aanbevolen) |
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.
