Met SPF (Sender Policy Framework) heb je de flexibiliteit om je systeem zo in te stellen dat het op twee manieren reageert op authenticatiefouten: Hardfail of SoftfailIn deze blog bespreken we de verschillen tussen SPF hardfail en softfail, de syntaxis om beide te configureren en hun gebruikssituaties. Dus laten we er meteen in duiken!
Belangrijkste conclusies
- SPF hardfail geeft aan dat een e-mailafzender niet geautoriseerd is, wat vaak leidt tot afwijzing van de e-mail.
- SPF softfail suggereert dat de e-mail nog steeds afkomstig kan zijn van een onbevoegde afzender, maar wijst de e-mail niet ronduit af, zodat verdere controle mogelijk is.
- Het implementeren van een strikt SPF-beleid is essentieel om onbevoegde e-mailimitatie te voorkomen en de merkreputatie te beschermen.
- De combinatie van SPF met DMARC voegt een essentiële beveiligingslaag toe, die een betere afhandeling van e-mailverificatiestoringen mogelijk maakt.
- Het regelmatig controleren van SPF-verificatieresultaten kan helpen bij het handhaven van een optimale e-mailbeveiligingshouding en het voorkomen van mogelijke kwetsbaarheden.
Het verschil tussen SPF Softfail en Hardfail
De onderstaande tabel legt het basisverschil uit tussen SPF hardfail en softfail.
SPF-syntaxis | Type mislukking | Status | Overeenkomstige actie ondernomen door de ontvanger |
---|---|---|---|
v=spf1 include:domain1.com -all | Hardfail | Afzender onbevoegd | E-mail kan worden geweigerd |
v=spf1 include:domain1.com ~all | Softfail | Afzender is mogelijk onbevoegd | E-mail wordt afgeleverd maar gemarkeerd als verdacht of mogelijk frauduleus |
SPF Hardfail vs Softfail : Zoals gedefinieerd in RFC
Volgens RFC 7208:
- Een "Fail" resultaat voor SPF geeft direct aan dat de afzender van de e-mail niet geautoriseerd is door het verzendende domein. "Fail" is synoniem met het Hardfail resultaat (-all) dat duidelijk wijst op ongeautoriseerd domeingebruik.
- Een veel meer ontspannen aanpak is echter het configureren van SPF Softfail, dat een "waarschijnlijke" indicatie geeft van ongeautoriseerd domeingebruik.
Vereenvoudig SPF met PowerDMARC!
Afhandeling van ontvangstfouten voor Hardfail vs. Softfail
In sectie 8.4definieert de RFC de volgende resultaatverwerkingsscenario's voor SPF hardfail vs. SPF softfail resultaten:
1. SPF Hardfail / Mislukt
Voor het "Fail" of hardfail resultaat kan je ontvanger server ervoor kiezen om de e-mail die niet geautoriseerd is te weigeren. Als het een SMTP-transactie is, moet een 550 5.7.1 foutcode worden geretourneerd met een toepasselijke foutbeschrijving.
Als de ontvangende server de e-mail niet afwijst tijdens de SMTP-transactie, dan raadt de RFC ontvangers aan om de SPF-resultaten te registreren in de header Received-SPF of Authentication-Results.
2. SPF Softfail
Als flexibeler beleid geeft Softfail aan dat het administratieve beheerdomein wel vermoedt dat de e-mail ongeautoriseerd is, maar het niet direct wil afwijzen. In dit geval wordt het bericht afgeleverd, maar met een waarschuwing voor verdere controle.
SPF Softfail Vs Hardfail: Wat raden we aan?
In het geval van SMTP e-mail relaying, kun je SPF softfail beschouwen als een veiligere keuze dan hardfail. Laten we eens kijken hoe:
SMTP e-mail relaying is de automatische overdracht van berichten van de ene server naar de andere aflevering. Dit betekent dat de e-mail wordt doorgestuurd naar een server waarvan het IP-adres niet voorkomt in het SPF-record van je domein. Dit maakt het een onbevoegde afzender voor uw e-mail, hoewel het in de praktijk legitiem is.
Heb je enige controle over deze activiteit? Het antwoord is nee, omdat de e-mail automatisch wordt doorgestuurd aan de kant van de ontvanger. Onder deze omstandigheden zal SPF falen voor de doorgestuurde e-mails.
Hier kan een SPF hardfail beleid je in de problemen brengen! Zoals we al weten, kunnen de hardfail mechanismen leiden tot het weigeren van mislukte berichten. Daarom kunnen deze doorgestuurde e-mails mogelijk niet worden afgeleverd als je domein is geconfigureerd met een hardfailbeleid.
Het ergste? De actie die wordt ondernomen door het SPF afhandelingsbeleid zal de DMARC en DKIM authenticatieresultaten overschrijven. In wezen kan de e-mail nog steeds niet worden afgeleverd, zelfs als DKIM en DMARC worden geaccepteerd.
Zoals gespecificeerd onder RFC 7489 paragraaf-10.1 als SPF-controles worden uitgevoerd vóór DMARC-bewerkingen, kan de aanwezigheid van een "-" voorvoegsel op het SPF-mechanisme van een afzender, zoals "-all", leiden tot onmiddellijke afwijzing van e-mails. Deze afwijzing vindt vroeg in het e-mailverwerkingsproces plaats, zelfs voordat DMARC-verwerking plaatsvindt.
Als het SPF-beleid van een e-mailafzender een "-all" mechanisme bevat, waarmee een strikt beleid wordt aangegeven om e-mails af te wijzen die niet door de SPF-controles komen, kan dit dus leiden tot afwijzing van het bericht voordat er DMARC-beleid of -verwerking plaatsvindt. Deze vroege afwijzing kan plaatsvinden ongeacht of de e-mail uiteindelijk door de DMARC-verificatie komt.
Onder deze omstandigheden wint SPF Softfail het dus van het Hardfail mechanisme. Het is een aanpak met een aanzienlijk lager risico die ruimte laat voor herziening door simpelweg geautoriseerde e-mails te markeren in plaats van ze te weigeren.
Hoe werken SPF Records?
Om SPF voor je e-mails te implementeren, moet je een SPF-record aanmaken en publiceren in de DNS van je domein. Een typisch voorbeeld van een SPF record is als volgt:
v=spf1 include:_spf.google.com ~all
In dit SPF-record autoriseer je alle e-mails die afkomstig zijn van IP-adressen die in het SPF-record van Google staan. Het faalmechanisme is helemaal aan het einde van het record gedefinieerd (~all), namelijk Softfail.
Een SPF-record definieert dus de gebruikte protocolversie, de verzendbronnen die je autoriseert en het faalmechanisme. Wanneer je dit record in je DNS publiceert, zorg je ervoor dat alleen geautoriseerde afzenders e-mails mogen versturen namens je domein. Als een niet-geautoriseerde bron zich voor u probeert uit te geven, faalt SPF met het type faalmechanisme dat in uw record is gedefinieerd.
Veilige SPF-implementatiestrategieën
Een optimale SPF-implementatie is essentieel om e-mailcommunicatie te beschermen tegen ongeautoriseerde spoofing en phishing-aanvallen. Door best practices te volgen, kunnen organisaties hun e-mailbeveiliging verbeteren en hun merkreputatie beschermen. Hier volgen enkele strategieën en richtlijnen voor het veilig implementeren van SPF:
1. Gebruik een SPF-recordgeneratietool
Het SPF implementatieproces begint met het aanmaken van records. Je kunt je record handmatig aanmaken door de SPF tags goed te begrijpen. Deze methode is echter gevoelig voor menselijke fouten. Idealiter kun je onze geautomatiseerde SPF generator tool gebruiken. Hiermee kun je een foutloos, nauwkeurig SPF-record maken dat is aangepast aan de behoeften van je organisatie.
2. Gebruik de juiste SPF-mechanismen
Gebruik SPF-mechanismen zoals "include", "a" en "IP4" om de toegestane verzendbronnen te specificeren. Wees voorzichtig bij het selecteren van mechanismen op basis van uw e-mailinfrastructuur en zorg ervoor dat ze een accurate weergave zijn van uw e-mailverzendpraktijken.
3. Uw SPF Record onderhouden en optimaliseren
Je Sender Policy Framework record moet onderhouden en geoptimaliseerd worden om te voorkomen dat het slecht werkt. SPF heeft de neiging om te breken wanneer je geautoriseerde afzenders de 10 DNS lookup limiet overschrijden aan de kant van de ontvanger. Om een optimale opzoeklimiet te handhaven, kan onze gehoste SPF oplossing uw beste kans! Wij helpen domeineigenaren SPF te optimaliseren met een enkele klik, om onder de opzoek- en leegmaaklimieten te blijven en foutloze SPF te behouden.
4. SPF combineren met DMARC
implementeren DMARC (Domain-based Message Authentication, Reporting, and Conformance) naast SPF biedt een extra (maar essentiële) beveiligingslaag. DMARC stelt domeineigenaren in staat om beleidsregels op te stellen voor het afhandelen van e-mail, inclusief de te nemen maatregelen bij e-mails die niet voldoen aan SPF.
DMARC heeft bewezen resultaten bij het minimaliseren van aanvallen op e-mailfraude, compromittering en imitatie.
5. Strikt beleid voor SPF bij falen implementeren
Configureer uw record om SPF-verificatie mislukkingen met strikte beleidsregels, zoals het weigeren of markeren van e-mails van domeinen met mislukkingen. Hiervoor kun je SPF hardfail of SPF softfail implementeren in plaats van een neutraal beleid.
6. De resultaten van SPF-authenticatie controleren
implementeren DMARC-rapporten om SPF-authenticatieresultaten te controleren, zoals SPF pass en fail, evenals uitlijningsfouten. A DMARC-analyser kan je helpen om SPF verificatiegegevens te analyseren op een georganiseerde, voor mensen leesbare manier.
Laatste woorden
Er is geen direct antwoord op de vraag "Wat is beter? SPF hardfail of softfail". Hoewel de hardfail tag je een betere beveiliging kan bieden, wordt het kiezen van de juiste oplossing voor het controleren van je verzendbronnen cruciaal.
PowerDMARC's geavanceerde domeinverificatie- en rapportageplatform biedt uitgebreide SPF- en DMARC-oplossingen voor bedrijven van elke omvang. Aanmelden vandaag nog in voor een gratis proefversie!
- E-mail salting aanvallen: Hoe verborgen tekst de beveiliging omzeilt - 26 februari 2025
- SPF-afvlakking: Wat is het en waarom heb je het nodig? - 26 februari 2025
- DMARC vs DKIM: belangrijkste verschillen en hoe ze samenwerken - 16 februari 2025