Defaults.Exposed › Rettelser › SPF (Sender Policy Framework)

Sådan retter du SPF (Sender Policy Framework)

SPF er en enkelt linje i dit domænes indstillinger, der angiver hvilke mailtjenester der må sende e-mail på vegne af din virksomhed. Uden den kan hvem som helst i verden sende e-mail, der ser ud som om den kommer fra dig — og din ægte e-mail havner oftere i kundernes spam.

Det korte svar for din virksomhed: Kriminelle kan sende e-mail og udgive sig for at være din virksomhed — til dine kunder, medarbejdere og leverandører — med falske fakturaer, anmodninger om betalingsoplysninger og meget mere. Samtidig risikerer dine egne tilbud og fakturaer at ende i spam, så aftaler stille og roligt går i stå.

Hvad dette kan koste dig

En svindler sender din kunde en faktura 'fra dig' med sit eget kontonummer og får pengene. Du finder ud af det uger senere, når kunden spørger til sin ordre — nu er det dit omdømme og potentielt dit ansvar.
Dine tilbud, fakturaer og svar ender stille og roligt i kundernes spam, fordi store udbydere ikke kan verificere, at de virkelig kommer fra dig. Aftaler køler af, og du forstår aldrig hvorfor.
En svindler udgiver sig for at være din leder eller økonomiansvarlige og beder medarbejdere om en hastebetaling eller gavekort — beskeden ser ægte ud, fordi den tilsyneladende kommer fra dit domæne, så nogen betaler.
En større prospects IT- eller sikkerhedsteam tjekker dit domæne og ser ingen afsenderbeskyttelse. De enten dropper dig eller kræver, at du fikser det inden underskrift — det koster dig aftalen eller ugers forsinkelse.
Du tror, du er beskyttet, fordi der findes en SPF-record — men den er sat til 'soft fail' uden DMARC bag den, eller er lydløst defekt, så falsk post stadig slipper igennem.

Hvorfor det betyder noget. At forfalske afsenderadressen på en e-mail er trivielt nemt og koster angriberen ingenting. SPF er den billigste og hurtigste måde at gøre dit domæne sværere at efterligne og holde din legitime post ude af spam. Google og Yahoo markerer nu aktivt eller afviser post fra domæner uden autentificering, så dette er ikke længere valgfrit — det er minimumskravet for overhovedet at få dine e-mails leveret.

Den korte version

Lige nu — medmindre du har SPF korrekt konfigureret — kan hvem som helst i verden sende e-mail, der ser ud som om den kommer fra din virksomhed. De kan sende falske fakturaer til dine kunder, falske betalingsanmodninger til dine medarbejdere og skrive til dine leverandører, som om de var dig — og beskederne vil se ægte ud, fordi der intet på dit domæne siger andet.

SPF (Sender Policy Framework) er løsningen. Det er en enkelt tekstlinje i dit domænes DNS-indstillinger, der angiver hvilke mailtjenester der faktisk må sende e-mail som dig. Modtagende mailudbydere — Gmail, Outlook, alle andre — tjekker den liste, inden de beslutter, om en besked er ægte. Ingen liste, eller en svag en, og de har intet at holde sig til.

Denne side dækker to ting, der begge skal være korrekte: om der overhovedet eksisterer en SPF-record, og om den er sat strengt nok til faktisk at gøre sin opgave.

Hvad dette kan koste dig

Her er de hverdagslige, virkelighedsnære måder, en manglende eller svag SPF-record omsættes til penge og tillid, der forsvinder ud ad døren. Vi nævner aldrig rigtige virksomheder — disse er mønstre, vi ser på tværs af data.

Faktura-omdirigering. En kriminel sender en af dine kunder en e-mail, der ser præcis ud som om den kom fra dig, med en ægte-udseende faktura med sit eget kontonummer. Din kunde betaler. Det første du hører er en rykker om, hvor ordren er. Nu er der en vred kunde, en betaling til en kriminel, og en svær samtale om, hvem der bærer tabet.
Direktør-/økonomisvindel. Nogen mailer din bogholder “fra” ejeren: “Kan du klare denne betaling inden arbejdsdagens slutning?” Fordi beskeden ægte ser ud til at komme fra dit domæne, trigrer den ingen alarmklokker. Penge forlader virksomheden.
Den stille leveringsbøde. Dine tilbud og fakturaer begynder at lande i kundernes spam, fordi Gmail og Yahoo ikke kan verificere, at de virkelig kommer fra dig. Du får ingen bounce, ingen fejl — aftaler bliver bare stille. Du mister forretning, og du kan ikke engang se det ske.
Den tabte kontrakt. En større klients indkøbs- eller sikkerhedsteam kører en grundlæggende tjek af dit domæne som del af onboarding. De ser ingen afsenderautentificering og flagger dig som en risiko. I bedste fald scrambler du for at fikse det under deadlinepres; i værste fald vælger de en konkurrent, der bestod.
Brand-forgiftningsbølgen. Dit domæne bruges i en phishing-kampagne rettet mod offentligheden. Folk, der er blevet snydt, mistror nu enhver e-mail med dit navn på — så selv dine ægte tilbud og fornyelser ignoreres eller rapporteres.

