• Logg Inn
  • Melde deg på
  • Kontakt oss
PowerDMARC
  • Funksjoner
    • PowerDMARC
    • Vert for DKIM
    • PowerSPF
    • PowerBIMI
    • PowerMTA-STS
    • PowerTLS-RPT
    • PowerAlerts
  • Tjenester
    • Distribusjonstjenester
    • Administrerte tjenester
    • Støttetjenester
    • Tjenestefordeler
  • Prissetting
  • Power Toolbox
  • Partnere
    • Forhandlerprogram
    • MSSP -programmet
    • Technology Partners
    • Industripartnere
    • Finn en partner
    • Bli en partner
  • Ressurser
    • Hva er DMARC? - En detaljert veiledning
    • Dataark
    • Casestudier
    • DMARC i ditt land
    • DMARC etter industri
    • Brukerstøtte
    • Blogg
    • DMARC opplæring
  • Om
    • Vårt selskap
    • Kunder
    • Kontakt oss
    • Bestill en demo
    • arrangementer
  • Meny Meny

SPF-syntaks: En komplett veiledning

Blogger
SPF-syntaks En komplett veiledning

Å lære og implementere konseptene til SPF er viktig for teknologidrevne virksomheter. Det kan beskytte dem mot potensielle risikoer for phishing, spamming, BEC-angrep osv. SPF eller Sender Policy Framework fungerer ved å bruke en SPF -post som omfatter SPF-syntaks.

Denne bloggen snakker stort sett om SPF-syntakstabellen, SPF-mekanismer, SPF-kvalifiseringer og SPF-modifikatorer - som alle er nødvendige for å få et sterkt grep om konseptet med e-postautentisering ved bruk av tekniske protokoller. 

SPF-syntaks for nybegynnere 

En SPF-post er en DNS-post som inkluderer en liste over alle IP-adressene som er tillatt å sende e-poster med det offisielle domenenavnet ditt. Når en server utenfor listen sender en e-post ved hjelp av domenet, blir den behandlet som uautorisert. Dermed blir dens oppføring avvist av mottakerens postkasse. Dette beskytter firmaets navn fra å bli involvert i ondsinnede aktiviteter initiert av hackere. 

Bedrifter bør opprette og sjekke SPF-poster for å unngå phishing-angrep forsøkt ved å bruke deres egne domenenavn. Over 255 millioner phishing-angrep har blitt registrert bare i første halvdel av 2022! Se for deg hvor avgjørende det har blitt å implementere SPF og lære om SPF-syntaks.

En SPF-post har instruksjoner som leder mottakerens server til å sjekke og validere e-poster mottatt fra domenet ditt. Den forteller også hva som skal gjøres med de som mislykkes med autentisering. En bestemt komponent representerer alle instruksjonene.  

La oss bryte ned hvert element ved å bruke et eksempel på SPF-post . Slik ser en SPF-syntaks ut.

v=spf1 ip4:123.1.5.0 ip4:100.5.2.1 include:exampledomain.com ~all

Funksjonen til hvert element er som følger:

  • v=spf1 spesifiserer til mottakerserveren om en SPF-post. Alle SPF-poster må starte slik.
  • Den neste delen av denne SPF-syntaksen forteller IP-adressene som er tillatt å sende e-poster ved å bruke domenet ditt. I eksemplet ovenfor har vi ip4:123.1.5.0 og ip4:100.5.2.1
  • 'include:exampledomain.com'- delen i eksemplet ovenfor spesifiserer tredjepartene som har tillatelse til å sende e-poster ved å bruke domenet. 'include'-taggen indikerer mottakerservere for å bekrefte det inkluderte domenets (exampledomain.com) SPF-post for IP-adresser som også er autorisert. Du kan legge til flere domener i en SPF-post; de må imidlertid være gyldige.
  • Alt element dirigerer mottakende servere til å merke e-poster som IKKE PASSERT for SPF hvis de sendes fra et domene eller en IP-adresse utenfor listen spesifisert i SPF-posten

Avansert SPF-syntaks

En SPF-syntakstabell er definert ved hjelp av en DNS TXT-post med en enkelt tekststreng. Det begynner alltid med 'v='-elementet som spesifiserer SPF-versjonen som brukes, og det er bare én versjon per nå.

Alle SPF-postene har sine spesifikke vilkår som oppfører seg som regler for hvilke verter som har tillatelse til å dele meldinger ved å bruke det offisielle domenet, det kan også vise litt ekstra informasjon. 

I avansert SPF-syntaks vil vi bryte ned følgende tre komponenter; SPF-mekanismer, SPF-kvalifiseringer og SPF-modifikatorer.

