SPF-record

En SPF-record beskriver, hvilke systemer der er godkendt til at sende e-mail med et bestemt domæne i SMTP-konvoluttens afsenderfelt. SPF står for Sender Policy Framework og publiceres som en TXT-record i DNS. Modtagende mailservere kan slå politikken op og sammenligne den med den server, der afleverer mailen.

Recorden kan godkende IP-adresser, domænets mailservere og eksterne tjenester gennem mekanismer som ip4, mx og include. En typisk værdi begynder med v=spf1 og afsluttes med en regel for alle andre afsendere, eksempelvis -all eller ~all.

SPF kontrollerer ikke i sig selv det synlige Fra-felt, som brugeren ser i mailprogrammet. Det arbejder med domæner i SMTP-processen. Derfor kombineres SPF ofte med DKIM og DMARC, som blandt andet vurderer alignment med det synlige afsenderdomæne.

En korrekt SPF-record kan forbedre modtagernes mulighed for at skelne legitime afsendere fra forfalskede. Den garanterer ikke levering i indbakken, fordi spamfiltre også vurderer omdømme, indhold, engagement og andre tekniske signaler.

Lav først en liste over alle systemer, der sender mail for domænet. Det kan være Microsoft 365 eller Google Workspace, webhotellets SMTP, kontaktformularer, nyhedsbrevstjeneste, CRM, fakturasystem og webshop. En glemt afsender kan begynde at fejle, når politikken strammes.

Find den eksisterende SPF-record, før du opretter noget nyt. Der må kun være én SPF-record for samme domænenavn. Flere tjenester skal samles i den samme værdi, typisk gennem flere include-mekanismer eller IP-regler.

Hold øje med SPF’s grænse for DNS-baserede opslag. Includes, mx, a, redirect og andre mekanismer kan udløse opslag, og en for kompleks politik kan give en permanent fejl. Fjern gamle tjenester og undgå at tilføje brede regler, som godkender mere end nødvendigt.

Test efter ændringen ved at sende til forskellige modtagere og kontrollere Authentication-Results i mailheaderen. Se både SPF-resultatet og hvilket domæne der blev evalueret. En “pass” på et teknisk returdomæne er ikke nødvendigvis nok til at give DMARC-alignment.

En virksomhed bruger Microsoft 365 til medarbejdermail og en ekstern nyhedsbrevstjeneste. SPF-recorden skal godkende begge systemer. Hvis kun Microsoft står i politikken, kan nyhedsbrevene få SPF-fail, selv om de er legitime og bestilt af virksomheden.

Websitet sender formularbeskeder direkte fra webserveren med kundens e-mailadresse som afsender. Det skaber problemer, fordi serveren ikke er godkendt for kundens domæne. En bedre løsning er at sende fra virksomhedens eget domæne og bruge kundens adresse i Reply-To-feltet.

En webshop flytter hosting, og den gamle server står stadig som ip4 i SPF-recorden. Samtidig tilføjes tre nye includes uden oprydning. Politikken nærmer sig opslaggrænsen og godkender en server, der ikke længere bruges. En kortlægning kan gøre recorden både sikrere og lettere at forstå.

En angriber sender mail med virksomhedens navn i det synlige Fra-felt, men bruger et andet domæne i SMTP-konvolutten, som består SPF. Det viser, hvorfor SPF alene ikke stopper alle former for spoofing. DMARC skal kontrollere, om de relevante domæner er aligned.

Den største fejl er to separate records, eksempelvis én for Google og én for nyhedsbrevstjenesten. SPF-evalueringen kræver én samlet politik. To værdier kan give permerror og gøre godkendelsen mindre pålidelig end slet ingen ændring.

En anden fejl er at kopiere en record fra en vejledning uden at kortlægge de virkelige afsendere. En bred +all-regel godkender alle og ødelægger formålet. En for stram -all kan omvendt ramme legitime systemer, hvis de ikke er medtaget.

Pas også på videresendelse. SPF kan fejle, når en mail videresendes gennem en server, som ikke er godkendt af det oprindelige domæne. DKIM-signaturen kan i mange tilfælde overleve videresendelsen, og DMARC kan bestå gennem DKIM-alignment.

Til sidst bør SPF ikke forveksles med den MX-record, der bestemmer, hvor indgående mail leveres. MX kan indgå som en SPF-mekanisme, men de to records har forskellige hovedopgaver.

SPF-resultater kan være pass, fail, softfail, neutral, none, temperror eller permerror. Det er ikke kun slutningen med -all eller ~all, der betyder noget. Hele evalueringen og den konkrete afsender skal læses i mailheaderen.

