DMARC advarer dig både mod phishing og glemte mailservere

Tre teknologier har tilsammen gjort det muligt at sikre sig mod misbrug af domænet til svindel med e-mailadresser, men den nyeste har endnu begrænset udbredelse i Danmark.

Det er blevet sværere at slippe af sted med at få en e-mail til at se ud til at komme fra en pålidelig afsender. Eller det burde det være, men det er langt fra alle danske domæner, som benytter den nyeste af de tre teknologier, der tilsammen forhindrer e-mail-spoofing.

Mens cirka 200.000 danske domæner anvender SPF, Sender Policy Framework, så er det blot lidt over 16.000 danske domæner, som også har implementeret DMARC. Det oplyser DK-Hostmaster, som administrerer de danske domæner, til Version2.

Den sidste af de tre, DMARC, er særligt interessant, fordi den handler om at håndhæve de andre to på en systematisk måde, og den kan samtidig gøre det lettere at sætte SPF og DKIM op.

DMARC er en protokol, som skal fortælle modtageren, hvordan en mail, der ser ud til at være spoofet, skal håndteres.

Det er både nyttigt til at hjælpe modtageren med at gennemskue en forfalsket afsender, men det er frem for alt nyttigt for den, der ejer det domæne, som svindlerne forsøger at benytte sig af.

»Med DMARC kan man signalere, hvordan man skal håndtere den mail, man modtager,« forklarer sikkerhedschef Erwin Lansing fra DK-Hostmaster.

Svært at få overblik i større organisationer

Både SPF, DKIM og DMARC benytter sig af DNS til at fortælle e-mailmodtagere, hvordan en e-mail fra domænet skal kontrolleres.

SPF fortæller, hvilke mailservere der må sende mails fra domænet.

DKIM bruger et krypteringsnøglepar til at kontrollere, at mailen er sendt fra en gyldig mailadresse på den godkendte server, og at der ikke er sket ændringer i mailen undervejs.

DMARC fortæller modtagerens mailserver, hvordan den skal håndtere e-mails, der dumper den ene eller begge de to test. Det kan enten være en afvisning, karantæne eller blot en notifikation til mailadministratoren på afsenderdomænet om fejlen.

»Den kan fortælle afsenderen, at der er en mail, der er blevet afvist. Det er rigtig smart. Hvis man er en stor virksomhed, så har man måske ikke overblik over alle de servere, der skal have lov til at sende e-mails fra domænet. Der kunne for eksempel være en server, der udsender et nyhedsbrev,« forklarer Erwin Lansing.

Start med notifikationer

Hvis man har sat SPF og DKIM op, så kan det altså være en god idé i første omgang at sætte DMARC op til blot at sende notifikationer, så man kan rette op på, at der eksempelvis er en server til nyhedsbreve, som ikke er inkluderet i SPF.

Alle tre teknologier understøttes af de store mailudbydere og mailservere som eksempelvis Google og Microsoft.

På den måde er der en god chance for at få feedback på, om man har sat sine domæner korrekt op, inden man skruer op for sikkerhedsniveauet og beder modtagerne om at afvise mails, der dumper SPF og DKIM.

Ifølge DK-Hostmaster har cirka 45 procent af de danske domæner, der bruger DMARC, konfigureret det til blot at notificere mailadministratoren.

50 procent, heriblandt flere af de domæner, der er oplagte mål for spoofing af afsenderadressen i phishing, har sat deres DMARC til at afvise mailen. Det vil sige, at hvis en mailserver, som benytter DMARC, modtager en phishing-mail, der forsøger at se ud til at være sendte fra eksempelvis Danske Banks domæne, så vil mailen blive afvist.

Flere hostingudbydere benytter også DMARC til at afvise mails, der foregiver at være afsendt fra parkerede domæner.

Det vil sige domæner, som ikke aktivt er i brug, og derfor ikke burde bruges til at afsende mails.

Ud over at sikre sig mod misbrug af domænenavnet, så kan der også være andre gode grunde til at implementere alle tre mail-beskyttelsesteknologier.

»DMARC indgår også i den scoring, der laves i nogle spamfiltre, og dermed kan man som afsender være mere sikker på at for eksempel ens nyhedsbrev når frem til modtageren,« siger Erwin Lansing.

