Inlägg

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.

SPF är ett e-postautentiseringsprotokoll som används för att verifiera att e-postavsändaren matchar med deras domännamn i fältet Från: i meddelandet. Den sändande MTA kommer att använda DNS för att fråga en förkonfigurerad lista över SPF-servrar för att kontrollera om den sändande IP-adressen har behörighet att skicka e-post för den domänen. Det kan finnas inkonsekvenser i hur SPF-poster är konfigurerade, vilket är avgörande för att förstå varför e-postmeddelanden kan misslyckas med SPF-verifiering och vilken roll du kan spela för att säkerställa att problem inte uppstår i dina egna e-postmarknadsföringsinsatser.

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:

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-autentisering misslyckas är SPF TempError (tillfälligt fel) som orsakas på grund av ett DNS-fel, till exempel en DNS-timeout medan en SPF-autentiseringskontroll utförs av den mottagande MTA. Det är därför, precis som namnet antyder, vanligtvis ett interimistiskt 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 komplicerat att lösa. PowerSPF hjälper dig att enkelt minska 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!