Har du någonsin sett ett e-postmeddelande misslyckas SPF? Om du har det, ska jag berätta exakt varför SPF-autentisering misslyckas. Sender Policy Framework, eller SPF, är en av de e-postverifieringsstandarder som vi alla har använt i åratal för att stoppa skräppost. Även om du inte var medveten om det, slår jag vad om att om jag kollade dina inloggningskontoinställningar för Facebook skulle det sannolikt visa dig "opt-in" till "endast e-post från vänner". Det är i själva verket samma sak som SPF.

Vad är SPF-autentisering?

SPF är ett protokoll för autentisering av e-post som används för att verifiera att avsändaren av e-postmeddelandet stämmer överens med sitt domännamn i fältet From: i meddelandet. Den avsändande MTA:n använder DNS för att fråga en förkonfigurerad lista över SPF-servrar för att kontrollera om den avsändande IP:n är auktoriserad att skicka e-post för den domänen. Det kan finnas inkonsekvenser i hur SPF-poster upprättas, vilket är avgörande för att förstå varför e-postmeddelanden kan misslyckas med SPF-verifieringen och vilken roll du kan spela för att se till att problem inte uppstår i din egen e-postmarknadsföring eller när du skickar marknadsföringskuponger via e-post för att vinna kunder.

Varför SPF-autentisering misslyckas : Ingen, Neutral, Hardfail, Softfail, TempError och PermError

SPF-autentiseringsfel kan inträffa på grund av följande orsaker:

Den mottagande MTA misslyckas med att hitta en SPF-post publicerad i din DNS
Du har flera SPF-poster publicerade i dns för samma domän
Dina IP-adresser har ändrat eller lagt till i sina IP-adresser som inte har uppdaterats i din SPF-post
Om du överskrider gränsen för 10 DNS-sökningar för SPF
Om du överskrider det maximala antalet tillåtna ogiltiga uppslagsgränsen på 2
Den förenklade SPF-postlängden överskrider gränsen på 255 SPF-tecken

Ovan följer olika scenarier för varför SPF-autentisering misslyckas. Du kan övervaka dina domäner med vår DMARC-analysator för att få rapporter om SPF-autentiseringsfel. När du har aktiverat DMARC-rapportering returnerar den mottagande MTA något av följande SPF-autentiseringsfelresultat för e-postmeddelandet beroende på orsaken till att din e-post misslyckades med SPF. Låt oss lära känna dem bättre:

Typer av SPF Fail Qualifiers

Följande är typer av SPF Fail kvalifikationsbeteckningar som alla läggs till som ett prefix före SPF Fail mekanismen:

"+" "Pass"
"-" "Underkänd"
"~" "Softfail"
"?" "Neutral"

Vilken betydelse har dessa? Om ditt e-postmeddelande misslyckas med SPF kan du välja hur strikt du vill att mottagarna ska hantera det. Du kan ange en kvalifikation för att "passera" meddelanden som inte klarar kontrollen (leverera dem), "misslyckas" med leveransen eller ta en "neutral" ståndpunkt (göra ingenting).

Fall 1: SPF Inget resultat returneras

I det första scenariot,- om den mottagande e-postservern utför en DNS-sökning och inte kan hitta domännamnet i DNS returneras inget resultat. Ingen returneras också om ingen SPF-post hittas i avsändarens DNS, vilket innebär att avsändaren inte har SPF-autentisering konfigurerad för den här domänen. I det här fallet misslyckas SPF-autentisering för dina e-postmeddelanden.

Generera din felfria SPF-post nu med vårt gratis SPF-skivgeneratorverktyg för att undvika detta.

Fall 2: SPF-neutralt resultat returneras

När du konfigurerar SPF för din domän, om du har fäst en ?all-mekanism på din SPF-post, betyder det att oavsett vad SPF-autentiseringen kontrollerar för dina utgående e-postmeddelanden, returnerar den mottagande MTA ett neutralt resultat. Detta händer eftersom när du har din SPF i neutralt läge anger du inte de IP-adresser som är auktoriserade att skicka e-postmeddelanden för din räkning och tillåter obehöriga IP-adresser att skicka dem också.