SPF, DKIM og DMARC kan dog kun beskytte mod phishing på de domæner, der benytter teknologierne og hos de modtagere, der har implementeret DMARC-håndtering.

Phishing-mails afsendt fra domæner, der er valgt, fordi de let kan forveksles med det rigtige domæne, bliver ikke stoppet af de tre teknologier.

»Det kan ikke tage typo-squatting, men forhindrer misbrug af de rigtige domæner,« siger Erwin Lansing.

DMARC er stadig på et forholdsvis tidligt trin i den lange standardiseringsproces, men siden 2015 har der dog været en stabil version af specifikationen, og flere store mailudbydere understøtter i dag DMARC.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk

Kommentarer (21)

Henrik Størner

Den egentlige verifikation af om en mail er valid foregår stadig med SPF og DKIM. Afsenderen kan med de to teknikker fortælle hvordan modtageren bør håndtere mails der fejler validering, og modtageren vælger selv om han vil validere mails med SPF og DKIM.

Så hvor er det at DMARC giver mig en fordel? Som legitim afsender skal jeg blot sørge for at få en "pass" på SPF og DKIM, og som modtager er det stadig væk de to der giver mig mest information om hvorvidt afsenderen er den, han siger han er.

Min mail-server skal så ydermere bruge krudt på at sende rapporter til domæne-ejeren når der har været forsøg på misbrug af hans domæne.

Så som domæne-ejer, hvad får jeg ud af at sætte en DMARC record op, andet end rapporter fra mailservere - som jeg alligevel ikke kan bruge til særlig meget?

(Og så ser jeg helt væk fra hvordan DMARC giver problemer med mailinglister).

Michael Fjeldsted

Så hvor er det at DMARC giver mig en fordel?

Spf validerer envelope og ikke from address.
Dkim er valgfrit på hver enkelt mail.
Du skal sætte spf og dkim op for hvert enkelt subdomain.

Dmarc kan du sætte op på hoved domain dvs fra skat.dk og så dækker det også alle tænkelige subdomain - som fx email.skat.dk selvangivelse.skat.dk eller hvilket subdomain man nu kan finde hvor der ikke er sat noget spf op.

Mad Dmarc angive du samtidigt at spf og dkim på alle mails skal være valid og at spf skal være aligned, så det ikke bare er en envelope på et andet domain. Du kan angive at hvis ikke spf og dkim er valid og aligned så skal mail'en afvises af modtageren.

Så som domæne-ejer kan du med dmarc sikre dig at dit domain ikke bliver misbrugt af andre. Hvis vi ser på dmarc record på skat.dk - så kan vi lige nu se at den ikke bliver brugt til at afvise mails, men kun informere. Dvs lige pt får skat rapporter tilbage omkring alle mails afsendt med domænet eller subdomæner af skat.dk. Når en gang de er klar til at afvise - så kan du faktisk stole på at en email fra @skat.dk rent faktisk er fra skat, men det der er lidt vej endnu fra skats side.
Samtidigt kræver det at din email udbyder rent faktisk afviser mails, som Dmarc siger der skal afvises. Google, Microsoft, Apple og Tdc understøtter dmarc, og hvis du ser på hvor danskerne har deres email, så er de 4 hvis de største.

Erwin Lansing

Din mailserver kan sende rapporter tilbage til domæne-ejeren hvis den tjekker DMARC ved modtagelse. Det kan du gøre hvis du vil hjælpe dem der sender mails til dig. Hvis du ikke vil det, kan du konfigurere din mailserver til ikke at sende rapporterne.

Hvis du ikke vil modtage rapporter for de mails din server sender ud, kan du ligeledes slippe for dem ved ikke at angive rapporteringsadresser i din DMARC-informationer. Du får alligevel det fordel at du, som domæne-ejer, kan instruere den modtagne mailserver hvordan den skal håndtere mails fra dine domæner hvis de fejler SPF og/eller DKIM, i stedet for at overlade det til den lokale politik hos modtageren. Hvis du er helt sikker på alle dine rigtige mails har korrekt SPF og DKIM, kan du sætte en reject politik så du er helt sikker på at falske emails aldrig kommer i modtagerens indbakke eller spam folder. På den anden side, vil nogle modtagere sætte en højere score for domæner med DMARC hvis mailen har gode SPF og DKIM, og du er dermed sikker på de mails netop havner i indbakken og ikke spamfolderen.

