Når kontorets mails havner i spam: SPF, DKIM og DMARC forklaret for små virksomheder

Når kontorets mails havner i spam, skyldes det oftest, at modtagerens mailserver ikke kan se, at afsenderen faktisk må sende på vegne af jeres domæne. Svaret er tre DNS-indstillinger: SPF (hvilke servere må sende), DKIM (en digital signatur på hver mail) og DMARC (hvad modtageren skal gøre, hvis de to første ikke passer). Mangler en af dem, eller er den sat forkert op efter et skift af mailudbyder eller nyhedsbrevsværktøj, kan et tilbud eller en faktura ende i spamfilteret. Samtidig kan andre misbruge jeres domæne til at sende falske mails. Her får du forklaringen i almindeligt sprog, de typiske fejl, en metode til at tjekke domænet og et forslag til, hvem på kontoret der skal eje opgaven.

Når mails havner i spam: sådan bedømmer modtagerens server jer

Forestil dig, at hver mail er et brev med jeres firmanavn som afsender. På papir kan alle skrive, hvad de vil, i afsenderfeltet. Sådan er det også i e-mail: afsenderadressen (From) kan i princippet sættes til hvad som helst, hvis modtageren ikke kontrollerer den. Derfor tjekker modtagerens server, om mailen kan dokumenteres at komme fra et sted, domæneejeren har godkendt.

Resultatet af tjekket indgår i en samlet vurdering sammen med andre signaler, fx afsenderens omdømme, mailens indhold og om modtageren tidligere har svaret jer. En mail uden gyldig autentificering starter med et handicap. Hvis den desuden har et vedhæftet PDF-tilbud fra en server, modtageren ikke kender, er der god grund til, at filteret bliver mistænksomt.

På det lille kontor viser problemet sig typisk sådan:

• En kunde ringer og spørger, om I har glemt at sende tilbuddet. Det ligger i hans spammappe.
• Fakturaer sendt fra regnskabsprogrammet bliver ikke betalt, fordi de aldrig kom frem.
• Nogle modtagere får mailen fint, andre ikke. Det afhænger af, hvor strengt deres mailudbyder filtrerer.
• Kunder eller leverandører får mails, I aldrig har sendt, fx en “opdateret betalingsoplysning” fra jeres domæne.

Det sidste punkt er det alvorligste. Hvis nogen kan sende mails, der ser ud til at komme fra jeres domæne, kan de bruges til fakturasvindel eller til at lokke login-oplysninger ud af jeres kunder. Det skader tilliden til jer, også selvom jeres egne systemer aldrig er blevet hacket. Er I udsat for svindel, bør I anmelde det til politiet. Der findes også generel offentlig vejledning om phishing og mailsikkerhed, som I kan søge hos relevante myndigheder.

Før I begynder at rette noget, bør I se, hvordan domænet står lige nu. Et værktøj som Domain Security Checker kan slå jeres domæne op og vise status for SPF, DKIM, DMARC og flere andre punkter samlet. Så retter I ud fra fakta og ikke ud fra gæt.

SPF, DKIM og DMARC i praksis: hvad gør de tre ting hver især?

De tre standarder lyder tekniske, men hver af dem svarer på ét simpelt spørgsmål. Alle tre ligger som tekstposter (TXT) i jeres domænes DNS-opsætning, dvs. det sted, hvor domæneudbyderen eller IT-partneren styrer, hvad jeres domæne peger på.

SPF: hvem må sende mail for domænet?

SPF (Sender Policy Framework) er en liste over de servere og tjenester, der har lov til at sende mail fra jeres domæne. Modtageren slår listen op og sammenligner den med den server, mailen kom fra. En SPF-post ser nogenlunde sådan ud:

v=spf1 include:spf.mailudbyder.example include:nyhedsbrev.example -all

Der er tre ting, du skal vide om den:

• Der må kun være én SPF-post pr. domæne. Står der to, giver det ofte fejl, og modtageren kan ignorere begge.
• Slutningen afgør strengheden. -all betyder, at alt, der ikke er på listen, skal afvises. ~all betyder, at det er mistænkeligt, men kan accepteres. ?all og +all er i praksis uden beskyttelse.
• SPF har en grænse på ti DNS-opslag. Hver include kan kalde flere opslag, så et kontor med mange tjenester kan nå grænsen uden at opdage det. Resultatet er en ugyldig SPF-post.

SPF har også en begrænsning: Den kontrollerer teknisk set den skjulte afsenderadresse (Return-Path), ikke den adresse, kunden ser. Derfor er SPF alene ikke nok.

DKIM: er mailen rørt undervejs, og kommer den fra jer?

DKIM (DomainKeys Identified Mail) sætter en digital signatur på hver udgående mail. Afsenderens system signerer med en privat nøgle, og den tilhørende offentlige nøgle ligger i jeres DNS. Modtageren kan dermed kontrollere to ting: at mailen er signeret af en part, der har adgang til nøglen, og at indholdet ikke er ændret undervejs.

Den offentlige nøgle ligger under en såkaldt selector, fx selector1._domainkey.jeresdomæne.dk. Hvert system, der sender mail for jer, har typisk sin egen selector. Det er også derfor, DKIM tit mangler efter et systemskift: Den nye tjeneste skal have sin egen nøgle lagt ind i DNS, og det sker ikke af sig selv.

DMARC: hvad skal modtageren gøre, hvis det ikke stemmer?

DMARC binder de to andre sammen. Den kræver, at SPF eller DKIM ikke bare består, men også passer til den adresse, som modtageren ser i From-feltet. Det kaldes alignment. Derudover fortæller DMARC modtageren, hvad den skal gøre med mails, der ikke består:

• p=none: Gør ingenting, men send rapporter. Det er overvågningstilstand.
• p=quarantine: Behandl mailen som mistænkelig, typisk ved at lægge den i spam.
• p=reject: Afvis mailen helt.

DMARC-posten ligger på _dmarc.jeresdomæne.dk og kan indeholde en adresse til rapporter (rua). Rapporterne er maskinlæsbare XML-filer fra modtagende mailudbydere. De viser, hvilke servere der sender mail i jeres navn, og hvor mange af dem der består. For en lille virksomhed er det som regel nemmest at lade en rapporttjeneste eller IT-partneren læse dem.

Kort sagt: SPF siger, hvem der må sende. DKIM beviser, at mailen er ægte og uændret. DMARC bestemmer konsekvensen og giver jer indsigt.

Typiske fejl efter skift af mailudbyder eller nyt nyhedsbrevsværktøj

De fleste mailproblemer opstår ikke, fordi nogen har glemt at lave opsætningen en gang for alle, men fordi opsætningen er blevet forældet. Det lille kontor skifter system uden en egentlig driftsproces, og DNS bliver ikke fulgt med. Her er de fejl, der går igen.

Den gamle SPF-post bliver stående

Virksomheden skifter fra én mailudbyder til en anden, men den gamle include bliver stående i SPF-posten. Det gør posten længere og rummer en tilladelse til en tjeneste, I ikke længere bruger. Hvis nogen overtager den gamle konto eller deler infrastruktur med andre, er der unødig risiko. Fjern, hvad I ikke bruger, men først når I har kontrolleret, at ingen systemer stadig sender via den.

To SPF-poster i stedet for én

Når nyhedsbrevsværktøjet beder jer “tilføje denne TXT-post”, tilføjer mange en ny SPF-post ved siden af den eksisterende. Resultatet er to poster, der begynder med v=spf1, og det er ugyldigt. Løsningen er at flette begge tjenesters include ind i én post.

DKIM er aldrig aktiveret hos den nye tjeneste

Mange tjenester sender mail uden at signere i jeres domænes navn, indtil I selv har lagt deres DKIM-nøgler i DNS og trykket “verificér”. Så består mailen måske SPF på tjenestens egen domæne, men ikke DMARC for jeres. Det er en klassiker med nyhedsbreve, webshopbekræftelser og fakturaer fra online regnskabssystemer.

