Innlegg

Hvorfor mislykkes SPF -godkjenning? Hvordan fikse SPF -feil?

Har du noen gang sett en e -postfeil SPF? Hvis du har det, skal jeg fortelle deg nøyaktig hvorfor SPF -autentisering mislykkes. Sender Policy Framework, eller SPF, er en av standardene for e -postbekreftelse vi alle har brukt i årevis for å stoppe spam. Selv om du ikke var klar over det, vil jeg satse på at hvis jeg sjekket innstillingene for påloggingskontoen din for Facebook, ville det sannsynligvis vise deg "melde deg på" bare "e-post fra venner". Det er faktisk det samme som SPF.

Hva er SPF-autentisering?

SPF er en e-postautentiseringsprotokoll som brukes til å verifisere at e-postavsenderen samsvarer med domenenavnet i Fra: -feltet i meldingen. Den avsendende MTA-en vil bruke DNS til å søke i en forhåndskonfigurert liste over SPF-servere for å sjekke om den avsendende IP-adressen er autorisert til å sende e-post for det aktuelle domenet. Det kan være inkonsekvenser i hvordan SPF-poster er satt opp, noe som er avgjørende for å forstå hvorfor e-poster kan mislykkes i SPF-verifisering, og hvilken rolle du kan spille for å sikre at det ikke oppstår problemer i din egen e-postmarkedsføring eller når du sender markedsføringskuponger via e-post for å vinne kunder.

Hvorfor SPF -godkjenning mislykkes: Ingen, nøytral, hardfail, softfail, TempError og PermError

SPF -autentiseringsfeil kan skje på grunn av følgende årsaker:

  • Mottakende MTA finner ikke en SPF -post publisert i DNS
  • Du har flere SPF -poster publisert på DNS for det samme domenet
  • ESP -ene dine har endret eller lagt til IP -adressene sine som ikke er oppdatert i SPF -posten
  • Hvis du overskrider grensen for 10 DNS -oppslag for SPF
  • Hvis du overskrider det maksimale antallet tillatte grenser for tomromsoppslag på 2
  • Lengden på din SPF -rekord overskrider grensen på 255 SPF -tegn

Gitt ovenfor er forskjellige scenarier for hvorfor SPF -autentisering mislykkes. Du kan overvåke domenene dine med DMARC -analysatoren vår for å få rapporter om SPF -autentiseringsfeil. Når du har aktivert DMARC -rapportering, returnerer mottakende MTA et av følgende SPF -autentiseringsfeilresultater for e -posten, avhengig av årsaken til at e -posten din mislyktes i SPF. La oss bli bedre kjent med dem:

Typer SPF Fail-kvalifiseringer

Følgende er typer SPF Fail-kvalifiseringer som hver er lagt til som et prefiks før SPF-feilmekanismen:

"+" "Pass"
"-" "Feil"
“~” “Softfail”
"?" "Nøytral"

Hvilken betydning har disse? I en situasjon som e-posten din mislykkes med SPF, kan du velge hvor strengt du vil at mottakerne skal håndtere den. Du kan spesifisere en kvalifisator for å "bestå" meldinger som ikke sjekker (leverer dem), "Feilte" levering, eller ta et "nøytralt" standpunkt (ikke gjør noe).

Sak 1: SPF Ingen resultat returneres

I det første tilfellet,- hvis den mottakende e-postserveren utfører et DNS-oppslag og ikke finner domenenavnet i DNS, returneres et resultat uten noe. Ingen returneres også hvis ingen SPF -post finnes i avsenderens DNS, noe som betyr at avsenderen ikke har SPF -godkjenning konfigurert for dette domenet. I dette tilfellet mislykkes SPF -autentisering for e -postene dine.

Generer din feilfrie SPF-post nå med vårt gratis SPF-postgeneratorverktøy for å unngå dette.

Sak 2: SPF -nøytralt resultat returneres

Når du konfigurerer SPF for domenet ditt, betyr dette at uansett hva SPF -autentiseringen sjekker for utgående e -poster, vil mottakende MTA returnere et nøytralt resultat. Dette skjer fordi når du har SPF i nøytral modus, angir du ikke IP -adressene som er autorisert til å sende e -post på dine vegne og lar uautoriserte IP -adresser også sende dem.