Claus Krogsgaard-Mattsson

Det er ikke helt korrekt. DKIM har i modsætning til DomainKeys ingen policy records. SPF fejler desuden ofte, når der forwardes og anvendes backup mx.

DMARC sikre domæneejeren at han kan definere minimumskravene til at acceptere mailen i modtagersystemet. Jeg kan f.eks. definere at en af de to mekanismer kan fejle, men at det er ok, så længe den anden mekanisme validere.

Med rapporterne er du med til at gøre opmærksom på, hvis der er et åbentlyst misbrug eller en fejl konfiguration. Det giver god mening for domæneejeren og er i alles interesse.

Rapporterne skal naturligvis fødes ind i et system, således du kan holde øje med ovennævnte. Dmarcian.com er et ok sted at starte...

Christoffer Thomsen

SPF har en mekanisme til at angive, hvordan modtageren skal behandle mails, som fejler et SPF-tjek, men DKIM har ikke. Spamfiltre kan derfor ikke som udgangspunkt antage at en mail uden DKIM-signatur er uautoriseret, heller ikke selvom domænet offentliggør en DKIM-nøgle i DNS.

Med DMARC kan du angive en politik for, hvordan fejlede SPF- og DKIM-tjek skal behandles. Du kan f.eks. angive, at alle mails fra dit domæne skal bestå både SPF- og DKIM-tjek, eller at mails gerne må fejle en af delene.

Du kan også angive, hvor strengt DMARC-politikken skal håndhæves. Du kan bede om blot at få tilsendt en rapport (f.eks. til postmaster-adressen på dit domæne), at mailen skal i "karantæne" (afvises ikke, men behandles som mistænksom – betyder typisk at den lægges i mailboksens spammappe), eller at modtagelse af mailen helt skal afvises.

Mailservere/spamfiltre kan selvfølgelig selv bestemme, hvor strengt de følger den offentliggjorte DMARC-politik, og de kan også selv vælge om de vil udsende DMARC-rapporter.

Som domæneejer får du det samme ud af det, som du får ud af at sætte SPF og DKIM op: bedre sikkerhed for at kun autoriserede servere kan sende mails med dit domæne som afsender.

Lasse Mølgaard

Men Google gør!

En af mine venners domæner blev hostet på min server. Han kunne ikke forstå at visse mails nåede ikke frem til modtageren. Jeg fandt ud af at modtageren var en Gmail-konto og at mailen røg direkte i spam mappen - til trods for at indholdet af mailen var helt normalt.

Så jeg sende en test mail til unlocktheinbox.com (genial værktøj) og fandt ud af at der var problemer med DMARC opsætningen.

Efter jeg rettede opsætningen til, var der ingen problemer.

Claus Andersen

De store er blevet for store - så derfor er end ikke DMARC nok. Men det er den hammer vi har.

Gmail og Hotmail fylder så enormt meget, at det er dem der driver hvad folk gør. De understøtter begge DMARC og sender fine rapporter til dig. Men de agerer ikke særligt godt på dem.

Jeg har haft et personligt domæne gennem mange år med meget få brugere på. De seneste år har det lagt hos Bluehost, men jeg har nu taget mig sammen til selv at tage mig af det. Jeg har arbejdet med mail siden X.400 (uha uha), så det burde jo ikke være noget problem.

Jeg startede med at sætte DKIM og SPF op. Checkede det virkede og kørte et par måneder i "test". Satte DMARC op med rapportering til Dmarcian og alt var smukt.

Min IPv4 og min IPv6 adresse er "rene". De er ikke listet i nogen blacklists overhovedet.

Jeg har skiftet til "strict" for DKIM, SPF og DMARC. Ingen "tilder" her!

Dvs. jeg burde have den mest paranoide og ønskværdige opsætning. Jeg er ligeglad med maillister - alt post fra mig kan kun komme fra 2 IP adresser. Jeg har lavet utallige tests og verificeret så godt jeg kunne.

