• Log på
  • Tilmeld dig
  • Kontakt os
PowerDMARC
  • Funktioner
    • PowerDMARC
    • Hosting af DKIM
    • PowerSPF
    • PowerBIMI
    • PowerMTA-STS
    • PowerTLS-RPT
    • PowerAlerts
  • Tjenester
    • Installationstjenester
    • Administrerede tjenester
    • Supporttjenester
    • Servicefordele
  • Prissætning
  • Power Toolbox
  • Partnere
    • Forhandlerprogram
    • MSSP-program
    • Teknologipartnere
    • Branchepartnere
    • Find en partner
    • Bliv partner
  • Ressourcer
    • Hvad er DMARC? - En detaljeret vejledning
    • Dataark
    • Casestudier
    • DMARC i dit land
    • DMARC efter industri
    • Støtte
    • Blog
    • DMARC-uddannelse
  • Om
    • Vores virksomhed
    • Klienter
    • Kontakt os
    • Bestil en demo
    • Begivenheder
  • Menuen Menu

Almindelige fejl, der skal undgås ved konfigurering af SPF-indstillinger

Blogs
Almindelige fejl, der skal undgås ved konfigurering af SPF-indstillinger

SPF validering er vigtig for at opnå en bedre leveringsgrad af e-mail og for at beskytte dit domæne mod phishing og spam angreb. Men SPF-indstillingerne er komplicerede, og du kan gå galt i byen, når du konfigurerer dem. Ved at rette og undgå disse almindelige fejl kan du sikre, at der ikke forekommer falske positive resultater og DMARC overholdelser korrekt til dit e-mail-afsendende domæne.

7 almindelige fejl, som du skal undgå, når du konfigurerer SPF-indstillinger

Nogle DNS-mekanismer bruges til at angive IP-adresser for systemer, der har tilladelse til at sende e-mails med en returadresse. Men forkert brug af dem medfører fejl som f.eks. overskridelse af SPF-recordens størrelse, mere end 10 DNS-opslag, mere end 2 uafklarede DNS-opslag osv.

Vi har listet almindelige SPF-fejl for at hjælpe dig med at undgå dem, når du konfigurerer SPF-indstillingerne.

Fejl 1: Flere SPF-poster

Der skal være én SPF-post pr. domæne, da modtagende servere ellers vil afvise begge. Fjern SPF-poster, som ikke er i brug i øjeblikket, f.eks. forældede tjenester med aktive SPF-poster.

Du kan løse denne SPF-indstillingsfejl ved at slå to eller flere poster sammen til én. Lad os sige, at et brugerdomæne har en SPF-record og indeholder en Elastic Email SPF-post, men at den ikke består verifikationskontrollen. Den mulige årsag til dette er, at der er 2 poster til stede på domænet. 

v=spf1 a mx include:_sampledomain1.com include:_spf.elasticemail.com ~all

v=spf1 a mx include:_sampledomain2.com ~all

Du kan løse dette problem ved at samle dem i en enkelt post på følgende måde:

v=spf1 a mx include:_sampledomain1.com include:_sampledomain2.com include:_spf.elasticemail.com ~all

Fejltagelse 2: For mange DNS-søgninger

Der er en grænse på 10 "include"-opslag, hvilket betyder, at du ikke kan generere mere end 10 henvisninger til andre domæner. Hver forekomst af parametrene "include", "a", "mx", "ptr", "exists" og "redirect" genererer et opslag. Hvis et domæne, der henvises til i en 'include' indeholder en anden parameter, vil det også blive talt med i grænsen på 10 opslag. Så overskridelse af opslagsgrænsen er en af de mest almindelige fejl, der sker under konfigurering af SPF-indstillinger.

Du kan rette dette ved at fjerne 'indeholder' og henvisninger til inaktive domæner.

Fejltagelse 3: Tilladelsesfuld alle Mekanisme

En SPF-post fortolkes fra venstre mod højre, og 'alle' mekanisme vil matche 'all' afsendere, der ikke matchede de foregående mekanismer. Det foreslås at placere 'all' mekanismen i slutningen af din SPF-record og bruge den med præfikset ~ (softfail) eller - (fail). Når der ikke er angivet noget præfiks, bruges + (pass) som standard.

