Hver server der i går sendte mail i dit domænes navn, står måske allerede i en rapport adresseret til dig. De færreste ejere har nogensinde åbnet én.
Har dit domæne en DMARC-record med en rapporteringsadresse — "rua"-feltet — sender verdens store mailmodtagere dig allerede rapporter, typisk én pr. modtager pr. dag. Hver rapport lister hver server der har sendt mail i dit domænes navn: mængderne, IP-adresserne, og om hver kilde bestod SPF- og DKIM-tjekkene. Du skal hverken købe noget eller tilmelde dig noget for at modtage dem. De kommer, fordi du selv har bedt om dem — måske for flere år siden, i en DNS-record nogen satte op og glemte.
Og så er der næsten ingen der læser dem, hvilket er forståeligt snarere end skødesløst. Rapporterne ankommer som zippede XML-vedhæftninger, bygget til maskiner, ikke mennesker. Åbner man en i sit mailprogram, ser man en vedhæftning med et halvtreds tegn langt filnavn; åbner man selve filen, ser man indlejrede koder og IP-adresser. Indholdet er ellers oprigtigt nyttigt — det besvarer et spørgsmål intet andet værktøj besvarer, nemlig "hvem derude sender e-mail i mit navn?" — men formatet garanterer at svaret bliver liggende ulæst i en indbakke.
Hvad indeholder en DMARC-rapport?
En DMARC-rapport er en daglig opsummering fra én mailmodtager, der lister hver server som har sendt mail i dit domænes navn: hvor mange beskeder der kom fra hver kilde, fra hvilke IP-adresser, og om hver kilde bestod SPF- og DKIM-tjekkene. Den indeholder ikke selve beskederne — den er en optælling af hvem der sendte, hvorfra, og om mailen bestod kontrollen.
Den skelnen er vigtig for forventningerne. En rapport fortæller dig at en bestemt server sendte fyrre beskeder som dit domæne i tirsdags, og at ingen af dem bestod kontrollen. Den viser dig ikke beskederne, emnelinjerne eller modtagerne. Den er en folketælling, ikke en aflytning — og derfor rejser det heller ingen af de privatlivsspørgsmål, som det ville gøre at læse rigtig post.
Én praktisk krølle, hvis du nogensinde læser dem i hånden: rapporter fra den virkelige verden afviger fra standarden på små punkter. Forskellige modtagere pakker filerne forskelligt, navngiver dem forskelligt og udelader eller ombytter af og til felter som standarden siger burde være der. Et værktøj der læser dem, skal kunne tåle det, og en streng fortolker vil kløjes i helt ægte rapporter fra store udbydere.
Er ukendte afsendere i en DMARC-rapport tegn på et angreb?
Som regel ikke. I den første rapport viser de fleste afsendere man ikke genkender, sig at være ens egne systemer: fakturasystemet, nyhedsbrevsværktøjet, bookingsystemet, et CRM — legitime afsendere som aldrig blev skrevet ind i SPF eller DKIM. At finde og godkende dem er den vigtigste tidlige gevinst, for en strammere politik ville ellers begynde at afvise jeres egne fakturaer.
Sådan går det for næsten alle virksomheder, for afsendersystemer hober sig op. Regnskabsprogrammet blev sat op ét år, nyhedsbrevsværktøjet et andet, bookingsystemet af et bureau der siden er skiftet ud. Hvert af dem sender mail "fra" jeres domæne, og hvert af dem skulle dengang have været skrevet ind i jeres SPF-record eller have haft en DKIM-nøgle — et trin der er let at springe over, fordi mailen som regel bliver leveret alligevel, så længe politikken er lempelig. DMARC-rapporten er ofte den første komplette oversigt virksomheden nogensinde har set over sine egne afsendere.
Den rigtige første reaktion på en rapport fuld af ukendte kilder er derfor nysgerrighed, ikke alarm. Gå dem igennem én ad gangen: et IP-område der tilhører jeres nyhedsbrevsudbyder, er jeres nyhedsbrev, og løsningen er at godkende det ordentligt — guiden til SPF- og DKIM-opsætning viser hvordan. Kun det der er tilbage efter den øvelse, fortjener mistanke.
Hvordan ser egentligt misbrug ud i DMARC-rapporterne?
Vedvarende mængder fra kilder der dumper både SPF og DKIM, ofte sendt fra netværk uden nogen forbindelse til jeres forretning — et hostingområde I aldrig har brugt, i et land I aldrig har handlet med, der sender mail som jeres domæne dag efter dag. Det mønster er nogen der låner jeres domænenavn til spam eller phishing, og det er præcis hvad rapporterne er lavet til at afsløre.
Læg mærke til signalets form: det er kombinationen der tæller. Begge tjek dumpet, i mængder, gentagne gange, fra et sted uden forbindelse til jer. Hvert element for sig er et svagt bevis — masser af ægte mail dumper ét tjek af kedelige årsager, som næste afsnit forklarer. Men en server der dumper alt og bliver ved med at sende, har ingen uskyldig forklaring, for en ægte afsender af jeres ville høre til et system I kan genkende — et bogholderi, et nyhedsbrevsværktøj, et bureau.
Ser du det mønster, er svaret ikke at jagte afsendernetværket — det er at stramme din politik, så de modtagende servere nægter at tage imod mailen. Det er netop det håndtag DMARC giver dig: du kan ikke forhindre nogen i at skrive dit domæne i et afsenderfelt, men du kan bede verdens mailudbydere om ikke at acceptere det, når de gør.
Hvorfor dumper nogle ægte mails SPF i rapporterne?
Fordi videresendelse bryder SPF efter sin natur. Når en besked videresendes automatisk, eller går gennem en mailingliste, ankommer den hos den endelige modtager fra videresenderens server i stedet for jeres, så SPF-tjekket fejler selvom beskeden er ægte. Spredte enkeltfejl i en rapport er hverdag, ikke et angreb.
Det er værd at have på plads, før du læser din første rapport, for ellers ligner hver linje med en fejl i en hændelse. En kunde der automatisk videresender sin arbejdsmail til en privat postkasse, giver en SPF-fejl i den udbyders rapport. En modtager på en gammeldags diskussionsliste giver en til. De viser sig som én eller to beskeder fra en ukendt server, én gang, og så en anden ukendt server ugen efter. DKIM overlever ofte videresendelse hvor SPF ikke gør — signaturen rejser med inde i beskeden — og det er en af grundene til at sætte begge op frem for at nøjes med SPF.
Det tåler også gentagelse, at det her er daglige opsummeringer, ikke alarmer. En rapport fortæller ikke at noget gik galt i dag; den fortæller hvad verden så. Det du skal læse efter, er tendensen over uger, ikke nogen enkelt linje.
Hvornår bør jeg stramme min DMARC-politik?
Først når du har læst rapporterne og godkendt hver legitim afsender de afslører. Den sikre vej er trinvis: bliv i overvågningstilstand indtil rapporterne er rene, gå så til karantæne, og derefter til afvisning. At stramme før man har læst, er sådan virksomheder ender med at afvise deres egne fakturaer og ordrebekræftelser.
De tre politikniveauer — "none", "quarantine", "reject" — er en bevidst trappe. "None" ændrer ingenting ved leveringen og findes alene så du kan følge rapporterne. "Quarantine" beder modtagerne behandle fejlende mail med mistro, typisk ved at lægge den i spam. "Reject" beder dem afvise den helt, og det er målet: derfra ankommer mail der forfalsker jeres domæne og dumper kontrollen, ganske enkelt ikke. Trappen virker kun taget i rækkefølge, for hvert trin forudsætter at det forrige viste et rent billede. Et domæne der springer direkte til "reject", mens et ikke-godkendt fakturasystem stadig sender, er et domæne hvis fakturaer holder op med at nå frem — i stilhed, og kun hos nogle modtagere, hvilket gør fejlen elendig at finde.
Rækkefølgen ligger altså fast: læs rapporterne, godkend de legitime afsendere de afslører, følg med indtil de fejl der er tilbage, er den videresendelses-støj der er beskrevet ovenfor, og stram så ét trin ad gangen. Uger på hvert trin er normalt. Der er ingen præmie for at nå "reject" hurtigt, og en reel pris for at nå derhen for tidligt.
Hvad du kan gøre i denne uge
Undersøg om din DMARC-record har en rapporteringsadresse. Har den ikke, så tilføj en — rapporterne koster ingenting og begynder at komme inden for få dage. Åbn så faktisk én: pak vedhæftningen ud, se på kilderne, og spørg om hver ukendt kilde "er det et system vi bruger?" før du spørger om noget mørkere. Godkend det der er jeres, hold øje med resten, og begynd først derefter at gå op ad politik-trappen.
Lyder det ikke som en velbrugt uge at pakke XML ud i hånden, er det præcis den slags arbejde overvågning findes til. MailControl modtager og læser dine DMARC-rapporter for dig, viser i almindeligt sprog hvem der sender som dit domæne, skiller jeres egne endnu ikke godkendte systemer fra afsendere uden nogen forbindelse til jer, og siger til når billedet er rent nok til at stramme politikken. Det ligger sammen med resten af TrustCtrl-tjekkene på jeres domæne, og den større sammenhæng — hvorfor autentificering afgør om I overhovedet når indbakken — er dækket i hvorfor havner mine mails i spam.