Berichten

Waarom SPF verificatie mislukt? Hoe SPF mislukking te verhelpen?

Heb je ooit een e-mail gezien die SPF niet haalde? Als dat zo is, dan zal ik je precies vertellen waarom SPF verificatie faalt. Sender Policy Framework, of SPF, is een van de e-mail verificatie standaarden die we allemaal al jaren gebruiken om spam tegen te houden. Zelfs als je er niet van op de hoogte was, durf ik te wedden dat als ik de instellingen van je login account voor Facebook zou controleren, je waarschijnlijk "opt-in" zou zien voor "alleen e-mail van vrienden". Dat is in feite hetzelfde als SPF.

Wat is SPF-authenticatie?

SPF is een e-mailverificatieprotocol dat wordt gebruikt om te controleren of de afzender van de e-mail overeenkomt met zijn domeinnaam in het veld Van: van het bericht. De verzendende MTA gebruikt DNS om een vooraf geconfigureerde lijst van SPF-servers te bevragen om te controleren of het verzendende IP-adres gemachtigd is om e-mail te verzenden voor dat domein. Er kunnen inconsistenties zijn in de manier waarop SPF-records worden opgezet, wat van cruciaal belang is om te begrijpen waarom e-mails de SPF-verificatie kunnen missen, en welke rol u kunt spelen om ervoor te zorgen dat zich geen problemen voordoen bij uw eigen e-mailmarketinginspanningen of wanneer u marketingcoupons verstuurt via e-mails om klanten te winnen.

Waarom SPF Authenticatie Faalt : Geen, Neutraal, Hardfail, Softfail, TempError, en PermError

SPF authenticatie mislukt om de volgende redenen:

  • De ontvangende MTA slaagt er niet in een SPF record te vinden dat in uw DNS gepubliceerd is
  • U heeft meerdere SPF records gepubliceerd in uw DNS voor hetzelfde domein
  • Uw ESP's hebben hun IP-adressen gewijzigd of toegevoegd die niet zijn bijgewerkt op uw SPF-record
  • Als u de 10 DNS lookup limiet voor SPF overschrijdt
  • Als u het maximum aantal toegestane opzoekingen overschrijdt van 2
  • De lengte van uw SPF record overschrijdt de limiet van 255 SPF karakters

Hierboven staan verschillende scenario's waarom SPF authenticatie mislukt. U kunt uw domeinen monitoren met onze DMARC analyzer om rapporten te krijgen over SPF authenticatie mislukkingen. Wanneer u DMARC rapportage heeft ingeschakeld, retourneert de ontvangende MTA een van de volgende SPF authenticatie mislukte resultaten voor de e-mail, afhankelijk van de reden waarom uw e-mail SPF heeft gefaald. Laten we ze beter leren kennen:

Soorten SPF Fail kwalificaties

De volgende types van SPF Fail qualifiers worden elk als prefix toegevoegd vóór het SPF fail mechanisme:

"+" "geslaagd"
"-" "Fail"
"~" "Softfail"
"?" "Neutral"

Wat doen deze ertoe? In het geval dat je e-mail SPF niet haalt, kun je kiezen hoe streng je wilt dat ontvangers hiermee omgaan. U kunt een kwalificatie specificeren om berichten die niet voldoen aan de controle "door te laten" (af te leveren), "Niet af te leveren", of een "Neutraal" standpunt in te nemen (niets doen).

Geval 1: SPF Geen resultaat wordt geretourneerd

In het eerste geval, - als de ontvangende e-mailserver een DNS lookup uitvoert en de domeinnaam niet in de DNS kan vinden, wordt een none resultaat geretourneerd. Geen wordt ook geretourneerd als er geen SPF record wordt gevonden in de DNS van de afzender, wat impliceert dat de afzender geen SPF authenticatie heeft geconfigureerd voor dit domein. In dit geval mislukt de SPF authenticatie voor uw emails.

Genereer nu uw foutloze SPF record met onze gratis SPF record generator tool om dit te vermijden.

Geval 2: SPF Neutraal resultaat wordt geretourneerd

Als u bij het configureren van SPF voor uw domein een ?all mechanisme aan uw SPF record hebt gekoppeld, betekent dit dat ongeacht wat de SPF authenticatiecontroles voor uw uitgaande e-mailberichten opleveren, de ontvangende MTA een neutraal resultaat retourneert. Dit gebeurt omdat wanneer je je SPF in neutrale modus hebt, je niet de IP adressen specificeert die geauthoriseerd zijn om namens jou emails te versturen en niet geauthoriseerde IP adressen toestaat om ze ook te versturen.