Eksterne leverandører kan ændre deres include-records uden at du redigerer din egen DNS. Det er praktisk, men betyder også, at du stoler på, at leverandøren vedligeholder sine godkendte afsendere ansvarligt.

Når en tjeneste opsiges, bør dens include fjernes. En gammel godkendelse kan være unødvendig og bidrage til opslaggrænsen. Dokumentér ejer og formål for hver del af recorden, så oprydning ikke bliver et gæt.

Include-mekanismen betyder ikke blot “inkludér denne tekst”. Modtageren foretager et nyt SPF-opslag på leverandørens domæne og evaluerer resultatet. Flere indlejrede includes kan derfor hurtigt bruge opslaggrænsen, selv om den synlige record ser kort ud.

Flattening af SPF erstatter includes med IP-adresser. Det kan reducere DNS-opslag, men kræver løbende opdatering, når leverandøren ændrer infrastruktur. En statisk flattened record uden vedligeholdelse kan godkende gamle IP’er og afvise nye legitime servere.

Brug af mx i SPF godkender serverne, der modtager mail for domænet, som afsendere. Det er kun korrekt, hvis de samme servere faktisk sender udgående mail. En mekanisme bør vælges efter mailflowet og ikke fordi den ser praktisk ud.

Kontaktformularer bør helst sende via en autentificeret mailtjeneste frem for PHP mail fra en tilfældig webserver. Det giver mere stabil SPF, DKIM og logning. Samtidig undgår man at skulle godkende hele hostingmiljøer, som kan rumme mange andre kunder.

Ved domæneflytning kan hjemmesiden fungere, mens SPF stadig ligger i den gamle DNS-zone eller mangler hos den nye udbyder. Flytningstjeklisten bør derfor indeholde alle records og ikke kun A, CNAME og MX. En zoneeksport eller dokumentation før skiftet er værdifuld.

SPF beskytter det domæne, politikken publiceres for, men underdomæner arver ikke automatisk alle forventninger. Hvis tjenester sender fra et subdomæne, bør dets egne records og DMARC-alignment vurderes. Et dedikeret mail-subdomæne kan gøre tredjepartstrafik lettere at adskille.

Rapporter og headerkontrol bør udføres efter hver ny afsender. Vent ikke til en leveringsfejl hos en vigtig kunde. En simpel test til Gmail, Outlook og et eksternt analyseværktøj kan opdage mange opsætningsfejl før en større udsendelse.

Mailudbyderens dokumentation kan ændre den anbefalede include-værdi. Brug derfor den officielle aktuelle record og ikke en gammel blogkopi. Det er især vigtigt ved platforme med flere regioner eller separate systemer til marketing- og transaktionsmail.

Når SPF fejler med temperror, kan årsagen være et midlertidigt DNS-problem. Permerror peger derimod ofte på en varig syntaks- eller opslagfejl. De to resultater bør ikke behandles ens i fejlsøgningen.

En SPF-check bør udføres på det præcise domæne i Return-Path eller MAIL FROM. At slå virksomhedens hoveddomæne op er ikke nok, hvis leverandøren bruger et subdomæne. Mailheaderen viser, hvilket domæne modtageren faktisk evaluerede.

Et domæne med mange afsendere bør have en opdateret oversigt over alle systemer, der sender mail: kontorpakke, webshop, formularer, nyhedsbrev og supportværktøj. Når en leverandør udfases, skal dens include eller IP fjernes igen. Ellers vokser recorden, og uvedkommende infrastruktur kan fortsat stå som godkendt.

Før du ændrer en SPF-record, bør du gemme den eksisterende værdi og kontrollere syntaksen i et testværktøj. En lille fejl som et manglende mellemrum kan påvirke al mail fra domænet. Ændringen bør derfor planlægges som drift, ikke som en tilfældig tekstredigering i DNS-panelet.

SPF beskytter ikke indholdet i mailen og krypterer heller ikke forbindelsen. Det fortæller kun, hvilke systemer der må sende på vegne af et bestemt envelope-domæne. Derfor skal SPF ses sammen med DKIM, DMARC, sikker adgang til mailkonti og almindelig beskyttelse mod kompromitterede brugere.

Vi hjælper med teknisk opsætning omkring hjemmesider og webshops, hvor formularer og ordremails skal fungere stabilt. Vores artikel om HTTP og HTTPS, giver desuden en enkel introduktion til forskellen mellem flere af internettets tekniske lag.