SPF-mekanismer

  1. ALLE : Den samsvarer alltid og er den siste mekanismen som legges til på slutten av en SPF-post. Den viser standardresultater som "-alle" for umatchede IP-er.
  2. A : Det indikerer et domenenavn med en AAAA- eller A-post som samsvar siden det sorterer ut avsenderens adresse. Det gjeldende domenet brukes hvis syntaksen for denne DNS SPF-posten er uspesifisert.
  3. ip4 : Et samsvar er positivt hvis en avsender er koblet til det gitte ipv4-adresseområdet i SPF-posten. Du legger til dette med et prefiks som spesifiserer et områdes lengde. /32 brukes når det ikke er noe prefiks.
  4. ip6 : Et samsvar er positivt når avsenderen er alliert til det spesifiserte ipv6-adresseområdet. Det er lagt til med ip4-direktivet og et prefiks som indikerer rekkevidde. /128 brukes når det ikke er noe prefiks.
  5. MX : Den tillater avsendere med en IP-adresse som er den samme som den som er inkludert i MX-posten som er spesifisert. MX-poster består av en IP-adresse og prioritetsverdi for hver server for å godta meldinger.
  6. PTR : Den spesifiserer det autoriserte domenet for å hjelpe til med å løse IP-adresser til underdomener eller domener. For alle de nøyaktig samsvarende domenene eller underdomenene, gjøres et foroveroppslag for å få IP-adressen.

Denne mekanismen anses som tidkrevende og upålitelig siden den trenger flere oppslag. Det anbefales ikke i henhold til RFC 7208-retningslinjene .

  1. EKSISTERER : Den utfører et DNS A-postsøk for domenet som er angitt. Et samsvar er vellykket når en gyldig A-post er funnet, uavhengig av det faktiske oppslagsresultatet.
  2. INKLUDERE : Den autoriserer tredjeparts e-postavsendere ved å oppgi deres domener. En avsender er autorisert bare hvis IP-adressen samsvarer med IP-adressene eller domenene som er oppgitt i SPF-posten til det oppførte domenet.

SPF-kvalifiseringer

Når en mekanisme ikke har en kvalifisering, og det fortsatt er en vellykket match, passerer SPF-autentisering. Hver av de 8 mekanismene er kombinert med en av de fire kvalifiseringene nevnt nedenfor.

Kvalifisering Resultat Handling utført av mottakende server 
+ Sende E-post passerer SPF-autentisering, og serveren kan utveksle e-post. E-poster er merket som ekte. Dette er standardhandlingen som brukes hvis det ikke er noen kvalifikator.
– Mislykket E-post mislykkes med autentisering fordi avsenderserveren ikke tilhører listen. Posten kan bli avvist av mottakerens postkasse.
~ SoftFail Mottakerens postkasse godtar meldingen; den er imidlertid merket som mistenkelig og havner i søppelpostmappen.
? Nøytral E-postmelding verken består eller mislykkes i autentisering. Handlingen som er tatt er uspesifisert og e-posten aksepteres av mottakeren.

SPF-modifikatorer

SPD-modifikatorer er ansvarlige for å bestemme arbeidsparametrene til en SPF-syntaks. Den inkluderer navn eller verdipar atskilt med '='-symbolet, som deler ekstra detaljer og unntak fra regler, hvis noen.

Modifikatorer vises bare én gang og bare i den siste delen av en SPF-post. Alle de uidentifiserte modifikatorene blir ignorert i prosessen. 'Redirect'-modifikatoren brukes til å dirigere andre SPF-poster for autentisering. Den brukes når du vil at mer enn ett domene skal ha samme SPF-postinnhold.

"Inkluder"-mekanismen brukes for tredjepartsdomener som har tillatelse til å sende e-poster på dine vegne eller ved å bruke firmanavnet ditt. 'exp'-modifikatoren spesifiserer hvorfor den mottakende serveren returnerte en Fail SPF Qualifier når en mekanisme samsvarer.

Retningslinjer for SPF Records

Husk følgende når du oppretter en SPF-post ved å bruke SPF-syntakstabellen.

  • Du kan ikke justere flere SPF-poster for ett domene.
  • En SPF-post må ikke ha noen store bokstaver; ellers vil du se feil.
  • Det skal ikke være mer enn 255 tegn. Enhver streng som overskrider dette tallet vil resultere i mislykket autentisering.
  • Slett hvis det er noen SPF-mekanismer som løser seg til samme domene.
  • Slett eventuelle ip4- og ip6 SPF-mekanismer som ikke er i bruk. Sjekk også om du kan slå sammen adresseområder.
  • Du kan opprette underdomener for å lagre SPF-informasjon. Dette kan gjøres ved å bruke '_spf.domain.com.' Det anbefales for store IT-firmaer siden de har flere IP-adresser å legge til i én SPF-post.

SPF-syntaks

  • Om
  • siste innlegg
