# MailWatch – fulltekst av guider og FAQ Kilde: https://mailwatch.no --- # Nye krav fra Gmail, Yahoo og Outlook: dette må alle som sender e-post ha på plass URL: https://mailwatch.no/blog/krav-gmail-yahoo-outlook-avsendere Publisert: 2026-09-26 Gmail, Yahoo og Outlook.com krever nå SPF, DKIM, DMARC, gyldig omvendt DNS og lav spamrate. Her er en konkret sjekkliste per leverandør, og hva som skjer hvis du ikke følger kravene. Siden februar 2024 har Gmail og Yahoo krevd at alle som sender e-post til brukerne deres har SPF eller DKIM, gyldig omvendt DNS og lav spamrate, og at de som sender mer enn rundt 5 000 meldinger per dag i tillegg har SPF, DKIM, DMARC og ett-klikks avmelding. Microsoft innførte tilsvarende krav for Outlook.com, Hotmail og Live.com fra 5. mai 2025. Oppfyller du ikke kravene, havner e-posten i søppelpost eller blir avvist helt. **Kort fortalt:** - Alle avsendere må ha SPF eller DKIM, gyldig forward- og reverse-DNS (PTR), TLS og en spamrate under 0,3 %. - Masseutsendere (over ca. 5 000 meldinger per dag) må ha både SPF og DKIM, en DMARC-policy (p=none holder) og alignment mot From-domenet. - Markedsføringsutsendelser må ha ett-klikks avmelding etter RFC 8058, og avmeldinger må behandles innen to dager. - Microsoft stiller i praksis de samme autentiseringskravene for Outlook.com-adresser fra mai 2025. - Selv små bedrifter bør oppfylle masseutsender-kravene – det koster lite og gir bedre leveranse overalt. ## Hvorfor kom de nye kravene? De store e-postleverandørene har i mange år anbefalt SPF, DKIM og DMARC, men anbefalinger alene har ikke vært nok. Phishing, spoofing og aggressiv markedsføring fra dårlig konfigurerte domener har fortsatt å fylle innboksene. Derfor gikk Google og Yahoo sammen høsten 2023 og annonserte at anbefalingene skulle bli krav fra februar 2024. Microsoft fulgte etter med egne krav for sine forbrukertjenester i 2025. Målet er enkelt: mottakeren skal kunne stole på at en e-post som ser ut til å komme fra **firma.no** faktisk kommer fra firma.no. Det beskytter både mottakerne og deg som avsender, fordi svindlere får mye vanskeligere for å misbruke domenet ditt. For norske bedrifter er dette relevant selv om kundene ikke bruker Gmail privat. En stor andel av norske privatpersoner har Gmail- eller Outlook.com-adresser, og mange bedrifter kjører Google Workspace, der de samme filtrene brukes. I tillegg ser vi at andre mottakere, også norske, i økende grad vekter autentisering tungt i spamfiltrene sine. ## Krav som gjelder alle avsendere Noen krav gjelder uansett hvor mye e-post du sender. Også en liten regnskapsbedrift som sender 20 fakturaer i uka må ha dette på plass: - SPF eller DKIM: Domenet ditt må autentiseres med minst én av dem. I praksis bør du ha begge. SPF er definert i RFC 7208 og DKIM i RFC 6376. - Gyldig forward- og reverse-DNS: IP-adressen som sender e-posten må ha en PTR-post (reverse DNS) som peker til et vertsnavn, og det vertsnavnet må peke tilbake til samme IP. Dette ordner som regel e-postleverandøren din, men egne servere og enkelte nettbutikk-servere mangler det ofte. - TLS: E-posten må sendes over en kryptert forbindelse. Alle moderne e-posttjenester gjør dette, men gamle skannere, printere og egne SMTP-servere kan være unntak. - Lav spamrate: Andelen meldinger som mottakerne markerer som spam må holdes under 0,3 %, og Google anbefaler å ligge under 0,1 %. - Riktig formaterte meldinger: Meldingene skal følge e-postformatet i RFC 5322, og du skal ikke late som du sender fra en Gmail-adresse når du ikke gjør det. ## Ekstra krav for masseutsendere Google definerer en masseutsender (bulk sender) som et domene som sender over omtrent 5 000 meldinger til personlige Gmail-kontoer i løpet av ett døgn. Grensen beregnes per domene, og alle meldinger fra samme hoveddomene teller sammen – også meldinger fra nyhetsbrevverktøy, CRM og nettbutikk. Har du først passert grensen én gang, behandles du som masseutsender fremover. Yahoo har ikke publisert en eksakt grense, men kravene er de samme. Masseutsendere må i tillegg ha: - Både SPF og DKIM for domenet. - En DMARC-post med minst p=none . DMARC er definert i RFC 7489. - DMARC-alignment: Domenet i From-feltet må samsvare med domenet som er godkjent av SPF eller signert av DKIM. - Ett-klikks avmelding i markedsføringsmeldinger, med headerne List-Unsubscribe og List-Unsubscribe-Post etter RFC 8058, pluss en synlig avmeldingslenke i selve meldingen. Avmeldinger skal behandles innen to dager. ``` List-Unsubscribe: , List-Unsubscribe-Post: List-Unsubscribe=One-Click ``` De fleste etablerte nyhetsbrevverktøy legger inn disse headerne automatisk, men sjekk det. Egenutviklede løsninger og eldre nettbutikk-plugins er de vanligste syndene. ## Sjekkliste per leverandør Tabellen under oppsummerer kravene fra de tre store. «Alle» betyr at kravet gjelder uansett volum, «Masse» at det gjelder avsendere over ca. 5 000 meldinger per dag. | Krav | Gmail | Yahoo | Outlook.com / Hotmail | | SPF eller DKIM | Alle | Alle | Anbefalt for alle | | Både SPF og DKIM | Masse | Masse | Masse (SPF og DKIM må passere) | | DMARC (minst p=none) | Masse | Masse | Masse | | DMARC-alignment med From | Masse | Masse | Masse (SPF eller DKIM, helst begge) | | Gyldig PTR / reverse DNS | Alle | Alle | Anbefalt | | TLS ved sending | Alle | Anbefalt | Anbefalt | | Spamrate under 0,3 % | Alle | Alle | Ingen fast grense, men lav klagerate forventes | | Ett-klikks avmelding (RFC 8058) | Masse, markedsføring | Masse, markedsføring | Anbefalt fungerende avmelding | | Avmelding behandlet innen 2 dager | Masse | Masse | Anbefalt | | Gjelder fra | Februar 2024 | Februar 2024 | 5. mai 2025 | **Tips:** Ikke tenk «vi sender ikke 5 000 e-poster om dagen, så dette gjelder ikke oss». Kravene for masseutsendere er i praksis det samme som god praksis, og leverandørene vekter autentisering også for små avsendere. Oppfyll alt i tabellen, så er du trygg uansett volum. ## Microsofts krav for Outlook.com Microsoft kunngjorde våren 2025 at domener som sender mer enn 5 000 meldinger per dag til Outlook.com, Hotmail.com og Live.com må ha SPF og DKIM som passerer, og en DMARC-post med minst `p=none` som er alignet med SPF eller DKIM – helst begge. Kravene gjelder forbrukerkontoene, ikke bedriftskunder på Microsoft 365, men det er ingen grunn til å behandle dem ulikt i ditt eget oppsett. Meldinger som ikke oppfyller kravene ble først sendt til søppelpost, og Microsoft har varslet at de etter hvert avvises med en feilmelding av typen `550 5.7.515 Access denied, sending domain does not meet the required authentication level`. Ser du den koden i returmeldinger, vet du nøyaktig hva som mangler. Bruker du selv Microsoft 365 til å sende e-post, har vi en egen guide for [SPF, DKIM og DMARC i Microsoft 365](https://mailwatch.no/blog/spf-dkim-dmarc-microsoft-365). Tilsvarende finnes for [Google Workspace](https://mailwatch.no/blog/spf-dkim-dmarc-google-workspace). ## Slik sjekker du om du oppfyller kravene Du trenger ikke gjette. Gå gjennom disse stegene, gjerne i denne rekkefølgen: - Sjekk DNS-postene. Slå opp SPF (TXT på firma.no), DMARC (TXT på _dmarc.firma.no) og DKIM (TXT på selector._domainkey.firma.no). Du kan sjekke domenet ditt gratis og få svar på under et minutt. - Kartlegg alle som sender for deg. E-postsystemet ditt er sjelden det eneste. Nyhetsbrev, CRM, fakturasystem, nettbutikk, kundeservice-verktøy og varslinger fra nettsiden sender ofte med ditt domene i From-feltet. Alle må inn i SPF eller signere med DKIM for ditt domene. - Kontroller alignment. Send en testmelding til en Gmail-adresse, åpne «Vis original» og se etter SPF: PASS , DKIM: PASS og DMARC: PASS . Gjenta for hvert system som sender. - Sjekk reverse DNS for alle IP-adresser du sender fra selv, for eksempel en egen SMTP-server eller en VPS som kjører nettbutikken. - Følg med på spamraten i Google Postmaster Tools. Den krever at du verifiserer domenet med en DNS-post, og viser spamrate, domene-omdømme og autentiseringsstatus over tid. - Test avmeldingen i nyhetsbrevet: finnes List-Unsubscribe-headerne, og vises «Avslutt abonnement» øverst i Gmail? Et typisk godt oppsett for et domene som bruker Microsoft 365 og et nyhetsbrevverktøy kan se slik ut: ``` firma.no. TXT "v=spf1 include:spf.protection.outlook.com include:_spf.nyhetsbrev.example -all" _dmarc.firma.no. TXT "v=DMARC1; p=none; rua=mailto:dmarc@firma.no; adkim=r; aspf=r" selector1._domainkey.firma.no. CNAME selector1-firma-no._domainkey.firma.onmicrosoft.com. ``` Husk at SPF har en grense på 10 DNS-oppslag. Legger du til mange tjenester med include, kan du passere grensen og få PermError, som i praksis betyr at SPF feiler. Se [artikkelen om for mange DNS-oppslag](https://mailwatch.no/blog/spf-for-mange-dns-oppslag) for hvordan du løser det. [Bilde: MailWatch domenevisning med status for SPF, DKIM, DMARC, MX og svartelister for ett domene]MailWatch viser status for SPF, DKIM, DMARC, MX og svartelister for hvert domene, og varsler hvis noe endrer seg. ## Vanlige feil vi ser hos norske bedrifter ### Nyhetsbrevet sender med leverandørens domene Mange nyhetsbrevverktøy sender i utgangspunktet med sitt eget domene i envelope-from og DKIM-signaturen. Da passerer SPF og DKIM teknisk sett, men ikke for ditt domene, og DMARC-alignment feiler. Løsningen er å sette opp «autentisert domene» eller «egen DKIM» i verktøyet, som regel via noen CNAME-poster. ### Nettbutikken sender ordrebekreftelser direkte fra webserveren WooCommerce og andre plattformer sender ofte via PHP mail() fra webserveren. Den IP-adressen står sjelden i SPF, mangler DKIM og har kanskje ikke en gang riktig PTR. Bytt til en SMTP-plugin som sender via e-postleverandøren din eller en transaksjonstjeneste. ### DMARC-posten mangler, eller står på p=none for alltid p=none oppfyller minimumskravet, men gir ingen beskyttelse mot spoofing. Planlegg veien videre til quarantine og reject – se [DMARC-oppsett steg for steg](https://mailwatch.no/blog/dmarc-oppsett-steg-for-steg). ### DKIM-nøkkelen er for kort eller aldri rotert Eldre oppsett bruker ofte 1024-biters nøkler. Det anbefales 2048 bit eller mer. Roter nøkler jevnlig, og fjern gamle selectorer du ikke bruker. ## Hva skjer hvis du ikke oppfyller kravene? Konsekvensene har kommet gradvis. I starten fikk avsendere som ikke fulgte kravene midlertidige feilmeldinger og økt sjanse for søppelpost. Etter hvert har leverandørene skjerpet håndhevingen, og meldinger som mangler autentisering blir nå i økende grad avvist permanent. For deg som avsender betyr det: - Fakturaer og ordrebekreftelser når ikke frem, eller havner i søppelpost uten at noen merker det. - Returmeldinger (bounces) med koder som 5.7.26 hos Gmail eller 5.7.515 hos Outlook.com. - Dårligere domene-omdømme over tid, som også påvirker e-post som faktisk er riktig autentisert. Det verste er at problemet ofte er usynlig. Du ser ikke at e-post havner i søppelpost hos mottakeren. Derfor er kontinuerlig overvåking av DNS-oppsettet og DMARC-rapportene langt tryggere enn en engangssjekk. ## Ofte stilte spørsmål ### Gjelder kravene fra Gmail også små bedrifter? Ja, deler av dem. Alle avsendere til Gmail må ha SPF eller DKIM, gyldig reverse DNS, TLS og en spamrate under 0,3 %. De strengere kravene om DMARC, alignment og ett-klikks avmelding gjelder formelt avsendere med over ca. 5 000 meldinger per dag, men det anbefales for alle. ### Holder det med DMARC p=none? For å oppfylle minimumskravene fra Gmail, Yahoo og Outlook.com holder p=none. Men p=none gir ingen beskyttelse mot at andre sender e-post i ditt navn, fordi mottakeren ikke blir bedt om å gjøre noe med meldinger som feiler. Målet bør være p=quarantine eller p=reject når alle legitime avsendere er på plass. ### Hvordan teller Google de 5 000 meldingene? Google teller meldinger sendt til personlige Gmail-kontoer fra samme hoveddomene i løpet av 24 timer. Meldinger fra alle systemer og subdomener som deler hoveddomenet, teller sammen. Når et domene først er klassifisert som masseutsender, beholder det den statusen. ### Hva er ett-klikks avmelding? Ett-klikks avmelding er definert i RFC 8058 og betyr at meldingen har headerne List-Unsubscribe og List-Unsubscribe-Post, slik at e-postklienten kan melde mottakeren av med ett klikk uten at mottakeren må åpne en nettside. Kravet gjelder markedsføring og nyhetsbrev, ikke transaksjonell e-post som fakturaer og ordrebekreftelser. ### Gjelder Microsofts krav også Microsoft 365-kunder? Kravene fra mai 2025 gjelder mottak til forbrukertjenestene Outlook.com, Hotmail.com og Live.com. Bedriftspostbokser i Microsoft 365 har egne filtre. Siden de samme prinsippene gir bedre leveranse overalt, bør du likevel ha SPF, DKIM og DMARC på plass uansett hvem mottakeren er. ### Hvordan vet jeg om e-posten min blir avvist? Se etter returmeldinger med koder som 5.7.26 (Gmail) eller 5.7.515 (Outlook.com), og følg med i Google Postmaster Tools. Den mest pålitelige metoden er å motta og lese DMARC-rapporter, som viser hvor mange meldinger fra domenet ditt som passerer eller feiler autentisering hos de store mottakerne. ## Oppsummering Kravene fra Gmail, Yahoo og Outlook.com handler om det samme: bevis at du er den du sier du er, og send bare e-post folk vil ha. Med SPF, DKIM, en DMARC-post, riktig reverse DNS og fungerende avmelding er du godt innenfor, uansett volum. Utfordringen er å holde oppsettet riktig over tid, når nye tjenester legges til og DNS endres. MailWatch overvåker SPF, DKIM, DMARC, MX og svartelister kontinuerlig, leser DMARC-rapportene for deg og varsler på e-post, SMS eller Pushover hvis noe bryter. Du kan [prøve gratis i 30 dager](https://mailwatch.no/auth/register) uten kredittkort. --- # Fra p=none til p=reject: DMARC-oppsett steg for steg URL: https://mailwatch.no/blog/dmarc-oppsett-steg-for-steg Publisert: 2026-09-26 En trygg plan for å gå fra DMARC p=none til p=reject uten å stoppe legitim e-post: kartlegging av avsendere, tidslinje, pct, subdomener og hvordan du ruller tilbake. Et trygt DMARC-oppsett gjøres i faser: du starter med `p=none` og rapportering, kartlegger alle tjenester som sender e-post for domenet, retter SPF og DKIM for hver av dem, og strammer deretter gradvis inn til `p=quarantine` og til slutt `p=reject`. For de fleste bedrifter tar det fra noen uker til et par måneder, avhengig av hvor mange systemer som sender e-post. **Kort fortalt:** - Start med p=none og rua-rapporter – det endrer ingenting for leveransen, men viser hvem som sender i ditt navn. - Kartlegg og rett opp alle legitime avsendere slik at de passerer SPF eller DKIM med alignment. - Gå videre til quarantine, gjerne med pct for å trappe opp gradvis, og deretter til reject. - Husk subdomenene: sp= styrer policy for subdomener, og ubrukte domener bør ha p=reject med en gang. - Ha en plan for tilbakerulling: lav TTL og en ferdig DNS-endring gjør at du kan gå et steg tilbake på minutter. ## Hvorfor gå helt til p=reject? DMARC (RFC 7489) lar deg fortelle mottakerne hva de skal gjøre med e-post som ser ut til å komme fra domenet ditt, men som ikke passerer autentisering. Policyen har tre nivåer: - p=none: Ikke gjør noe spesielt, bare send meg rapporter. Gir innsikt, men ingen beskyttelse. - p=quarantine: Behandle meldinger som feiler som mistenkelige, typisk ved å legge dem i søppelpost. - p=reject: Avvis meldinger som feiler allerede under SMTP-samtalen. Det er først på quarantine og reject at DMARC faktisk stopper noen som forfalsker domenet ditt, for eksempel i [direktørsvindel og falske fakturaer](https://mailwatch.no/blog/direktorsvindel-falske-fakturaer). p=none holder for å oppfylle [kravene fra Gmail, Yahoo og Outlook](https://mailwatch.no/blog/krav-gmail-yahoo-outlook-avsendere), men det er et startpunkt, ikke et mål. ## Fase 0: Forberedelser Før du rører DMARC-posten bør du vite hvordan domenet ser ut i dag. Sjekk tre ting: - SPF: Finnes det én, og bare én, SPF-post på domenet? Holder den seg under grensen på 10 DNS-oppslag (RFC 7208)? Mekanismene include, a, mx, ptr, exists og redirect teller, mens ip4, ip6 og all ikke gjør det. - DKIM: Signerer e-postsystemet ditt med en nøkkel for ditt eget domene, helst 2048 bit? - Eksisterende DMARC: Har noen allerede lagt inn en DMARC-post? Da må du vite hva den sier før du endrer den. Den raskeste måten er å [sjekke domenet ditt gratis](https://mailwatch.no/domenesjekk) i MailWatch-domenesjekken, som viser SPF, DKIM, DMARC og MX samlet. Senk også TTL på DMARC-posten, for eksempel til 300 sekunder (5 minutter), mens du jobber med den. Da slår endringer raskt igjennom, og du kan rulle tilbake raskt om nødvendig. ## Fase 1: p=none med rapportering (uke 1–4) Publiser en DMARC-post med p=none og en adresse for aggregerte rapporter (rua): ``` _dmarc.firma.no. 300 TXT "v=DMARC1; p=none; rua=mailto:dmarc@firma.no; adkim=r; aspf=r" ``` Dette endrer ingenting for leveransen, men i løpet av et døgn begynner mottakere som Google, Microsoft og Yahoo å sende deg daglige XML-rapporter. Rapportene viser hvilke IP-adresser som har sendt e-post med ditt domene i From-feltet, hvor mange meldinger, og om SPF og DKIM passerte med alignment. Rå XML-rapporter er tunge å lese manuelt, og selv små domener kan få mange rapporter i uka. Vi har skrevet en egen guide om [hvordan du leser DMARC-rapporter](https://mailwatch.no/blog/lese-dmarc-rapporter), men de fleste velger å sende rua til et verktøy som tolker dem automatisk. **Tips:** La p=none stå i minst to til fire uker. Mange systemer sender bare sjelden, for eksempel månedlige fakturaer, kvartalsvise purringer eller årlige påminnelser. Kort observasjonstid er den vanligste grunnen til at legitim e-post blir stoppet senere. ## Fase 2: Kartlegg og rett opp alle avsendere Dette er den viktigste fasen, og den tar mest tid. Lag en liste over alle tjenester som sender e-post med domenet ditt. Bruk DMARC-rapportene som fasit, men snakk også med kollegaer – markedsavdelingen, økonomi, kundeservice og webbyrået vet ofte om systemer IT ikke har oversikt over. ### Typisk avsenderliste for en norsk SMB | Tjeneste | Formål | SPF | DKIM for eget domene | Status | | Microsoft 365 / Google Workspace | Vanlig e-post | include | Ja, aktiveres i adminpanelet | OK | | Nyhetsbrevverktøy | Markedsføring | Ofte ikke nødvendig | CNAME-poster fra leverandør | Må settes opp | | Regnskaps-/fakturasystem | Fakturaer, purringer | include | Varierer | Sjekk | | Nettbutikk | Ordrebekreftelser | Via SMTP-leverandør | Via SMTP-leverandør | Må flyttes fra PHP mail() | | Kundeservice/helpdesk | Svar på henvendelser | include | CNAME/TXT | Sjekk | | Skanner/printer | Skann-til-e-post | Via Microsoft 365-relay | Via relay | Sjekk | ### SPF eller DKIM – hva er nok? DMARC passerer hvis **enten** SPF eller DKIM passerer med alignment mot From-domenet. I praksis bør du prioritere DKIM for alle tjenester, fordi DKIM-signaturen overlever videresending, mens SPF ikke gjør det. Mange tredjepartstjenester bruker dessuten sitt eget domene som envelope-from, slik at SPF aldri kan gi alignment for ditt domene uansett hva du legger i SPF-posten. Legger du til mange include-mekanismer, pass på grensen på 10 oppslag. Se [SPF PermError: for mange DNS-oppslag](https://mailwatch.no/blog/spf-for-mange-dns-oppslag) hvis du nærmer deg den. ### Hva med kilder du ikke kjenner igjen? I rapportene vil du nesten alltid se IP-adresser du ikke kjenner. Noen er videresendinger (for eksempel fra en mottakers private e-postadresse eller en e-postliste), og noen er rene forfalskningsforsøk. Forfalskningene er nettopp det p=reject skal stoppe, så de trenger du ikke rette opp. Målet er at alle legitime avsendere har DMARC-pass. [Bilde: MailWatch oversikt over sendende servere med SPF-autorisasjon, PTR og svartelistestatus]Avsenderoversikten i MailWatch viser hvilke servere som sender for domenet ditt, og om de er autorisert i SPF. ## Fase 3: p=quarantine, gjerne gradvis (uke 5–8) Når rapportene over en periode på minst to uker viser at alle legitime kilder passerer DMARC, kan du gå til quarantine. Mange velger å trappe opp med pct-taggen, som angir hvor stor andel av meldingene som feiler som skal omfattes av policyen: ``` _dmarc.firma.no. 300 TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@firma.no" ``` Med pct=25 blir en fjerdedel av meldingene som feiler behandlet etter quarantine, mens resten behandles som om policyen var ett nivå lavere (her: none). En vanlig trapp er 10 → 25 → 50 → 100, med en uke på hvert trinn mens du følger med på rapportene. **Viktig:** Ikke alle mottakere implementerer pct likt, og den reviderte DMARC-spesifikasjonen (DMARCbis) erstatter pct med et enklere t=-flagg for testmodus. Se derfor på pct som en ekstra sikkerhetsmargin, ikke som en garanti for at bare en bestemt andel påvirkes. Den egentlige sikkerheten ligger i at du har kartlagt avsenderne grundig i fase 2. Følg med på to ting i denne fasen: rapportene (dukker det opp legitime kilder som feiler?) og henvendelser fra brukere eller kunder om e-post som ikke kommer frem eller havner i søppelpost. ## Fase 4: p=reject (uke 9–12) Når quarantine med pct=100 har stått stabilt i et par uker uten problemer, er du klar for reject. Du kan igjen bruke pct for å trappe opp, men mange går rett til 100 % når quarantine har fungert: ``` _dmarc.firma.no. 3600 TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@firma.no; adkim=r; aspf=r" ``` Med p=reject avviser mottakerne meldinger som feiler, og svindlere kan ikke lenger sende e-post som ser ut til å komme fra firma.no til mottakere som respekterer DMARC. Når alt er stabilt kan du øke TTL igjen, for eksempel til 3600 sekunder. Fortsett å motta og lese rapporter også etter at du har nådd reject. Nye systemer blir tatt i bruk, leverandører endrer IP-adresser, og noen legger kanskje til en ny tjeneste uten å si fra til IT. Rapportene er det som varsler deg før kundene merker noe. ### Oppsummert tidslinje | Fase | Policy | Varighet | Hva du gjør | | 0 | – | 1–2 dager | Sjekk SPF, DKIM, eksisterende DMARC, senk TTL | | 1 | p=none | 2–4 uker | Samle rapporter, finn alle avsendere | | 2 | p=none | Parallelt med fase 1 | Rett opp SPF og DKIM for alle legitime avsendere | | 3 | p=quarantine | 2–4 uker | Trapp opp pct, følg med på rapporter og brukere | | 4 | p=reject | Permanent | Fortsatt overvåking, øk TTL | ## Subdomener og domener som ikke sender e-post DMARC-policyen på firma.no gjelder også for subdomener som ikke har sin egen DMARC-post, med mindre du angir noe annet med `sp=`. Det betyr at en svindler kan prøve å sende fra **faktura.firma.no** hvis du ikke har tenkt på subdomenene. - sp=reject på hoveddomenet gir streng policy for alle subdomener uten egen post. Det er et godt valg når hoveddomenet er på reject. - Egen DMARC-post på subdomenet , for eksempel _dmarc.nyhetsbrev.firma.no, lar deg ha en egen policy for et subdomen som brukes av et bestemt system. Det er nyttig hvis ett system trenger lengre tid på p=none. - Domener som ikke sender e-post – for eksempel firma.com, gamle merkevaredomener eller kampanjedomener – bør få p=reject med en gang, sammen med en SPF-post som ikke tillater noen: ``` firma-gammel.no. TXT "v=spf1 -all" _dmarc.firma-gammel.no. TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@firma.no" ``` Parkerte domener er populære blant svindlere nettopp fordi de ofte er glemt. De er også de enkleste å beskytte, siden det ikke finnes legitim e-post som kan stoppes. ## Slik ruller du tilbake hvis noe går galt Selv med god kartlegging kan det dukke opp en glemt tjeneste. Da er det viktig å kunne handle raskt: - Gå ett steg tilbake , ikke helt til start. Fra reject til quarantine, eller fra quarantine til none. Du beholder rapporteringen og det meste av beskyttelsen. - Ha lav TTL mens du strammer inn, slik at endringen slår igjennom på minutter. Med TTL på 86400 sekunder kan det ta opptil et døgn før alle mottakere ser den nye policyen. - Finn årsaken i rapportene: hvilken IP eller tjeneste feiler, og feiler den SPF, DKIM eller begge? - Rett opp avsenderen – legg den til i SPF eller sett opp DKIM for ditt domene – og stram inn igjen når rapportene viser pass. Ha den forrige DMARC-posten notert, slik at du ikke må improvisere under press. Et alternativ til å gå tilbake på hoveddomenet er å flytte det problematiske systemet til et eget subdomene med egen policy. ## Ofte stilte spørsmål ### Hvor lang tid tar det å gå fra p=none til p=reject? For en typisk norsk SMB med fem til ti systemer som sender e-post tar det vanligvis to til tre måneder. Det meste av tiden går med til å kartlegge avsendere og sette opp DKIM hos tredjepartstjenester. Domener som ikke sender e-post i det hele tatt, kan settes til p=reject med en gang. ### Kan jeg gå rett til p=reject? Det kan du, men det er risikabelt hvis domenet brukes til å sende e-post. Uten en periode med p=none og rapporter vet du ikke om alle legitime avsendere passerer, og du risikerer at fakturaer, ordrebekreftelser eller nyhetsbrev blir avvist. For domener som aldri sender e-post er p=reject fra start derimot anbefalt. ### Hva gjør pct i DMARC-posten? pct angir hvor stor prosentandel av meldingene som feiler DMARC som skal omfattes av policyen, og brukes til å trappe opp gradvis. Standardverdien er 100. Ikke alle mottakere implementerer pct likt, og den reviderte DMARC-spesifikasjonen erstatter den med et testflagg, så pct bør brukes som ekstra sikkerhetsmargin og ikke erstatte grundig kartlegging. ### Hva er forskjellen på p= og sp=? p= angir policyen for domenet der DMARC-posten er publisert, mens sp= angir policyen for subdomener som ikke har sin egen DMARC-post. Uten sp= arver subdomenene policyen fra p=. Det er vanlig å sette sp=reject når hoveddomenet har nådd p=reject. ### Påvirker p=reject videresendt e-post? Videresending bryter ofte SPF, fordi meldingen sendes fra en ny server. DKIM overlever vanligvis videresending så lenge meldingen ikke endres. Har alle avsenderne dine gyldig DKIM for ditt domene, vil videresendt e-post som regel fortsatt passere DMARC. ## Oppsummering Veien fra p=none til p=reject er ikke teknisk vanskelig, men den krever oversikt og tålmodighet. Start med rapportering, kartlegg alle avsendere, rett opp SPF og DKIM, og stram inn trinnvis med en klar plan for tilbakerulling. MailWatch mottar og tolker DMARC-rapportene automatisk, viser hvilke servere som sender for domenet ditt og varsler deg på e-post, SMS eller Pushover hvis noe endrer seg – slik at du kan gå til p=reject med trygghet. Du kan [prøve gratis i 30 dager](https://mailwatch.no/auth/register). --- # Hvorfor havner e-posten i søppelpost? 12 vanlige årsaker og løsninger URL: https://mailwatch.no/blog/hvorfor-havner-e-post-i-spam Publisert: 2026-09-26 E-post havner oftest i søppelpost på grunn av manglende SPF, DKIM eller DMARC, dårlig avsenderomdømme eller svartelister. Her er de 12 vanligste årsakene og hva du gjør med hver av dem. E-post havner i søppelpost når mottakerens filter ikke stoler nok på avsenderen. De vanligste årsakene er manglende eller feil e-postautentisering (SPF, DKIM og DMARC), dårlig omdømme på domenet eller IP-adressen, oppføring på en svarteliste og innhold eller lenker som ligner spam. Heldigvis kan de fleste årsakene både måles og rettes. **Kort fortalt:** - Start alltid med autentisering: SPF, DKIM og DMARC må være på plass og alignet med From-domenet. - Sjekk om domenet eller sende-IP-en står på en svarteliste , og at IP-en har gyldig PTR (omvendt DNS). - Omdømme bygges over tid: nye domener, kalde lister og høy klagerate trekker ned. - Innhold betyr mindre enn før, men forkortede lenker, bare bilder og vedlegg kan fortsatt utløse filtrene. ## Slik vurderer spamfiltre e-posten din Moderne spamfiltre hos Gmail, Outlook og andre gir ikke én enkelt «spamscore» basert på ord i teksten. De vurderer en rekke signaler samtidig: Er avsenderen den den utgir seg for å være? Hva er historikken til domenet og IP-adressen? Hvordan har mottakerne reagert på tidligere e-post – åpnet, svart, slettet eller merket som spam? Og ligner innholdet på kjent spam eller svindel? Siden februar 2024 har Google og Yahoo i tillegg stilt faste krav til alle som sender e-post til deres brukere, og Microsoft fulgte etter for Outlook.com fra 5. mai 2025. Oppfyller du ikke kravene, øker risikoen for søppelpost eller avvisning betydelig. Du finner detaljene i artikkelen om [de nye kravene fra Gmail, Yahoo og Outlook](https://mailwatch.no/blog/krav-gmail-yahoo-outlook-avsendere). Nedenfor går vi gjennom de 12 vanligste årsakene, omtrent i rekkefølgen vi anbefaler å sjekke dem. ## Årsak 1–4: Manglende eller feil autentisering ### 1. SPF mangler eller er feil SPF (RFC 7208) forteller mottakeren hvilke servere som får sende e-post fra domenet ditt. Mangler posten, eller mangler en av tjenestene dere bruker (nettbutikk, nyhetsbrev, CRM), vil e-post fra den tjenesten feile SPF. En vanlig variant er at SPF-posten har [for mange DNS-oppslag](https://mailwatch.no/blog/spf-for-mange-dns-oppslag) og gir PermError for all e-post. **Løsning:** Sørg for én SPF-post som dekker alle legitime avsendere, maks 10 DNS-oppslag, og som avsluttes med `~all` eller `-all`. ### 2. DKIM mangler eller signerer med feil domene DKIM (RFC 6376) legger en kryptografisk signatur på e-posten. Mange tjenester signerer som standard med sitt eget domene (for eksempel `d=sendtjeneste.com`) i stedet for ditt. Da får du DKIM-pass, men ikke alignment mot From-adressen – og DMARC kan feile. **Løsning:** Aktiver egendefinert DKIM for domenet ditt i hver tjeneste, med nøkkel på minst 2048 bit. ### 3. DMARC mangler Uten DMARC (RFC 7489) vet ikke mottakeren hva den skal gjøre med e-post som feiler, og du får ingen rapporter om hvem som sender på vegne av domenet. Gmail og Yahoo krever DMARC for alle som sender mer enn 5 000 meldinger per dag, og det er i praksis blitt et grunnkrav for alle. **Løsning:** Start med en DMARC-post med `p=none` og rapportadresse: ``` _dmarc.firma.no. TXT "v=DMARC1; p=none; rua=mailto:dmarc@firma.no" ``` Stram deretter inn trinnvis til `p=quarantine` og `p=reject` når rapportene viser at all legitim e-post består. ### 4. Manglende alignment DMARC krever at minst én av SPF eller DKIM ikke bare består, men at domenet som ble sjekket matcher domenet i From-adressen. Et nyhetsbrev med From `post@firma.no`, Return-Path hos leverandøren og DKIM signert av leverandøren får pass på SPF og DKIM – men feiler DMARC. **Løsning:** Sett opp eget return-path-domene (f.eks. `nyhet.firma.no`) og DKIM for ditt domene hos leverandøren. [Bilde: MailWatch domenevisning med status for SPF, DKIM, DMARC, MX og svartelister for ett domene]I domenevisningen i MailWatch ser du status for SPF, DKIM, DMARC, MX og svartelister på ett sted. ## Årsak 5–7: Omdømme og infrastruktur ### 5. IP-adressen eller domenet står på en svarteliste Svartelister (DNSBL) som Spamhaus, SpamCop og Barracuda brukes av svært mange e-postservere. Står sende-IP-en eller domenet ditt der, blir e-posten ofte avvist direkte eller lagt i søppelpost. Årsaken er gjerne en kompromittert konto, en infisert maskin på nettverket eller et skjema på nettsiden som misbrukes. **Løsning:** Sjekk alle relevante lister, finn og stopp årsaken, og be deretter om fjerning. Hele prosessen er beskrevet i [slik sjekker og fjerner du svartelisteoppføringer](https://mailwatch.no/blog/svartelister-e-post). ### 6. Manglende eller feil PTR (omvendt DNS) En e-postserver som sender direkte ut på internett bør ha en PTR-post (reverse DNS) som peker på et vertsnavn, og dette vertsnavnet bør peke tilbake til samme IP (forward-confirmed reverse DNS). Google og Yahoo krever gyldig forward og reverse DNS. Mangler PTR, eller ser den generisk ut (som `203-0-113-25.dyn.isp.no`), blir e-posten ofte avvist eller filtrert. **Løsning:** PTR settes av den som eier IP-adressen – be hosting- eller nettleverandøren sette den til f.eks. `mail.firma.no`, og sørg for at `mail.firma.no` har en A-post med samme IP. Bruker du Microsoft 365 eller Google Workspace, håndteres dette av leverandøren. ### 7. Nytt domene eller ny IP uten historikk Et domene som er registrert i forrige uke og plutselig sender tusenvis av e-poster, ser mistenkelig ut. Filtrene har ingen historikk å vurdere, og nye domener brukes ofte i svindel. **Løsning:** «Varm opp» domenet og IP-en gradvis. Start med små volumer til engasjerte mottakere og øk over noen uker. Ikke send store kampanjer fra et helt nytt domene. ## Årsak 8–9: Mottakerlister og engasjement ### 8. Dårlig listehygiene Sender du til gamle adresser som ikke lenger finnes, får du mange «hard bounces». Noen gamle adresser er også gjort om til spamfeller – adresser som bare finnes for å avsløre avsendere med dårlige lister. Kjøpte lister er det verste du kan gjøre. **Løsning:** Bruk bekreftet påmelding (double opt-in), fjern adresser som gir hard bounce umiddelbart, og fjern mottakere som ikke har åpnet eller klikket på lang tid. Kjøp aldri lister. ### 9. Høy klagerate og vanskelig avmelding Når mottakere trykker «Rapporter spam», teller det tungt. Google krever at spamraten i Postmaster Tools holdes under 0,3 %, og anbefaler under 0,1 %. En vanlig årsak til klager er at avmeldingen er vanskelig å finne – da er spam-knappen enklere. **Løsning:** Legg inn en tydelig avmeldingslenke, og for masseutsendelser også ett-klikks avmelding via `List-Unsubscribe` og `List-Unsubscribe-Post`-headerne (RFC 8058). Send bare e-post folk har bedt om, og med forventet frekvens. ``` List-Unsubscribe: , List-Unsubscribe-Post: List-Unsubscribe=One-Click ``` ## Årsak 10–12: Innhold, lenker og teknikk ### 10. Innhold som ligner spam Enkeltord som «gratis» sender deg sjelden i søppelpost alene, men helheten betyr noe. E-post som bare består av ett stort bilde, har mye STORE BOKSTAVER og utropstegn, eller mangler tekstversjon, scorer dårligere. Det samme gjelder e-post som ligner fakturasvindel eller phishing. **Løsning:** Ha en god balanse mellom tekst og bilder, send både HTML- og tekstdel (multipart), og skriv som et menneske. Unngå vedlegg som .zip, .exe eller makro-dokumenter – bruk heller lenke til en side på ditt eget domene. ### 11. Lenker til dårlige eller forkortede domener Lenker vurderes like strengt som avsenderen. URL-forkortere (som bit.ly) brukes mye i spam, og lenker til domener med dårlig omdømme eller som står på domene-svartelister (som Spamhaus DBL) kan trekke hele e-posten ned. Det samme gjelder at lenketeksten viser ett domene mens lenken går til et annet. **Løsning:** Lenk til ditt eget domene, bruk sporingsdomene på ditt eget subdomene hvis nyhetsbrevverktøyet støtter det, og unngå URL-forkortere. ### 12. Manglende TLS og feil i tekniske headere Google og Yahoo krever at e-post sendes over TLS. Feil i Message-ID, dato, manglende From-navn eller ugyldig HTML kan også gi minuspoeng. Videresending gjennom gamle systemer som bryter DKIM-signaturen er en annen klassisk feilkilde. **Løsning:** Sørg for at e-postserveren støtter TLS, og test e-posten med et verktøy som viser headerne. Vurder også MTA-STS og TLS-RPT for innkommende e-post, som sikrer at e-post til deg alltid krypteres. ## Slik feilsøker du i riktig rekkefølge - Sjekk autentiseringen. Sjekk domenet ditt gratis for SPF, DKIM, DMARC, MX og svartelister. - Se på headerne i en e-post som havnet i søppelpost. Se etter Authentication-Results : står det spf=pass , dkim=pass og dmarc=pass ? - Les DMARC-rapportene. De viser alle IP-er som sender med domenet ditt og om de består. Se slik leser du DMARC-rapporter . - Sjekk omdømmet. Registrer domenet i Google Postmaster Tools og Microsoft SNDS, og sjekk svartelister for alle sende-IP-er. - Se på listen og innholdet. Bounce-rate, klagerate, avmeldingsmulighet og lenker. **Tips:** Test mot flere mottakere. Havner e-posten i søppelpost hos Gmail men ikke hos Outlook, er det gjerne omdømme eller engasjement. Havner den i søppelpost overalt, er det nesten alltid autentisering eller svarteliste. ## Ofte stilte spørsmål ### Hvorfor havner e-posten min i søppelpost hos Gmail, men ikke hos Outlook? Gmail og Outlook bruker forskjellige filtre og vekter omdømme og mottakerengasjement ulikt. Når problemet bare gjelder én leverandør, skyldes det ofte omdømme, klagerate eller at du ikke oppfyller akkurat den leverandørens krav. Sjekk Google Postmaster Tools for Gmail og Microsoft SNDS for Outlook. ### Er SPF, DKIM og DMARC nok til å unngå søppelpost? Nei, autentisering er et grunnkrav, men ikke en garanti. Den beviser at e-posten faktisk kommer fra deg, slik at filtrene kan vurdere ditt omdømme. Har domenet dårlig omdømme, står på en svarteliste eller sender uønsket e-post, kan den fortsatt havne i søppelpost. ### Hvordan vet jeg om e-postserveren min står på en svarteliste? Du kan slå opp sende-IP-en og domenet på de store svartelistene som Spamhaus, SpamCop og Barracuda, enten direkte hos dem eller med et verktøy som sjekker mange lister samtidig. Løpende overvåking varsler deg så snart en oppføring skjer, i stedet for at du oppdager det når kundene klager. ### Hva er en akseptabel spamklagerate? Google krever at spamraten målt i Postmaster Tools holdes under 0,3 %, og anbefaler å holde den under 0,1 %. Det betyr maks én klage per tusen meldinger for å være på den trygge siden. Høyere rate gir raskt dårligere leveranse til innboksen. ### Hvorfor havner e-post fra et nytt domene i søppelpost? Et nytt domene har ingen historikk, og filtrene er derfor forsiktige. Nye domener brukes dessuten ofte i svindel. Sett opp SPF, DKIM og DMARC fra første dag, og øk sendevolumet gradvis over noen uker til mottakere som forventer e-posten. ## Oppsummering De fleste søppelpostproblemer skyldes et fåtall ting: autentisering som mangler eller ikke er alignet, dårlig omdømme, svartelister og mottakerlister som ikke er vedlikeholdt. Start med det tekniske, som er enklest å måle, og jobb deg deretter over til lister og innhold. MailWatch overvåker SPF, DKIM, DMARC, MX og svartelister for domenene dine kontinuerlig, tolker DMARC-rapportene automatisk og varsler deg på e-post, SMS eller Pushover når noe endrer seg. Du kan [starte en gratis prøveperiode](https://mailwatch.no/auth/register) på 30 dager. --- # SPF PermError: for mange DNS-oppslag – slik fikser du det URL: https://mailwatch.no/blog/spf-for-mange-dns-oppslag Publisert: 2026-09-26 SPF tillater maks 10 DNS-oppslag. Går du over, får du PermError og SPF feiler for all e-post. Her er hvordan du teller oppslagene og rydder opp uten å miste leveranse. SPF-feilen **PermError: too many DNS lookups** betyr at SPF-posten din krever mer enn 10 DNS-oppslag for å bli evaluert, som er grensen i SPF-standarden (RFC 7208). Mottakeren gir da opp og behandler SPF som ugyldig for all e-post fra domenet. Løsningen er å redusere antall oppslag: fjern tjenester du ikke bruker, flytt markedsførings- og systemutsendelser til egne subdomener, og bruk IP-adresser direkte der det er trygt. **Kort fortalt:** - SPF har en hard grense på 10 DNS-oppslag . include , a , mx , ptr , exists og redirect teller – ip4 , ip6 og all gjør det ikke. - Nestede include-er teller også: én include kan koste flere oppslag. - I tillegg er det maks 2 «void lookups» (oppslag som ikke gir svar) før du får PermError. - Den beste løsningen er som regel opprydding og subdomener per tjeneste – ikke flattening. ## Hva betyr SPF PermError egentlig? SPF (Sender Policy Framework) er en TXT-post i DNS som lister hvilke servere som får sende e-post på vegne av domenet ditt. Er du usikker på grunnprinsippene, kan du lese [vår innføring i hva SPF er](https://mailwatch.no/blog/hva-er-spf) først. Når en mottakende server sjekker SPF, må den ofte gjøre flere DNS-oppslag for å finne alle IP-adressene som er tillatt. For å hindre at SPF blir misbrukt til å belaste DNS-servere, setter RFC 7208 (seksjon 4.6.4) en grense: evalueringen skal ikke bruke mer enn **10 mekanismer og modifikatorer som krever DNS-oppslag**. Blir grensen overskredet, skal resultatet være `permerror` – en permanent feil som ikke går over av seg selv. Konsekvensen er at SPF ikke lenger gir `pass` for noen av avsenderne dine. Med DMARC betyr det at du bare står igjen med DKIM som mulig vei til DMARC-pass. Mangler DKIM hos en av tjenestene, eller er signaturen ikke alignet, feiler DMARC – og med `p=quarantine` eller `p=reject` havner e-posten i søppelpost eller blir avvist. **Viktig:** Noen mottakere er tolerante og evaluerer likevel, andre stopper nøyaktig ved oppslag nummer 11. Gmail og Microsoft følger grensen. At det «fungerer hos deg» er derfor ingen garanti for at det fungerer hos kundene dine. ## Slik teller du DNS-oppslag i SPF Det er ikke antall ord i SPF-posten som teller, men antall oppslag mottakeren må gjøre. Reglene er: | Mekanisme / modifikator | Teller som oppslag? | Kommentar | | include: | Ja, 1 + alt inni | Alle oppslag i den inkluderte posten teller også | | a / a: | Ja, 1 | Slår opp A/AAAA for domenet | | mx / mx: | Ja, 1 | I tillegg maks 10 MX-navn som slås opp | | ptr | Ja, 1 | Frarådet i RFC 7208 – bør fjernes | | exists: | Ja, 1 | Brukes bl.a. av Salesforce | | redirect= | Ja, 1 + alt inni | Som include, men erstatter hele posten | | ip4: / ip6: | Nei | Ingen DNS-oppslag | | all | Nei | Ingen DNS-oppslag | ### Et typisk eksempel Her er en SPF-post vi ofte ser hos norske bedrifter som har vokst med nye verktøy over tid: ``` firma.no. TXT "v=spf1 a mx include:spf.protection.outlook.com include:_spf.google.com include:servers.mcsv.net include:sendgrid.net include:mail.zendesk.com include:_spf.salesforce.com include:spf.webhotell.no include:spf.regnskapssystem.no ~all" ``` Tell opp: `a` (1) + `mx` (1) + åtte include-er (8) = 10 allerede før vi har sett inni noen av dem. Inkluderer `sendgrid.net` en ny include (det gjør den), og webhotellets post inneholder en `a` og en `mx`, er du fort oppe i 13–14. Resultat: PermError. Leverandørene endrer også sine egne SPF-poster uten å varsle deg. En post som var på 9 oppslag i fjor, kan være på 11 i dag uten at du har rørt den. Derfor bør du både telle manuelt og overvåke løpende. ### Slik sjekker du selv - Hent SPF-posten: dig +short TXT firma.no (eller nslookup -type=txt firma.no på Windows). - For hver include og redirect : slå opp den posten og tell oppslagene inni, rekursivt. - Legg til 1 for hver a , mx , ptr og exists . - Noter også oppslag som returnerer NXDOMAIN eller tomt svar – de er «void lookups». Det er tungvint å gjøre for hånd. Du kan [sjekke domenet ditt gratis](https://mailwatch.no/domenesjekk) med MailWatch, som teller alle oppslag rekursivt og viser hvilke include-er som koster mest. [Bilde: MailWatch SPF-verktøy som viser mekanismene i SPF-posten og totalt antall DNS-oppslag]SPF-verktøyet i MailWatch viser hver mekanisme, hvor mange oppslag den koster, og om du er over grensen på 10. ## Void lookups: den andre grensen RFC 7208 har en mindre kjent grense i tillegg: maks **2 void lookups**. Et void lookup er et DNS-oppslag som gir NXDOMAIN (domenet finnes ikke) eller et tomt svar. Typiske årsaker: - En include til en tjeneste du har sagt opp, der leverandøren har fjernet SPF-posten sin. - Skrivefeil, for eksempel include:spf.protection.outlok.com . - a: eller mx: som peker på et vertsnavn som ikke lenger eksisterer. Tre slike oppslag gir PermError, selv om totalen er godt under 10. Void lookups er dessuten et tegn på at posten ikke er vedlikeholdt, så rydd dem bort uansett. ## Steg 1: Fjern det du ikke bruker Den raskeste gevinsten er nesten alltid opprydding. Gå gjennom hver mekanisme og spør: sender denne tjenesten faktisk e-post med vårt domene i avsenderadressen (Return-Path/envelope-from) i dag? - Gamle tjenester: Nyhetsbrevverktøy, CRM-er og webhoteller dere har sluttet å bruke. Fjern dem. - a og mx : Sender webserveren eller MX-serveren din faktisk e-post? Hvis du bruker Microsoft 365 eller Google Workspace, er MX-ene deres allerede dekket av leverandørens include. mx er ofte ren sløsing. - ptr : Frarådet i standarden, tregt og upålitelig. Fjern. - Tjenester som bruker eget Return-Path-domene: Mange moderne tjenester (f.eks. SendGrid, Mailchimp/Mandrill, HubSpot) bruker sitt eget eller et eget subdomene i envelope-from og oppnår DMARC via DKIM. Da trenger de ikke stå i SPF-posten på hoveddomenet i det hele tatt. Sjekk leverandørens dokumentasjon. **Tips:** Usikker på hvem som faktisk sender? DMARC-aggregatrapporter viser alle IP-er som har sendt e-post med domenet ditt de siste dagene. Se [slik leser du DMARC-rapporter](https://mailwatch.no/blog/lese-dmarc-rapporter) – det er den sikreste måten å finne ut hva som trygt kan fjernes. ## Steg 2: Bruk subdomener for e-posttjenester Den mest robuste løsningen for bedrifter med mange avsendere er å gi hver type utsendelse sitt eget subdomene. SPF evalueres mot domenet i envelope-from (Return-Path), og hvert subdomene har sin egen SPF-post med sin egen grense på 10 oppslag. ``` ; Hoveddomenet: kun ansattes e-post firma.no. TXT "v=spf1 include:spf.protection.outlook.com -all" ; Nyhetsbrev nyhet.firma.no. TXT "v=spf1 include:servers.mcsv.net -all" ; Kundeservice / helpdesk support.firma.no. TXT "v=spf1 include:mail.zendesk.com -all" ; Fakturaer og systemvarsler fra nettbutikken varsel.firma.no. TXT "v=spf1 include:sendgrid.net -all" ``` Fordelene er flere enn bare færre oppslag: - Omdømmet skilles: Får et nyhetsbrev mange spamklager, rammer det i mindre grad e-posten fra ansatte. - Enklere feilsøking: Du ser i DMARC-rapportene hvilken tjeneste som sender hva. - DMARC fungerer fortsatt: Med standard «relaxed alignment» i DMARC godtas nyhet.firma.no som alignet med firma.no i From-adressen. Kunden ser fortsatt post@firma.no som avsender hvis du vil. Hvordan du setter opp subdomene varierer: hos de fleste ESP-er heter det «custom return-path», «bounce domain» eller «domain authentication». Husk å sette opp DKIM for subdomenet samtidig. Planlegger du å stramme inn DMARC, er [guiden fra p=none til p=reject](https://mailwatch.no/blog/dmarc-oppsett-steg-for-steg) nyttig. ## Steg 3: Bruk ip4/ip6 for egne servere Har du egne servere med faste IP-adresser – en ERP-server, en skanner/multifunksjonsmaskin som sender via egen relé, eller en VPS for nettbutikken – er det bedre å oppgi IP-en direkte enn å bruke `a:server.firma.no`. `ip4:` og `ip6:` koster ingen oppslag. ``` firma.no. TXT "v=spf1 ip4:203.0.113.25 include:spf.protection.outlook.com -all" ``` Dette er trygt for adresser du selv kontrollerer. Husk å oppdatere SPF hvis serveren bytter IP. ## Steg 4: SPF-flattening – fordeler og ulemper «Flattening» betyr å erstatte include-er med IP-adressene de peker på, slik at hele posten består av `ip4`/`ip6` og nesten ikke krever oppslag. Det løser grensen umiddelbart, men har reelle ulemper: | Fordeler | Ulemper | | Løser 10-oppslagsgrensen med én gang | Leverandører endrer IP-ene sine uten varsel – statisk flattening blir utdatert og legitim e-post feiler | | Raskere evaluering hos mottaker | Posten kan bli for lang (TXT-strenger på maks 255 tegn, og svar over 512 byte kan kreve TCP) | | Du ser nøyaktig hvilke IP-er som er tillatt | Store leverandører har mange nettverk – du risikerer å godkjenne store IP-områder unødvendig | | | Makro-baserte poster (som Salesforce sin exists:%{i}... ) kan ikke flates ut | Vil du flate ut, bør det gjøres med en tjeneste som oppdaterer posten automatisk når leverandøren endrer seg – og kun for de include-ene som er nødvendige. Manuell, engangs flattening er en av de vanligste årsakene til at e-post plutselig begynner å feile måneder senere. Vår anbefaling: rydd opp og bruk subdomener først. Flattening er siste utvei. ## Andre vanlige SPF-feil å sjekke samtidig - To SPF-poster: Et domene skal ha nøyaktig én TXT-post som starter med v=spf1 . To poster gir også PermError. Slå dem sammen. - +all : Godkjenner hele internett. Bruk ~all eller -all . - Syntaksfeil: Mellomrom etter kolon ( include: spf... ), manglende v=spf1 eller feil anførselstegn. - SPF-posten er for lang: Del lange poster i flere strenger innenfor samme TXT-post, maks 255 tegn per streng. ## Ofte stilte spørsmål ### Hvor mange DNS-oppslag kan en SPF-post ha? En SPF-post kan maksimalt utløse 10 DNS-oppslag under evaluering, ifølge RFC 7208. Mekanismene include, a, mx, ptr, exists og modifikatoren redirect teller, inkludert alle oppslag i nestede include-er. ip4, ip6 og all teller ikke. ### Hva skjer hvis SPF har mer enn 10 oppslag? Mottakeren returnerer SPF-resultatet PermError, og SPF gir ikke pass for noe e-post fra domenet. Da må DMARC bestå via DKIM alene. Tjenester uten korrekt DKIM-signatur vil feile DMARC, og med en streng DMARC-policy blir e-posten lagt i søppelpost eller avvist. ### Hva er et void lookup i SPF? Et void lookup er et DNS-oppslag under SPF-evalueringen som gir NXDOMAIN eller et tomt svar, for eksempel en include til en tjeneste som ikke lenger finnes. RFC 7208 tillater maks 2 slike. Ved det tredje blir resultatet PermError, uavhengig av totalt antall oppslag. ### Er SPF-flattening en god idé? Flattening løser oppslagsgrensen, men statiske IP-lister blir utdaterte når leverandørene endrer nettverkene sine, og da feiler legitim e-post. Det bør bare brukes med automatisk oppdatering, og etter at du har ryddet bort ubrukte include-er og flyttet tjenester til subdomener. ### Hjelper det å bruke subdomener for nyhetsbrev og systemvarsler? Ja. Hvert subdomene har sin egen SPF-post og sin egen grense på 10 oppslag, så hoveddomenet slipper å inkludere alle tjenestene. I tillegg skilles omdømmet mellom markedsføring og vanlig e-post, og DMARC fungerer fortsatt med relaxed alignment. ### Hvorfor fikk jeg PermError selv om jeg ikke har endret SPF-posten? Leverandørene du inkluderer kan ha endret sine egne SPF-poster, for eksempel lagt til en ny nestet include. Da øker antall oppslag hos deg uten at du har rørt noe. Løpende overvåking av SPF fanger opp slike endringer før de rammer e-postleveransen. ## Oppsummering SPF PermError på grunn av for mange DNS-oppslag er en av de vanligste – og mest unødvendige – årsakene til at e-post feiler autentisering. Tell oppslagene rekursivt, fjern tjenester du ikke bruker, flytt utsendelsestjenester til egne subdomener og bruk ip4/ip6 for egne servere. Fordi leverandører endrer postene sine over tid, lønner det seg å overvåke SPF løpende. MailWatch teller oppslagene dine automatisk og varsler deg på e-post, SMS eller Pushover hvis grensen overskrides. Du kan [prøve gratis i 30 dager](https://mailwatch.no/auth/register) uten kredittkort. --- # Slik leser du DMARC-rapporter (RUA) URL: https://mailwatch.no/blog/lese-dmarc-rapporter Publisert: 2026-09-26 DMARC-rapporter viser hvem som sender e-post i ditt navn. Her forklarer vi XML-strukturen med et eksempel, hva du skal se etter, og hvordan du skiller legitime avsendere fra forfalskning. En DMARC-rapport (RUA, aggregert rapport) er en XML-fil som mottakere som Google, Microsoft og Yahoo sender deg, vanligvis én gang i døgnet. Den viser hvilke IP-adresser som har sendt e-post med ditt domene i From-feltet, hvor mange meldinger det var, og om de passerte SPF, DKIM og DMARC. Ved å lese rapportene finner du alle legitime avsendere som må rettes opp, og du ser om noen forsøker å forfalske domenet ditt. **Kort fortalt:** - Rapportene kommer som zip- eller gzip-komprimerte XML-vedlegg til adressen i rua= i DMARC-posten. - Hver beskriver én IP-adresse, antall meldinger, DMARC-resultatet og de rå SPF- og DKIM-resultatene. - policy_evaluated viser om SPF/DKIM passerte med alignment – det er det DMARC bryr seg om. - Kjente tjenester som feiler må rettes opp; ukjente IP-er som feiler alt er ofte forfalskning eller videresending. - Videresending bryter SPF, men DKIM overlever ofte. ARC (RFC 8617) hjelper mottakere å stole på videresendere. ## Hva er en DMARC-rapport? DMARC (RFC 7489) definerer to typer rapporter: - Aggregerte rapporter (rua): Statistikk per avsender-IP over en periode, typisk 24 timer. Inneholder ikke innholdet i meldingene. Det er disse denne artikkelen handler om. - Feilrapporter (ruf): Kopier eller utdrag av enkeltmeldinger som feilet. Få store mottakere sender dem i dag, blant annet av personvernhensyn. Du ber om aggregerte rapporter ved å legge til rua= i DMARC-posten: ``` _dmarc.firma.no. TXT "v=DMARC1; p=none; rua=mailto:dmarc@firma.no" ``` Skal rapportene sendes til en adresse på et annet domene, for eksempel en tjeneste som tolker dem for deg, må mottakerdomenet bekrefte at det tar imot rapporter for ditt domene med en egen DNS-post (firma.no._report._dmarc.mottaker.no). Seriøse rapporttjenester ordner dette automatisk. Er du usikker på grunnlaget, les først [hva DMARC er](https://mailwatch.no/blog/hva-er-dmarc). ## XML-strukturen forklart med et eksempel Her er en forenklet, men realistisk rapport fra en stor mottaker for domenet firma.no. Den inneholder to records: én fra Microsoft 365 som passerer, og én fra en ukjent IP som feiler. ``` google.com noreply-dmarc-support@google.com 1234567890123456789 1758844800 1758931199 firma.no r r none none 100 40.107.22.51 148 none pass pass firma.no firma.no selector1 pass firma.no pass 203.0.113.77 12 none fail fail firma.no mail.eksempel.net pass ``` ### report_metadata Hvem som har laget rapporten (org_name), en unik rapport-ID og perioden rapporten dekker. Tidspunktene i date_range er Unix-tid i sekunder (UTC). I eksempelet dekker rapporten ett døgn. ### policy_published DMARC-posten slik mottakeren så den da den behandlet meldingene. Nyttig for å bekrefte at en endring faktisk har slått igjennom: står det fortsatt p=none i rapportene etter at du byttet til quarantine, har mottakeren ikke sett den nye posten ennå. ### record og row Hver record samler meldinger med samme kombinasjon av avsender-IP og resultater. **source_ip** er IP-adressen som leverte meldingene, og **count** er hvor mange meldinger det gjelder. ### policy_evaluated Dette er DMARC-vurderingen. **disposition** viser hva mottakeren faktisk gjorde (none, quarantine eller reject). **dkim** og **spf** her viser om de passerte med alignment mot From-domenet. DMARC passerer hvis minst én av dem er pass. Feltet kan også ha en **reason** med typer som forwarded, mailing_list, local_policy eller trusted_forwarder hvis mottakeren har overstyrt policyen. ### identifiers **header_from** er domenet i From-feltet, altså det mottakeren ser. Noen rapportører tar også med envelope_from (Return-Path-domenet). ### auth_results De rå resultatene for SPF og DKIM, uavhengig av alignment. Her ser du hvilket domene SPF ble sjekket mot, og hvilket domene og hvilken selector DKIM-signaturen brukte. **Viktig:** Ikke la deg lure av «spf: pass» i auth_results. I den andre recorden i eksempelet passerer SPF for mail.eksempel.net, men policy_evaluated sier spf fail. Det betyr at SPF passerte for et annet domene enn firma.no, og derfor ikke gir alignment. Det er policy_evaluated som avgjør DMARC-resultatet. ## Hva du skal se etter Når du går gjennom rapportene, er det lurt å gruppere records etter avsender-IP og organisasjon, og så sortere etter antall meldinger. Still disse spørsmålene for hver kilde: - Hvem eier IP-adressen? Slå opp PTR (reverse DNS) og eventuelt hvem som eier IP-blokken. 40.107.x.x tilhører Microsoft, 209.85.x.x Google, og nyhetsbrev- og transaksjonstjenester har gjerne tydelige vertsnavn. - Er dette en tjeneste vi bruker? Sammenlign med listen over systemer som skal sende for domenet. - Passerer den DMARC? Minst én av dkim og spf i policy_evaluated må være pass. - Hvis den feiler – hvorfor? Se i auth_results: mangler DKIM-signatur, signeres det med leverandørens domene, eller står IP-en ikke i SPF? ## Legitime kilder eller forfalskning? De fleste kilder i rapportene havner i en av fire kategorier. Tabellen gir et utgangspunkt for hvordan du tolker og håndterer dem. | Mønster i rapporten | Sannsynlig forklaring | Hva du gjør | | Kjent tjeneste, SPF og DKIM pass | Riktig konfigurert avsender | Ingenting – dette er målet | | Kjent tjeneste, DKIM pass med leverandørens domene, DMARC fail | DKIM er ikke satt opp for ditt domene | Aktiver egen DKIM (ofte CNAME-poster) i tjenesten | | Kjent tjeneste, SPF fail, ingen DKIM | Tjenesten mangler i SPF og signerer ikke | Legg til include i SPF og sett opp DKIM | | Ukjent IP, SPF og DKIM fail, ofte fra mange land | Forfalskning (spoofing) eller spam | Ingenting å rette – p=reject stopper dette | | Ukjent IP, SPF fail, men DKIM pass for ditt domene | Videresending eller e-postliste | Normalt, DMARC passerer takket være DKIM | Et klassisk forfalskningsmønster er et lite antall meldinger fra IP-adresser i helt andre deler av verden, uten DKIM-signatur og med SPF som enten feiler eller passerer for et helt annet domene. Ser du dette samtidig med at ansatte får falske fakturaer, bør du prioritere å komme til p=reject. Les mer om [direktørsvindel og falske fakturaer](https://mailwatch.no/blog/direktorsvindel-falske-fakturaer). **Tips:** Ikke få panikk over et par meldinger fra ukjente IP-er. Alle domener blir forsøkt forfalsket innimellom. Det viktige er at dine legitime tjenester passerer, slik at du trygt kan stramme inn policyen. ## Videresending, e-postlister og ARC Videresending er den vanligste grunnen til at legitim e-post feiler i rapportene. Når en mottaker videresender e-post fra jobbadressen til en privat Gmail-konto, blir meldingen levert fra videresenderens server. Den IP-adressen står selvfølgelig ikke i din SPF-post, så SPF feiler. DKIM overlever derimot som regel, fordi signaturen følger med meldingen. Så lenge innholdet og de signerte headerne ikke endres, passerer DKIM fortsatt med alignment, og DMARC passerer. Dette er hovedgrunnen til at alle avsendere bør ha DKIM for eget domene. E-postlister er vanskeligere. De endrer ofte emnefeltet (for eksempel ved å legge til [liste]) eller legger til en bunntekst, og da brytes DKIM-signaturen. Mange listeservere løser det ved å skrive om From-adressen til listens egen adresse. ARC (Authenticated Received Chain, RFC 8617) er laget for dette problemet. En videresender som støtter ARC registrerer autentiseringsresultatene slik de var da meldingen kom inn, og signerer dem. Neste mottaker kan da velge å stole på den kjeden og la meldingen passere selv om SPF og DKIM nå feiler. I rapportene ser du det ofte som en reason med type forwarded, trusted_forwarder eller local_policy i policy_evaluated. Du kan ikke styre ARC selv som avsender, men det er nyttig å vite hvorfor noen meldinger som feiler DMARC likevel ikke blir avvist. ## Manuell lesing eller automatisk analyse? For et lite domene med én eller to avsendere kan du fint lese noen rapporter manuelt for å forstå hvordan de fungerer. Men volumet vokser raskt: hver mottaker sender én rapport per døgn, rapportene er komprimerte vedlegg, og samme avsender dukker opp i mange rapporter fra ulike mottakere. Det er uoversiktlig å følge utviklingen over tid. Et verktøy som mottar og tolker rapportene automatisk slår sammen dataene per avsender, slår opp hvem som eier IP-adressene og viser trender. Det gjør det mye enklere å gå trygt fra p=none til p=reject, slik vi beskriver i [DMARC-oppsett steg for steg](https://mailwatch.no/blog/dmarc-oppsett-steg-for-steg). [Bilde: MailWatch liste over tolkede DMARC-rapporter per rapportør med SPF- og DKIM-resultat]MailWatch tolker DMARC-rapportene automatisk og viser SPF- og DKIM-resultat per rapportør og avsender. ## Ofte stilte spørsmål ### Hvor ofte kommer DMARC-rapporter? De fleste store mottakere sender aggregerte DMARC-rapporter én gang i døgnet, og hver rapport dekker vanligvis 24 timer. Du får én rapport fra hver mottaker som har fått e-post fra domenet ditt i perioden. Små mottakere sender ofte ikke rapporter i det hele tatt. ### Hva er forskjellen på rua og ruf? rua er adressen for aggregerte rapporter, som inneholder statistikk per avsender-IP uten meldingsinnhold. ruf er adressen for feilrapporter, som kan inneholde utdrag av enkeltmeldinger som feilet. Få store mottakere sender feilrapporter i dag, så rua er den viktigste. ### Hvorfor passerer SPF i auth_results, men feiler i policy_evaluated? auth_results viser det rå SPF-resultatet for domenet i envelope-from, mens policy_evaluated viser om resultatet var alignet med From-domenet. Hvis SPF passerte for leverandørens domene og ikke ditt, feiler SPF i DMARC-sammenheng. Løsningen er vanligvis å sette opp DKIM for ditt eget domene hos tjenesten. ### Er alle ukjente IP-adresser i rapporten svindlere? Nei. Mange ukjente IP-er er videresendere, e-postlister eller tjenester noen i bedriften har tatt i bruk uten å si fra. Sjekk PTR og hvem som eier IP-blokken før du konkluderer. Kilder som feiler både SPF og DKIM og ikke kan knyttes til en kjent tjeneste, er som regel forfalskning. ### Kan jeg sende DMARC-rapporter til en annen adresse enn mitt eget domene? Ja, rua kan peke til en adresse på et annet domene, for eksempel en rapporttjeneste. Da må mottakerdomenet publisere en DNS-post som bekrefter at det tar imot rapporter for ditt domene. Uten den posten vil mange mottakere ikke sende rapportene. ## Oppsummering DMARC-rapporter er det beste verktøyet du har for å forstå hvem som sender e-post i ditt navn. Se på policy_evaluated for DMARC-resultatet, bruk auth_results for å finne årsaken når noe feiler, og skill mellom legitime tjenester, videresending og forfalskning. MailWatch tar imot og tolker rapportene automatisk, viser avsenderne dine med SPF- og DKIM-resultat, og varsler deg hvis noe endrer seg. Start med å [sjekke domenet ditt gratis](https://mailwatch.no/domenesjekk), eller [prøv MailWatch gratis i 30 dager](https://mailwatch.no/auth/register). --- # Står e-postserveren din på en svarteliste? Slik sjekker og fjerner du den URL: https://mailwatch.no/blog/svartelister-e-post Publisert: 2026-09-26 En oppføring på Spamhaus, SpamCop eller Barracuda kan stoppe e-posten din over natta. Slik sjekker du svartelister, finner årsaken, ber om fjerning og unngår å havne der igjen. Står e-postserveren din på en svarteliste (DNSBL), vil mange mottakere avvise eller filtrere e-posten fra deg. Du sjekker det ved å slå opp sende-IP-en og domenet mot de store listene som Spamhaus, SpamCop og Barracuda. For å bli fjernet må du først finne og stoppe årsaken – typisk en kompromittert konto eller infisert maskin – og deretter be om fjerning hos hver liste. **Kort fortalt:** - De viktigste listene er Spamhaus (ZEN = SBL + XBL + PBL, pluss DBL for domener), SpamCop og Barracuda . - Finn og stopp årsaken før du ber om fjerning – ellers blir du listet igjen, ofte raskere. - SpamCop og UCEPROTECT nivå 1 utløper automatisk; Spamhaus og Barracuda har egne skjemaer for fjerning. - Betal aldri for «ekspressfjerning» – UCEPROTECT nivå 2 og 3 brukes av få store mottakere. ## Hva er en svarteliste (DNSBL)? En DNSBL (DNS-based Blocklist) er en liste over IP-adresser eller domener som har sendt spam, er kompromittert eller ikke burde sende e-post direkte. Mottakende e-postservere slår opp avsenderens IP i sanntid via DNS. Står IP-en på listen, kan serveren avvise e-posten med en feilmelding, eller gi den en høyere spamscore. Oppslaget skjer ved å snu IP-adressen og legge til listens domene. For IP-en 203.0.113.25 ser det slik ut: ``` dig +short 25.113.0.203.zen.spamhaus.org 127.0.0.11 Svarteliste-oppføringer er en av de vanligste årsakene til plutselige leveranseproblemer. Se også oversikten over [hvorfor e-post havner i søppelpost](https://mailwatch.no/blog/hvorfor-havner-e-post-i-spam) for andre årsaker. ## De viktigste svartelistene Det finnes hundrevis av svartelister, men bare et fåtall brukes bredt. Disse bør du bry deg om: | Liste | Hva den inneholder | Fjerning | | Spamhaus SBL | IP-er knyttet til spamoperasjoner og tjenester som støtter dem, manuelt vurdert | Kontakt Spamhaus via deres oppslagsverktøy; ofte via nettleverandøren | | Spamhaus CSS (del av SBL) | Automatisk listing av IP-er med dårlig sendeatferd, f.eks. «snowshoe»-spam | Selvbetjent via Spamhaus når årsaken er rettet | | Spamhaus XBL | Kompromitterte maskiner, botnett, infiserte enheter og misbrukte proxyer | Selvbetjent etter at infeksjonen er fjernet | | Spamhaus PBL | IP-områder som ikke skal sende direkte til MX (typisk dynamiske/privatkunde-IP-er) | Ikke en straff – kan fjernes for egne e-postservere med riktig rDNS | | Spamhaus DBL | Domener brukt i spam, phishing eller skadevare (også lenker i e-post) | Skjema hos Spamhaus | | SpamCop (SCBL) | IP-er rapportert av brukere og fanget i spamfeller | Utløper automatisk ca. 24 timer etter siste rapport | | Barracuda (BRBL) | IP-er med dårlig omdømme observert av Barracudas nettverk | Gratis skjema på barracudacentral.org | | UCEPROTECT L1/L2/L3 | Enkelt-IP (L1), hele IP-blokker (L2) eller hele nettverk/ASN (L3) | L1 utløper automatisk; se forbehold nedenfor | **Spamhaus ZEN** er en samleliste som slår sammen SBL, CSS, XBL og PBL i ett oppslag, og er den som oftest brukes av e-postservere. Står du på ZEN, er det blant det alvorligste som kan skje for e-postleveransen. I tillegg har Microsoft og Gmail sine egne, interne omdømmesystemer. Blokkeres du av Outlook.com eller Microsoft 365 med en feilmelding som viser til blokkert IP, ber du om fjerning via Microsofts egen portal for avsendere (sender.office.com). ## Slik sjekker du om du står på en svarteliste - Finn riktig IP-adresse. Det er IP-en som leverer e-posten til mottakeren som teller – se i headerne på en sendt e-post (den første Received -linjen utenfor ditt eget nettverk). Bruker du Microsoft 365 eller Google Workspace, er det deres IP-er, og de håndterer omdømmet selv. - Sjekk hos listene direkte. Spamhaus har et eget oppslagsverktøy for IP og domene på check.spamhaus.org, og Barracuda har oppslag på barracudacentral.org. - Sjekk domenet også. Domene-lister som Spamhaus DBL gjelder både avsenderdomenet og domener du lenker til. - Les feilmeldingen. Avviste e-poster (bounces) sier ofte eksakt hvilken liste som blokkerer, f.eks. 554 5.7.1 Service unavailable; Client host [203.0.113.25] blocked using zen.spamhaus.org . **Viktig:** Spamhaus blokkerer oppslag som går via store offentlige DNS-resolvere (som 8.8.8.8 eller 1.1.1.1) og svarer da med en feilkode i 127.255.255.x-området. Mange enkle sjekkverktøy tolker dette feilaktig som en oppføring. Bekreft alltid med Spamhaus sitt eget oppslagsverktøy før du går i gang med tiltak. Du kan også [sjekke domenet ditt gratis](https://mailwatch.no/domenesjekk) med MailWatch, som slår opp MX- og sende-IP-er mot de viktigste listene samtidig. [Bilde: MailWatch oversikt over sendende servere med SPF-autorisasjon, PTR og svartelistestatus per IP]Under «Avsendere» viser MailWatch hver sendende server med SPF-autorisasjon, PTR og svartelistestatus. ## Finn årsaken før du ber om fjerning Dette er steget mange hopper over. Ber du om fjerning uten å ha rettet problemet, blir du listet igjen – og de fleste lister gjør det vanskeligere, eller umulig for en periode, å bli fjernet andre gang. Vanlige årsaker: - Kompromittert e-postkonto: Et passord på avveie brukes til å sende spam via din server. Sjekk utgående kø og logger for uvanlige volumer, og tving passordbytte og MFA. - Infisert maskin eller enhet: En PC, et kamera eller en ruter i nettverket er del av et botnett (typisk XBL-oppføring). Finn enheten via brannmurlogger – se etter utgående trafikk på port 25 fra andre enn e-postserveren. - Misbrukt nettskjema: Kontaktskjemaer og nyhetsbrevpåmelding uten CAPTCHA kan brukes til å sende e-post til tilfeldige mottakere. - Kompromittert nettside: Et utdatert WordPress-tillegg kan gi angripere mulighet til å sende e-post fra webserveren. - Dårlig listehygiene: Nyhetsbrev til gamle eller kjøpte lister treffer spamfeller. - Delt IP: På delt hosting kan en annen kunde være synderen. Da må hostingleverandøren rydde opp. **Tips:** Blokker utgående port 25 i brannmuren for alt unntatt e-postserveren din. Det alene hindrer de fleste XBL-oppføringer fra infiserte enheter. ## Slik ber du om fjerning (delisting) ### Spamhaus Slå opp IP-en eller domenet i Spamhaus sitt oppslagsverktøy. Det viser hvilken liste du står på, hvorfor, og hvilke steg som gjelder. For **XBL** og **CSS** kan du som regel be om fjerning selv når årsaken er rettet. For **SBL** er oppføringen ofte knyttet til nettleverandøren, og det er de som må ta kontakt. **PBL** er ikke en straff: den betyr bare at IP-området ikke er ment for direkte e-postlevering. Driver du en ekte e-postserver på en fast IP, kan du be om fjerning, men sørg først for at PTR peker på et eget vertsnavn som `mail.firma.no`. ### SpamCop SpamCop-oppføringer utløper automatisk omtrent 24 timer etter siste rapport eller spamfelletreff. Den eneste måten å bli fjernet på er å stoppe spammen. Gjentatte oppføringer er et tydelig tegn på at problemet ikke er løst. ### Barracuda Barracuda har et gratis skjema for fjerning på barracudacentral.org. Du oppgir IP, e-postadresse og en kort forklaring på hva som er gjort. Behandlingen tar vanligvis kort tid. ### UCEPROTECT – et viktig forbehold UCEPROTECT nivå 1 lister enkelt-IP-er og utløper automatisk etter en tid uten ny spam. Nivå 2 og 3 lister hele IP-blokker og nettverk, så også helt uskyldige kunder hos samme leverandør blir oppført. UCEPROTECT tilbyr betalt «ekspressfjerning», men vi anbefaler ikke å betale: nivå 2 og 3 brukes av svært få store e-postmottakere, og oppføringen påvirker sjelden leveransen i praksis. Står du bare på UCEPROTECT L2/L3, og e-posten ellers kommer frem, kan du trygt la det være. ### Microsoft og andre leverandører For blokkeringer hos Outlook.com og Microsoft 365 bruker du Microsofts avsenderportal. Registrer også IP-ene dine i Microsoft SNDS og domenet i Google Postmaster Tools, slik at du ser omdømmet over tid. ## Slik unngår du å havne på svartelister igjen - Ha korrekt autentisering. SPF, DKIM og DMARC reduserer misbruk av domenet ditt og gjør det lettere å skille legitim e-post fra forfalskninger. Start med DMARC steg for steg . - Sørg for riktig PTR og HELO. Sende-IP-en bør ha en PTR som peker på et vertsnavn i ditt domene, og som peker tilbake til samme IP. - Beskytt kontoer. MFA på alle e-postkontoer, og varsling ved uvanlige utgående volumer. - Begrens utgående port 25 til e-postserveren. - Hold listene rene. Double opt-in, fjern hard bounces, kjøp aldri lister. - Overvåk kontinuerlig. Jo raskere du oppdager en oppføring, desto mindre skade gjør den. ## Ofte stilte spørsmål ### Hvordan sjekker jeg om IP-adressen min står på en svarteliste? Finn IP-adressen som faktisk leverer e-posten din, og slå den opp hos de store listene som Spamhaus, SpamCop og Barracuda, eller bruk et verktøy som sjekker mange lister samtidig. Bekreft Spamhaus-treff i deres eget oppslagsverktøy, fordi oppslag via offentlige DNS-resolvere kan gi falske treff. ### Hvor lang tid tar det å bli fjernet fra en svarteliste? Det varierer. SpamCop fjerner oppføringen automatisk omtrent 24 timer etter siste rapport, Barracuda og Spamhaus XBL/CSS behandles ofte raskt etter en forespørsel, mens SBL kan ta lenger tid fordi nettleverandøren må involveres. Uansett må årsaken være rettet først. ### Hva er Spamhaus PBL, og er det farlig å stå der? PBL (Policy Block List) lister IP-områder som ikke er ment for direkte e-postlevering, typisk dynamiske IP-er for privatkunder. Det er ikke en straff for spam. Sender du via en ordinær e-posttjeneste, påvirker det deg ikke, men en egen e-postserver på en slik IP må enten fjernes fra PBL eller sende via en relé. ### Bør jeg betale UCEPROTECT for å bli fjernet? Nei, i de fleste tilfeller ikke. UCEPROTECT nivå 1 utløper automatisk, og nivå 2 og 3, som lister hele nettverk, brukes av svært få store e-postmottakere. Kommer e-posten din ellers frem, har oppføringen liten praktisk betydning. ### Hvorfor ble jeg svartelistet igjen rett etter fjerning? Nesten alltid fordi årsaken ikke er løst: en kompromittert konto, en infisert enhet eller et misbrukt nettskjema sender fortsatt spam. Undersøk logger og utgående trafikk grundig før du ber om fjerning på nytt, siden gjentatte oppføringer gjør neste fjerning vanskeligere. ## Oppsummering En svarteliste-oppføring er alvorlig, men som regel mulig å løse raskt: finn riktig IP, bekreft oppføringen hos listen selv, stopp årsaken og be om fjerning. Spamhaus er den viktigste å holde seg unna, mens UCEPROTECT nivå 2 og 3 sjelden har praktisk betydning. MailWatch sjekker MX- og sende-IP-ene dine mot svartelister døgnet rundt og varsler deg på e-post, SMS eller Pushover så snart noe dukker opp – ofte før kundene merker det. Du kan [prøve MailWatch gratis i 30 dager](https://mailwatch.no/auth/register). --- # SPF, DKIM og DMARC for Microsoft 365: komplett oppsettsguide URL: https://mailwatch.no/blog/spf-dkim-dmarc-microsoft-365 Publisert: 2026-09-26 Slik setter du opp SPF, DKIM og DMARC riktig for Microsoft 365 – med nøyaktige DNS-poster, DKIM-aktivering i Defender-portalen og tips for tredjepartsavsendere. For å autentisere e-post fra Microsoft 365 trenger domenet ditt tre ting: en SPF-post med **include:spf.protection.outlook.com**, to DKIM-CNAME-poster (**selector1** og **selector2**) som du aktiverer i Microsoft Defender-portalen, og en DMARC-post på **_dmarc**. Microsoft setter ikke opp dette automatisk for ditt eget domene – det må du gjøre selv i DNS. Denne guiden viser nøyaktig hvilke poster du trenger, i hvilken rekkefølge, og hvordan du tar med tredjepartstjenester som sender på vegne av domenet. **Kort fortalt:** - SPF: v=spf1 include:spf.protection.outlook.com -all – legg til andre tjenester i samme post, aldri lag to SPF-poster. - DKIM: publiser to CNAME-poster (selector1 og selector2) og slå på signering i Defender-portalen. Uten dette signerer Microsoft med onmicrosoft.com-domenet, som ikke gir DMARC-alignment. - DMARC: start med p=none og rapporter (rua), gå til quarantine og reject når alle legitime avsendere er på plass. - Nyhetsbrev, CRM, fakturasystem og nettbutikk må også autentiseres – ellers vil de feile når DMARC strammes inn. ## Hvorfor du må gjøre dette selv Når du legger til et eget domene som firma.no i Microsoft 365, ber oppsettveiviseren deg om MX-posten, autodiscover-posten og en SPF-post. Mange stopper der. Men DKIM for ditt eget domene er ikke aktivert som standard, og DMARC nevnes knapt. Resultatet er at e-post fra firma.no ofte bare er beskyttet av SPF – og at DKIM-signaturen som Microsoft legger på, peker til firma.onmicrosoft.com i stedet for firma.no. Det holder ikke lenger. Gmail og Yahoo har siden februar 2024 krevd SPF, DKIM og DMARC for avsendere som sender over 5 000 meldinger per dag, og Microsoft innførte tilsvarende krav for Outlook.com fra 5. mai 2025. Selv om du sender langt mindre, bruker mottakerne autentisering som et viktig signal i spamfilteret. Les mer om kravene i [de nye kravene fra Gmail, Yahoo og Outlook](https://mailwatch.no/blog/krav-gmail-yahoo-outlook-avsendere). De tre standardene jobber sammen: - SPF (RFC 7208) sier hvilke servere som får sende e-post for domenet ditt. Se hva er SPF for grunnleggende forklaring. - DKIM (RFC 6376) legger en kryptografisk signatur på hver melding. - DMARC (RFC 7489) krever at SPF eller DKIM stemmer med domenet i Fra-feltet (alignment), og forteller mottakeren hva som skal skje hvis ingen av dem gjør det. ## SPF for Microsoft 365 SPF-posten er en TXT-post på roten av domenet (vises ofte som @ hos DNS-leverandøren). Hvis Microsoft 365 er det eneste som sender e-post fra domenet, ser den slik ut: ``` firma.no. TXT "v=spf1 include:spf.protection.outlook.com -all" ``` `include:spf.protection.outlook.com` dekker alle IP-adressene Exchange Online sender fra. `-all` betyr at alt annet skal avvises (hard fail). Microsoft anbefaler selv `-all` for domener der du har full oversikt. Er du usikker på om alle avsendere er med, kan du starte med `~all` (soft fail) og stramme inn senere – DMARC er uansett det som i praksis styrer hva som skjer med meldinger som feiler. ### Legg til andre avsendere i samme post Et domene kan bare ha **én** SPF-post. To poster som begge starter med `v=spf1` gir PermError, og da feiler SPF for all e-post. Sender du også via for eksempel Mailchimp, et fakturasystem eller en webserver, slår du det sammen: ``` firma.no. TXT "v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net ip4:203.0.113.25 -all" ``` ### Pass på grensen på 10 DNS-oppslag SPF tillater maksimalt 10 DNS-oppslag per evaluering. Mekanismene `include`, `a`, `mx`, `ptr`, `exists` og `redirect` teller, mens `ip4`, `ip6` og `all` ikke gjør det. Oppslag inne i hver include teller også. Microsoft sin include bruker selv et par oppslag, så med fire–fem tredjepartstjenester er det fort gjort å bomme. I tillegg er det en grense på 2 «void lookups» (oppslag som ikke gir svar). Les mer i [SPF PermError: for mange DNS-oppslag](https://mailwatch.no/blog/spf-for-mange-dns-oppslag). **Viktig:** Ikke legg inn `include:outlook.com` eller `include:hotmail.com` – det er feil include for Microsoft 365 og autoriserer i stedet forbrukertjenestene. Riktig verdi er `spf.protection.outlook.com`. ## DKIM i Microsoft 365: CNAME-poster og aktivering Microsoft 365 bruker to DKIM-selektorer, **selector1** og **selector2**. I stedet for at du legger inn den offentlige nøkkelen selv, publiserer du to CNAME-poster som peker til nøkler Microsoft håndterer. Det gjør at Microsoft kan rotere nøklene uten at du må endre DNS. ### Steg 1: Finn de riktige CNAME-verdiene Gå til Microsoft Defender-portalen (security.microsoft.com) og velg **E-post og samarbeid → Policyer og regler → Trusselpolicyer → Innstillinger for e-postgodkjenning** (Email authentication settings), og deretter fanen **DKIM**. Klikk på domenet ditt. Portalen viser de to CNAME-postene du skal publisere. For mange tenanter ser de slik ut: ``` selector1._domainkey.firma.no. CNAME selector1-firma-no._domainkey.firma.onmicrosoft.com. selector2._domainkey.firma.no. CNAME selector2-firma-no._domainkey.firma.onmicrosoft.com. ``` Punktum i domenet erstattes med bindestrek (firma.no blir firma-no), og siste del er tenantens opprinnelige onmicrosoft.com-domene. For domener som er lagt til nyere kan Microsoft vise et annet mål-format (under dkim.mail.microsoft). **Kopier alltid verdiene nøyaktig slik portalen viser dem** i stedet for å bygge dem selv. ### Steg 2: Publiser postene i DNS Opprett de to CNAME-postene hos DNS-leverandøren din. Mange norske leverandører vil at du bare skriver vertsnavnet (`selector1._domainkey`), ikke hele navnet med domenet på slutten. Vent til postene er synlige – vanligvis minutter, men det kan ta opp til noen timer avhengig av TTL. ### Steg 3: Slå på DKIM-signering Tilbake i Defender-portalen setter du bryteren **Signer meldinger for dette domenet med DKIM-signaturer** til på. Hvis postene ikke er på plass ennå, får du en feilmelding om at CNAME-postene ikke finnes. Foretrekker du PowerShell (Exchange Online), gjør du det samme slik: ``` New-DkimSigningConfig -DomainName firma.no -Enabled $false Get-DkimSigningConfig -Identity firma.no | Format-List Selector1CNAME, Selector2CNAME Set-DkimSigningConfig -Identity firma.no -Enabled $true ``` Nye nøkler er 2048-bit som standard. Har du et eldre oppsett med 1024-bit, kan du rotere til 2048-bit med `Rotate-DkimSigningConfig -Identity firma.no -KeySize 2048` eller via «Roter DKIM-nøkler» i portalen. ### Steg 4: Kontroller at det virker Send en e-post til en Gmail-konto og velg «Vis original». Du skal se `DKIM: PASS with domain firma.no`. Står det firma.onmicrosoft.com, er signeringen for ditt eget domene ikke aktiv ennå. ## DMARC for Microsoft 365 Når SPF og DKIM er på plass, legger du til DMARC som en TXT-post på `_dmarc.firma.no`. Start alltid med overvåking: ``` _dmarc.firma.no. TXT "v=DMARC1; p=none; rua=mailto:dmarc@firma.no; fo=1" ``` `p=none` betyr at mottakerne ikke gjør noe med meldinger som feiler, men de sender deg daglige aggregerte rapporter (rua). Rapportene viser hvem som sender e-post med ditt domene i Fra-feltet, og om SPF og DKIM passerer. Det er den eneste pålitelige måten å finne tjenester du har glemt. Når rapportene viser at all legitim e-post passerer, strammer du inn trinnvis: | Fase | DMARC-post | Typisk varighet | | Overvåking | p=none; rua=… | 2–4 uker, eller til alle avsendere er kartlagt | | Delvis karantene | p=quarantine; pct=25; rua=… | 1–2 uker | | Full karantene | p=quarantine; rua=… | 2–4 uker | | Avvisning | p=reject; rua=… | Permanent | Den detaljerte fremgangsmåten finner du i [DMARC steg for steg fra p=none til p=reject](https://mailwatch.no/blog/dmarc-oppsett-steg-for-steg). [Bilde: MailWatch viser mottatte DMARC-rapporter per rapportør med SPF- og DKIM-resultat]MailWatch tar imot og tolker DMARC-rapportene, slik at du ser hvilke tjenester som sender på vegne av domenet – og om de passerer. ## Hva med onmicrosoft.com-domenet? Alle Microsoft 365-tenanter har et opprinnelig domene som firma.onmicrosoft.com. Microsoft håndterer SPF og DKIM for dette domenet selv, så der trenger du ikke gjøre noe. To ting er likevel verdt å vite: - Ikke send ekstern e-post fra onmicrosoft.com. Sørg for at alle brukere, delte postbokser og programvare har ditt eget domene som primær avsenderadresse. Microsoft har også innført begrensninger på hvor mye ekstern e-post som kan sendes fra onmicrosoft.com-adresser, nettopp for å hindre misbruk. - Du kan legge til DMARC for onmicrosoft.com-domenet. I Microsoft 365 administrasjonssenter under Innstillinger → Domener kan du velge onmicrosoft.com-domenet og legge til en TXT-post med navnet _dmarc . En p=reject der hindrer at noen utgir seg for å være din tenant. ## Tredjepartsavsendere: nyhetsbrev, CRM og fakturering Den vanligste årsaken til problemer etter at DMARC er strammet inn, er ikke Microsoft 365 – det er alt det andre. Typiske eksempler i norske bedrifter: - Nyhetsbrevverktøy (Mailchimp, Brevo, Make og lignende) - Regnskaps- og fakturasystemer som sender faktura fra faktura@firma.no - CRM og kundeservice (HubSpot, Zendesk, Freshdesk) - Nettbutikk og nettside (WooCommerce, Shopify, kontaktskjema) - Skannere og multifunksjonsskrivere som sender «scan to e-mail» For hver tjeneste bør du sette opp DKIM med ditt eget domene (de fleste gir deg en eller flere CNAME- eller TXT-poster) og eventuelt legge dem til i SPF. For DMARC holder det at én av SPF eller DKIM passerer med alignment, og DKIM er det mest robuste valget fordi signaturen overlever videresending. **Tips:** Skannere og interne systemer som sender via SMTP, kan ofte sende gjennom Microsoft 365 i stedet for direkte ut på internett (SMTP AUTH på smtp.office365.com eller en tilkobling/connector). Da blir meldingene signert med DKIM av Microsoft, og du slipper å legge kontorets IP-adresse i SPF. ### Egne underdomener for masseutsendelser Sender dere store volumer markedsføring, kan det lønne seg å bruke et underdomene som nyhet.firma.no. Da får nyhetsbrevet sitt eget omdømme og sin egen SPF-post, og problemer der smitter mindre over på den vanlige e-posten fra firma.no. ## Vanlige feil i Microsoft 365-oppsett - To SPF-poster , for eksempel en gammel fra webhotellet og en ny fra Microsoft. Slå dem sammen til én. - DKIM aldri aktivert for eget domene. Signaturen viser da onmicrosoft.com, og DMARC må lene seg på SPF alene – som ryker ved videresending. - CNAME-poster med doble domenenavn , som selector1._domainkey.firma.no.firma.no , fordi DNS-leverandøren legger til domenet automatisk. - DMARC på p=reject for tidlig , før fakturasystemet eller nyhetsbrevet er autentisert. - Ingen rua-adresse i DMARC-posten, slik at du aldri ser rapportene og ikke oppdager problemer. Du kan raskt [sjekke domenet ditt gratis](https://mailwatch.no/domenesjekk) for å se om SPF, DKIM og DMARC er riktig satt opp. ## Ofte stilte spørsmål ### Hva skal SPF-posten være for Microsoft 365? Hvis bare Microsoft 365 sender e-post fra domenet, bruker du `v=spf1 include:spf.protection.outlook.com -all`. Sender andre tjenester også, legger du dem til i den samme posten. Et domene skal bare ha én SPF-post. ### Er DKIM slått på automatisk i Microsoft 365? Nei, ikke for egne domener. Microsoft signerer med tenantens onmicrosoft.com-domene som standard, og det gir ikke DMARC-alignment for ditt eget domene. Du må publisere CNAME-postene for selector1 og selector2 og aktivere signering i Defender-portalen. ### Hvorfor får jeg feilmelding når jeg prøver å aktivere DKIM? Som regel fordi CNAME-postene ikke er synlige i DNS ennå, eller fordi de er skrevet feil. Kontroller at vertsnavnet er selector1._domainkey og selector2._domainkey, at målet er kopiert nøyaktig fra portalen, og at DNS-leverandøren ikke har lagt domenet til to ganger. ### Trenger onmicrosoft.com-domenet SPF, DKIM og DMARC? SPF og DKIM for onmicrosoft.com-domenet håndteres av Microsoft. DMARC kan du legge til selv i Microsoft 365 administrasjonssenter under Domener. Det viktigste er uansett at ingen sender ekstern e-post fra onmicrosoft.com-adressen. ### Hvor lang tid tar det å gå fra p=none til p=reject? For de fleste små og mellomstore bedrifter tar det fra noen uker til et par måneder. Tiden avhenger av hvor mange tjenester som sender på vegne av domenet, og hvor raskt dere får satt opp DKIM for hver av dem. DMARC-rapportene viser når alt er på plass. ## Oppsummering Et komplett Microsoft 365-oppsett består av én SPF-post med spf.protection.outlook.com, to DKIM-CNAME-poster som er aktivert i Defender-portalen, og en DMARC-post som strammes inn gradvis. Det krevende er ikke Microsoft, men å få med alle tredjepartstjenestene – og å oppdage det når noe endrer seg senere. MailWatch overvåker SPF, DKIM, DMARC og svartelister kontinuerlig, tolker DMARC-rapportene for deg og varsler på e-post eller SMS når noe går galt. Du kan [prøve gratis i 30 dager](https://mailwatch.no/auth/register), uten kredittkort. --- # SPF, DKIM og DMARC for Google Workspace: slik setter du det opp riktig URL: https://mailwatch.no/blog/spf-dkim-dmarc-google-workspace Publisert: 2026-09-26 Steg for steg: SPF med _spf.google.com, 2048-bit DKIM-nøkkel fra Admin-konsollen og en DMARC-policy som beskytter domenet – også når andre tjenester sender for deg. For å autentisere e-post fra Google Workspace trenger du en SPF-post med **include:_spf.google.com**, en DKIM-nøkkel som du genererer i Google Admin-konsollen og publiserer som TXT-post på **google._domainkey**, og en DMARC-post på **_dmarc**. Google signerer ikke med ditt eget domene før du har gjort dette selv. Her får du hele oppsettet steg for steg, inkludert hvordan du tar med nyhetsbrev, CRM og andre tjenester som sender på vegne av domenet. **Kort fortalt:** - SPF: v=spf1 include:_spf.google.com ~all , med eventuelle andre avsendere i samme post. - DKIM: Admin-konsollen → Apper → Google Workspace → Gmail → Autentiser e-post. Velg 2048-bit og selektoren «google», publiser TXT-posten og klikk «Start autentisering». - DMARC: start med p=none og rua-rapporter, stram inn til quarantine og reject når alle legitime avsendere passerer. - Uten egen DKIM signerer Google med et gappssmtp.com-domene, som ikke gir DMARC-alignment. ## Hvorfor Google Workspace-oppsettet ikke er ferdig ut av boksen Når du registrerer firma.no i Google Workspace, får du beskjed om å verifisere domenet og legge inn MX-poster. E-posten fungerer da, og det er lett å tro at alt er i orden. Men uten egen DKIM-nøkkel signerer Google meldingene med et teknisk domene under gappssmtp.com, ikke med firma.no. Og uten DMARC har mottakerne ingen instruks om hva de skal gjøre med e-post som utgir seg for å komme fra deg. Det er et problem av to grunner. For det første har Gmail og Yahoo siden februar 2024 krevd SPF, DKIM og DMARC for avsendere med over 5 000 meldinger per dag til Gmail-adresser, og Microsoft innførte lignende krav for Outlook.com fra 5. mai 2025. For det andre bruker alle store e-posttjenester autentisering som et viktig signal når de vurderer om en melding er spam – også for små avsendere. Les mer i [de nye kravene fra Gmail, Yahoo og Outlook](https://mailwatch.no/blog/krav-gmail-yahoo-outlook-avsendere). Kort om rollene: - SPF (RFC 7208) lister opp hvilke servere som får sende for domenet. - DKIM (RFC 6376) signerer hver melding kryptografisk. Les hva er DKIM for en grundigere forklaring. - DMARC (RFC 7489) krever at SPF eller DKIM stemmer med Fra-domenet, og gir mottakeren en policy og en rapportadresse. ## SPF for Google Workspace SPF-posten legges som en TXT-post på roten av domenet. Hvis Google Workspace er den eneste avsenderen, er posten slik: ``` firma.no. TXT "v=spf1 include:_spf.google.com ~all" ``` Google anbefaler selv `~all` (soft fail). Du kan bruke `-all` når du vet at alle avsendere er med, men i praksis er det DMARC-policyen som avgjør hva mottakerne gjør med meldinger som feiler. ### Flere avsendere – fortsatt én post Et domene skal ha nøyaktig én SPF-post. Hvis webhotellet allerede har lagt inn en SPF-post, må du slå den sammen med Googles i stedet for å legge til en ny: ``` firma.no. TXT "v=spf1 include:_spf.google.com include:sendgrid.net ip4:198.51.100.10 ~all" ``` ### Tell DNS-oppslagene SPF har en grense på 10 DNS-oppslag. `include`, `a`, `mx`, `ptr`, `exists` og `redirect` teller; `ip4`, `ip6` og `all` gjør det ikke. Googles `_spf.google.com` bruker fire oppslag alene, fordi den inkluderer tre underliggende nettblokk-poster. Da har du seks igjen til alle andre tjenester. Det finnes også en grense på 2 «void lookups». Går du over, får du PermError og SPF feiler. Se [SPF PermError: for mange DNS-oppslag](https://mailwatch.no/blog/spf-for-mange-dns-oppslag) for hvordan du rydder. ## DKIM for Google Workspace: generer 2048-bit nøkkel I motsetning til Microsoft 365, der du publiserer CNAME-poster, legger du inn selve den offentlige nøkkelen som en TXT-post når du bruker Google Workspace. Slik gjør du det: ### Steg 1: Generer nøkkelen i Admin-konsollen - Logg inn på admin.google.com med en superadministrator-konto. - Gå til Meny → Apper → Google Workspace → Gmail → Autentiser e-post (Authenticate email). - Velg domenet (firma.no) i nedtrekkslisten. - Klikk Generer ny post . - Velg nøkkellengde 2048 og behold prefikset (selektoren) google , med mindre du allerede bruker «google» som selektor et annet sted. - Klikk Generer . Konsollen viser vertsnavnet og TXT-verdien. ### Steg 2: Publiser TXT-posten Posten ser omtrent slik ut (nøkkelen er forkortet her): ``` google._domainkey.firma.no. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…" ``` En 2048-bit nøkkel er lengre enn 255 tegn, som er grensen for én tekststreng i en TXT-post. De fleste DNS-leverandører deler opp verdien automatisk, men noen krever at du deler den i flere strenger i anførselstegn selv. Hvis leverandøren din ikke støtter lange TXT-poster i det hele tatt, kan du falle tilbake på 1024-bit – men 2048-bit er anbefalt og bør være målet. **Viktig:** Kopier hele nøkkelen uten linjeskift eller ekstra mellomrom. En manglende bokstav gjør signaturen ugyldig, og da feiler DKIM for all e-post når du slår det på. ### Steg 3: Start autentisering Vent til posten er synlig i DNS (ofte noen minutter, noen ganger lenger avhengig av TTL). Gå tilbake til **Autentiser e-post** og klikk **Start autentisering**. Statusen skal endre seg til at e-post blir autentisert med DKIM. For helt nye Google Workspace-kontoer kan det ta en stund – opptil et par døgn – før du i det hele tatt får generert nøkkelen, fordi Gmail må være aktivert for domenet først. ### Steg 4: Kontroller resultatet Send en melding til en annen e-postkonto, åpne «Vis original» (i Gmail) eller meldingskildene, og se etter `DKIM: PASS with domain firma.no` og `s=google` i DKIM-signaturen. Står det fortsatt gappssmtp.com, er ikke signeringen for ditt eget domene aktiv ennå. ## DMARC for Google Workspace Når SPF og DKIM fungerer, publiserer du DMARC som en TXT-post på `_dmarc.firma.no`. Start med overvåking: ``` _dmarc.firma.no. TXT "v=DMARC1; p=none; rua=mailto:dmarc@firma.no" ``` Med `p=none` skjer det ingenting med e-posten, men mottakere som Gmail, Outlook og Yahoo sender deg daglige aggregerte rapporter i XML-format. De viser hvilke IP-adresser og tjenester som sender med firma.no i Fra-feltet, og om de passerer SPF og DKIM med alignment. Rapportene er uleselige i rå form, så du trenger et verktøy som tolker dem. Les mer i [slik leser du DMARC-rapporter](https://mailwatch.no/blog/lese-dmarc-rapporter). [Bilde: Oversikt over DMARC-rapporter i MailWatch med SPF- og DKIM-resultat per rapportør]I MailWatch blir DMARC-rapportene tolket automatisk, så du ser hvilke avsendere som passerer og hvilke som mangler DKIM. ### Stram inn gradvis | Fase | Policy | Når du går videre | | 1. Overvåking | p=none | Når alle legitime avsendere passerer DKIM eller SPF med alignment | | 2. Karantene | p=quarantine (eventuelt med pct for å starte forsiktig) | Når rapportene er stabile i et par uker | | 3. Avvisning | p=reject | Sluttmål – forfalsket e-post avvises | Den komplette fremgangsmåten står i [DMARC steg for steg fra p=none til p=reject](https://mailwatch.no/blog/dmarc-oppsett-steg-for-steg). ## Tredjepartsavsendere og Google-spesifikke fallgruver Google Workspace er sjelden den eneste avsenderen. Nyhetsbrev, fakturasystem, CRM, bookingsystem og nettbutikk sender gjerne fra adresser på firma.no. Hver av dem må autentiseres før du går til `quarantine` eller `reject`: - Sett opp DKIM med eget domene i hver tjeneste. De fleste gir deg CNAME-poster (for eksempel s1._domainkey og s2._domainkey ) eller en TXT-post med egen selektor. Flere DKIM-selektorer på samme domene er helt normalt. - Legg til SPF-include der tjenesten bruker ditt domene som envelope-avsender. Mange tjenester bruker sitt eget returadresse-domene, og da hjelper SPF-includen ikke for DMARC – DKIM er det som teller. - Skannere og skrivere kan sende via Googles SMTP-relétjeneste (smtp-relay.gmail.com) i stedet for rett ut. Konfigureres dette i Admin-konsollen under Gmail → Ruting, og da går meldingene gjennom Google. ### Google Grupper og videresending E-post som går gjennom Google Grupper eller e-postlister kan få endret emnefelt eller bunntekst, og da brytes DKIM-signaturen. Google legger på ARC-headere (RFC 8617) som hjelper mottakere å stole på den opprinnelige autentiseringen, men ikke alle mottakere bruker ARC. Hold øye med DMARC-rapportene etter at du har gått til `reject`. **Tips:** Registrer domenet i Google Postmaster Tools. Når du sender en viss mengde e-post til Gmail-brukere, ser du domenets omdømme, spamrate og autentiseringsresultater direkte fra Google. Spamraten bør holdes under 0,3 %, helst under 0,1 %. ## Vanlige feil - To SPF-poster – en fra webhotellet og en fra Google. Slå dem sammen. - DKIM-nøkkel generert, men aldri aktivert. Mange publiserer TXT-posten og glemmer å klikke «Start autentisering». - Avkuttet DKIM-nøkkel fordi DNS-leverandøren bare tok de første 255 tegnene. - Feil vertsnavn , for eksempel google._domainkey.firma.no.firma.no , når leverandøren legger til domenet automatisk. - DMARC uten rua , slik at ingen ser når en tjeneste slutter å passere. Er du usikker på hvordan domenet ditt ser ut nå? [Sjekk domenet ditt gratis](https://mailwatch.no/domenesjekk) – du får status for SPF, DKIM, DMARC og MX på sekunder. ## Ofte stilte spørsmål ### Hva skal SPF-posten være for Google Workspace? Hvis bare Google Workspace sender e-post for domenet, bruker du `v=spf1 include:_spf.google.com ~all`. Andre tjenester legges til i den samme posten. Et domene skal aldri ha mer enn én SPF-post. ### Hvor finner jeg DKIM-innstillingene i Google Workspace? I Google Admin-konsollen under Apper → Google Workspace → Gmail → Autentiser e-post. Der velger du domenet, genererer en ny post med 2048-bit nøkkel og selektoren «google», publiserer TXT-posten i DNS og klikker «Start autentisering». ### Hva gjør jeg hvis DNS-leverandøren ikke godtar en 2048-bit DKIM-nøkkel? Prøv først å dele verdien i flere strenger på maksimalt 255 tegn i samme TXT-post, noe de fleste DNS-systemer støtter. Hvis leverandøren ikke støtter det, kan du generere en 1024-bit nøkkel i stedet. Det fungerer, men 2048-bit er anbefalt, så vurder å bytte DNS-leverandør på sikt. ### Signerer Google e-posten med DKIM uten at jeg gjør noe? Ja, men med et teknisk domene under gappssmtp.com, ikke med ditt eget domene. Det gir ikke DMARC-alignment. For at DKIM skal telle for DMARC, må du generere og aktivere en nøkkel for ditt eget domene. ### Hvor lang tid tar det før DKIM virker i Google Workspace? Når TXT-posten er synlig i DNS og du har klikket «Start autentisering», begynner Google å signere i løpet av kort tid, men det kan ta opptil 48 timer. For nyopprettede Google Workspace-kontoer må Gmail ha vært aktivt en stund før nøkkelen kan genereres. ## Oppsummering Et riktig Google Workspace-oppsett består av én SPF-post med _spf.google.com, en aktivert 2048-bit DKIM-nøkkel på google._domainkey, og en DMARC-policy som strammes inn fra `p=none` til `p=reject`. Det som oftest går galt senere, er at en ny tjeneste tas i bruk eller en DNS-post endres uten at noen merker det. MailWatch overvåker SPF, DKIM, DMARC, MX og svartelister kontinuerlig, tolker DMARC-rapportene og varsler deg på e-post, SMS eller Pushover. [Start en gratis prøveperiode](https://mailwatch.no/auth/register) for ett domene i 30 dager. --- # Direktørsvindel og falske fakturaer: slik beskytter e-postautentisering bedriften URL: https://mailwatch.no/blog/direktorsvindel-falske-fakturaer Publisert: 2026-09-26 Direktørsvindel og falske fakturaer koster norske bedrifter dyrt. Se hva DMARC faktisk stopper, hva det ikke stopper, og hvilke rutiner som tetter resten av hullene. Direktørsvindel (CEO-svindel) og falske fakturaer er e-postbasert svindel der angriperen utgir seg for å være en leder, en leverandør eller en kollega for å få noen til å betale penger til feil konto. E-postautentisering med SPF, DKIM og DMARC på `p=reject` stopper én viktig variant: at svindleren sender e-post med **nøyaktig ditt domene** i avsenderfeltet. Men den stopper ikke lookalike-domener eller kaprede e-postkontoer – derfor trenger du også MFA, faste betalingsrutiner og verifisering per telefon. **Kort fortalt:** - Svindlerne bruker tre hovedmetoder: forfalsket eksakt domene, lookalike-domener (som firrna.no) og kaprede, ekte e-postkontoer. - DMARC med p=reject stopper bare den første – men den er billig å stoppe og beskytter også kundene og leverandørene dine. - Mot lookalike-domener og kaprede kontoer hjelper MFA, merking av ekstern e-post, overvåking av liknende domener og rutiner. - Den viktigste enkeltregelen: endring av kontonummer eller hastebetalinger skal alltid bekreftes på telefon, til et nummer du har fra før. ## Hva er direktørsvindel og fakturasvindel? Internasjonalt kalles dette Business Email Compromise (BEC). Felles for alle variantene er at svindleren ikke trenger skadevare eller avansert hacking. Det holder med en troverdig e-post, litt research og et godt tidspunkt. Politiet, Økokrim og Nasjonal sikkerhetsmyndighet (NSM) har gjentatte ganger advart norske virksomheter mot denne typen svindel, og både store og små bedrifter, kommuner og organisasjoner er rammet. De vanligste scenarioene: - Direktørsvindel: En e-post som ser ut til å komme fra daglig leder, ber økonomiansvarlig om en rask og konfidensiell overføring – ofte begrunnet med et oppkjøp eller en hemmelig avtale. Den kommer gjerne når lederen er på reise eller i møter. - Falsk faktura eller endret kontonummer: En «leverandør» sender beskjed om at de har byttet bank, og at fremtidige fakturaer skal betales til et nytt kontonummer. Eller en faktura blir sendt med riktig logo og beløp, men feil kontonummer. - Lønnssvindel: En «ansatt» ber lønningsansvarlig oppdatere kontonummeret for lønnsutbetaling. - Gavekort-svindel: «Sjefen» ber en ansatt kjøpe gavekort til kunder og sende kodene på e-post. Svindlerne kjenner ofte navn, roller og leverandører fra nettsiden, LinkedIn, Brønnøysundregistrene og pressemeldinger. Det gjør e-postene overraskende troverdige. ## Slik utgir svindlerne seg for å være deg For å forstå hva e-postautentisering kan og ikke kan gjøre, må du skille mellom teknikkene: | Teknikk | Eksempel | Stoppes av DMARC p=reject? | | Forfalsket eksakt domene | Fra: daglig.leder@firma.no (sendt fra en fremmed server) | Ja | | Lookalike-domene | Fra: daglig.leder@firrna.no, firma-no.com, firma.co | Nei – domenet tilhører svindleren, som kan ha gyldig SPF, DKIM og DMARC | | Falskt visningsnavn | Fra: «Kari Nordmann, Firma AS» | Nei – e-posten er autentisk fra gmail.com | | Kapret konto | Ekte e-post fra leverandørens egen konto etter at passordet er stjålet | Nei – e-posten passerer all autentisering | Det er viktig å være ærlig om dette: DMARC er ikke en magisk løsning mot all svindel. Men forfalskning av eksakt domene er den enkleste og billigste teknikken for svindleren, og uten DMARC kan hvem som helst sende e-post som ser ut til å komme fra firma.no. Den døren bør være stengt. ## Hva DMARC faktisk stopper – og hvorfor det er verdt det Med SPF (RFC 7208) og DKIM (RFC 6376) kan mottakeren kontrollere om en e-post faktisk kommer fra en server som har lov til å sende for domenet. DMARC (RFC 7489) kobler dette til domenet i Fra-feltet og forteller mottakeren hva som skal skje med e-post som feiler. Med `p=reject` blir forfalsket e-post avvist før den når innboksen. ``` _dmarc.firma.no. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@firma.no" ``` Det gir tre gevinster: - Egne ansatte beskyttes mot e-post som ser ut til å komme fra kolleger på firma.no – forutsatt at deres egen e-postserver sjekker DMARC, noe Microsoft 365 og Google Workspace gjør. - Kunder og leverandører beskyttes mot falske fakturaer som utgir seg for å komme fra deg. Dette er ofte den største gevinsten, og det beskytter omdømmet ditt. - Du får innsyn. DMARC-rapportene viser hvem som prøver å sende e-post i ditt navn. Se slik leser du DMARC-rapporter . Vil du innføre DMARC trygt uten å stoppe legitim e-post, følger du [DMARC steg for steg fra p=none til p=reject](https://mailwatch.no/blog/dmarc-oppsett-steg-for-steg). Bruker dere Microsoft 365, finner du alt du trenger i [oppsettsguiden for Microsoft 365](https://mailwatch.no/blog/spf-dkim-dmarc-microsoft-365). **Viktig:** `p=none` beskytter ingen. Det er et nyttig overvåkingssteg, men så lenge policyen står på none, blir forfalsket e-post levert som normalt. Mange bedrifter blir stående der i årevis. ### Ikke glem domener dere ikke sender fra Mange bedrifter eier flere domener: gamle firmanavn, .com-varianten, kampanjedomener. Hvis de ikke brukes til e-post, bør de låses helt, slik at ingen kan misbruke dem: ``` gammeltfirma.no. TXT "v=spf1 -all" _dmarc.gammeltfirma.no. TXT "v=DMARC1; p=reject" gammeltfirma.no. MX 0 . ``` Den siste posten er en såkalt «null MX» (RFC 7505), som sier at domenet ikke tar imot e-post. [Bilde: DMARC-rapporter i MailWatch som viser hvilke servere som sender e-post i domenets navn og om de passerer SPF og DKIM]DMARC-rapportene avslører både glemte tjenester og forsøk på å sende e-post i ditt navn fra fremmede servere. ## Lookalike-domener: det DMARC ikke ser Når eksakt forfalskning ikke lenger fungerer, registrerer svindlerne et domene som ligner: en bokstav byttet ut (rn i stedet for m), en bindestrek, et annet toppdomene. Slike domener kan få helt gyldig SPF, DKIM og DMARC – de er jo svindlerens egne. Tiltak som hjelper: - Merking av ekstern e-post. Både Microsoft 365 og Google Workspace kan markere e-post fra eksterne avsendere tydelig. En «ekstern»-merking på en e-post som ser ut til å komme fra sjefen, er et klart faresignal. - Beskyttelse mot etterligning. Microsoft Defender for Office 365 og Googles avanserte phishing-innstillinger kan varsle når visningsnavn eller domener ligner på dine egne eller dine viktigste partneres. - Defensiv registrering av de mest opplagte variantene av domenet ditt, som .com og vanlige skrivefeil. - Overvåking av nye domeneregistreringer som ligner ditt merkenavn, slik at du kan reagere tidlig. ## Kaprede kontoer: når e-posten er ekte Den farligste varianten er når svindleren har tatt over en ekte e-postkonto – hos deg eller hos en leverandør – etter å ha stjålet passordet via phishing. Da kan svindleren lese tidligere korrespondanse, vente på riktig faktura og svare i en eksisterende tråd. Ingen teknisk autentisering vil reagere, fordi e-posten faktisk kommer fra riktig konto. Her er tiltakene: - Tofaktorautentisering (MFA) på alle e-postkontoer , helst phishing-resistent MFA som passnøkler eller sikkerhetsnøkler for ledere og økonomi. - Varsling på mistenkelige videresendingsregler. Svindlere oppretter ofte regler som skjuler eller videresender e-post. Sjekk jevnlig, og bruk innebygde varsler i Microsoft 365 og Google Workspace. - Sjekk leverandørenes e-postsikkerhet. Et raskt oppslag viser om en leverandør har DMARC. Du kan sjekke domenet ditt gratis – og dine viktigste leverandørers – med vår domenesjekk. ## Rutiner som stopper svindelen uansett teknikk Teknikk reduserer risikoen, men det er rutinene som stopper svindelen når alt annet har sluppet gjennom. Disse bør være skriftlige og kjent for alle som håndterer betalinger: - Endring av kontonummer bekreftes alltid på telefon , til et nummer du har fra før (fra avtale, tidligere faktura eller nettsiden) – aldri til nummeret som står i e-posten. - Tofaktorgodkjenning av betalinger : to personer må godkjenne utbetalinger over et visst beløp, og nye mottakere. - Hastverk og hemmelighold er røde flagg. «Dette må skje i dag» og «ikke snakk med noen om dette» er klassiske tegn på svindel. Gjør det legitimt å stoppe og sjekke – også når det gjelder sjefen. - Lederne sier tydelig fra om at de aldri vil be om betalinger eller gavekort utenom de vanlige rutinene. - Opplæring av økonomi, lønn og ledersekretærer med konkrete eksempler. Nettvett.no, som driftes av NSM, har gode råd og materiell på norsk. **Tips:** Har dere allerede betalt til en svindler? Kontakt banken umiddelbart – jo raskere, jo større er sjansen for å stoppe eller hente tilbake pengene. Anmeld forholdet til politiet og ta vare på e-postene med fullstendige headere. ## Ofte stilte spørsmål ### Stopper DMARC direktørsvindel? DMARC med p=reject stopper direktørsvindel der svindleren forfalsker nøyaktig ditt domene i avsenderfeltet. Det stopper ikke e-post fra lookalike-domener, falske visningsnavn på Gmail-adresser eller kaprede ekte kontoer. DMARC bør derfor kombineres med MFA, merking av ekstern e-post og faste betalingsrutiner. ### Hva er et lookalike-domene? Et lookalike-domene er et domene som ligner på et ekte, for eksempel firrna.no i stedet for firma.no, eller firma-no.com. Svindlere registrerer dem for å lure mottakere som ikke ser nøye etter. Fordi domenet tilhører svindleren, kan e-posten passere SPF, DKIM og DMARC. ### Hvordan vet jeg om noen sender e-post i vårt navn? Legg inn en DMARC-post med rua-adresse. Da sender mottakere som Gmail og Microsoft daglige rapporter som viser alle servere som har sendt e-post med ditt domene i avsenderfeltet. Et verktøy som tolker rapportene gjør det enkelt å se ukjente avsendere. ### Hva bør vi gjøre hvis vi har betalt en falsk faktura? Kontakt banken med en gang, siden rask handling øker sjansen for å stoppe overføringen. Anmeld svindelen til politiet, og ta vare på e-postene med fullstendige headere som dokumentasjon. Sjekk også om en e-postkonto er kompromittert, og bytt passord og aktiver MFA. ### Beskytter DMARC kundene våre også? Ja. Med p=reject blir e-post som forfalsker ditt domene avvist hos mottakere som sjekker DMARC, noe alle store e-posttjenester gjør. Det gjør det vanskeligere for svindlere å sende falske fakturaer til kundene dine i ditt navn, og beskytter omdømmet ditt. ## Oppsummering Direktørsvindel og falske fakturaer stoppes best med flere lag: DMARC på `p=reject` stenger døren for forfalskning av ditt eksakte domene, MFA og varsling beskytter mot kaprede kontoer, og faste rutiner med telefonverifisering stopper resten. MailWatch hjelper deg med den tekniske delen: vi overvåker SPF, DKIM og DMARC kontinuerlig, tolker DMARC-rapportene så du ser hvem som sender i ditt navn, og varsler deg på e-post eller SMS hvis noe endres. [Prøv gratis i 30 dager](https://mailwatch.no/auth/register). --- # MTA-STS, TLS-RPT og BIMI: neste steg etter DMARC URL: https://mailwatch.no/blog/mta-sts-tls-rpt-bimi Publisert: 2026-09-26 Har du SPF, DKIM og DMARC på plass? Da er MTA-STS, TLS-RPT og BIMI neste steg: kryptert innkommende e-post, rapporter om TLS-feil og logoen din synlig i mottakerens innboks. MTA-STS, TLS-RPT og BIMI er de tre naturlige stegene etter at SPF, DKIM og DMARC er på plass. **MTA-STS** tvinger andre e-postservere til å bruke kryptert og verifisert TLS når de leverer e-post til deg, **TLS-RPT** gir deg rapporter når slik levering feiler, og **BIMI** lar logoen din vises ved siden av e-posten i innboksen – men bare når DMARC håndheves med quarantine eller reject. Her ser du hva hver standard gjør, hvilke DNS-poster og filer du trenger, og i hvilken rekkefølge det lønner seg å innføre dem. **Kort fortalt:** - MTA-STS (RFC 8461): en policyfil på https://mta-sts.firma.no/.well-known/mta-sts.txt og en TXT-post på _mta-sts.firma.no . Start i testing , gå til enforce . - TLS-RPT (RFC 8460): én TXT-post på _smtp._tls.firma.no med en rua-adresse. Gir daglige rapporter om TLS-problemer. - BIMI: krever DMARC med p=quarantine eller p=reject på 100 %, en logo i SVG Tiny PS og i praksis et VMC- eller CMC-sertifikat. - Innfør TLS-RPT og MTA-STS i testing samtidig, og BIMI når DMARC er ferdig strammet inn. ## Hvorfor trenger du mer enn DMARC? SPF (RFC 7208), DKIM (RFC 6376) og DMARC (RFC 7489) handler om utgående e-post: de beviser at meldinger som utgir seg for å komme fra firma.no, faktisk gjør det. Hvis du ikke har dette på plass ennå, start med [hva er DMARC](https://mailwatch.no/blog/hva-er-dmarc) og [DMARC steg for steg](https://mailwatch.no/blog/dmarc-oppsett-steg-for-steg). Men DMARC sier ingenting om hvordan e-post til deg blir transportert. SMTP ble laget uten kryptering, og STARTTLS – utvidelsen som krypterer forbindelsen mellom e-postservere – er i utgangspunktet frivillig. En angriper som kan manipulere nettverkstrafikken, kan fjerne STARTTLS-tilbudet (et såkalt nedgraderingsangrep) eller peke avsenderen til en falsk MX-server. Avsenderen leverer da e-posten i klartekst eller til feil mottaker, uten at noen merker det. Det er dette MTA-STS løser. | Standard | Beskytter | Retning | Krever | | SPF, DKIM, DMARC | Mot forfalskning av avsenderdomenet | Utgående | DNS | | MTA-STS | Mot nedgradering og falsk MX | Innkommende | DNS + HTTPS-nettside | | TLS-RPT | Gir innsyn i TLS-feil | Innkommende | DNS | | BIMI | Synlig merkevare og tillit | Utgående | DNS + logo + (i praksis) sertifikat | ## Slik fungerer MTA-STS MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) består av to deler: - En TXT-post på _mta-sts.firma.no som forteller at domenet har en policy, og hvilken versjon den har. - En policyfil som hentes over HTTPS fra https://mta-sts.firma.no/.well-known/mta-sts.txt . Den lister opp hvilke MX-servere som er gyldige, og om TLS skal håndheves. En avsenderserver som støtter MTA-STS – blant annet Gmail og Microsoft 365 – ser TXT-posten, henter policyen og mellomlagrer den. Ved senere leveranser krever den at MX-serveren har et gyldig TLS-sertifikat som stemmer med vertsnavnet. Hvis ikke, og policyen står i `enforce`, leveres ikke e-posten. Fordi policyen hentes over HTTPS med sertifikatvalidering, kan en angriper ikke bare forfalske den via DNS. ### Steg 1: Lag policyfilen Filen er ren tekst. For et domene som bruker Microsoft 365, kan den se slik ut: ``` version: STSv1 mode: testing mx: *.mail.protection.outlook.com max_age: 604800 ``` For Google Workspace lister du Googles MX-verter i stedet, for eksempel: ``` version: STSv1 mode: testing mx: smtp.google.com mx: aspmx.l.google.com mx: *.aspmx.l.google.com max_age: 604800 ``` Feltene betyr: - mode : testing (feil rapporteres, men e-post leveres likevel), enforce (levering avbrytes ved feil) eller none (policyen trekkes tilbake). - mx : én linje per gyldig MX-vert. Jokertegn er lov for ett nivå, som *.mail.protection.outlook.com . - max_age : hvor lenge avsendere kan mellomlagre policyen, i sekunder. Maksimum er 31557600 (omtrent ett år). En uke (604800) er fornuftig mens du tester; mange går opp til flere måneder når policyen er stabil. ### Steg 2: Publiser filen over HTTPS Filen må ligge på nøyaktig `https://mta-sts.firma.no/.well-known/mta-sts.txt`, med et gyldig TLS-sertifikat for `mta-sts.firma.no` og innholdstypen `text/plain`. Du trenger altså et underdomene som peker til en webserver. Det kan være ditt eget webhotell, en statisk hosting-tjeneste eller en tjeneste som leverer MTA-STS for deg. Omdirigeringer (redirects) er ikke tillatt. ### Steg 3: Publiser TXT-posten ``` _mta-sts.firma.no. TXT "v=STSv1; id=20260926T120000" ``` `id` er en unik verdi (opptil 32 bokstaver og tall) som avsendere bruker for å se om policyen er endret. **Hver gang du endrer policyfilen, må du også endre id** – ellers fortsetter avsenderne å bruke den mellomlagrede versjonen til max_age utløper. En tidsstempel-id som over gjør det enkelt. **Viktig:** Ikke gå til `mode: enforce` før TLS-RPT-rapportene har vist ingen feil over en periode. Står MX-vertene ikke i policyen, eller sertifikatet på MX-serveren er ugyldig, vil avsendere som respekterer policyen slutte å levere e-post til deg. Husk også å oppdatere policyen (og id) før du bytter e-postleverandør. ## TLS-RPT: rapporter om TLS-feil TLS-RPT (SMTP TLS Reporting, RFC 8460) er for MTA-STS det rua-rapportene er for DMARC. Du publiserer én TXT-post, og avsendere som støtter standarden sender deg en daglig rapport om hvor mange forbindelser som lyktes, og hvilke som feilet – og hvorfor. ``` _smtp._tls.firma.no. TXT "v=TLSRPTv1; rua=mailto:tls-rapporter@firma.no" ``` Rapportene er JSON-filer (ofte gzip-komprimert) med feiltyper som `certificate-expired`, `certificate-host-mismatch`, `starttls-not-supported` eller `sts-policy-fetch-error`. De avslører for eksempel at sertifikatet på en backup-MX har gått ut, eller at policyfilen ikke kan hentes. TLS-RPT har ingen risiko: posten påvirker ikke leveringen, den gir bare innsyn. Derfor bør du legge den inn **samtidig** med MTA-STS i testing-modus. Den virker også sammen med DANE (RFC 7672), et alternativ til MTA-STS som bygger på DNSSEC. **Tips:** Bruk en egen postkasse eller et alias for TLS-rapportene, på samme måte som for DMARC-rapporter. De kommer daglig fra flere avsendere og kan ellers fort drukne i den vanlige innboksen. ## BIMI: logoen din i innboksen BIMI (Brand Indicators for Message Identification) lar e-postklienter vise logoen din som avatar ved siden av meldinger fra domenet. Gmail, Apple Mail, Yahoo og flere andre støtter det. BIMI er ikke en ferdig RFC, men en spesifikasjon utviklet av BIMI Group, og den bygger direkte på DMARC. ### Krav før du kan bruke BIMI - DMARC må håndheves : p=quarantine eller p=reject på organisasjonsdomenet, med pct=100 (standardverdien hvis pct utelates). p=none eller en lavere pct kvalifiserer ikke, og underdomenepolicyen ( sp ) kan heller ikke være none . - SPF og DKIM må passere med alignment for meldingene som skal vise logoen. - Logoen må være i SVG Tiny PS (Portable/Secure), en begrenset SVG-profil: kvadratisk, baseProfile="tiny-ps" , et -element, ingen skript, ingen eksterne referanser og ingen innebygde punktbilder. - Et merkesertifikat – i praksis nødvendig for Gmail og Apple Mail. ### VMC eller CMC? | | VMC (Verified Mark Certificate) | CMC (Common Mark Certificate) | | Krever registrert varemerke | Ja | Nei | | Alternativt krav | – | Logoen må ha vært brukt offentlig på domenet i minst 12 måneder | | Gmail | Logo og blå verifisert-hake | Logo, uten hake | | Apple Mail | Støttet | Ikke støttet per i dag | Begge sertifikattypene kjøpes fra godkjente utstedere (blant andre DigiCert og GlobalSign), innebærer identitetskontroll av virksomheten og har en årlig kostnad. For varemerker gjelder det at registreringen må være hos et varemerkekontor som utstederne godtar – sjekk dette før du bestiller. ### BIMI-posten ``` default._bimi.firma.no. TXT "v=BIMI1; l=https://firma.no/bimi/logo.svg; a=https://firma.no/bimi/vmc.pem" ``` `l=` peker til logoen og `a=` til sertifikatet (PEM-fil). Begge må serveres over HTTPS. Uten sertifikat kan du utelate `a=`, men da vil de fleste store klienter ikke vise logoen. ## Anbefalt rekkefølge - SPF, DKIM og DMARC med p=none – grunnmuren. Se veiledningene for Microsoft 365 og Google Workspace . - TLS-RPT – ufarlig og gir innsikt fra dag én. - MTA-STS i testing – følg med på TLS-rapportene i et par uker. - DMARC til quarantine og reject – basert på DMARC-rapportene. - MTA-STS i enforce – når TLS-rapportene er rene. - BIMI – når DMARC håndheves på 100 % og du har logo og sertifikat klart. [Bilde: Domenedetaljer i MailWatch med status for SPF, DKIM, DMARC, MX og svartelister]MailWatch overvåker DNS-postene som hele oppsettet hviler på, og varsler hvis noe endres eller slutter å virke. ## Vanlige feil - Glemt å endre id i _mta-sts-posten etter at policyfilen er oppdatert. - Utløpt sertifikat på mta-sts-underdomenet, slik at policyen ikke kan hentes. - MX-verter som mangler i policyen, for eksempel en backup-MX eller nye MX-navn etter et leverandørbytte. - BIMI med DMARC p=none – logoen vises aldri. - SVG-logo lagret som vanlig SVG fra et designprogram i stedet for SVG Tiny PS. Vil du se hvordan domenet ditt står i dag? [Sjekk domenet ditt gratis](https://mailwatch.no/domenesjekk). ## Ofte stilte spørsmål ### Hva er MTA-STS? MTA-STS (RFC 8461) er en standard som lar et domene kreve at andre e-postservere bruker kryptert TLS med gyldig sertifikat når de leverer e-post til domenet. Den består av en TXT-post på _mta-sts og en policyfil som publiseres over HTTPS på mta-sts-underdomenet. Den beskytter mot nedgraderingsangrep og falske MX-servere. ### Hva er forskjellen på testing og enforce i MTA-STS? I testing-modus leverer avsendere e-posten selv om TLS-kontrollen feiler, men feilene rapporteres via TLS-RPT. I enforce-modus avbrytes leveringen hvis MX-serveren ikke har gyldig TLS eller ikke står i policyen. Start alltid med testing. ### Trenger jeg TLS-RPT hvis jeg har MTA-STS? Ja, det anbefales sterkt. TLS-RPT (RFC 8460) er den eneste måten å få vite at avsendere har problemer med å levere til deg over TLS. Uten rapportene oppdager du ikke feil før e-post faktisk uteblir. ### Hvilken DMARC-policy krever BIMI? BIMI krever at DMARC håndheves med p=quarantine eller p=reject, og at policyen gjelder 100 % av meldingene. p=none kvalifiserer ikke. I tillegg må meldingene passere DMARC for at logoen skal vises. ### Må jeg ha registrert varemerke for å bruke BIMI? For et VMC-sertifikat, ja. Med et CMC-sertifikat trenger du ikke registrert varemerke, men logoen må ha vært brukt offentlig i minst 12 måneder. Gmail viser logoen med begge typer, men den blå verifisert-haken krever VMC. ## Oppsummering MTA-STS og TLS-RPT sikrer at e-post til deg leveres kryptert og at du får vite når det svikter, mens BIMI gir synlig merkevare i innboksen som belønning for et strengt DMARC-oppsett. Alt sammen hviler på DNS-poster og sertifikater som kan endres eller utløpe uten at noen merker det. MailWatch overvåker e-postoppsettet ditt kontinuerlig og varsler på e-post, SMS eller Pushover når noe endrer seg. [Prøv MailWatch gratis i 30 dager](https://mailwatch.no/auth/register). --- # Hva er SPF? Slik beskytter du domenet mot e-postforfalskning URL: https://mailwatch.no/blog/hva-er-spf Publisert: 2026-02-16 SPF er en DNS-post som forteller mottakerne hvilke servere som får sende e-post fra domenet ditt. Her er syntaksen, mekanismene, ~all mot -all, eksempler og de vanligste feilene. **SPF (Sender Policy Framework) er en TXT-post i DNS som lister opp hvilke servere og tjenester som har lov til å sende e-post på vegne av domenet ditt.** Når en mottakerserver får en e-post, slår den opp SPF-posten og sjekker om IP-adressen som leverte meldingen står på listen. SPF er definert i RFC 7208 og er, sammen med DKIM og DMARC, grunnmuren i moderne e-postautentisering. **Kort fortalt:** - SPF er én TXT-post på domenet som starter med v=spf1 og slutter med en all -mekanisme. - Den sjekker avsenderadressen i konvolutten (Return-Path), ikke Fra-adressen mottakeren ser. Derfor trenger du også DMARC. - Du har maks 10 DNS-oppslag. Går du over, får du PermError og SPF feiler for all e-post. - Et domene skal bare ha én SPF-post. To poster gir også PermError. - Bruk ~all mens du rydder, og vurder -all når du har full oversikt over alle avsendere. ## Hvordan SPF fungerer En e-post har to avsenderadresser. Den ene er **Fra-adressen** (header From) som vises i e-postklienten. Den andre er **konvolutt-avsenderen** (MAIL FROM, også kalt Return-Path eller bounce-adresse), som serverne bruker seg imellom og som mottar returmeldinger. SPF sjekker den siste. Slik foregår en SPF-sjekk i praksis: - En server med IP-adressen 203.0.113.25 kobler til mottakeren og oppgir MAIL FROM: . - Mottakeren slår opp TXT-postene på firma.no og finner den som starter med v=spf1 . - Mekanismene i posten evalueres fra venstre mot høyre. Den første som treffer IP-adressen, avgjør resultatet. - Resultatet (pass, fail, softfail, neutral, none, temperror eller permerror) brukes i spamfilteret og i DMARC-vurderingen. Er konvolutt-avsenderen tom, som ved returmeldinger, sjekkes i stedet HELO-navnet serveren presenterer seg med. **Viktig:** SPF alene hindrer ikke at noen forfalsker Fra-adressen du ser i innboksen. En svindler kan bruke sitt eget domene i konvolutten, bestå SPF og likevel vise `daglig.leder@firma.no` som avsender. Det er [DMARC](https://mailwatch.no/blog/hva-er-dmarc) som knytter SPF-resultatet til Fra-adressen gjennom såkalt alignment. ## Syntaksen i en SPF-post En SPF-post er en vanlig TXT-post på roten av domenet (eller på et subdomene som sender e-post). Den består av tre deler: versjonen, en rekke mekanismer og en avsluttende `all`. ``` firma.no. 3600 IN TXT "v=spf1 ip4:203.0.113.25 include:spf.protection.outlook.com -all" ``` - v=spf1 – må stå først, nøyaktig slik. - ip4:203.0.113.25 – tillater én bestemt IPv4-adresse (egen server, skriver eller nettbutikk). - include:spf.protection.outlook.com – tillater alle servere som Microsoft 365 lister i sin SPF. - -all – alt annet skal regnes som ikke autorisert. ### Mekanismer | Mekanisme | Hva den gjør | Teller som DNS-oppslag? | | ip4: / ip6: | Tillater en IP-adresse eller et nettverk, f.eks. ip4:198.51.100.0/24 | Nei | | a | Tillater IP-adressene som domenets A/AAAA-post peker på | Ja | | mx | Tillater IP-adressene til domenets MX-servere | Ja (og hver MX-vert må slås opp) | | include: | Henter inn SPF-posten til et annet domene, typisk en e-posttjeneste | Ja, pluss alle oppslag inni den | | exists: | Treffer hvis et gitt domenenavn har en A-post (avansert bruk) | Ja | | ptr | Sjekker omvendt DNS. Frarådet i RFC 7208, skal ikke brukes | Ja | | all | Treffer alt. Står alltid sist | Nei | I tillegg finnes to **modifikatorer**: `redirect=`, som lar et domene bruke en annen SPF-post i sin helhet (teller som oppslag), og `exp=`, som angir en forklaringstekst ved feil og brukes sjelden. ### Kvalifikatorer Foran hver mekanisme kan det stå en kvalifikator. Står det ingenting, gjelder `+`. | Kvalifikator | Resultat | Betydning | | + | Pass | Serveren er autorisert (standard) | | - | Fail | Serveren er ikke autorisert, meldingen kan avvises | | ~ | SoftFail | Sannsynligvis ikke autorisert, meldingen merkes som mistenkelig | | ? | Neutral | Domenet uttaler seg ikke. Gir i praksis ingen beskyttelse | Kvalifikatorene brukes nesten bare på `all`. Skriv aldri `+all`: da sier du at hele internett har lov til å sende e-post fra domenet ditt. ## ~all eller -all? Dette er det vanligste spørsmålet om SPF, og svaret avhenger av hvor langt du har kommet. - ~all (softfail) er det trygge valget mens du kartlegger avsendere. Legitim e-post fra en tjeneste du har glemt, blir som regel levert, men får dårligere spamvurdering. - -all (hardfail) sier tydelig at alt som ikke står i listen, er uautorisert. Noen mottakere avviser slike meldinger allerede i SMTP-samtalen, før DMARC og DKIM i det hele tatt blir vurdert. Når du har DMARC på plass, er det DMARC-policyen som bestemmer hva som skal skje med meldinger som feiler. Derfor velger mange å bli på `~all` og la `p=reject` i DMARC gjøre jobben. Det gir mindre risiko for at videresendt e-post med gyldig DKIM-signatur blir avvist bare på grunn av SPF. Begge valg er faglig forsvarlige. Det viktigste er at listen over avsendere er komplett, og det ser du best i DMARC-rapportene. ## Eksempler på SPF-poster ### Bare Microsoft 365 ``` v=spf1 include:spf.protection.outlook.com -all ``` ### Google Workspace og nyhetsbrevtjeneste ``` v=spf1 include:_spf.google.com include:servers.mcsv.net ~all ``` ### Egen server, nettbutikk og Microsoft 365 ``` v=spf1 ip4:203.0.113.25 ip4:198.51.100.0/28 include:spf.protection.outlook.com ~all ``` ### Domene som aldri sender e-post Parkerte domener og domener som bare brukes til nettsider, bør si tydelig ifra at de ikke sender e-post. Ellers er de fritt fram for svindlere. ``` v=spf1 -all ``` Kombiner gjerne med en DMARC-post med `p=reject` og en tom MX (`0 .`, RFC 7505) for å stenge domenet helt. **Tips:** Kopier include-verdien nøyaktig slik leverandøren oppgir den i sitt administrasjonspanel, og legg den inn i den eksisterende SPF-posten i stedet for å opprette en ny. ## De vanligste SPF-feilene ### 1. For mange DNS-oppslag RFC 7208 setter en grense på **10 DNS-oppslag** per SPF-evaluering. Mekanismene `include`, `a`, `mx`, `ptr`, `exists` og modifikatoren `redirect` teller, også de som ligger inni andre includes. `ip4`, `ip6` og `all` teller ikke. Legger du til CRM, nyhetsbrev, helpdesk og regnskapssystem, er grensen fort nådd. Resultatet blir **PermError**, og mange mottakere behandler det som at SPF feiler. Se hvordan du løser det i artikkelen om [SPF PermError og for mange DNS-oppslag](https://mailwatch.no/blog/spf-for-mange-dns-oppslag). ### 2. Mer enn to «void lookups» Et oppslag som ikke gir noe svar (NXDOMAIN eller tomt svar) kalles et void lookup. Maks to er tillatt. Det skjer typisk når du har en include til en tjeneste du har sagt opp, eller en skrivefeil i domenenavnet. ### 3. To SPF-poster på samme domene Når en ny tjeneste ber deg «legge til en SPF-post», ender mange opp med to TXT-poster som begge starter med `v=spf1`. Det gir PermError. Slå dem sammen til én post. ### 4. Glemte avsendere Fakturasystemet, nettbutikken, skanneren på kontoret eller nettsidens kontaktskjema sender kanskje med domenet ditt i konvolutten uten å stå i SPF. Dette dukker opp som SPF-feil i DMARC-rapportene. ### 5. Syntaksfeil Mellomrom etter kolon (`include: _spf.google.com`), `v=spf1` som ikke står først, `all` midt i posten (alt etter den ignoreres) eller manglende `all` til slutt. Pass også på at posten ikke blir lengre enn 255 tegn i én streng. Lengre poster må deles i flere strenger innenfor samme TXT-post, noe de fleste DNS-leverandører håndterer automatisk. ### 6. Å tro at SPF arves av subdomener SPF gjelder bare for det eksakte domenenavnet. Sender du fra `nyhetsbrev.firma.no`, trenger det subdomenet sin egen SPF-post. ## Begrensninger ved SPF SPF er nødvendig, men ikke tilstrekkelig. Det har tre kjente svakheter: - Videresending bryter SPF. Når en melding videresendes, kommer den fra videresenderens IP, som ikke står i din SPF-post. DKIM overlever videresending og er derfor en viktig sikkerhetsnett. - SPF beskytter ikke Fra-adressen. Uten DMARC-alignment kan konvolutten og den synlige avsenderen være helt forskjellige domener. - Delte plattformer. En include til en stor e-posttjeneste autoriserer i prinsippet alle kundene til den tjenesten. Kombinert med DKIM og DMARC blir dette et mye mindre problem. Siden februar 2024 krever Gmail og Yahoo at avsendere som sender mer enn 5000 meldinger om dagen, har SPF, DKIM og DMARC på plass, og Microsoft innførte tilsvarende krav for Outlook.com fra 5. mai 2025. Les mer i artikkelen om [de nye kravene fra Gmail, Yahoo og Outlook](https://mailwatch.no/blog/krav-gmail-yahoo-outlook-avsendere). ## Slik sjekker du SPF-posten din Den raskeste måten er å slå opp TXT-postene direkte: ``` # Linux / macOS dig TXT firma.no +short # Windows nslookup -type=TXT firma.no ``` Da ser du selve posten, men ikke hvor mange oppslag den bruker totalt, eller om en include lenger ned i kjeden er ødelagt. Det enkleste er å [sjekke domenet ditt gratis](https://mailwatch.no/domenesjekk) med MailWatch. Du får SPF, DKIM, DMARC, MX og svartelister i én rapport. [Bilde: MailWatch SPF-verktøy som viser mekanismene i SPF-posten og antall DNS-oppslag]SPF-verktøyet i MailWatch bryter posten ned i mekanismer og teller DNS-oppslagene, også de som ligger inni includes. Du kan også sende en e-post til en Gmail-konto, åpne meldingen og velge «Vis original». Der står det `SPF: PASS` eller `FAIL` med IP-adressen som ble sjekket. En engangssjekk er likevel bare et øyeblikksbilde. SPF-poster endrer seg når leverandører oppdaterer sine includes, når noen i organisasjonen tar i bruk en ny tjeneste, eller når DNS-leverandøren byttes. Derfor lønner det seg å overvåke posten fortløpende. ## Ofte stilte spørsmål ### Hva står SPF for? SPF står for Sender Policy Framework. Det er en standard (RFC 7208) der domeneeieren publiserer en TXT-post i DNS som lister opp hvilke servere som har lov til å sende e-post for domenet. Mottakerservere bruker posten til å vurdere om en melding er ekte. ### Kan jeg ha flere SPF-poster på samme domene? Nei. Et domene skal ha nøyaktig én TXT-post som starter med `v=spf1`. Har du to, gir SPF-sjekken PermError, og mange mottakere behandler e-posten som om SPF feilet. Slå sammen alle mekanismene i én post. ### Hva er forskjellen på ~all og -all? `~all` (softfail) sier at servere som ikke er listet, sannsynligvis ikke er autorisert, og meldingen blir som regel levert, men merket. `-all` (hardfail) sier at de ikke er autorisert, og noen mottakere avviser meldingen direkte. Med DMARC på plass er det DMARC-policyen som styrer håndteringen, så begge er vanlige valg. ### Hvor mange include kan jeg ha i SPF? Det er ikke antall includes som begrenses, men antall DNS-oppslag: maks 10 totalt, inkludert oppslagene inni hver include. En enkelt include til en stor leverandør kan alene bruke tre eller fire oppslag. Går du over grensen, får du PermError. ### Er SPF nok til å stoppe falske e-poster? Nei. SPF sjekker bare konvolutt-avsenderen, ikke Fra-adressen mottakeren ser, og SPF brytes ved videresending. For å hindre at noen utgir seg for å være domenet ditt, trenger du også DKIM og en DMARC-policy med `p=quarantine` eller `p=reject`. ### Trenger domener som ikke sender e-post, en SPF-post? Ja. Et domene uten SPF er lettere å misbruke. Publiser `v=spf1 -all` for å si at domenet aldri sender e-post, og kombiner med en DMARC-post med `p=reject`. ## Oppsummering SPF er en enkel, men lettødelagt byggestein: én post per domene, maks 10 oppslag, en komplett liste over avsendere og en tydelig `all` til slutt. Sammen med DKIM og DMARC gjør den det langt vanskeligere å forfalske domenet ditt og bedre sjansen for at e-posten havner i innboksen. MailWatch overvåker SPF-posten din kontinuerlig, teller DNS-oppslag, viser hvilke servere som faktisk sender for domenet gjennom DMARC-rapportene, og varsler deg på e-post, SMS eller Pushover hvis noe endrer seg. Du kan [prøve gratis i 30 dager](https://mailwatch.no/auth/register) uten kredittkort. --- # Hva er DKIM? Digital signatur for e-post forklart URL: https://mailwatch.no/blog/hva-er-dkim Publisert: 2026-02-16 DKIM signerer e-posten din digitalt slik at mottakeren kan bekrefte at den kommer fra domenet ditt og ikke er endret underveis. Slik fungerer signering, selektorer, nøkkellengde og rotasjon. **DKIM (DomainKeys Identified Mail) er en digital signatur som avsenderserveren legger på hver e-post, og som mottakeren kontrollerer mot en offentlig nøkkel publisert i domenets DNS.** Stemmer signaturen, vet mottakeren at meldingen er godkjent av domenet og ikke er endret underveis. DKIM er definert i RFC 6376 og er den delen av e-postautentiseringen som tåler videresending best. **Kort fortalt:** - Avsenderen signerer utvalgte headere og innholdet med en privat nøkkel. Den offentlige nøkkelen ligger i DNS på selektor._domainkey.firma.no . - Selektoren er et navn som gjør det mulig å ha flere nøkler samtidig, for eksempel én per e-posttjeneste. - Bruk RSA-nøkler på minst 2048 bit, og roter dem jevnlig. - For at DKIM skal telle i DMARC, må signaturens domene ( d= ) samsvare med Fra-domenet. ## Hvordan DKIM-signering fungerer DKIM bygger på vanlig offentlig nøkkel-kryptografi. Du, eller e-posttjenesten din, har et nøkkelpar: en privat nøkkel som bare avsenderserveren kjenner, og en offentlig nøkkel som alle kan slå opp i DNS. - Signering: Når en e-post sendes, lager serveren en hash av meldingsteksten og av utvalgte headere (typisk From, To, Subject, Date og Message-ID). Hashen signeres med den private nøkkelen. - Header legges til: Signaturen legges i en ny header, DKIM-Signature , sammen med informasjon om domene, selektor og algoritme. - Verifisering: Mottakeren leser d= og s= fra headeren, henter den offentlige nøkkelen fra DNS og kontrollerer signaturen. - Resultat: Stemmer alt, blir resultatet dkim=pass . Er innholdet endret eller nøkkelen feil, blir det dkim=fail . Slik kan en DKIM-signatur se ut (forkortet): ``` DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=firma.no; s=mail2026; h=from:to:subject:date:message-id; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR... ``` | Tag | Betydning | | v=1 | DKIM-versjon | | a=rsa-sha256 | Algoritme. rsa-sha1 er utdatert og skal ikke brukes (RFC 8301) | | c=relaxed/relaxed | Kanonisering for header/innhold. relaxed tåler små endringer i mellomrom og linjeskift, simple tåler nesten ingenting | | d= | Domenet som tar ansvar for signaturen. Brukes i DMARC-alignment | | s= | Selektoren, som peker på riktig nøkkel i DNS | | h= | Hvilke headere som er signert | | bh= | Hash av meldingsinnholdet | | b= | Selve signaturen | **Tips:** DKIM overlever vanlig videresending fordi signaturen følger med meldingen, i motsetning til [SPF](https://mailwatch.no/blog/hva-er-spf), som er knyttet til IP-adressen som leverer. Derfor er DKIM den viktigste enkeltmekanismen for å få [DMARC](https://mailwatch.no/blog/hva-er-dmarc) til å bestå. ## DKIM-posten i DNS Den offentlige nøkkelen publiseres som en TXT-post på et underdomene med formen `._domainkey.`: ``` mail2026._domainkey.firma.no. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu5x..." ``` - v=DKIM1 – versjon (anbefalt, bør stå først). - k=rsa – nøkkeltype. ed25519 finnes også (RFC 8463), men støtten hos mottakere er ikke universell, så bruk det eventuelt i tillegg til RSA. - p= – den offentlige nøkkelen i base64. Tom p= betyr at nøkkelen er trukket tilbake. - t=y – testmodus. Bør fjernes når oppsettet fungerer. Mange tjenester, som Microsoft 365 og flere nyhetsbrevverktøy, ber deg i stedet opprette en **CNAME** som peker til en nøkkel de selv drifter. Fordelen er at leverandøren kan rotere nøkkelen uten at du må endre DNS. ``` selector1._domainkey.firma.no. CNAME selector1-firma-no._domainkey.firma.onmicrosoft.com. ``` ## Hva er en DKIM-selektor? Selektoren er et fritt valgt navn som lar et domene ha mange DKIM-nøkler samtidig. Hver tjeneste som sender for domenet ditt, bør signere med sin egen nøkkel og sin egen selektor. Det gjør det mulig å bytte eller trekke tilbake én nøkkel uten å påvirke de andre. | Tjeneste | Typiske selektorer | Posttype | | Microsoft 365 | selector1 , selector2 | CNAME | | Google Workspace | google (standard, kan endres) | TXT | | Mailchimp | k2 , k3 | CNAME | | SendGrid | s1 , s2 | CNAME | | Egen server | Valgfritt, f.eks. mail2026 | TXT | Selektorene hos leverandørene kan endre seg over tid, så sjekk alltid det tjenesten selv oppgir i sitt kontrollpanel. ### Slik finner du selektoren Det finnes ingen måte å liste opp alle selektorer for et domene via DNS. Du må vite navnet. Tre måter å finne det på: - Se i en mottatt e-post. Send en melding fra tjenesten til deg selv, åpne kildekoden («Vis original» i Gmail, «Vis meldingskilde» i Outlook) og finn s= i DKIM-Signature -headeren. - Se i DMARC-rapportene. Aggregerte rapporter viser domene og selektor for hver DKIM-signatur mottakerne har sjekket. Les mer i slik leser du DMARC-rapporter . - Se i leverandørens kontrollpanel. Der står det hvilke DNS-poster du skal opprette. Når du vet selektoren, kan du slå opp nøkkelen: ``` dig TXT selector1._domainkey.firma.no +short nslookup -type=TXT google._domainkey.firma.no ``` ## Nøkkellengde: 1024 eller 2048 bit? RFC 8301 krever minst 1024 bit og anbefaler 2048 bit for RSA-nøkler. 1024-bit nøkler regnes i dag som svake, og flere store mottakere vurderer dem strengere. **Bruk 2048 bit** med mindre en gammel DNS-leverandør gjør det umulig. En 2048-bit nøkkel er lengre enn 255 tegn, som er grensen for én enkelt streng i en TXT-post. Posten må derfor deles i flere strenger innenfor samme post: ``` mail2026._domainkey.firma.no. IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..." "...resten av nøkkelen...IDAQAB" ) ``` De fleste moderne DNS-paneler deler automatisk. Pass på at det ikke kommer mellomrom eller anførselstegn midt i nøkkelen, for da blir den ugyldig. 4096-bit nøkler gir i praksis ingen merkbar ekstra sikkerhet for e-post, men gir store DNS-svar og er ikke alltid støttet. 2048 er det anbefalte nivået. ## Rotasjon av DKIM-nøkler En privat nøkkel som har vært i bruk lenge, har større sjanse for å ha lekket, for eksempel via en gammel server eller en tidligere leverandør. God praksis er å rotere nøklene jevnlig, typisk hver 6. til 12. måned, og alltid når en ansatt med tilgang slutter eller en server kompromitteres. Med selektorer kan rotasjonen gjøres uten nedetid: - Lag et nytt nøkkelpar og publiser den offentlige nøkkelen under en ny selektor (f.eks. mail2027 ). - Vent til DNS har spredt seg (minst TTL-tiden, gjerne et døgn). - Bytt signeringen på serveren til den nye selektoren. - La den gamle nøkkelen ligge i DNS i noen dager, slik at meldinger som allerede er underveis, fortsatt kan verifiseres. - Trekk tilbake den gamle nøkkelen ved å tømme p= eller slette posten. Microsoft 365 gjør dette med `selector1` og `selector2`, der du kan starte rotasjon fra administrasjonssenteret. Tjenester som bruker CNAME, roterer som regel automatisk. ## DKIM og DMARC: alignment En gyldig DKIM-signatur er ikke nok i seg selv. For at DKIM skal telle i DMARC, må domenet i `d=` samsvare med domenet i Fra-adressen. Med standard «relaxed» alignment holder det at de deler organisasjonsdomene, så `d=mail.firma.no` godkjennes for `From: post@firma.no`. Et vanlig problem er at en tjeneste signerer med sitt eget domene, for eksempel `d=sendgrid.net` eller `d=firma.onmicrosoft.com`. Da blir DKIM `pass`, men ikke aligned, og hjelper ikke DMARC. Løsningen er å sette opp «custom DKIM» eller «domeneautentisering» hos leverandøren, slik at de signerer med ditt domene. Gmail og Yahoo krever siden februar 2024 at avsendere med mer enn 5000 meldinger om dagen har DKIM, og at enten SPF eller DKIM er aligned med Fra-domenet. Microsoft har tilsvarende krav for Outlook.com fra mai 2025. ## Vanlige DKIM-feil og hvordan du retter dem ### DKIM er ikke aktivert I Microsoft 365 må DKIM for eget domene aktiveres manuelt etter at CNAME-postene er publisert. Inntil da signeres e-posten med onmicrosoft.com-domenet, som ikke gir alignment. Se guiden for [Microsoft 365](https://mailwatch.no/blog/spf-dkim-dmarc-microsoft-365). ### Nøkkelen finnes ikke i DNS Feil selektor, skrivefeil i vertsnavnet eller at DNS-panelet automatisk har lagt til domenet to ganger (`selector1._domainkey.firma.no.firma.no`). Resultatet blir `dkim=temperror` eller `permerror`. ### Ødelagt nøkkel Mellomrom, linjeskift eller ekstra anførselstegn midt i `p=`-verdien, eller at en lang nøkkel er kuttet ved 255 tegn. Sammenlign nøkkelen i DNS med den leverandøren oppgir. ### Innholdet endres etter signering Antivirus-gatewayer, signaturverktøy som legger til bunntekst og e-postlister som endrer emnefeltet, kan bryte signaturen. Signer så sent som mulig i kjeden. For videresending og e-postlister finnes ARC (RFC 8617), som lar mellomledd bevare autentiseringsresultatet. ### Gammel nøkkel eller svak algoritme 1024-bit nøkler og `rsa-sha1` bør byttes ut. Oppgrader til 2048 bit og `rsa-sha256` ved neste rotasjon. [Bilde: MailWatch domenevisning med status for SPF, DKIM, DMARC, MX og svartelister]Domenevisningen i MailWatch viser status for DKIM-selektorene dine sammen med SPF, DMARC, MX og svartelister. Vil du se hvordan domenet ditt står nå, kan du [sjekke domenet ditt gratis](https://mailwatch.no/domenesjekk). ## Ofte stilte spørsmål ### Hva står DKIM for? DKIM står for DomainKeys Identified Mail. Det er en standard (RFC 6376) der avsenderserveren signerer e-post med en privat nøkkel, og mottakeren verifiserer signaturen med en offentlig nøkkel som ligger i domenets DNS. ### Hva er en DKIM-selektor? En selektor er et navn som peker på én bestemt DKIM-nøkkel i DNS, på formen `selektor._domainkey.domene.no`. Den gjør det mulig å ha flere nøkler samtidig, for eksempel én per e-posttjeneste, og å rotere nøkler uten nedetid. Selektoren står i `s=`-feltet i DKIM-Signature-headeren. ### Hvilken nøkkellengde bør jeg bruke for DKIM? Bruk RSA med 2048 bit. 1024 bit er minimum etter RFC 8301, men regnes som svakt. Fordi en 2048-bit nøkkel er lengre enn 255 tegn, må TXT-posten deles i flere strenger, noe de fleste DNS-leverandører gjør automatisk. ### Hvor ofte bør jeg bytte DKIM-nøkkel? En vanlig anbefaling er hver 6. til 12. måned, og alltid ved mistanke om at nøkkelen kan være kompromittert. Publiser ny nøkkel under ny selektor, bytt signering, og trekk tilbake den gamle etter noen dager. ### Hvorfor feiler DKIM selv om nøkkelen er riktig? Den vanligste årsaken er at meldingen er endret etter signering, for eksempel av en bunntekst, et antivirusfilter eller en e-postliste. Det kan også skyldes at nøkkelen i DNS er kuttet eller inneholder mellomrom, eller at avsenderen signerer med en annen selektor enn du tror. ### Holder det med DKIM uten SPF? DMARC krever bare at én av dem består med alignment, så teknisk kan DKIM alene gi DMARC pass. I praksis bør du ha begge: Gmail og Yahoo krever både SPF og DKIM for store avsendere, og SPF er en reserve når DKIM-signaturen brytes. ## Oppsummering DKIM gir e-posten din en kryptografisk signatur som beviser hvor den kommer fra og at den ikke er endret. Bruk 2048-bit nøkler, én selektor per tjeneste, sørg for at alle tjenester signerer med ditt eget domene, og roter nøklene jevnlig. MailWatch overvåker DKIM-postene dine, viser i DMARC-rapportene hvilke tjenester som signerer riktig og hvilke som ikke gjør det, og varsler deg på e-post, SMS eller Pushover hvis en nøkkel forsvinner eller slutter å virke. [Start en gratis prøveperiode](https://mailwatch.no/auth/register) for å få oversikt. --- # Hva er DMARC? Policy, alignment og rapporter forklart URL: https://mailwatch.no/blog/hva-er-dmarc Publisert: 2026-02-16 DMARC bestemmer hva mottakere skal gjøre med e-post som utgir seg for å komme fra domenet ditt uten å bestå SPF eller DKIM. Her er policyer, alignment, rapporter og ferdige eksempler. **DMARC (Domain-based Message Authentication, Reporting and Conformance) er en DNS-post som forteller mottakerne hva de skal gjøre med e-post som bruker domenet ditt i Fra-adressen, men som ikke består SPF eller DKIM.** Samtidig ber den mottakerne sende deg rapporter om all e-post de ser fra domenet ditt. DMARC er definert i RFC 7489 og er det som faktisk stopper forfalskede avsenderadresser. **Kort fortalt:** - DMARC-posten ligger på _dmarc.firma.no og starter med v=DMARC1 . - En melding består DMARC hvis SPF eller DKIM består og samtidig samsvarer (er «aligned») med domenet i Fra-adressen. - Policyen styrer hva som skjer ved feil: p=none (bare overvåk), p=quarantine (søppelpost) eller p=reject (avvis). - Med rua= får du daglige aggregerte rapporter som viser hvem som sender e-post i ditt navn. - Start med p=none , rydd opp i avsenderne og stram inn gradvis til p=reject . ## Hvordan DMARC fungerer [SPF](https://mailwatch.no/blog/hva-er-spf) sjekker om serveren har lov til å sende for domenet i konvolutten (Return-Path). [DKIM](https://mailwatch.no/blog/hva-er-dkim) sjekker om meldingen er signert av et domene og ikke endret. Men ingen av dem sier noe om Fra-adressen mottakeren faktisk ser. Det er det hullet svindlere utnytter, og det er det DMARC tetter. Når en mottaker får en e-post fra `From: faktura@firma.no`, skjer dette: - Mottakeren slår opp TXT-posten på _dmarc.firma.no . - Den sjekker SPF og DKIM som vanlig. - Den sjekker om domenet som besto SPF eller DKIM, samsvarer med firma.no . - Består minst én av dem med alignment, består meldingen DMARC. Ellers brukes policyen i posten. - Resultatet registreres og sendes til deg i neste aggregerte rapport. ### Alignment: relaxed og strict Alignment betyr at domenet som er autentisert, må høre sammen med domenet i Fra-adressen. For SPF sammenlignes Fra-domenet med domenet i Return-Path. For DKIM sammenlignes det med `d=` i signaturen. | Modus | Tag | Krav | Eksempel med From: post@firma.no | | Relaxed (standard) | adkim=r / aspf=r | Samme organisasjonsdomene | d=nyhetsbrev.firma.no godkjennes | | Strict | adkim=s / aspf=s | Nøyaktig samme domene | Bare d=firma.no godkjennes | For de aller fleste er relaxed riktig. Strict gir lite ekstra beskyttelse og mange flere feil når tjenester sender fra subdomener. **Viktig:** En tjeneste kan bestå både SPF og DKIM og likevel feile DMARC. Det skjer når den bruker sitt eget domene i Return-Path og signerer med `d=tjenesten.com`. Løsningen er å sette opp egen DKIM-signering (ofte kalt «domeneautentisering») hos leverandøren, slik at den signerer med ditt domene. ## DMARC-policyene: none, quarantine og reject | Policy | Hva mottakeren gjør med meldinger som feiler | Når den brukes | | p=none | Ingenting spesielt. Meldingen behandles som vanlig, men rapporteres | I starten, for å kartlegge alle avsendere | | p=quarantine | Legger meldingen i søppelpost eller karantene | Når de fleste legitime avsendere består | | p=reject | Avviser meldingen under leveransen | Målet: full beskyttelse mot forfalskning | `p=none` beskytter ikke mot noe, den gir deg bare innsyn. Gmail og Yahoo godtar `p=none` som minimum for avsendere med mer enn 5000 meldinger om dagen (krav fra februar 2024), og Microsoft stiller samme minimumskrav for Outlook.com fra mai 2025. Men det er først med quarantine eller reject at svindlere faktisk blir stoppet. Det er særlig viktig mot direktørsvindel og falske fakturaer, der angriperen utgir seg for å være deg. ## Alle taggene i en DMARC-post En DMARC-post er en TXT-post på `_dmarc`-subdomenet: ``` _dmarc.firma.no. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@firma.no; adkim=r; aspf=r" ``` | Tag | Verdier | Betydning | | v | DMARC1 | Påkrevd, skal stå først | | p | none , quarantine , reject | Påkrevd. Policy for domenet | | sp | som p | Policy for subdomener. Utelatt betyr at subdomener arver p | | rua | mailto: -adresse(r) | Hvor aggregerte rapporter skal sendes | | ruf | mailto: -adresse(r) | Hvor feilrapporter (forensic) skal sendes | | pct | 0–100 (standard 100) | Andel av feilende meldinger policyen gjelder for | | adkim | r / s | Alignment for DKIM (standard relaxed) | | aspf | r / s | Alignment for SPF (standard relaxed) | | fo | 0 , 1 , d , s | Når feilrapporter skal lages. 1 = hvis SPF eller DKIM feiler | | ri | sekunder (standard 86400) | Ønsket rapportintervall. De fleste sender uansett daglig | ### rua og ruf: rapportene **rua** gir deg aggregerte rapporter i XML, vanligvis én per mottaker per døgn. De inneholder ikke selve e-postene, men IP-adresser, antall meldinger og SPF-, DKIM- og DMARC-resultat for hver kilde. Det er her du ser at nettbutikken sender uten DKIM, eller at noen i utlandet forsøker å sende i ditt navn. Hvordan du tolker dem, står i [slik leser du DMARC-rapporter](https://mailwatch.no/blog/lese-dmarc-rapporter). **ruf** gir feilrapporter om enkeltmeldinger. De kan inneholde personopplysninger, og de store leverandørene som Gmail og Microsoft sender dem i liten grad eller ikke i det hele tatt. For de fleste norske virksomheter er rua nok, og det er enklere å forholde seg til GDPR uten ruf. Skal rapportene til et annet domene enn ditt eget, for eksempel en overvåkingstjeneste, må det domenet bekrefte at det tar imot rapporter for deg med en egen TXT-post (`firma.no._report._dmarc.mottaker.no`). Seriøse tjenester ordner dette automatisk. ### pct og sp `pct` lar deg innføre en streng policy gradvis. Med `p=quarantine; pct=25` blir en fjerdedel av de feilende meldingene lagt i søppelpost, resten behandles som om policyen var ett nivå lavere. Støtten varierer mellom mottakere, og den oppdaterte DMARC-spesifikasjonen som er under arbeid i IETF (DMARCbis), fjerner `pct` til fordel for et enklere testflagg. Bruk den gjerne underveis, men ikke bygg strategien rundt den. `sp` gir subdomenene en egen policy. Vanligst er å la subdomenene arve hovedpolicyen, eller sette `sp=reject` for å hindre misbruk av oppdiktede subdomener som `faktura.firma.no`. ## Eksempler: DMARC-poster du kan bruke ### 1. Start: bare overvåking ``` v=DMARC1; p=none; rua=mailto:dmarc@firma.no ``` Ingen påvirkning på leveransen. Du begynner å motta rapporter. ### 2. Gradvis innstramming ``` v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@firma.no ``` ### 3. Full beskyttelse ``` v=DMARC1; p=reject; rua=mailto:dmarc@firma.no ``` ### 4. Hoveddomene i karantene, subdomener avvist ``` v=DMARC1; p=quarantine; sp=reject; rua=mailto:dmarc@firma.no ``` ### 5. Domene som aldri sender e-post ``` v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s ``` Kombiner med SPF-posten `v=spf1 -all`. Det er en enkel måte å stenge parkerte domener mot misbruk. **Tips:** Bruk en egen adresse eller en tjeneste til rua. Et aktivt domene kan få dusinvis av XML-filer i døgnet, og de er ikke laget for å leses i en vanlig innboks. ## Slik innfører du DMARC trygt Å hoppe rett til `p=reject` er den sikreste måten å stoppe din egen fakturautsendelse på. Innføringen bør skje i faser: - Kartlegg: Publiser p=none med rua og samle rapporter i minst to til fire uker. - Rydd opp: Sørg for at alle legitime tjenester (e-postplattform, CRM, nyhetsbrev, fakturasystem, nettbutikk) består SPF eller DKIM med alignment. Sett opp egen DKIM der det mangler. - Stram inn: Gå til p=quarantine , gjerne med pct først, og følg med på rapportene. - Fullfør: Når rapportene viser at bare uautoriserte kilder feiler, går du til p=reject . - Overvåk: Nye tjenester og endringer hos leverandører dukker opp hele tiden. Fortsett å lese rapportene. Hele prosessen med sjekklister og hva du ser etter i hver fase, finner du i artikkelen [fra p=none til p=reject: DMARC steg for steg](https://mailwatch.no/blog/dmarc-oppsett-steg-for-steg). [Bilde: MailWatch-oversikt over DMARC-rapporter per rapportør med SPF- og DKIM-resultater]MailWatch tar imot og tolker DMARC-rapportene automatisk, slik at du ser hvilke avsendere som består SPF og DKIM før du strammer inn policyen. ## Vanlige DMARC-feil - Posten ligger på feil sted. Den skal på _dmarc.firma.no , ikke på firma.no . Pass også på at DNS-panelet ikke legger til domenet to ganger. - Flere DMARC-poster. Har _dmarc mer enn én post som starter med v=DMARC1 , ignoreres DMARC. - Bli stående på p=none for alltid. Mange stopper etter første steg. Da får du rapporter, men ingen beskyttelse. - Ingen rua. Uten rapporter flyr du i blinde og kan ikke trygt stramme inn. - Syntaksfeil. Manglende semikolon, rua=dmarc@firma.no uten mailto: , eller at v=DMARC1 ikke står først. - Glemte avsendere. Tjenester som sender i ditt navn uten alignment, blir stoppet når du går til quarantine eller reject. Det er derfor rapportene er så viktige. Er du usikker på hvordan domenet ditt står i dag, kan du [sjekke domenet ditt gratis](https://mailwatch.no/domenesjekk) og se SPF, DKIM og DMARC på ett sted. ## Ofte stilte spørsmål ### Hva står DMARC for? DMARC står for Domain-based Message Authentication, Reporting and Conformance. Det er en standard (RFC 7489) som bygger på SPF og DKIM, og som lar domeneeieren bestemme hva mottakere skal gjøre med e-post som feiler autentisering, og få rapporter om all e-post som sendes i domenets navn. ### Hva er forskjellen på p=none, p=quarantine og p=reject? `p=none` betyr at mottakeren bare rapporterer og leverer som vanlig. `p=quarantine` betyr at meldinger som feiler, havner i søppelpost. `p=reject` betyr at de avvises helt. Bare quarantine og reject gir reell beskyttelse mot forfalskning. ### Må både SPF og DKIM bestå for at DMARC skal bestå? Nei. Det holder at én av dem består og samtidig er aligned med domenet i Fra-adressen. I praksis bør du likevel ha begge, fordi SPF brytes ved videresending og DKIM kan brytes hvis meldingen endres underveis. ### Hva er DMARC-alignment? Alignment betyr at domenet som består SPF (Return-Path) eller DKIM (`d=`), hører sammen med domenet i Fra-adressen. Med relaxed alignment, som er standard, holder det at de har samme organisasjonsdomene. Med strict må de være helt like. ### Hvor lang tid tar det å gå fra p=none til p=reject? For en liten virksomhet med få tjenester kan det ta noen uker. Større organisasjoner med mange systemer som sender e-post, bruker ofte to til seks måneder. Det avgjørende er at DMARC-rapportene viser at alle legitime avsendere består før du strammer inn. ### Trenger jeg DMARC hvis jeg ikke sender nyhetsbrev? Ja. DMARC beskytter først og fremst mot at andre sender e-post i ditt navn, for eksempel falske fakturaer til kundene dine. Det gjelder alle domener, også de som bare brukes til vanlig e-post eller ikke sender e-post i det hele tatt. ## Oppsummering DMARC binder SPF og DKIM sammen med Fra-adressen, gir deg innsyn gjennom rapporter og lar deg til slutt avvise all forfalsket e-post fra domenet ditt. Start med `p=none` og `rua`, bruk rapportene til å rydde opp, og stram inn til `p=reject`. MailWatch tar imot og tolker DMARC-rapportene for deg, viser hvem som sender på vegne av domenet, overvåker DMARC-, SPF- og DKIM-postene fortløpende og varsler deg på e-post, SMS eller Pushover når noe endrer seg. Du kan [prøve gratis i 30 dager](https://mailwatch.no/auth/register). --- # Ofte stilte spørsmål ## Hva er SPF, og hvorfor trenger jeg det? SPF er en DNS-oppføring som forteller mottakende e-postservere hvilke servere som har lov til å sende e-post på vegne av domenet ditt. Uten SPF kan hvem som helst sende e-post som ser ut som den kommer fra ditt domene, noe som kan føre til phishing og svindel. ## Hva er DKIM, og hvordan fungerer det? DKIM (DomainKeys Identified Mail) legger til en digital signatur i e-postene dine. Mottakerserveren sjekker signaturen mot en offentlig nøkkel publisert i DNS for å verifisere at meldingen er ekte og ikke er endret underveis. ## Hva er DMARC, og hvordan beskytter det meg? DMARC (Domain-based Message Authentication, Reporting and Conformance) lar deg bestemme hva som skal skje med e-post som ikke passerer SPF- eller DKIM-sjekker. Du kan velge å overvåke (none), sette i karantene (quarantine) eller avvise (reject) slike meldinger. DMARC gir deg også rapporter om all e-posttrafikk fra domenet ditt. ## Hva er MX-oppføringer? MX (Mail Exchange) er DNS-oppføringer som forteller andre e-postservere hvor e-post til domenet ditt skal leveres. Feil MX-oppsett kan føre til at e-post ikke kommer frem eller havner på feil server. ## Hva koster MailWatch? MailWatch har tre planer: Gratis prøveperiode (30 dager), Start til 950 kr/år eks. mva for opptil 5 domener, og Business til 2 500 kr/år eks. mva med ubegrensede domener og alle funksjoner. MVA (25%) legges til ved betaling. ## Hvordan kommer jeg i gang? Det er enkelt å komme i gang med MailWatch: 1) Registrer en gratis konto, 2) Legg til domenet du vil overvåke, 3) MailWatch sjekker automatisk SPF, DKIM, DMARC og MX, og gir deg en helsescore. Du får umiddelbart oversikt over e-postsikkerheten din. ## Hvilke varslingskanaler støttes? MailWatch kan varsle deg via e-post, SMS, Pushover og WhatsApp når det oppstår endringer eller problemer med e-postsikkerheten din. Du velger selv hvilke kanaler du vil bruke og hva du vil bli varslet om. ## Hva er en helsescore? MailWatch beregner en helsescore fra 0 til 10 for hvert domene basert på SPF-, DKIM-, DMARC- og MX-oppsettet ditt. En høy score betyr at e-postsikkerheten er godt konfigurert. Scoren oppdateres automatisk ved hver sjekk.