Sak 3: SPF Softfail -resultat

I likhet med SPF -nøytral, er SPF softfail identifisert av ~ all mekanisme som innebærer at den mottakende MTA ville godta e -posten og levere den i innboksen til mottakeren, men den vil bli merket som spam, i tilfelle IP -adressen ikke er oppført i SPF -posten som finnes i DNS, noe som kan være en grunn til at SPF -autentisering mislykkes for e -posten din. Nedenfor er et eksempel på SPF softfail:

 v = spf1 inkluderer: spf.google.com ~ alt

Sak 4: SPF Hardfail -resultat

SPF -hardfail, også kjent som SPF -feil, er når mottak av MTA -er vil forkaste e -postmeldinger som stammer fra en hvilken som helst sendekilde som ikke er oppført i SPF -posten. Vi anbefaler deg å konfigurere SPF hardfail i SPF -posten din hvis du vil oppnå beskyttelse mot etterligning av domener og e -postforfalskning. Nedenfor er et eksempel på SPF hardfail:

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

Sak 5: SPF TempError (SPF midlertidig feil)

En av de svært vanlige og ofte ufarlige årsakene til at SPF-autentisering mislykkes, er SPF TempError (midlertidig feil) som skyldes en DNS-feil som en DNS-tidsavbrudd mens en SPF-autentiseringssjekk utføres av den mottakende MTA. Det er derfor, akkurat som navnet antyder, vanligvis en midlertidig feil som returnerer en 4xx-statuskode som kan forårsake midlertidig SPF-feil, men som gir et SPF-passresultat når det prøves på nytt senere.

Sak 6: SPF PermError (SPF Permanent Error)

Et annet vanlig resultat som domenefeil står overfor er SPF PermError. Dette er grunnen til at SPF -autentisering mislykkes i de fleste tilfelle. Dette skjer når SPF -posten blir ugyldiggjort av den mottakende MTA. Det er mange grunner til at SPF kan brytes og bli ugyldig av MTA mens du utfører DNS -oppslag:

  • Overskrider grensen for oppslag på 10 SPF
  • Feil SPF -postsyntaks
  • Mer enn én SPF -post for samme domene
  • Overskrider SPF -rekordlengden på 255 tegn
  • Hvis SPF -posten din ikke er oppdatert med endringer gjort av ESP -ene

Merk: Når en MTA utfører en SPF -sjekk på en e -post, spør den etter DNS eller utfører et DNS -oppslag for å sjekke ektheten til e -postkilden. Ideelt sett har du maksimalt 10 DNS -oppslag i SPF, som overskrider SPF og returnerer et PermError -resultat.

Hvordan kan Dynamic SPF Flattening løse SPF PermError?

I motsetning til de andre SPF-feilene, er SPF PermError mye mer vanskelig og komplisert å løse. PowerSPF hjelper deg med å dempe det enkelt ved hjelp av automatisk SPF-utflatning . Det hjelper deg:

  • Hold deg under SPF -grensen
  • Optimaliser SPF -oppføringen din umiddelbart
  • Flat ut posten din til en enkelt setning
  • Sørg for at SPF -posten din alltid er oppdatert om endringer gjort av ESP -ene

Vil du teste om du har SPF konfigurert riktig for domenet ditt? Prøv vårt gratis SPF -oppslagsverktøy i dag!

/av

Forskjellen mellom SPF -all og SPF ~all | SPF -alle vs ~alle

SPF finnes i domenets DNS som en TXT-post med en rekke mekanismer og modifikatorer som står for spesifikke instruksjoner. SPF all-mekanismen er til stede i høyre ende av en SPF-post, innledet med "-" eller "~". La oss ta en titt på hva forskjellen er mellom SPF -all og ~all mekanismene for å bestemme når du bør konfigurere dem.

SPF -alle vs ~alle

Både SPF -all og ~all mekanismene betyr "NOT PASS" for SPF-autentisering. I nyere tid, for et flertall av e-posttjenesteleverandører, er det ingen forskjell mellom -all og ~all-mekanismen, og det samme resultatet returneres. Slik var det imidlertid ikke for noen år siden.