Fejltagelse 4: Brug af ptr mekanisme

SPF 'ptr' mekanismen bruges til omvendt DNS-søgning, der returnerer værtsnavnet til den tilsvarende IP-adresse. Disse oplysninger er især nyttige for B2B-mærker. Men denne mekanisme har problemer med pålideligheden og belaster de omvendte DNS-servere og de e-mail-systemer, der er forbundet med dem.

Det er derfor, at RFC7208 fraråder brugen af 'ptr' mekanisme. I de fleste tilfælde kan du erstatte den med 'a' mekanisme.

Fejltagelse 5: Brug af mx Mekanisme

Brug 'mx' med domænenavne og ikke med navnene på mailservere. Angivelse af mx:mailserver.sample.com anses for at være forkert, medmindre du faktisk kræver SPF-validering for at finde alle de værter, der accepterer post for domænet "mailserver.sample.com". I de fleste tilfælde vil der ikke være nogen sådanne værter, da "mailserver.sample.com" i sig selv er en vært og ikke et domæne.

Du vil ikke støde på dette som en syntaksfejl, men det vil ikke bare matche noget som helst.

Den korrekte måde at validere mod MX-posten for "sample.com" er mx:sample.com. Når du skal definere en bestemt mailservers værtsnavn eller IP-adresse, a:mailserver.sample.com eller ip4:x.x.x.x.x skal bruges

Fejltagelse 6: Oprettelse af en SPF-optegnelse uden ordentlig research

Dette gælder især for internetudbydere. Du må ikke oprette poster med halve oplysninger om domænet, dets ejer og det mærke, som det tilhører. Undersøg, hvilken e-mail-server de bruger, ellers kan du ende med at blokere deres udgående e-mail-leveringsvej fra deres mailserver på kontoret.

Fejltagelse 7: slåfejl

Undgå at begå almindelige fejl ved at konfigurere SPF-indstillinger ved at dobbelttjekke SPF-rekordet for stavefejl. Du kan skrive "inlcude" i stedet for "include". Dette kan gøre hele posten ugyldig.

Fejl 8: Du offentliggør ikke SPF-poster for HELO-navne, der bruges af dine e-mail-servere

Verifying HELO or EHLO names is encouraged by the SPF RFC. HELO or its developed version EHLO is used when Mail from is <> despite the recipient’s failure in doing 100% HELO checking.

Offentliggørelse af en HELO-protokol omfatter generering af en SPF-post, der svarer til det HELO FQDN, som din mailserver bruger. For eksempel: mailserver.sample1.com

Generelt skal det være en helt anden SPF-regel end den, der kontrollerer From-adressen i dit domæne, der er knyttet til "sample1.com".

Fejl 9: TXT-optegnelsens indhold vises ikke med dobbelte anførselstegn

Indholdet af en DNS TXT-post er altid inden for dobbelte anførselstegn ("-"), men disse bør aldrig være en del af selve indholdet af DNS-posten. Disse anførselstegn er kun til visningsformål, da de hjælper med at adskille starten og slutningen af indholdet af en TXT-record.

En SPF-post skal begynde med v=spf1 men hvis den begynder med "v=spf1bliver den slet ikke genkendt.

Stadig et problem?

Enhver ændring i SPF-indstillingerne kræver noget tid at sprede sig gennem internettet. Det kan også tage op til 72 timer. Men hvis du stadig har problemer, kan du bruge vores gratis SPF-record-checker værktøj eller kontakt vores eksperthold på [email protected].

spf-indstillinger

  • Om
  • Seneste indlæg
Ahona Rudra
Manager for digital markedsføring og indholdsskribent hos PowerDMARC
Ahona arbejder som Digital Marketing and Content Writer Manager hos PowerDMARC. Hun er en passioneret forfatter, blogger og marketingspecialist inden for cybersikkerhed og informationsteknologi.
Nyeste indlæg af Ahona Rudra (se alle)
  • Top 5 over cybersikkerhedsadministrerede tjenester i 2023 - 29. maj 2023
  • Hvordan planlægger man en glidende overgang fra DMARC None til DMARC Reject? - 26. maj 2023
  • Hvordan tjekker du dit domænes sundhed? - 26. maj 2023