Systemer, ingen har tænkt på

Mailen fra kontoret kommer ikke kun fra Outlook eller Gmail. Overvej, hvad der ellers sender i jeres navn:

• regnskabs- eller faktureringsprogram
• CRM og tilbudssystem
• bookingsystem og kundeportal
• webshop eller kontaktformular på hjemmesiden
• printer eller scanner, der mailer scannede dokumenter
• nyhedsbrevsværktøj og automatiske kampagner

Hvis I strammer DMARC til, uden at disse systemer er sat rigtigt op, risikerer I at blokere jeres egne legitime mails. Lav derfor først en liste over alle afsendere.

DMARC sat til reject for tidligt

Det er fristende at gå direkte til den strengeste politik. Gør man det, før man har overblik over afsenderne, kan fakturaer og kundemails pludselig blive afvist. Start i overvågningstilstand, læs rapporterne, ret op og stram derefter gradvist.

Domæneskift, subdomæner og parkerede domæner

Har virksomheden flere domæner, fx et gammelt firmanavn, et .com ved siden af .dk eller domæner, der kun omdirigerer til hjemmesiden, glemmer man ofte at beskytte dem. Et domæne, der ikke sender mail, bør have en SPF-post, der afviser alt, og en DMARC-politik, så det ikke kan misbruges. Det samme gælder subdomæner, fx nyhedsbrev.jeresdomæne.dk, hvis et eksternt værktøj sender derfra.

Ændringen sker, men DNS-ændringen glemmes i overgangen

Ved et skifte af mailudbyder skal MX-posterne (der styrer, hvor indkommende mail leveres), SPF, DKIM og evt. autodiscover opdateres. Hvis den eksterne leverandør klarer migreringen, er det en god idé at spørge direkte: “Hvilke DNS-ændringer har I lavet for SPF, DKIM og DMARC, og hvilke skal vi selv gøre?” Få svaret skriftligt.

Sådan tjekker du domænet og læser resultatet

Et domænetjek er en af de hurtigste driftsopgaver på kontoret. I skal bruge domænenavnet, ikke adgangskoder. Når du kører jeres domæne gennem Domain Security Checker, får du en samlet sikkerhedsscore og en oversigt over fund og anbefalinger. Du kan også indtaste ekstra subdomæner, hvis I vil have dem med i en subdomæne-beskyttelsestest.

Forstå værktøjets strenge målestok

Værktøjet bruger høje krav. Som udgangspunkt får kun DMARC med p=reject, SPF med -all og aktiveret DNSSEC status som PASS. Hvis I bruger ~all i SPF eller p=quarantine i DMARC, får I en WARNING. Det er ikke det samme som en fejl. Det betyder, at opsætningen virker, men ikke er så stram som den kunne være.

For et lille kontor betyder det i praksis:

• En FAIL eller manglende post (fx ingen DMARC overhovedet) bør rettes først.
• En WARNING skal vurderes. Er I på p=quarantine og kender alle afsendere, er næste skridt at overveje reject. Er I usikre på afsenderne, er quarantine et fornuftigt mellemtrin.
• Et PASS betyder, at punktet opfylder den høje standard. Det er ikke en garanti for, at alle mails leveres, for leveringen afhænger også af omdømme og indhold.

Værktøjet markerer desuden, om et resultat er et “Live check” eller en “Regelbaseret vurdering”. Et live check er et faktisk opslag i DNS lige nu. En regelbaseret vurdering er en vurdering ud fra fastlagte regler. Det er værd at skelne mellem de to, når I læser rapporten: Det første er en observation, det andet en anbefaling.

En enkel gennemgang, du kan følge