Hvordan fungerte SPF all (Softfail vs Fail)-mekanismen før DMARC?

DMARC ble opprettet lenge etter at SPF allerede hadde vært på markedet som standard e-postautentiseringsprotokoll. På dette tidspunktet fungerte SPF-all softfail-mekanismen på følgende måte: 

La oss anta at SPF-posten din var: 

v=spf1 include:spf.domain.com ~all (der ~all betyr SPF Softfail)

Mottakerens e-postserver ville ha utført et DNS-oppslag for å spørre avsenderens DNS for deres SPF-post. Hvis e-postens returbanedomene ikke var oppført i avsenderens post, ville mottaksserveren ha returnert et SPF "NOT PASS"-resultat, men ville ha levert e-posten til mottakerens innboks.

La oss nå anta at SPF-posten din var: 

v=spf1 include:spf.domain.com -all (der -all betyr SPF Fail)

Mottakerens e-postserver ville ha utført et DNS-oppslag for å spørre avsenderens DNS for deres SPF-post. Hvis e-postens returbanedomene ikke var oppført i avsenderens post, ville mottakerserveren ha returnert et SPF "NOT PASS"-resultat, men i dette tilfellet ville e-posten blitt avvist og ikke levert til mottakerens innboks.

Les mer om historien til Sender Policy Framework . 

Hvordan håndterer e-posttjenesteleverandører SPF -all vs ~all-mekanismen nå?

Mens du står fritt til å bruke SPF -all eller ~all for de fleste postboksleverandører for øyeblikket uten å måtte bekymre deg for leveringsfeil for legitime e-poster, kan det oppstå en situasjon der en server avviser e-posten din i tilfelle -all-attributtet .

Bare for å være på den sikre siden, kan du unngå å bruke SPF hard fail-all-mekanismen mens du oppretter SPF-posten. Slik gjør du:

  • Åpne PowerDMARC SPF- postgeneratoren for å begynne å lage en post gratis
  • Etter å ha inkludert IP-adressene og domenene eller e-postsenderne dine, bla ned til den siste delen som er utpekt for å instruere e-postserveren hvor strenge de skal være mens de bekrefter e-postene dine
  • Velg alternativet "Soft-fail" før du trykker på "Generer SPF Record"-knappen

Hva anbefaler vi? SPF -alle eller SPF ~alle

Problemer med levering av e-post knyttet til SPF-all-mekanismen kan oppstå i svært sjeldne tilfeller. Dette er ikke et tilbakevendende problem som du vil støte på ofte. For å sikre at du aldri støter på dette problemet, kan du gjøre følgende:

  • Konfigurer DMARC for e-postene dine, og aktiver DMARC-rapportering
  • Angi DMARC-policyen din til å overvåke og inspisere SPF-autentiseringsresultatene dine nøye for å oppdage eventuelle inkonsekvenser i e-postleveransen
  • Hvis alt er bra, kan du bruke -all-mekanismen i SPF-posten din. Vi anbefaler å bruke hard fail-attributtet siden det bekrefter at du er trygg på ektheten til e-postene dine, noe som kan øke domenets omdømme

Hvis du er usikker på om du bruker SPF -all, kan du følge disse trinnene:

  • Sett opp en SPF-post ved å bruke ~all-mekanismen
  • Konfigurer DMARC for e-postene dine, og aktiver DMARC-rapportering
  • Angi DMARC-policyen din til å avvise

Feilsøking av andre SPF-feil

Når du bruker nettbaserte verktøy, kan du ofte komme over meldingen " No SPF record found " som er en vanlig feiltilstand som oppstår fra et nullresultat som returneres når en server så opp domenets SPF-post. Vi har dekket en artikkel i detalj som snakker om dette problemet og hjelper brukere med å løse det. Klikk på den lenkede teksten for å vite mer!

Hvis du har DMARC på plass for domenet ditt på toppen av SPF, vil e-postservere sjekke domenets DMARC-policy for å fastslå hvordan du vil at e-poster som mislykkes med autentisering skal behandles. Disse retningslinjene for DMARC avgjør om e-postene dine blir levert, satt i karantene eller avvist. 