27. marts 2023/af Ahona Rudra
Tags: hvordan man optimerer spf-indstillinger, indstillinger SPF, spf record-indstillinger, spf-indstillinger, spf-indstillinger
Del denne post
  • Del på Facebook
  • Del på Twitter
  • Del på WhatsApp
  • Del på LinkedIn
  • Del efter mail

Beskyt din e-mail

Stop e-mail-spoofing, og forbedr e-mail-levering

15 dages gratis prøveperiode!


Kategorier

  • Blogs
  • Nyheder
  • Pressemeddelelser

Seneste Blogs

  • Top 5 over cybersikkerhedsadministrerede tjenester i 2023
    Top 5 over cybersikkerhedsadministrerede tjenester i 202329. maj, 2023 - 10:00 am
  • Sådan planlægger du en glidende overgang fra DMARC none til DMARC reject
    Hvordan planlægger man en glidende overgang fra DMARC None til DMARC Reject?26. maj 2023 - 5:00 pm
  • Sådan tjekker du domænets sundhed
    Hvordan tjekker du dit domænes sundhed?26. maj 2023 - 5:00 pm
  • Hvorfor-skal-Microsoft-starte-med-at-understøtte-BIMI?
    Hvorfor skal Microsoft omfavne BIMI?25. maj 2023 - 6:00 pm
logofod powerdmarc
SOC2 GDPR PowerDMARC GDPR-kompatibel Crown Commercial Service
global cyberalliance certificeret powerdmarc Csa

Viden

Hvad er e-mail-godkendelse?
Hvad er DMARC?
Hvad er DMARC-politik?
Hvad er SPF?
Hvad er DKIM?
Hvad er BIMI?
Hvad er MTA-STS?
Hvad er TLS-RPT?
Hvad er RUA?
Hvad er RUF?
AntiSpam mod DMARC
DMARC-justering
DMARC-overholdelse
Fuldbyrdelse af DMARC
BIMI Implementeringsvejledning
Permerror
MTA-STS implementeringsvejledning til TLS-RPT

Værktøjer

Gratis DMARC Record Generator
Gratis DMARC Record Checker
Gratis SPF Record Generator
Gratis opslag efter SPF-poster
Gratis DKIM Record Generator
Gratis opslag efter DKIM-poster
Gratis BIMI Record Generator
Gratis BIMI Record Opslag
Gratis opslag efter FCrDNS-poster
Gratis TLS-RPT Record Checker
Gratis MTA-STS Record Checker
Gratis TLS-RPT Record Generator

Produkt

Produkt rundvisning
Funktioner
PowerSPF
PowerBIMI
PowerMTA-STS
PowerTLS-RPT
PowerAlerts
API-dokumentation
Administrerede tjenester
Beskyttelse mod forfalskning af e-mail
Beskyttelse af mærker
Anti Phishing
DMARC til Office365
DMARC til Google Mail GSuite
DMARC til Zimbra
Gratis DMARC-uddannelse

Prøv os

Kontakt os
Gratis prøveperiode
Bestil demo
Partnerskab
Prisfastsættelse
FAQ
Support
Blog
Begivenheder
Anmodning om funktion
Logbog over ændringer
Systemstatus

  • English
  • Français
  • Nederlands
  • Deutsch
  • Русский
  • Polski
  • Español
  • Italiano
  • 日本語
  • 中文 (简体)
  • Português
  • Norsk
  • Svenska
  • 한국어
© PowerDMARC er et registreret varemærke.
  • Kvidre
  • Youtube
  • Linkedin
  • Facebook
  • Instagram
  • Kontakt os
  • Vilkår og betingelser
  • Politik om beskyttelse af personlige oplysninger
  • Cookie-politik
  • Sikkerhedspolitik
  • overholdelse
  • GDPR-meddelelse
  • Sitemap
Hvor let er det at forfalske e-mail?Hvor let er det at forfalske e-mail?Hvad er filløs malwareHvad er Fileless Malware?
Rul til toppen