Men Hotmail var ligeglad - og Google var ligeglad. Kan de ikke lide dig - så er du på herrens mark. Normale kommunikationsformer fungerer ikke med giganterne - de opstiller selv deres egen retningslinier. Begge har så webforms man kan henvende sig via. Gad vide hvor mange andre ude i verden der har en webform der venter på mig? Jeg er ikke børnefornærmet over at havne i deres fælde. Min harme er istedet at de hellere blokerer en gang for meget (selvom SPF, DKIM og DMARC er på plads - på et gammelt domæne). Dernæst at man skal bruge rigtigt meget tid på at finde Deres webforms for de-listing. Det burde som minimum være på den side deres 550 linker til.

Efter henvendelsen til Hotmail fik jeg automatiserede mails tilbage der ikke rigtigt sagde noget. Tilgengæld har der ikke været problemer med at levere til dem siden.

Google derimod er ligeglade - det er som vinden blæser. Man får ingen respons. Nogle gange virker det - andre gange ikke.

Fejlbeskeden man får fra dem er:

550-5.7.1 [2a01:4f8:c17:1733::2       1] Our system has detected an  
    unusual rate 550-5.7.1 of unsolicited mail originating from your IP  
    address. To protect our 550-5.7.1 users from spam, mail sent from your IP  
    address has been blocked.

Seneste fejlbesked fra den 15/2 - idag 16/2 gik en mail igennem. Det kan man dog ikke regne med er permanent.

Naturligvis har jeg sikret min postfix ikke er et open relay. At mit certifikat er gyldigt. At min FreeBSD ikke har andre suspekte services kørende. Checket at netstat ikke mener der er andet end min legitime trafik. Og naturligvis mine maillogs (der er ikke nogen der har gættet mine brugeres password). "Unusual amount" fra min adresse vil derfor være i omegnen af 1 - 3 legitime mails pr. dag.

Jeg har yderligere været listet hos dnswl.org siden 7/2. Og har ikke været listet i nogle offentlige blacklists overhovedet.

Seneste DMARC rapporter (rua) modtaget fra Google angiver for både DKIM og SPF at DMARC er "aligned" og med status "pass" (på visse mails).

Det er pokkers svært at bevise "negativer". Altså at bevise at jeg ikke gør noget skidt. Mit bedste argument er, at hvis jeg skulle være kompromitteret på ukendt vis, så er det mærkeligt, at jeg ikke er fanget nogen blacklists ude i verden.
Omvendt, så giver Google ingen log informationer. Det står til troende at deres system virker. Man kan ikke henvende sig til dem ud over en webform som de ikke svarer på. De sender heller ikke noget til "ruf" (dmarc) eller abuse@. Den omvendte bevisbyrde er tung at løfte.

Så min pointe er, at SPF, DKIM og DMARC er fint nok. Men vi er på vej til at overgive det hele til de store. Istedet for, at være et reelt netværk hvor vi er nødt til, at spille sammen efter aftalte spilleregler, så er det istedet de store der sætter dagsordenen og gør som de har lyst.

Det er nu vi "små fisk" skal stille kravene til de "større fisk" (firmaer/offentlige) om at følge standarderne. Gør vi ikke det, så fortsætter de "store fisk" med grønthøstermetoderne. De "større fisk" skal nok klare sig, da de på sigt blot vil købe sig til ydelsen hos de "store fisk". Store monopoler har IMHO aldrig været en god ting.

Så DMARC, SPF og DKIM er kedeligt stof - men vi bør alle gøre en indsats for at få det udbredt. Manglende handling fordi "det virker fint nu" vil komme tilbage og jage os grusomt.

Henrik Schack

Har du også de problemer hvis du leverer over IPv4 til Google ?

Iøvrigt, hvis du kan få afvist en email til en betalende kunde hos Google, så kan vedkommende oprette en support sag på hvorfor han ikke kan modtage email fra dig.

Claus Andersen

Begge protokoller er enablet.

inet_protocols = ipv4,ipv6

smtp_address_preference er ikke sat og default'er derfor til any.

Jeg respekterer derfor Google's præference (via MX). Har ikke kørt med IPv4 only. Jeg er 97,98% sikker på, at jeg kun har set fejlen over IPv6.