DMARC-avvisning hjelper til med å beskytte domenet ditt mot en rekke etterligningsangrep som forfalskning, phishing og løsepengeprogramvare.

/av

Hvordan fikser "SPF Softfail-domene utpeker ikke IP som tillatt avsender"?

Hvis bedriften din bruker sine egne domener og domenehåndteringsposter, er det store sjanser for at de får e-postproblemer og har kommet over feilen "SPF Softfail Domain Does Not Designate IP as Permitted Sender". Det er avgjørende at selskaper på riktig måte angir IP-adressene som brukes til å sende ut e-poster på deres vegne, som en tillatt avsender i SPF-posten.

Hva er SPF?

SPF eller Sender Policy Framework er en standard for e-postautentisering som beskytter organisasjoner mot etterligning. En angriper kan bruke et selskaps domene og merkenavn for å sende falske meldinger til kundene sine. Disse phishing-e-postene virker autentiske nok til å overbevise kundene og få dem til å falle for en internettsvindel i selskapets navn. Dette vil skade et selskaps merkevaretroverdighet og skade dets offentlige image. SPF kan tenkes som en sikker liste over pålitelige domener til et selskap hvor autentisk kommunikasjon kan komme fra.

Hvordan sjekke om domenet ditt er en tillatt avsender?

Det første trinnet for å løse feilen " SPF Softfail Domain Does Not Designate IP as Permitted Sender" er å sjekke avsenderautoriteten din. Å gjøre slik:

Trinn 1 : Logg inn på selskapets domenes e-postkonto, la oss si [email protected]

Trinn 2 : Send en e-post til en annen e-postkonto som du har tilgang til; dette kan være til et eksternt domene som Gmail, Yahoo, Hotmail eller andre.

Trinn 3 : Logg på e-postkontoen du sendte den første e-posten til, og se overskriftene til denne e-posten. Den vil bli merket som "Vis original".

Da vil du se noe som ligner på dette. Legg merke til SPF Softfail-meldingen.

-Opprinnelig melding -

X-mottatt: …

Lørdag 13. mars 2022 11:01:19 IST

Retursti: [email protected]

Mottatt: fra mymy2.spfrecords.com (mymy2.spfrecords.com [60.130.71.223])

av mx.google.com med ESMTPS-ID 

*id*

For [email protected]

Mottatt SPF: softfail (google.com: domain of transitioning [email protected] angir ikke 60.130.71.223 som tillatt avsender) client-ip=60.130.71.223; 

Autentiseringsresultater: mx.google.com;

Spf = softfail (google.com: domain of transitioning [email protected] angir ikke 60.130.71.223 som tillatt avsender) client-ip=60.130.71.223; 

*slutt på overskriftsmelding

Merk : Hvis du observerte "Received-SPF: pass" i overskriften, er domenet du bruker til å sende e-postene autentisert og er allerede lagt til i SPF-posten din, og du har ikke noe å bekymre deg for. Som vist ovenfor er det imidlertid et softfail-problem. Vi skal nå se på hvordan vi kan løse det samme.

Hva betyr "SPF Softfail-domene utpeker ikke IP som tillatt avsender"?

E-postavsenderen din har en verts -IP som ser omtrent slik ut:

30.10.323.005

Hvis denne IP-adressen for avsenderdomenet ikke er inkludert i domenets SPF-post, klarer ikke e-postmottaksserveren å identifisere den angitte IP-en som en tillatt avsender. Serveren tolker automatisk meldingen til å komme fra en uautorisert kilde. Dette er en mulig årsak til at SPF mislyktes for meldingen. Det gir en høy sannsynlighet for DMARC-feil hvis e-postautentiseringssystemet utelukkende er avhengig av SPF for kildeverifisering (og ikke DKIM). 

Under slike omstendigheter, hvis protokollpolicyen din er satt til å avvise, vil meldingen din aldri bli levert! Derfor må domeneeieren ta raske og handlingsrettede tiltak for å fikse problemet "SPF Softfail Domain Does Not Designate IP as Permitted Sender".

Hvordan inkludere en IP som tillatt avsender for SPF?

Løsningen for dette kan deles inn i følgende trinn: 