Geval 3: SPF Softfail Resultaat

Vergelijkbaar met SPF neutraal, wordt SPF softfail geïdentificeerd door het ~all mechanisme, wat inhoudt dat de ontvangende MTA de mail accepteert en aflevert in de inbox van de ontvanger, maar dat deze wordt gemarkeerd als spam, in het geval dat het IP adres niet voorkomt in het SPF record in de DNS, wat een reden kan zijn waarom SPF authenticatie mislukt voor uw e-mail. Hieronder staat een voorbeeld van een SPF softfail:

 v=spf1 include:spf.google.com ~all

Geval 4: SPF Hardfail Resultaat

SPF hardfail, ook bekend als SPF fail is wanneer ontvangende MTA's emails zouden negeren die afkomstig zijn van een versturende bron die niet in je SPF record voorkomt. Wij raden u aan om SPF hardfail in uw SPF record te configureren, als u bescherming wilt tegen domein impersonatie en email spoofing. Hieronder staat een voorbeeld van SPF hardfail:

v=spf1 include:spf.google.com -all

Geval 5: SPF TempError (SPF tijdelijke fout)

Een van de meest voorkomende en vaak onschuldige redenen waarom SPF authenticatie mislukt is SPF TempError (tijdelijke fout) die veroorzaakt wordt door een DNS fout zoals een DNS timeout terwijl een SPF authenticatie controle wordt uitgevoerd door de ontvangende MTA. Het is dus, zoals de naam al doet vermoeden, meestal een tussentijdse fout die een 4xx status code terugstuurt die een tijdelijke SPF mislukking kan veroorzaken, maar een SPF pass resultaat oplevert als het later opnieuw geprobeerd wordt.

Geval 6: SPF PermError (SPF permanente fout)

Een ander veel voorkomend resultaat waar domeinfouten mee te maken krijgen is SPF PermError. Dit is de reden waarom SPF authenticatie in de meeste gevallen mislukt. Dit gebeurt wanneer je SPF record ongeldig wordt gemaakt door de ontvangende MTA. Er zijn vele redenen waarom SPF kan breken en ongeldig gemaakt kan worden door de MTA tijdens het uitvoeren van DNS lookups:

  • Overschrijden van de 10 SPF lookup limiet
  • Onjuiste SPF record syntax
  • Meer dan één SPF record voor hetzelfde domein
  • Overschrijding van de SPF record lengte limiet van 255 tekens
  • Als uw SPF record niet up to date is met de wijzigingen die uw ESP's

Opmerking: Wanneer een MTA een SPF controle uitvoert op een e-mail, bevraagt hij de DNS of voert hij een DNS lookup uit om de authenticiteit van de e-mail bron te controleren. Idealiter zijn in SPF maximaal 10 DNS lookups toegestaan, bij overschrijding daarvan zal SPF falen en een PermError resultaat geven.

Hoe kan Dynamic SPF Flattening een SPF PermError oplossen?

In tegenstelling tot de andere SPF fouten, is de SPF PermError veel lastiger en ingewikkelder op te lossen. PowerSPF helpt u om dit probleem op te lossen met behulp van automatische SPF afvlakking. Het helpt u:

  • Blijf onder de harde limiet van de SPF
  • Optimaliseer direct uw SPF record
  • Verlaag uw record tot een enkele verklaring
  • Zorg ervoor dat uw SPF-record altijd wordt bijgewerkt bij wijzigingen door uw ESP's

Wilt u testen of u SPF correct heeft geconfigureerd voor uw domein? Probeer dan vandaag nog onze gratis SPF record lookup tool!

/door

Het verschil tussen SPF -all en SPF ~all | SPF -all vs ~all

SPF bestaat in de DNS van uw domein als een TXT record met een heleboel mechanismen en modifiers die voor specifieke instructies staan. Het SPF all mechanisme staat aan het rechter eind van een SPF record, voorafgegaan door "-" of "~". Laten we eens kijken wat het verschil is tussen de SPF -all en ~all mechanismen om te bepalen wanneer je ze zou moeten configureren.

SPF -all vs ~all

Zowel het SPF -all als het ~all mechanisme betekenen "NOT PASS" voor SPF authenticatie. De laatste tijd is er voor de meeste e-mail service providers geen verschil meer tussen het -all en ~all mechanisme, en wordt hetzelfde resultaat geretourneerd. Dit was een paar jaar geleden echter niet het geval.