1. Kør domænet – brug det domæne, I sender mail fra (det efter @ i jeres adresser).
2. Gem rapporten – tag en kopi eller et skærmbillede med dato, så I kan sammenligne efter ændringer.
3. Tjek SPF – er der præcis én post? Slutter den med -all eller ~all? Står der tjenester, I ikke bruger?
4. Tjek DKIM – er der signering for de systemer, der sender? Hvis værktøjet ikke kan finde selectoren, kan det skyldes, at den hedder noget andet end forventet. Spørg leverandøren, hvilken selector de bruger.
5. Tjek DMARC – findes posten? Hvilken politik? Er der en rapportadresse?
6. Se på resten – fx DNSSEC og beskyttelse af subdomæner. DNSSEC kræver, at både domæneudbyderen og DNS-hosten understøtter det, så det er en opgave for IT-partneren.
7. Lav en prioriteret liste – manglende poster først, derefter advarsler, til sidst finjustering.
8. Test bagefter – send en testmail til en privat Gmail- og Outlook-adresse og se, om den lander i indbakken. Kig i mailens “originale header” eller “vis original” for at se resultatet af SPF, DKIM og DMARC.

DNS-ændringer kan tage tid at slå igennem, afhængigt af indstillingerne for jeres domæne. Hvis et tjek lige efter en ændring stadig viser det gamle, er det ikke nødvendigvis en fejl. Vent og kør tjekket igen.

Falske mails i virksomhedens navn: sådan stopper I misbrug af domænet

Når nogen sender mails, der ser ud til at komme fra jeres domæne, kaldes det spoofing. En typisk variant er en falsk mail “fra direktøren” til bogholderiet med en bøn om hurtig betaling, eller en falsk faktura til jeres kunder med et andet kontonummer. DMARC med en streng politik er det vigtigste værn mod, at andre sender direkte fra jeres domæne.

Men vær opmærksom på begrænsningen: DMARC beskytter ikke mod lookalike-domæner, fx hvis nogen registrerer et domæne, der ligner jeres, med en ombyttet bogstavkombination. Her hjælper kun opmærksomhed, mailfiltre og interne regler. Fastlæg fx, at ændringer i bankoplysninger altid bekræftes telefonisk på et kendt nummer, aldrig ved at svare på mailen.

En realistisk vej fra p=none til p=reject

1. Kortlæg afsendere. Lav listen over alle systemer, der sender i jeres navn.
2. Ret SPF og DKIM for hvert system, så de består og passer til jeres domæne.
3. Indfør DMARC med p=none og en rapportadresse. Brug en postkasse eller tjeneste, der kan håndtere rapporterne, ikke en privat indbakke.
4. Læs rapporterne over en periode, der dækker jeres normale rytme, inklusive månedsskifte og nyhedsbreve, og find afsendere, der fejler.
5. Skift til p=quarantine, når de legitime afsendere består.
6. Skift til p=reject, når I er sikre. Hold øje med klager over manglende mails de første uger.

Der er ingen genvej, der giver både fuld beskyttelse og nul risiko fra dag ét. Tempoet afhænger af, hvor mange systemer I har, og hvor godt I kender dem. En IT-partner kan hjælpe med at læse rapporterne og lave ændringerne, men ejerskabet af beslutningerne bør ligge hos jer.

Bliv ikke fanget af bulk-kravene

Store mailudbydere som Google og Yahoo har indført krav om autentificering for afsendere, der sender store mængder mail. De samme principper er relevante, uanset hvor mange mails I sender. Selv hvis I kun sender nyhedsbreve til en lille kundeliste, er det klogt at følge de samme principper. Nyhedsbrevsværktøjets egen vejledning til “domæneautentificering” er det rigtige sted at starte, og den bør følges, før første kampagne sendes.

Hvem på kontoret bør eje opgaven?

I mange små virksomheder falder mailopsætningen mellem to stole. Den, der oprettede domænet, er ofte holdt op, hjemmesidebureauet ejer DNS, og IT-partneren styrer mailen. Ingen har overblikket, og ingen opdager, at et nyt system sender uden signering. Derfor er ejerskab lige så vigtigt som den tekniske opsætning.

Ejeren bør være en rolle, ikke en teknisk titel

Den bedste ejer er den, der alligevel har ansvar for drift og leverandører: kontorchefen, driftsansvarlig, administrationsmedarbejderen eller direktøren i en meget lille virksomhed. Personen behøver ikke kunne skrive DNS-poster, men skal kunne:

• vide, hvem der administrerer domænet, og have adgang til domæneudbyderens konto
• stille de rigtige spørgsmål til leverandører og IT-partner
• godkende, at nye systemer må sende mail i firmaets navn
• gemme dokumentationen på ét sted

Udpeg også en stedfortræder. Domæneadgang, der kun findes hos én person, er en driftsrisiko ved sygdom eller opsigelse.

Tre faste rutiner

1. Ved indkøb af nyt system: Spørgsmålet “Sender det mail i vores navn?” skal være en fast del af indkøbet. Hvis ja, skal ejeren sikre SPF og DKIM, inden det går i drift.
2. Ved skift eller opsigelse af leverandør: Fjern gamle include-poster og DKIM-nøgler, når de ikke længere bruges, og kør domænetjekket bagefter.
3. Fast gennemgang: Sæt en tilbagevendende kalenderpåmindelse, fx to gange om året, til at køre tjekket, sammenligne med sidste rapport og læse DMARC-rapporter.

Spørgsmål, ejeren bør stille leverandører

• Hvilken SPF-include og hvilke DKIM-poster skal jeg lægge i DNS?
• Signerer I med vores domæne, eller med jeres eget?
• Hvordan verificerer jeg, at DKIM virker, inden vi sender første kampagne?
• Hvad sker der med vores domæneopsætning, hvis vi opsiger aftalen?

Dokumentér det, så det kan overleveres

Et simpelt dokument er nok: domæne og udbyder, hvem der har adgang, hvilke systemer der sender mail, hvilke selectors der bruges, hvilken DMARC-politik der gælder, og hvornår der sidst blev tjekket. Det er det, den næste person på kontoret har brug for, hvis mails pludselig begynder at forsvinde. Har I en ekstern IT-partner, så bed om, at de opdaterer dokumentet, hver gang de ændrer noget.

Ofte stillede spørgsmål

Hvorfor havner mine mails i spam, selvom SPF, DKIM og DMARC er sat op?

Autentificering er kun én del af modtagerens vurdering. Afsenderens omdømme, mailens indhold, vedhæftede filer, links og hvor ofte modtagerne markerer jer som spam spiller også ind. Kontrollér desuden, at selve mailen består alle tre tjek. Det kan du se i mailens originale header hos en testmodtager. Nogle gange består SPF eller DKIM, men uden at passe til afsenderadressen, og så fejler DMARC alligevel.

Skal en lille virksomhed have DMARC på p=reject?

Det er den stærkeste beskyttelse mod, at andre sender direkte fra jeres domæne, og strenge tjekværktøjer kræver det for at give fuld score. Men det er først forsvarligt, når I kender alle legitime afsendere. Mange går trinvis fra none til quarantine og derefter reject. Spørg jeres IT-partner til råds, hvis I har mange systemer.

Hvad er forskellen på ~all og -all i SPF?

~all (softfail) fortæller modtageren, at mails fra servere uden for listen er mistænkelige, men ikke nødvendigvis skal afvises. -all (hardfail) siger, at de skal afvises. Den strengere variant giver bedre beskyttelse, men forudsætter, at listen over godkendte afsendere er komplet. Ellers risikerer I at afvise egne mails.

Hvor ofte bør vi tjekke domænet?

Som minimum efter hver ændring i mailopsætningen, fx nyt system, nyt nyhedsbrevsværktøj, skift af udbyder eller nyt domæne, og derudover fast et par gange om året. Husk at teste, hvor en testmail lander, og ikke kun at kigge på DNS-posterne.

Kan vi selv rette DNS-posterne, eller skal vi bruge en IT-partner?

Mange domæneudbydere har et enkelt kontrolpanel, hvor man kan tilføje TXT-poster. En fejl kan dog stoppe jeres mail, så vær sikker på, hvad I ændrer, og gem den gamle værdi, før I retter. Er I i tvivl, især ved DMARC-stramning, DNSSEC eller mange systemer, er det en god idé at lade en IT-partner gøre det eller gennemgå det, I har lavet.