De mails der er gået igennem i dag kan jeg se er via IPv4. Der er ikke lavet nogen ændringer serverside hos mig fra i går til i dag. Om Google har skiftet præference - eller det blot er en tilfældighed i resolveren ved jeg ikke. Men et supervigtigt datapunkt.

Jeg er faktisk også betalende kunde på G Suite, så i mit tilfælde vil det være ret nemt. Det er dog blot en meget omvendt måde at gøre tingene på, da det er modtageren der skal oprette sagen. Det er jo den omvendte verden hvilket jeg ser ret stramt på. Prøver det nok i praksis, men er principielt meget imod det.

Elmer Henriksen

Jeg droppede Google Apps for tre år siden og skiftede til egen mailserver, og jeg har oplevet nøjagtig det samme. Jeg vil efterhånden mene at jeg har prøvet alt:

  • Fire forskellige ISP'er i mindst et halvt år ad gangen, uden at det har gjort nogen forskel: Hetzner (DE), OVH (FR), Tilaa (NL) og IODC (DK)
  • rDNS-domænet er altid et .dk domæne med gyldige MX records og uden anonym WHOIS. Det lader ikke til at gøre nogen forskel om det matcher afsenderdomænet eller ej
  • Mail serverens A record (som PTR peger på) har TTL på 86400
  • Treårigt certifikat fra RapidSSL (om end et self-signed egentlig burde være rigeligt når det kun er server-til-server kommunikation med STARTTLS)
  • Har været whitelisted på DNSWL.org i 2+ år
  • Altid strikse SPF (-all), DMARC (p=reject) og ADSP (dkim=discardable) records
  • Benytter udelukkende IPv4, og har aldrig været blacklisted nogle steder (tjekker ugentligt med http://multirbl.valli.org/)
  • Har aldrig været brugt til nogen former for automatiserede mails, udelukkende privat kommunikation - jeg benytter altid Amazon SES på webservere o.lign. i tilfælde af at de bliver inficeret
  • Aktiv DNSSEC på alle domæner og udelukkende 2048 bit DKIM keys
  • Er tilmeldt postmaster tools hos både Gmail (https://postmaster.google.com/) og Hotmail (https://postmaster.live.com/snds/), men ingen af dem melder om problemer

Alting står som PASS i mail-headeren hos Gmail, men alligevel lander alt i spam-mappen hos nye modtagere.
Jeg har dog kun været ude for at Gmail direkte har nægtet modtagelse med en fejl 550 når jeg har forsøgt at sende til en mailingliste/gruppe på et Google Apps-domæne. Normalt bliver mine mails accepteret, men ryger direkte i spam.

Jeg nægter at give op og sige farvel til decentraliseret e-mail, så jeg plejer at sende en sms eller en mail via en Gmail-adresse med en "jeg har sendt dig en mail, tjek din spammappe og husk at markér som ikke-spam"-besked til nye modtagere som anvender Gmail - i hvert fald når det drejer sig om en privat, ikke-kritisk henvendelse.

Michael Rasmussen

Jeg har lige lavet en test her (egen mail server). DMARC, DKIM, og SPF:

Feb 16 18:58:25 iredmail amavis[11494]: (11494-13) Passed CLEAN   
{RelayedOutbound}, MYNETS LOCAL [192.168.2.79]:59064   
<x@y.tld> -> <z@gmail.com>, Queue-ID: 3DA3E120098, Message-ID:   
<20170216185821.0e861735@sleipner.y.tld>, mail_id: f_ZkJWVsd2oS,   
Hits: -, size: 3004, queued_as: 617C512009F, dkim_new=dkim:y.tld, 1  
53 ms  
Feb 16 18:58:25 iredmail postfix/smtp[24732]:   
3DA3E120098: to=<z@gmail.com>, relay=127.0.0.1[127.0.0.1]:10024,   
delay=0.2, delays=0.04/0/0.01/0.16, dsn=2.0.0, status=sent (250 2.0.0   
from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 617C512009F)  
Feb 16 18:58:25 iredmail postfix/qmgr[1528]: 3DA3E120098: removed  
Feb 16 18:58:25 iredmail postfix/smtp[24803]: Trusted TLS connection   
established to gmail-smtp-in.l.google.com[173.194.220.26]:25: TLSv1.2   
with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)  
Feb 16 18:58:26 iredmail postfix/smtp[24803]: 617C512009F:   
to=<z@gmail.com>, relay=gmail-smtp-in.l.google.com[173.194.220.26]:25,   
delay=0.92, delays=0.01/0.03/0.33/0.54, dsn=2.0.0, status=sent   
(250 2.0.0 OK 1487267906 d68si3806525lfg.39 - gsmtp)  
Feb 16 18:58:26 iredmail postfix/qmgr[1528]: 617C512009F: removed

Mener at kunne huske Google bestemte på et tidspunkt, at al mail, der ikke leveres via SMTP-TLS, automatisk tagges som spam.

Elmer Henriksen

Det er ikke altid tilfældet, synes jeg. Jeg har oplevet at modtage mails på min arbejds-Gmail som har været sendt uden TLS, men uden at de er røget i spam.
Der står til gengæld en besked om det i toppen af mailen når man bruger deres webinterface, så det er ikke til at overse. Man kan også se det på den første Received: header efter den har nået Gmails servere (ESMTP vs. ESMTPS).

Men ja - OpenSMTPD bruger TLS out-of-the-box for udgående post, men i Postfix skal det manuelt aktiveres i master.cf.

Michael Fjeldsted

Gmail og Hotmail fylder så enormt meget, at det er dem der driver hvad folk gør. De understøtter begge DMARC og sender fine rapporter til dig. Men de agerer ikke særligt godt på dem.

Nu vender vi det hele lidt på hovedet. Dmarc sikrer at emails der siger de er fra domain.com virkelig er fra domain.com og hvis ikke kan den slettes.
Dmarc siger intet om indholdet i din mail og om det er en personlig mail, et nyhedsbrev eller spam.
Jeg kan jo godt oprette megabilligt.dk og så købe en masse email adresser som jeg kan sende til og så sende en masse affiliate mails ud - det er der alt for mange der gør og bare fordi de kører valid dmarc, dkim og spf på altformangetilbud.dk, så betyder det jo ikke at deres mails ikke er spam og uønsker i mange folks indbakker.

Jeg satte selv lidt ip-adresser op til en mailsserver i efteråret og det tog lidt tid at få hul på hotmail og gmail. Men når bare man sender en vis volumen, og man får modtageren til at interagere - dvs klikke eller svare på mail'en så tog det ikke så lang tid at få hul. Det var med nogle 1000 mails om dagen - hvor spf, dkim, rDns, a-records osv var 100% i orden fra dag 1.
Dvs Dmarc siger intet om hvordan et spam filter skal håndtere en valid email - og det er der en god grund til.

Claus Andersen

Jeg kan jo godt oprette megabilligt.dk

Helt enig! Du kunne endda have købt mit fine gamle domæne. Og du vil da heller ikke høre mig beklage mig, hvis man også indførte warm-up af domæner (throttle mængden for nye domæner). Jeg er endda glad for dnswl. Min pointe er, at deres bahandling af false positives gør problemet værre! For, at SPF, DKIM, og DMARC har en reel værdi, så skal det være udbredt. Er det meget udbredt, så kan det bruges som et meget stærkere signal end simple heuristiske tekstanalyser. Det er derfor i deres interesse, at sikre god behandling af false positives. Lige gyldigt hvilken teknologi vi opfinder vil den kunne bruges af "bad actors". Men min læring er lige nu er, at det er for besværligt. Var jeg en almindelig virksomhed, så ville jeg droppe DKIM og DMARC for at skifte tilbage til Bluehost med en tilde SPF. Bluehost er en discount udbyder der ikke rigtigt gider sikre, om brugerne udsender spam, så de arbejder aktivt med at blive de-listet og skifter jævnligt IP adresser. Alle de dårlige vaner vi netop forsøger at udrydde.

Jeg satte selv lidt ip-adresser op til en mailsserver i efteråret og det tog lidt tid at få hul på hotmail og gmail.

Det bliver en meget høj hest at komme ned af for dig hvis du ryger i lignende problemer. Og hvis du bliver afvist allerede ved havelågen, så vil jeg fraråde lige at sende nogle tusinde mails afsted.

Dvs Dmarc siger intet om hvordan et spam filter skal håndtere en valid email - og det er der en god grund til.

Fra hestens egen mund:

At a high level, DMARC is designed to satisfy the following requirements:

  • Minimize false positives.
  • Provide robust authentication reporting.
  • Assert sender policy at receivers.
  • Reduce successful phishing delivery.
  • Work at Internet scale.
  • Minimize complexity.

It is important to note that DMARC builds upon both the DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF) specifications that are currently being developed within the IETF. DMARC is designed to replace ADSP by adding support for:

  • wildcarding or subdomain policies,
  • non-existent subdomains,
  • slow rollout (e.g. percent experiments)
  • SPF
  • quarantining mail