Hoe werkte het SPF all (Softfail vs Fail) mechanisme vóór DMARC?

DMARC werd gecreëerd lang nadat SPF reeds op de markt was als het standaard e-mail authenticatieprotocol. In die tijd werkte het SPF -all softfail mechanisme op de volgende manier: 

Laten we aannemen dat je SPF record was: 

v=spf1 include:spf.domain.com ~all (waar ~all SPF Softfail betekent)

De e-mailserver van de ontvanger zou een DNS lookup hebben uitgevoerd om de DNS van de afzender te vragen naar zijn SPF record. Als het Return-path domein van de e-mail niet in het record van de afzender voorkomt, zou de ontvangende server een SPF "NOT PASS" resultaat hebben teruggestuurd, maar zou de e-mail hebben afgeleverd afgeleverd in de inbox van de ontvanger.

Stel nu dat je SPF record was: 

v=spf1 include:spf.domain.com -all (waar -all SPF Fail betekent)

De e-mailserver van de ontvanger zou een DNS lookup hebben uitgevoerd om de DNS van de afzender te vragen naar zijn SPF record. Als het Return-path domein van de e-mail niet in het record van de afzender voorkomt, zou de ontvangende server een SPF "NOT PASS" resultaat hebben teruggezonden, maar in dit geval zou de e-mail zijn geweest geweigerd en niet afgeleverd in de inbox van de ontvanger.

Lees meer over de geschiedenis van Sender Policy Framework. 

Hoe gaan e-mail service providers nu om met het SPF -all vs ~all mechanisme?

Hoewel je op dit moment vrij bent om SPF -all of ~all te gebruiken voor de meeste postbusproviders zonder je zorgen te hoeven maken over afleveringsfouten voor legitieme emails, kan er een situatie ontstaan waarbij een server je e-mail weigert in geval van het -all attribuut.

Om het veiliger te maken, kunt u het SPF hard fail -all mechanisme vermijden bij het maken van uw SPF record. Dit is hoe je het doet:

  • Open de PowerDMARC SPF record generator om te beginnen met het gratis aanmaken van een record
  • Nadat u de IP-adressen en domeinen van uw e-mailverzenders hebt ingevoerd, gaat u naar het laatste gedeelte dat is bedoeld om e-mailservers te instrueren hoe streng ze moeten zijn bij het verifiëren van uw e-mails
  • Kies de "Soft-fail" optie alvorens op de "Genereer SPF Record" knop te drukken

Wat bevelen wij aan? SPF -allemaal of SPF ~allemaal

Problemen met de bezorgbaarheid van e-mail in verband met het SPF -all mechanisme kunnen zich in zeer zeldzame gevallen voordoen. Dit is geen terugkerend probleem dat u vaak zult tegenkomen. Om ervoor te zorgen dat u dit probleem nooit tegenkomt, kunt u de volgende stappen ondernemen:

  • Configureer DMARC voor uw e-mails, en schakel DMARC rapportage in
  • Stel uw DMARC-beleid in op bewaking en inspecteer uw SPF-verificatieresultaten nauwkeurig om eventuele inconsistenties in de bezorgbaarheid van e-mail op te sporen
  • Als alles goed is, kunt u het -all mechanisme in uw SPF record gebruiken. Wij raden aan om het hard fail attribuut te gebruiken omdat het bevestigt dat u zeker bent van de authenticiteit van uw e-mails, wat de reputatie van uw domein kan verbeteren

Als u momenteel niet zeker bent over het gebruik van SPF -all, kunt u de volgende stappen volgen:

  • Maak een SPF record aan met het ~all mechanisme
  • Configureer DMARC voor uw e-mails, en schakel DMARC-rapportage in
  • Stel uw DMARC beleid in op weigeren

Oplossen van andere SPF fouten

Bij het gebruik van online tools komt u vaak de melding "Geen SPF record gevonden"Dit is een veel voorkomende foutmelding als gevolg van een null resultaat wanneer een server het SPF record van uw domein heeft opgezocht. We hebben een artikel gewijd aan dit probleem en helpen gebruikers het op te lossen. Klik op de gelinkte tekst voor meer informatie!

Als u DMARC heeft ingesteld voor uw domein bovenop SPF, zullen email servers de DMARC policy van uw domein controleren om te bepalen hoe u emails wilt behandelen die niet geauthenticeerd kunnen worden. Dit DMARC beleid zal bepalen of uw emails worden afgeleverd, in quarantaine worden geplaatst, of worden geweigerd. 