1. Lag en liste over sendekilder for domenet ditt. Du kan bruke en liste over e-postadresser basert på domenet ditt, samt tredjeparts sendekilder for e-posttransaksjoner.

2. Identifiser nå verts-IP-ene til disse sendekildene 

Hvordan finne IP-adresser knyttet til kildene for e-postsending?

Det er ganske enkelt! For å finne IP-adressen til kilden du sender, åpne e-posten og se hele e-postoverskriften. For å gjøre det må du klikke på de tre prikkene øverst til høyre i e-posten for å se rullegardinmenyen og velge " Vis original ".

På den opprinnelige meldingen, bla ned til Mottatt -linjen, vil du kunne se verts-IP-adressen til den opprinnelige avsenderen, som vist nedenfor:

3. Bruk vår SPF Record Generator til å generere en gratis SPF-post for ditt domene.

  • I postgeneratoren legger du til alle IP-adressene du ønsker skal autentiseres for å sende e-post og kommunikasjon på vegne av selskapet.
  • Legg til eventuelle tredjepartsservere eller eksterne leveringstjenester som en autorisert sendekilde for domenet ditt. På denne måten vil alle e-poster som sendes via tredjepartsservere også bestå SPF-autentiseringen.

4. Når du har brukt SPF Record Generator til å generere SPF Record for domenet ditt med alle de pålitelige domenene og IP-adressene lagt til, er det bare å implementere SPF ved å publisere den på DNS. Slik kan du oppnå det:

  • Logg på DNS Management Console
  • Deretter går du til det valgte domenet (domenet du prøver å legge til/endre SPF-posten for)
  • Spesifiser ressurstypen din som 'TXT'
  • Angi vertsnavnet som "_spf"
  • Lim inn verdien på den genererte SPF -posten din 
  • Lagre endringer for å konfigurere SPF for domenet ditt

Merk : Navnene eller overskriftene ovenfor kan variere basert på DNS-administrasjonskonsollen du bruker for bedriften din .

På denne måten kan domeneeierne sikre at alle deres pålitelige IP-adresser og domener de kan bruke til å sende kommunikasjon på vegne av selskapet blir lagt til serveren, og en lignende feil der SPF Softfail Domain ikke utpeker IP som den tillatte avsenderen vil ikke forekomme. 

Hvordan bruke SPF-standarden effektivt?

Den eneste måten å styrke et selskaps SPF-teknologi på er å inkorporere den med DMARC . Her er fordelene ved å gjøre dette,

1. DMARC = SPF + DKIM

E-postautentiseringsprotokoller som DMARC konfigureres ved å legge til en TXT-post til DNS. Bortsett fra å konfigurere en policy for domenets e-poster, kan du også utnytte DMARC for å aktivere en rapporteringsmekanisme for å sende deg et vell av informasjon om domenene, leverandørene og e-postkildene dine.

DMARC kan hjelpe deg å bruke både SPF (Sender Policy Framework) og DKIM (DomainKeys Identified Mail) teknologier i tandem for å gi domenet ditt enda bedre beskyttelse mot spoofing.

Merk : Dette anbefales, men ikke obligatorisk. DMARC kan fungere med enten SPF- eller DKIM-identifikatorjustering.

2. Rapportering og tilbakemelding med PowerDMARC

Verken SPF eller DKIM gir domeneeieren tilbakemelding om e-poster som mislykkes med autentisering. DMARC sender detaljerte rapporter direkte til deg, som PowerDMARC-plattformen konverterer til lettleste diagrammer og tabeller.

3. Kontroller hva som skjer med uautentiserte e-poster 

DMARC lar deg, domeneeieren, bestemme om en e-post som mislykkes ved validering går til innboks, spam eller blir avvist. Med PowerDMARC er alt du trenger å gjøre å klikke på én knapp for å angi DMARC-policyen din, og det er så enkelt.

Uautoriserte avsendere kan være en farlig trussel mot sikkerheten til kundene dine og bedriftens image og merkeverdi. Beskytt kundene dine mot nettfisking og svindel ved å innlemme DMARC i bedriften din, og la bare e-poster fra autentiserte avsendere nå dem.

/av