Fra p=none til p=reject: DMARC-oppsett steg for steg
· 10 min lesetid · Av MailWatch-teamet
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.
- 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. p=none holder for å oppfylle kravene fra Gmail, Yahoo og Outlook, 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 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, men de fleste velger å sende rua til et verktøy som tolker dem automatisk.
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 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.

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.
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.
Prøv MailWatch gratis i 30 dager · Sjekk domenet ditt gratis