Så DMARC fortæller præcis hvilke policies der skal håndhæves og hvordan man bør gøre det. Så jo - det er et kraftigt signal (blandt andre) til dit spam filter.

Jeg kan naturligvis ikke kræve at mine mails bliver leveret. Men grunden til at email har fungeret så godt og så længe er, at vi pænt fortæller hvorfor og hvad man kan gøre hvis det ikke virker.

Hvis du ønsker at udbrede DMARC, så husk at behandle dem der bruger det bedre end dem der ikke gør det. Hvis ikke ved havelågen, så hæv kvaliteten af de webforms man skal hoppe igennem.

Claus Andersen

Det lærer de helt sikkert også om når hans modtagere går ind og finder mail'en frem fra spamfilteret

Tydeligvis ikke - Elmer Henriksen skriver det har stået på i 3 år.

Vi kan være helt enige om, at idéen med, at hæve reputation når du bliver fisket manuelt af filteret af en bruger er god. Pointen er, at der ikke er nogle ankemuligheder. Byrettens dom er stadfæstet. I dette tilfælde er "byretten" en maskine (som er skrevet af mennesker).

Og I mit eget tilfælde: En 550 ved havelågen. Dvs. der er ikke noget brugerne kan gøre. De argumenterer med, at de ser meget trafik fra min IP uden at underbygge det. Der kan ikke følges op på det.