DMARC afwijzing helpt uw domein te beschermen tegen een verscheidenheid van impersonatie aanvallen zoals spoofing, phishing, en ransomware.

/door

Hoe " SPF Softfail Domain Does Not Designate IP as Permitted Sender " te herstellen?

Als uw bedrijf zijn eigen domeinen gebruikt en mails afhandelt, is de kans groot dat ze tegen e-mail problemen aanlopen, en de " SPF Softfail Domain Does Not Designate IP as Permitted Sender " fout zijn tegengekomen. Het is van cruciaal belang dat bedrijven de IP-adressen die gebruikt worden om namens hen emails te versturen, correct aanwijzen als toegestane afzender in het SPF Record.

Wat is SPF?

SPF of Sender Policy Framework is een e-mailauthenticatiestandaard die organisaties beschermt tegen impersonatie. Een aanvaller kan het domein en de merknaam van een bedrijf gebruiken om valse berichten naar hun klanten te sturen. Deze phishing-e-mails lijken authentiek genoeg om de klanten te overtuigen en hen te laten vallen voor een internetzwendel uit naam van het bedrijf. Dit schaadt de geloofwaardigheid van het merk en het imago van een bedrijf. SPF kan worden gezien als een safelist van vertrouwde domeinen van een bedrijf waarvandaan authentieke communicatie kan komen.

Hoe kan ik controleren of uw domein een toegestane afzender is?

De eerste stap bij het oplossen van de "SPF Softfail Domain Does Not Designate IP as Permitted Sender" fout op te lossen is het controleren van uw afzender autoriteit. Om dit te doen:

Stap 1: Log in op de e-mailaccount van het bedrijfsdomein, laten we zeggen, [email protected]

Stap 2: Stuur een e-mail naar een andere e-mail account waartoe u toegang heeft; dit kan een extern domein zijn zoals Gmail, Yahoo, Hotmail, of anderen.

Stap 3: Log in op de e-mail account waar je de eerste mail naartoe hebt gestuurd, en bekijk dan de headers van deze mail. Het zal gemarkeerd zijn als "Toon origineel".

Dan zie je iets wat hier op lijkt. Let op het SPF Softfail bericht.

-Oorspronkelijke boodschap -

X-Ontvangen: ...

Sat, 13 Maart, 2022 11:01:19 IST

Return-Path: [email protected]

Ontvangen: van mymy2.spfrecords.com (mymy2.spfrecords.com [60.130.71.223])

door mx.google.com met ESMTPS id 

*id*

Voor [email protected]

Ontvangen SPF: softfail (google.com: domein van overgang [email protected] wijst 60.130.71.223 niet aan als toegestane afzender) client-ip=60.130.71.223; 

Authenticatie resultaten: mx.google.com;

Spf = softfail (google.com: domein van omschakelende [email protected] wijst 60.130.71.223 niet aan als toegestane afzender) client-ip=60.130.71.223; 

*einde van het voorbericht

Note: Als je "Received-SPF: pass" in de header ziet, dan is het domein dat je gebruikt om de mails te versturen geauthenticeerd en al toegevoegd aan je SPF record, en hoef je je nergens zorgen over te maken. Maar, zoals hierboven getoond, is er een softfail probleem. We zullen nu bekijken hoe we dit kunnen oplossen.

Wat betekent "SPF Softfail Domain Does Not Designate IP as Permitted Sender"?

De afzender van uw e-mail heeft een host IP dat er ongeveer zo uitziet:

30.10.323.005

Als dit IP-adres voor het verzendende domein niet is opgenomen in het SPF-record van uw domein, kan de ontvangende e-mailserver het aangewezen IP-adres niet identificeren als een toegestane afzender. De server interpreteert het bericht automatisch als zijnde afkomstig van een ongeautoriseerde bron. Dit is een mogelijke reden waarom SPF voor het bericht faalde. Het levert een hoge waarschijnlijkheid van DMARC falen op als het e-mail authenticatie systeem alleen afhankelijk is van SPF voor bron verificatie (en niet DKIM). 

Onder dergelijke omstandigheden, als uw protocolbeleid is ingesteld op afwijzen, zal uw bericht nooit worden afgeleverd! Daarom moet de eigenaar van het domein snel actie ondernemen om het probleem "SPF Softfail Domain Does Not Designate IP as Permitted Sender" op te lossen.

Hoe kan ik een IP toevoegen als toegestane afzender voor SPF?

De oplossing hiervoor kan in de volgende stappen worden onderverdeeld: 