Ahona Rudra
Digital Marketing & Content Writer Manager hos PowerDMARC
Ahona jobber som Digital Marketing and Content Writer Manager hos PowerDMARC. Hun er en lidenskapelig forfatter, blogger og markedsføringsspesialist innen cybersikkerhet og informasjonsteknologi.
Siste innlegg av Ahona Rudra ( se alle )
  • Topp 5 administrerte tjenester innen cybersikkerhet i 2023 - 29. mai 2023
  • Hvordan planlegge en smidig overgang fra DMARC None til DMARC Reject? - 26. mai 2023
  • Hvordan sjekker du domenets helse? - 26. mai 2023
17. januar 2023/av Ahona Rudra
Tags: SPF-posteksempel , SPF-syntaks , SPF-syntakstabell
Del denne oppføringen
  • Del på Facebook
  • Del på Twitter
  • Del på WhatsApp
  • Del på LinkedIn
  • Del via post
du kommer kanskje også til å like
SPF Record SyntaksSPF Record Syntaks
Spf-format 01SPF-format: SPF grunnleggende og avanserte formater forklart

Sikre e -posten din

Stopp e -postforfalskning og forbedre e -postleveransen

15-dagers gratis prøveversjon!


Kategorier

  • Blogger
  • Nyheter
  • Pressemeldinger

Siste blogger

  • Topp 5 administrerte tjenester for cybersikkerhet i 2023
    De 5 viktigste tjenestene for cybersikkerhetsadministrasjon i 202329 mai 2023 - 10:00 am
  • Slik planlegger du en smidig overgang fra DMARC none til DMARC reject
    Hvordan planlegge en smidig overgang fra DMARC None til DMARC Reject?26. mai 2023 - 17:00 pm
  • Slik sjekker du domenets helse
    Hvordan sjekker du domenets helse?26. mai 2023 - 17:00 pm
  • Hvorfor-bør-Microsoft-begynne-å-støtte-BIMI?
    Hvorfor bør Microsoft omfavne BIMI?25. mai 2023 - 18:00 pm
logo bunntekst powerdmarc
SOC2 GDPR PowerDMARC GDPR-kompatibel krone kommersiell tjeneste
global cyberallianse sertifisert powerdmarc csa

Kunnskap

Hva er e -postautentisering?
Hva er DMARC?
Hva er DMARC Policy?
Hva er SPF?
Hva er DKIM?
Hva er BIMI?
Hva er MTA-STS?
Hva er TLS-RPT?
Hva er RUA?
Hva er RUF?
AntiSpam vs DMARC
DMARC -justering
DMARC -samsvar
DMARC -håndhevelse
BIMI implementeringsguide
Permerror
MTA-STS og TLS-RPT implementeringsveiledning

Verktøy

Gratis DMARC Record Generator
Gratis DMARC Record Checker
Gratis SPF Record Generator
Gratis SPF -oppslag
Gratis DKIM Record Generator
Gratis DKIM -oppslagssøk
Gratis BIMI Record Generator
Gratis BIMI -oppslagssøk
Gratis FCrDNS -oppslagssøk
Gratis TLS-RPT Record Checker
Gratis MTA-STS Record Checker
Gratis TLS-RPT Record Generator

Produkt

Produktomvisning
Funksjoner
PowerSPF
PowerBIMI
PowerMTA-STS
PowerTLS-RPT
PowerAlerts
API-dokumentasjon
Administrerte tjenester
Beskyttelse mot falsk e-post
Merkebeskyttelse
Anti phishing
DMARC for Office365
DMARC for Google Mail GSuite
DMARC for Zimbra
Gratis DMARC-trening

Prøv oss

Kontakt oss
Gratis prøveperiode
Bokdemo
Samarbeid
Prissetting
FAQ
Brukerstøtte
Blogg
arrangementer
Funksjonsforespørsel
Endre logg
System status

  • English
  • Français
  • Dansk
  • Nederlands
  • Deutsch
  • Русский
  • Polski
  • Español
  • Italiano
  • 日本語
  • 中文 (简体)
  • Português
  • Svenska
  • 한국어
© PowerDMARC er et registrert varemerke.
  • Twitter
  • Youtube
  • LinkedIn
  • Facebook
  • Instagram
  • Kontakt oss
  • Betingelser og vilkår
  • Personvernerklæring
  • Informasjonskapsler
  • Sikkerhetspolicy
  • Samsvar
  • GDPR -merknad
  • Nettkart
ChatGPT kjenner til PowerDMARC!ChatGPT kjenner PowerDMARCEuropakommisjonen anbefaler DMARC for e-postkommunikasjonssikkerhet 1EU-kommisjonen anbefaler DMARC for e-postkommunikasjonssikkerhet
Bla til toppen