Fall 3: SPF Softfail Resultat

I likhet med SPF-neutral identifieras SPF softfail av ~all mekanism vilket innebär att den mottagande MTA skulle acceptera e-postmeddelandet och leverera det till mottagarens inkorg, men det skulle markeras som skräppost, om IP-adressen inte listas i SPF-posten som finns i DNS, vilket kan vara en anledning till att SPF-autentisering misslyckas för din e-post. Nedan ges ett exempel på SPF softfail:

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

Fall 4: SPF Hardfail Resultat

SPF hardfail, även känd som SPF-fel, är när mottagandet av MTA skulle ignorera e-postmeddelanden som kommer från någon sändande källa som inte finns med i din SPF-post. Vi rekommenderar att du konfigurerar SPF hardfail i din SPF-post, om du vill få skydd mot domänpersonifiering och e-postförfalskning. Nedan ges ett exempel på SPF hardfail:

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

Ärende 5: SPF TempError (tillfälligt fel i SPF)

En av de mycket vanliga och ofta ofarliga orsakerna till att SPF-autentiseringen misslyckas är SPF TempError (tillfälligt fel) som orsakas av ett DNS-fel som en DNS-timeout medan en SPF-autentiseringskontroll utförs av den mottagande MTA. Det är därför, precis som namnet antyder, vanligtvis ett tillfälligt fel som returnerar en 4xx-statuskod som kan orsaka tillfälligt SPF-fel, men ger ett SPF-passresultat när det provas igen senare.

Fall 6: SPF PermError (permanent SPF-fel)

Ett annat vanligt resultat som domänfel står inför är SPF PermError. Det är därför SPF-autentisering misslyckas i de flesta fall. Detta händer när din SPF-post ogiltigförklaras av den mottagande MTA. Det finns många anledningar till att SPF kan brytas och göras ogiltigt av MTA när dns-sökningar utfördes:

Överskrider uppslagsgränsen på 10 SPF
Felaktig syntax för SPF-post
Mer än en SPF-post för samma domän
Överskrider SPF-postlängdsgränsen på 255 tecken
Om din SPF-post inte är uppdaterad med ändringar som gjorts av dina EPS

Anmärkning: När en MTA utför en SPF-kontroll av ett e-postmeddelande frågar den DNS eller utför en DNS-sökning för att kontrollera om e-postkällan är äkta. Helst, i SPF får du högst 10 DNS-uppslag, vilket överskrider vilket kommer att misslyckas SPF och returnera ett PermError-resultat.

Hur kan dynamisk SPF-förenkling lösa SPF-permerror?

Till skillnad från de andra SPF-felen är SPF PermError mycket svårare och mer komplicerat att lösa. PowerSPF hjälper dig att enkelt mildra det med hjälp av automatisk SPF-förenkling. Det hjälper dig:

Håll dig under SPF:s hårda gräns
Optimera din SPF-post direkt
Förenkla din post till en enda include-sats
Se till att din SPF-post alltid uppdateras på ändringar som gjorts av dina EPS

Vill du testa om du har konfigurerat SPF korrekt för din domän? Prova vårt gratis SPF-skivuppslagsverktyg idag!

SPF finns i domänens DNS som en TXT-post med en rad mekanismer och modifieringar som står för specifika instruktioner. SPF all-mekanismen finns i den högra änden av en SPF-post, föregången av "-" eller "~". Låt oss ta en titt på vad skillnaden är mellan SPF-mekanismerna -all och ~all för att avgöra när du bör konfigurera dem.

SPF -all vs ~all

Både SPF-mekanismerna -all och ~all innebär att SPF-autentisering inte godkänns. På senare tid har majoriteten av e-postleverantörerna inte gjort någon skillnad mellan -all och ~all, och samma resultat returneras. Detta var dock inte fallet för några år sedan.

Hur fungerade SPF all (Softfail vs Fail) mekanismen före DMARC?

DMARC skapades långt efter det att SPF redan fanns på marknaden som standardprotokoll för autentisering av e-post. Vid denna tidpunkt fungerade SPF -all softfail mekanismen på följande sätt:

Låt oss anta att din SPF-post var:

v=spf1 include:spf.domain.com ~all (där ~all betyder SPF Softfail)

Mottagarens e-postserver skulle ha utfört en DNS-sökning för att fråga avsändarens DNS efter deras SPF-post. Om e-postmeddelandets domän för returvägen inte finns med i avsändarens post skulle den mottagande servern ha returnerat ett SPF-resultat "NOT PASS", men skulle ha levererat e-postmeddelandet. till mottagarens inkorg.

Låt oss nu anta att din SPF-post var:

v=spf1 include:spf.domain.com -all (där -all betyder SPF Fail)

Mottagarens e-postserver skulle ha utfört en DNS-sökning för att fråga avsändarens DNS efter deras SPF-post. Om e-postmeddelandets domän för returvägen inte finns med i avsändarens post skulle den mottagande servern ha returnerat ett SPF-resultat "NOT PASS", men i detta fall skulle e-postmeddelandet ha varit avvisats och inte levererats. till mottagarens inkorg.

Läs mer om historien om Sender Policy Framework.

Hur hanterar e-postleverantörer SPF -all vs ~all-mekanismen nu?

Du kan för närvarande använda SPF -all eller ~all för de flesta brevlådeoperatörer utan att behöva oroa dig för att legitima e-postmeddelanden inte kan levereras, kan det uppstå en situation där en server avvisar ditt e-postmeddelande om attributet -all används..

För att vara på den säkra sidan kan du undvika att använda SPF-mekanismen "Hard fail -all" när du skapar din SPF-post. Så här gör du:

Öppna PowerDMARC SPF-postgeneratorn för att börja skapa en post gratis
Efter att ha inkluderat IP-adresser och domäner för dina e-postavsändare rullar du ner till det sista avsnittet som är avsett för att instruera e-postserverns hur strikta de ska vara när de verifierar dina e-postmeddelanden.
Välj alternativet "Soft-fail" innan du trycker på knappen "Generate SPF Record".

Vad rekommenderar vi? SPF -all eller SPF ~all

Problem med leveransbarhet av e-postmeddelanden som rör SPF -all-mekanismen kan förekomma i mycket sällsynta fall. Detta är inte ett återkommande problem som du kommer att stöta på ofta. För att se till att du aldrig råkar ut för det här problemet kan du vidta följande åtgärder:

Konfigurera DMARC för din e-post och aktivera DMARC-rapportering.
Ställ in din DMARC-policy på övervakning och granska dina SPF-autentiseringsresultat noga för att upptäcka eventuella inkonsekvenser i e-postleveranserna.
Om allt är bra kan du använda -all-mekanismen i din SPF-post. Vi rekommenderar att du använder attributet hard fail eftersom det visar att du är säker på att din e-post är äkta, vilket kan öka din domäns rykte.

Om du är osäker på om du ska använda SPF -all kan du följa de här stegen:

Konfigurera en SPF-post med hjälp av ~all-mekanismen
Konfigurera DMARC för din e-post och aktivera DMARC-rapportering
Ställ in din DMARC-policy så att den avvisar

Felsökning av andra SPF-fel

När du använder online-verktyg kan du ofta stöta på "Ingen SPF-post hittad", vilket är ett vanligt fel som beror på att resultatet är noll när en server sökte efter din domäns SPF-post. Vi har en detaljerad artikel som handlar om detta problem och hjälper användare att lösa det. Klicka på den länkade texten för att få veta mer!

Om du har DMARC för din domän utöver SPF kommer e-postservrar att kontrollera din domäns DMARC-policy för att fastställa hur du vill att e-postmeddelanden som misslyckas med autentiseringen ska behandlas. Denna DMARC-policy avgör om din e-post levereras, sätts i karantän eller avvisas.

DMARC-avvisning hjälper till att skydda din domän mot en mängd olika personangrepp som spoofing, phishing och utpressningstrojaner.

Tag Archive for: SPF misslyckas

Varför misslyckas SPF-autentiseringen? Hur åtgärdar jag SPF-fel?