1. Maak een lijst van verzendbronnen voor uw domein. U kunt een lijst van e-mailadressen gebruiken op basis van uw domein, maar ook verzendbronnen van derden voor e-mailtransacties.

2. Identificeer nu de host IP's van deze zendende bronnen 

Hoe vindt u IP-adressen die gekoppeld zijn aan uw e-mailverzendbronnen?

Het is vrij eenvoudig! Om het IP-adres van je verzendbron te vinden, open je de e-mail en bekijk je de volledige e-mail header. Om dit te doen klik je op de drie puntjes in de rechterbovenhoek van je e-mail om het drop-down menu te bekijken, en selecteer "Origineel weergeven".

Scroll in het oorspronkelijke bericht naar beneden naar de Ontvangen kunt u het IP-adres van de oorspronkelijke afzender vinden, zoals hieronder is aangegeven:

3. Gebruik onze SPF Record Generator om een gratis SPF record voor uw domein te genereren.

  • Voeg in de recordgenerator alle IP-adressen toe waarvan u wilt dat ze worden geauthenticeerd om namens het bedrijf e-mails en communicatie te verzenden.
  • Voeg servers van derden of externe bezorgdiensten toe als een geautoriseerde verzendbron voor uw domein. Op deze manier zullen alle mails die via servers van derden worden verzonden ook de SPF Authenticatie passeren.

4. Zodra je de SPF Record Generator hebt gebruikt om het SPF Record voor je domein te genereren met alle vertrouwde domeinen en IP Adressen eraan toegevoegd, is alles wat je nog moet doen SPF implementeren door het te publiceren op je DNS. Hier is hoe je dat kunt bereiken:

  • Log in op uw DNS Management Console
  • Navigeer vervolgens naar het domein van uw keuze (het domein waarvoor u het SPF-record probeert toe te voegen/te wijzigen)
  • Specificeer uw resource type als "TXT
  • Geef de hostnaam op als "_spf"
  • Plak de waarde van uw gegenereerde SPF record 
  • Wijzigingen opslaan om SPF voor uw domein te configureren

Note: De bovenstaande namen of headers kunnen verschillen naargelang de DNS Management Console die u voor uw bedrijf gebruikt.

Op die manier kunnen de domeineigenaars ervoor zorgen dat al hun vertrouwde IP-adressen en domeinen die zij zouden kunnen gebruiken om namens het bedrijf communicatie te verzenden, aan de server worden toegevoegd, en zal een soortgelijke fout waarbij het SPF Softfail Domain geen IP als toegestane afzender aanwijst, zich niet voordoen. 

Hoe kan de SPF-norm effectief worden gebruikt?

De enige manier om de SPF technologie van een bedrijf te verstevigen is door het te integreren met DMARC. Hier zijn de voordelen om dit te doen,

1. DMARC = SPF + DKIM

E-mailverificatieprotocollen zoals DMARC worden geconfigureerd door een TXT record aan uw DNS toe te voegen. Naast het configureren van een beleid voor de e-mails van uw domein, kunt u DMARC ook gebruiken om een rapportagemechanisme in te schakelen om u een schat aan informatie over uw domeinen, verkopers en e-mailbronnen te sturen.

DMARC kan u helpen gebruik te maken van zowel SPF (Sender Policy Framework) als DKIM (DomainKeys Identified Mail) technologieën in tandem om uw domein nog beter te beschermen tegen spoofing.

Note: Dit is aanbevolen, maar niet verplicht. DMARC kan zowel met SPF als met DKIM identifier alignment werken.

2. Rapportage en feedback met PowerDMARC

SPF noch DKIM geeft de domeineigenaar feedback over e-mails die niet geverifieerd kunnen worden. DMARC stuurt gedetailleerde rapporten rechtstreeks naar u, die het PowerDMARC platform omzet in gemakkelijk te lezen grafieken en tabellen.

3. Bepaal wat er gebeurt met niet-geauthenticeerde e-mails 

DMARC laat u, de domeineigenaar, beslissen of een e-mail die niet gevalideerd kan worden naar inbox of spam gaat, of wordt geweigerd. Met PowerDMARC, hoeft u alleen maar op een knop te klikken om uw DMARC beleid in te stellen, zo eenvoudig is het.

Ongeautoriseerde afzenders kunnen een gevaarlijke bedreiging vormen voor de veiligheid van uw klanten en het imago en de merkwaarde van uw bedrijf. Bescherm uw klanten tegen phishing en scams door DMARC in uw bedrijf op te nemen, en laat alleen mails van geauthenticeerde afzenders toe om hen te bereiken.

/door