Tråden igennem alle disse: angriberen bruger ingenting, og din virksomhed bærer omkostningen og skylden.

Hvad det faktisk er

Når en e-mail ankommer, ønsker den modtagende mailserver at vide én ting: er dette virkelig fra den, det påstår at være fra? SPF besvarer dele af dette spørgsmål.

Du udgiver en kort tekstlinje i dit domænes DNS-indstillinger — en “TXT-record” — der navngiver de mailtjenester, der har tilladelse til at sende på dine vegne. Noget som:

v=spf1 include:_spf.google.com include:sendgrid.net -all

På klart dansk lyder det: “Ægte post fra os kommer fra Googles servere og SendGrids servere — afvis alt andet, der hævder at være os.”

De to dele, der tæller for din karakter:

Eksisterer recorden overhovedet? Dette er det store spørgsmål (det bærer den største vægt af alle enkelt-e-mail-tjek). Ingen record betyder, at modtagere ikke har nogen liste at tjekke imod, så efterligning er fuldt åben. Der er også en subtil fejltilstand her: hvis dit domæne har to eller flere SPF-records, siger reglerne, at alle af dem er ugyldige — så du har faktisk ingen SPF overhovedet, selvom det ser ud som om du har.
Er politikken streng nok? En record kan eksistere men stadig være tandløs. Afslutningen — “all”-mekanismen — er instruktionen til modtagere:
- -all (hard fail) — afvis alt, der ikke er på listen. Stærkest. Fulde point.
- ~all (soft fail) + DMARC sat til reject — den moderne anbefalede opsætning. Tilsvarende beskyttelse som hard fail, uden risikoen for, at videresendt post bouncer. Fulde point.
- ~all + DMARC sat til quarantine — acceptabelt, lidt svagere; flyt DMARC til reject for fuld beskyttelse.
- ~all alene (ingen DMARC-håndhævelse) — svagt. Dette siger “sandsynligvis falsk, lever alligevel.” Forfalsket post slipper stadig igennem. Dette er den fælde, mange virksomheder falder i, når de tror, de er beskyttede.
- ?all (neutral) — giver ingen beskyttelse.
- +all — aktivt farligt: det fortæller verden, at hvem som helst må sende som dig. Brug aldrig dette.

Der er endnu en usynlig fejl: SPF må kun udløse op til 10 DNS-opslag, når den evalueres. Sæt for mange include:-poster ind, og recorden overskrider denne grænse, og modtagere behandler hele tingene som defekt — og du er tilbage til ingen beskyttelse. Dette er et almindeligt, stille problem for virksomheder, der bruger mange marketing- og SaaS-værktøjer.

Hvad “godt” ser ud som: præcis én SPF-record, der lister alle tjenester, der legitimt sender post som dig, der ender med -all (eller ~all parret med DMARC ved p=reject), og der forbliver komfortabelt under 10-opslags-grænsen.

Sådan fikser du det (gratis, ~10 minutter)

Overrækk dette afsnit til den person der administrerer dit domæne eller din hjemmeside — og bemærk, at fikset er gratis. Det er en ændring til en DNS-indstilling, ikke et produkt du køber. Vi opkræver kun betaling for at overvåge, at det forbliver korrekt over tid, ikke for at foretage ændringen.

Trin 1 — List alle tjenester, der sender e-mail som dig. Dette er den del, folk tager fejl af. Skriv dem alle ned: din mailboks-udbyder (Google Workspace, Microsoft 365 osv.), plus alle nyhedsbrevværktøjer, CRM, helpdesk, e-handelsplatform, faktura-/regnskabsapp og bookingsystem. Hvis en tjeneste sender post i dit navn, og du glemmer den, vil din SPF blokere dens post, når du stramme politikken.

Trin 2 — Udgiv én TXT-record på dit roddomæne. Kombiner “include”-linjerne for alle dine afsendere i én enkelt record. Per gængs platform:

Google Workspace: include:_spf.google.com
Microsoft 365: include:spf.protection.outlook.com
SendGrid: include:sendgrid.net
Mailchimp: include:servers.mcsv.net
Zoho: include:zoho.eu (eller det regionalt relevante domæne)

En kombineret record ser sådan ud:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net -all

Hvor du tilføjer den, efter udbyder:

Cloudflare: DNS → Records → Tilføj record → Type TXT, Navn @, Indhold = værdien ovenfor.
Microsoft 365 / Google admin: de udgiver den præcise include-streng at bruge i deres opsætningsguide; kopier den ind i din DNS-udbyders TXT-record.
GoDaddy / de fleste hosts: DNS-administration → Tilføj → TXT, Host/Navn @, Værdi = recorden.

Trin 3 — Start sikkert, stram derefter. Mens du bekræfter, at din afsenderliste er komplet, udgiv med ~all (soft fail), så intet legitimt blokeres ved et uheld. Når du har bekræftet, at al din ægte post stadig flyder, stram til -all (hard fail) — eller, bedre, behold ~all og tilføj en DMARC-politik på p=reject, som er den anbefalede moderne parring.