Claus Bruun

Jeg har været igennem samme mølle med eget domæne, og det virker nærmest som om, at "de store" kører en udmattelsespolitik, sådan at os med eget domæne og hosting falder til patten og opretter mail hos dem (så kan de jo også snage i vores mail og tjene penge på det).

Umiddelbart ser det ud til, at de store som udgangspunkt flagger alle nye domain/IP adresser - som ikke kommer fra andre store - til at være mistænkelige og kun ved at opbygge en reputation, kommer det til at kører normalt.

Det er i al fald, hvad jeg har oplevet, når jeg fx. skulle skrive til folk med en MS hosted adresse første gang: Mailen ryger som regel i spam-folderen med auto delete efter 10 dage, og brugerne ser aldrig mailen. Så snart brugeren klikker "ikkespam" eller starter en dialog med mig, modtages mailen ok fremover.

Det er så, hvad det er, men problemet er, at jeg som afsender aldrig får at vide, at det sker, og jeg således ikke kan stole på, at mine mails bliver modtaget, med mindre jeg eksplicit beder modtageren om at besvare min mail.

Jeg har oplevet det andre varianter hos Google og specielt Yahoo, og til MS's forsvar skal det siges, at deres procedure til at de-liste IPadresser faktisk virker inden for 24 timer, hvor mails til Yahoo bare bliver routed til /dev/nul.

Det kan nogen gange hjælpe at route mail over store anerkendte relays (husk SPF). Jeg brugte med held dnsexit.com i en periode til både MS og Yahoo, hvor min ISP havde givet mig en IPv4 adresse, der engang havde boet i Rumænien! Da jeg fik en jomfruelig IP adresse var relay ikke længere nødvendigt).

Log ind eller opret en konto for at skrive kommentarer

Partnernyheder

Welcome to a seminar on tools that help you become GDPR compliant!

Getting GDPR compliant by May 2018 implies a lot of activities covering the legal aspects, internal business processes, data management, and security technology.
28. feb 2017

Maja Rosendahl Larsen ansat hos Affecto

24. jan 2017

Introduction to Jedox – Affecto Seminar, Copenhagen

12. jan 2017