Trin 4 — Sørg for, at du har præcis ÉN record. Hvis en gammel SPF-record allerede eksisterer, rediger den frem for at tilføje en ny. To v=spf1-records ophæver hinanden og efterlader dig ubeskyttet.

Trin 5 — Hold øje med opslags-tællingen. Hvis du har mange afsendere, kan du overskride 10-opslags-grænsen. Sker det, konsolider — nogle udbydere tilbyder “SPF-flattening,” eller drop afsendere du ikke længere bruger.

Trin 6 — Tjek dit domæne igen for at bekræfte, at det nu består, med recorden til stede og politikken streng.

Almindelige fejl

To SPF-records. Den mest almindelige stille fejl. At tilføje en ny record i stedet for at redigere den eksisterende ugyldiggør begge. Der må kun være præcis én.
Stoppe ved ~all og antage, at du er færdig. Soft fail uden DMARC bag den er det svage midterterræn — det ser konfigureret ud, men beskytter dig næppe. Gå enten til -all, eller par ~all med DMARC p=reject.
At glemme en afsender. At stramme til -all inden du har listet din faktura-app, CRM eller nyhedsbrevværktøj vil begynde at blokere din egen legitime post. List alt først.
At sprænge 10-opslags-grænsen. Hver include: kan kæde til flere opslag. For mange, og recorden behandles som defekt. Hold den slank.
At bruge +all. Dette autoriserer eksplicit hele internettet til at sende som dig. Det er værre end ikke at have nogen record. Udgiv det aldrig.

Hvor dette passer ind

SPF er fundamentet, men det er ét af tre lag. DKIM tilføjer en kryptografisk signatur, der beviser, at en besked ikke er blevet manipuleret med, og DMARC er instruktionen, der binder SPF og DKIM sammen og siger til modtagere, hvad de faktisk skal gøre med post, der fejler — herunder at blokere efterligning af det synlige “from”-navn dine kunder ser. Gør SPF rigtigt først (det er den hurtigste gevinst og bærer den største vægt), tilføj derefter DKIM og DMARC for fuldt ud at lukke døren. Alle tre rettelser er gratis.

Konfigurer det hos din udbyder

Trin for trin hos populære udbydere:

FAQ

Jeg er ikke teknisk — kan jeg selv klare det?

Du behøver ikke forstå detaljerne. Ændringen er én eller to linjer tilføjet til dit domænes indstillinger, udført af den der administrerer din hjemmeside eller din IT-udbyder. Send dem afsnittet 'Sådan fikser du det' nedenfor — det tager som regel få minutter og er gratis. Vi opkræver kun betaling for at overvåge, at det forbliver korrekt over tid.

Vi har allerede en SPF-record — er vi ikke dækket?

Ikke nødvendigvis. At have en record er den første halvdel; at have den sat strengt er den anden. En record, der slutter med '~all' (soft fail) uden DMARC bag den, siger til modtagende servere 'dette kan være falsk, men lever det alligevel' — det giver minimal beskyttelse. To SPF-records, eller én der laver for mange opslag, behandles som defekt og giver dig ingen beskyttelse overhovedet, selvom det ser ud som om den eksisterer. Begge halvdele skal være korrekte.

Kan det at fikse dette ved et uheld bryde min egen e-mail?

Det kan det, hvis recorden mangler en legitim afsender — for eksempel dit fakturaprogram eller nyhedsbrevværktøj der sender post i dit navn. Derfor er den sikre fremgangsmåde at liste alle tjenester der sender post som dig først, udgive med en blød '~all' mens du bekræfter, at intet er glemt, og derefter stramme til hard fail. Udføres i den rækkefølge, bryder det intet.

Hvad er forskellen på '~all' og '-all', og hvilken skal vi bruge?

'-all' (hard fail) beder modtagere om at afvise alt, der ikke er på din liste — den stærkeste indstilling. '~all' (soft fail) siger 'sandsynligvis ikke legitimt, men accepter det alligevel.' Den moderne best-practice-anbefaling er '~all' kombineret med en DMARC-politik på 'reject' — det par giver samme beskyttelse som '-all' uden risikoen for, at videresendt post bouncer. '~all' alene, uden DMARC der håndhæver det, er den svage konfiguration, du skal undgå.

Stopper SPF al e-mail-spoofing alene?

Nej — det er det essentielle første lag, ikke hele svaret. SPF angiver hvilke servere der må sende for dig, men det siger ikke til modtagere hvad de skal gøre, når en besked fejler, og det dækker ikke det synlige 'from'-navn brugeren ser. For fuldt ud at låse for efterligning vil du også have DKIM og DMARC. SPF er det hurtigste, højest-virkende første skridt, så start her og tilføj derefter de andre to.

Hvor lang tid tager det at træde i kraft, og koster det noget?

DNS-ændringer træder som regel i kraft inden for minutter til et par timer. Selve fikset er altid gratis — det er blot at redigere en indstilling hos din DNS-udbyder. Enhver der siger, at du skal købe et betalt produkt for at tilføje en SPF-record, tager fejl.