Eneco.com heeft als DMARC policy p=none dus als je dit gebruikt om mail in spamfolders te zetten is er bij jou wat stuk.
Wellicht zijn ze nog bezig het helemaal in te regelen? Dan is het gebruikelijk om te testen met p=none.

Ik ben het met je eens dat het buitengewoon dom is om de ene keer eneco.nl en de andere keer eneco.com te gebruiken
maar ja de mensen die hier over gaan die hebben dat soort slimheid niet (laten we er maar vanuit gaan dat ze op andere
gebieden slimmer zijn - misschien ook dat niet).

Maar afwachten of de Japanners het beter begrijpen...

Dmarc is niet iets nieuws, maar het gaat druppelend traag.

Zoals Bitje schrijft, implementeren steeds meer bedrijven een dmarc policy, maar doen het ontzettend traag. Vooral omdat je geen bestaande structuren willen breken.

Wij gebruiken het al heel wat jaren met een reject policy. Als klein bedrijf is het mailverkeer bij ons overzichtelijk en was implementatie een fluitje van een cent.

Er wordt echter aangeraden om eerst met een none policy te beginnen. Jammer genoeg laten veel bedrijven het dan bij de none. Het enige wat ze er dan aan hebben is dat ze dagelijks statistieken krijgen van 'verkeerde' mail. (Eneco laat de statistieken maken door 'demarciam.eu'.

Hun dmarc record is als volgt (Had je al bekeken neem ik aan)


Als een bedrijf veel mail via externe partijen laat versturen, kan het heel complex worden om dit alles in orge te krijgen. Maar dan praat je over grote bedrijven en dan behoren ze het geld te hebben om een ict-er in dienst te nemen die daar genoeg kennis van heeft.

Bij Ziggo.nl zie ik hetzelfde 'none' beleid. Dat is ervoor dat alle ingehuurde helpdesken hun mail met een gespoofde mailadressen kunnen blijven versturen. (Ik heb dat soort gespoofde mail al ontvangen met een spf=fail) De officiële mail komt bij ziggo daarom niet meer van een ziggo.nl adres maar van een "e.ziggo.nl" adres. Daar staat wel een 'reject' policy op.

De duitse tak van DHL snapt nog minder van dmarc. (Of misschien juist wel). Ik krijg wekelijks een mailtje dat er een pakje verstuurd is. De afzender is "deutschepost.de". Dit bedrijf heeft een 'reject' policy. De mailtjes bevatten echter geen DKIM ondertekening. Stikt genomen hoeft dat ook niet, zolang de SPF maar klopt, en dat doet hij. Als je deze mail echter forward, zul je een DMARC fail krijgen. Een mail met een DKIM ondertekening kun je normaal wel forwarden omdat de handtekening het forwarden overleeft. (Mits de mail onveranderd geforward wordt)

Klopt, maar in dit geval zou dat ook niet werken - en terecht. Want een derde partij kan leuk een handtekening zetten over vanalles inclusief de spoofed afzender bij eneco.com, maar dat zegt natuurlijk helemaal niks. Terecht dat je dan een dmarc=fail krijgt, want iedereen kan wel roepen dat ie namens eneco mailt.

Ik heb bewust geen spamfilter (aan laten zetten door xs4all) omdat ik foute e-mails wil kunnen onderzoeken, maar daarmee ben ik ongetwijfeld een uitzondering.

Aangezien deze mail alle eigenschappen van een fake mail heeft en daar dus niet van onderscheiden kan worden (ook niet door spamfilters), hoort elk fatsoenlijk spamfilter deze mail als fake, en dus spam, te behandelen. Een spamfilter is juist "stuk" als het dit soort mails doorlaat zonder waarschuwing.

Ik vermoed dan ook dat veel Eneco klanten deze mail niet in hun inbox zullen aantreffen.

De bedoeling van het hele scala SPF, DKIM, DomainKeys, DMARC, ARC (er waren er nog meer) is juist aantonen dat het getoonde afzenderdomein dat ook werkelijk is. Zolang we accepteren dat dit soms niet goed gaat ("Wellicht zijn ze nog bezig het helemaal in te regelen?), zijn al deze maatregelen verspilde moeite.

Ik heb ook het spamfilter uit staan bij XS4All. Ik kreeg vorige week een mail in al mijn mailboxen van XS4All met de mededeling dat mijn mailboxen verkleind zouden worden naar maximaal 100MB. Weet ik meteen dat alles nog goed staat :-)

100MB is zat voor POP3 .

Mocht XS4All/KPN ooit verplicht stellen dat je een spamfilter hebt, dan is er nu nog de mogelijkheid om die spam in je mailbox zelf af te leveren.

Overigens krijg ik geen spam op de mailboxen van XS4All, maar ik ben dan ook heel selectief in aan wie ik die mail adressen geef. Ooit heb ik wel iets verkeerd gedaan met een mailbox en kreeg ik daarop spam. Die mailbox heb ik toen weer opgeheven (er zaten toen vier contacten op waarvan ik er nu eentje kwijt ben).

Nieuwe Anoniem

Daar ben ik het niet mee eens. Een spamfilter kan allerlei aspecten van een mail bekijken om te beslissen of iets spam
is, maar het aanwezig zijn van een DMARC policy met p=none zou niet meer effect mogen hebben dan de afwezigheid
van een DMARC policy, met uitzondering van het melden van mismatches naar de opgegeven reporting mailbox.
Alleen als er een p=quarantine of p=reject DMARC policy is mag dat gebruikt worden voor actie op de mail.
En dat doet XS4ALL ook.

Natuurlijk, maar DMARC inregelen in een grote organisatie waar het soort mensen werkt wat zowel een .nl als een .com
domein registreert en gebruikt is niet triviaal. Dat moet je eerst testen, vandaar p=none.
Je moet een tijdje meekijken om zeker te weten dat er niet ergens nog een afdeling is die ergens een mailinglijst
gehost heeft waar je als ICT niks van wist. Als je in hun SPF record kijkt dan zie je al dat het daar een grote puinzooi
is, ook op dat gebied, en dat het dus echt wel nodig zal zijn om te testen.
Kennelijk is er ergens in de organisatie iemand de de diensten van msdp1.com heeft ingeschakeld maar daar is
de hele DMARC tent nog niet goed voor ingericht.
Ik weet niet hoe lang dit p=none record er al staat, misschien zijn ze druk bezig om het allemaal te repareren, misschien
hebben ze het al opgegeven en staat dit er al jaren. Maar effect zou het niet moeten hebben op spambeslissingen.

Eens. Dit dwingt mij ook om daar geen bergen e-mails te bewaren. Ik haal ze overigens op in Thunderbird met IMAPS. Dat betekent natuurlijk ook dat ik zelf verantwoordelijk ben voor het maken van back-ups.

Indien een e-mail-verzendende organisatie niet wil dat derden namens hen fake mails kunnen versturen die in mailboxes van ontvangers belanden (inclusief spamfolders), moeten ze DMARC et al goed configureren en horen ontvangende mailservers non-compliant mails te weigeren.

Spamfilters zijn van oudsher verzamelingen van subjectieve criteria die elke e-mail-ontvangende partij zelf kan vaststellen. Jij en ik kunnen er een mening over hebben of je op basis van een halfbakken DMARC configuratie, mails wel of niet als spam moet beschouwen en behandelen, maar uiteindelijk hebben wij daar niets over te zeggen.

Dat is niet relevant. Het gaat er niet om of men wel of niet wil voorkomen dat er fake mails gestuurd worden, het gaat
er om of een work-in-progress op dat gebied mag resulteren in false positives in een spamfilter. NEE, naar mijn mening.

Ja daarom host ik mijn mail ook zelf. Dan heb ik daar geen last van. Daarvoor wel, bijv als mail van een bedrijf wat
DMARC met p=reject geforward werd door een alias service die DKIM verminkte, naar een XS4ALL mailbox. Dat werd
geheel volgens de standaard gereject en dus weggemikt, terwijl ik liever heb dat het met een boel punten in mijn
spambox komt. En zo werkt dat nu ook.

Ik probeerde onderscheid te maken tussen het primaire doel van DMARC en dergelijke, versus het gebruik ervan in spamfilters. Als het primaire doel van DMARC, SPF, DKIM etc. al discutabel is (zelfs "niet relevant" gevonden wordt), waarom verklaren we al die meuk (met stevige bijwerkingen) dan niet voor mislukt?

Dat is fijn voor jou, maar de meeste mensen hebben geen idee dat zoiets kan, laat staan dat ze zover gaan. We gaan internetveiligeheid niet vergroten door weg te lopen bij standaardvoorzieningen en, ieder voor zich, haar/zijn eigen oplossingen te bakken.

Ik ben DMARC aan het implementeren bij een redelijk groot bedrijf met ongeveer 60 mail domeinen. We hebben net de 2 grootste gedaan. Duurde iets meer dan een jaar om alles op orde te krijgen.

Grootste issue is het vinden van de verzenders. 1na grootste issue is die verzender vervolgens uitleggen wat hij/zij moet doen.
Anders tussen aardig goed geworden in het uitleggen van DMARC, SPF en DKIM aan een leek ;)

Kun jij wel Nederlands lezen? "Dat" in "Dat is niet relevant" verwijst uiteraard niet naar het primaire doel van DMARC maar
naar de relevantie van jouw opmerking, en dan met name het "non-compliant mails weigeren".
Waarbij dan ook nog eens moet worden aangetekend dat bij een DMARC policy p=none de verzender expliciet aangeeft
dat er geen actie op non-compliant mails genomen moet worden (anders dan rapportage).

Uit de RFC:

To enable Domain Owners to receive DMARC feedback without impacting
existing mail processing, discovered policies of "p=none" SHOULD NOT
modify existing mail disposition processing.

Ik chargeerde en schoot daarbij door, mijn excuses. Maar dan kom ik wel terug op jouw eerdere bijdrage.

Die "work-in-progress" duurt al minstens anderhalf jaar (daarvoor voegde xs4all de "Authentication-Results" header niet -of niet altijd- toe, dus wellicht langer):
Zo heb ik meerdere "dmarc=fail" mails van msdp1.com namens eneco.com ontvangen, dus waarwom leert Eneco daar niet van?

Temeer Eneco dit voor andere partijen, die mailings voor hen verzorgen, wel weet te regelen:

En over jouw mening, uit https://dmarc.org/wiki/FAQ#Does_DMARC_.E2.80.9Cp.3Dnone.E2.80.9D_affect_the_way_my_emails_get_delivered.3F:
Bij de msdp1.com mails zijn SPF en DKIM correct, maar beide voor msdp1.com - niet voor eneco.com. Dus, conform de FAQ, moet je er niet van opkijken als spamfilters ervan uitgaan dat dit phishing mails zijn, want die kunnen exact dezelfde eigenschappen hebben.

Zolang Eneco.com niet configureert dat msdp1.com namens hen e-mails mag verzenden, zijn die mails gewoon spam. Met onwetendheid en laksheid (zie ook de de Duitse DHL in de bijdrage van Briolet) maken we internet niet veiliger.

Aan de andere kant: als een groot deel van de organisaties niets implementeert of "p=none"-achtige policies eindeloos laat staan, mail clients het SMTP from adres niet tonen en/of gebruikers simpelweg gefopt kunnen worden met
"Eneco Service" <spam@example.com>, kunnen we wat mij betreft best de conclusie trekken dat SPF, DKIM, DMARC etc. mislukt zijn, en dat ARC hetzelfde lot beschoren is.

Ja ik denk dat Eneco enthousiast begonnen is met die DMARC policy, onder het mom van experimenteren met nieuwe
technologieen en "baat het niet dan schaadt het niet" maar er na een tijdje achter kwam dat het allemaal niet zo eenvoudig
is als je een bedrijf vol paarse broeken hebt die mailinglijsten gerust bij externe bedrijven neerleggen zonder ICT daarover
te raadplegen. Ze hebben die p=none policy laten staan zodat ze het wel kunnen blijven monitoren maar ze hebben
besloten er toch maar niks mee te gaan doen. Wellicht ook onder invloed van tegengeluiden tegen SPF/DKIM/DMARC
of wellicht is de medewerker die dit trok inmiddels weg daar.
Beter p=none dan dat er p=quarantaine staat of zelfs p=reject en er nooit meer iemand naar kijkt.

En denk eraan, DMARC is niet bedoeld voor het blokkeren van spam, alleen voor het blokkeren van spoofed mail.
En wellicht heeft Eneco daar (nog) niet mee te maken gehad. Bovendien kan iemand die zich wil voordoen als Eneco
gewoon iets als eneco.nu of regelmijneneco.nl registreren en daar helpt DMARC dan niks tegen. DMARC werkt niet goed
juist door dat verdunnen van de waarde van domeinnamen wat diezelfde paarse broeken op hun geweten hebben.

Om het goed te doen, moeten die externe partijen de mail via de mailserver van eneco versturen, of eneco moet een private key aan de externe partijen verstrekken. Maar die externe partijen moeten dan ook dkim kunnen ondertekenen via de private key.

Als eneco dit wel in orde heeft met andere partijen, denk ik dat het probleem bij msdp1.com ligt, die niet mee wil werken.

Dat neemt niet weg dat eneco wel alvast het spf record het kunnen aanpassen. msdp1.com publiceert blijkbaar een spf record, welke eneco via een include had kunnen toevoegen. Dat was de dmarc fail al weggeweest bij niet geforwarde mail.

Wrong on that!!!

Andere partijen die zenden namens eneco moeten hun eigen key paris gebruiken en in de mails de juiste selector opegeven tbv dkim.

Private keys heten niet voor niets private, je moet ten alle tijde de orginele bron kunnen achterhalen dus nooit een private key delen met derden !!!!

DKIM heeft daar de selector voor ( lees de rfc maar eens goed door !)

Eneco moet zijn SPF en DMARC op orde hebben, net als DNSSEC en DANE, anders is DMARC volledig nutteloos: want wie zegt dat het betreffende dns record wel van eneco is ;-)

NEE! Eneco moet met die externe partijen afspreken welke DKIM selector ze gebruiken (bijv de naam van die partij)
en in hun eigen DNS een CNAME zetten van die selector naar een DNS naam van de externe partij die daar dan hun
public key neerzet en evt aanpast bij updates. Of die externe partij moet de public key aan Eneco geven en die zetten
die dan als TXT record in hun eigen DNS (met als nadeel dat er bij key updates weer onderling contact nodig is).

Maar dat moeten ze dus met ALLE externe partijen gaan doen. En dat kan lastig zijn als het niet bekend is welke
externe partijen er zijn en/of er nog steeds externe partijen toegevoegd worden.
Op het moment dat je een DMARC policy hebt staan kun je geen externe partijen meer toevoegen zonder deze procedure
te doorlopen. Dat kan een reden zijn om DMARC maar te laten zitten, of alleen p=none te gebruiken.

Bedenk ook dat p=none weliswaar geen beveiliging biedt, maar wel monitoring van incidenten.

Ik heb ook nooit beweerd dat eneco de private key die ze zelf gebruiken moet doorgeven. Ik bedoelde meer dat ze een keypair moeten aanmaken en dan de private key aan de derde partij moeten geven en de public key moeten publiceren. Het is geen probleem als beide partijen die private key kennen. De een moet hem gebruiken en voor de ander betreft het mail die in hun naam wordt verzonden.

In elk geval heeft eneco die public key nodig. De derde party kan die public key niet zelf publiceren.

Zelfs dat wil je niet, dan krijg je nl. discussie en conflicten: aangezien beide partijen dan de private kunnen gebruiken voor het signen ;-)
Nooit maar dan ook NOOIT een shared private key gebruiken/maken tussen derden, zoals ik al aangaf: DKIM heeft daar binnen de RFC een oplossing voor bedacht met selectors. Eneco hoeft alleen een cname naar de selector bij de derde partij op te nemen in dns en klaar is het.
Zo werkt het bij MS, Mailchimp, sendgrid en alle andere partijen die geauthoriseerd namens een toko mail sturen.

Tip: Lees de rfc en security richtlijnen mbt sleutel materiaal eens heel grondig door.

Het veiligst is het als de derde partij zelf een keypair genereert, de public key naar Eneco stuurt, Eneco via een gescheiden en veilig kanaal vaststelt dat die public key daadwerkelijk van die derde partij is en dan die key publiceert.

Waarom is dat het veiligst? Is het niet beter om die CNAME methode te gebruiken?
(we gaan er uiteraard vanuit dat beide partijen DNSSEC hebben, dat is toch al een must als je over veiligheid gaat haarkloven)

Ik bedoelde "het veiligst" in relatie tot het uitwisselen van asymmetrische sleutels.

Nooit doen, want die public key is niet van Eneco, om dat duidelijk te houden altijd de CNAME methode toepassen.
Daarnaast maakt een dergelijke partij 1 keypair aan en gebruikt die voor vele klanten.
En als ze die key-pair moeten aanpassen: moeten ze eerst aan jou die nieuwe public sturen wachten tot die in jou dns staat en dan pas gebruiken... NOT, daarom: CNAME.

Ik neem ook even voor het gemak aan dat jij dit verder nooit zult adviseren, jou postings kennende heb je daar iets aan kennis over ;-)

Ik krijg dagelijks een mailtje van mijn bank, die door Tripolis verstuurd wordt. Zij gebruiken inderdaad ook de CNAME methode:


Ik krijg ook mailtjes van de Hanos via tripolis. Die ondertekent tripolis met hun eigen domein. Maar wel een andere public key als voor mijn bank:

Linksom of rechtsom autoriseer je een derde partij om namens jou te handelen. Daar is een vertrouwensrelatie voor nodig (waarbij ik me in veel gevallen afvraag of die voldoende onderzocht en terecht is).

Aan CNAME DNS records (aliases op andere domeinnamen) kleven overigens ook nadelen - die wel eens groter zouden kunnen zijn als je de feitelijke domeinnaam (mogelijk via meerdere stappen) vergeet te monitoren en deze in verkeerde handen valt, zoals nieuws over een onderzoek in https://www.zdnet.com/article/microsoft-has-a-subdomain-hijacking-problem/ beschrijft, met https://web.archive.org/web/20190101033148/http://paymentrequestint.microsoft.com/ als een van de voorbeelden.

Het is speculeren, maar de kans dat zoiets gebeurt (of een aanvaller ongeautoriseerde schrijftoegang tot DNS records van de vertrouwde partij krijgt) zou wel eens groter kunnen zijn dan dat een private key in verkeerde handen valt.

Het is goed te merken dat je alleen vanaf de zijlijn en zonder daadwerkelijke ervaring met DMARC post, Erik.
Je vergeet dat (zelfs met die p=none policy) de grote partijen die DMARC implementeren bij ontvangst van mail een
rapport genereren (eens per dag) aan het opgegeven adres met daarin hun bevindingen rond DMARC.
Dat kun je naar jezelf sturen en bijvoorbeeld in een database importeren of je kunt het, zoals Eneco doet, naar een
partij sturen die zich daar in specialiseert (dmarcanalyzer.com). Daar kun je vervolgens allerlei triggers configureren
waardoor je mail alerts krijgt als er rare dingen gebeuren.

Dit gebeurt dus OOK als je p=none hebt wat naar jouw idee geen goede situatie is. Je krijgt van die dmarcanalyzer
een bericht als er geconstateerd is dat er mail "van jouw domein" gestuurd wordt met niet kloppende SPF of DKIM
en dus kun je vrij simpel constateren wanneer er dingen fout aan het gaan zijn met je keys etc. En je hebt zelfs info
over welke partijen mail sturen dus als jij je mailinglist hebt uitbesteed aan een externe partij en je krijgt ineens rapporten
van mail die is afgeleverd op een ander moment dan dat je een nieuwsbrief de deur uit gedaan hebt dan krijg je daar
rapporten over. Daar kun je vervolgens wat mee doen, bijvoorbeeld je CNAME weghalen als die partij kennelijk niet
te vertrouwen is.

Het is dus niet zo dat je zomaar je identiteit uit handen geeft zonder mogelijkheid daar verder nog wat aan de controleren.
"als je vergeet op te letten dan kan het fout gaan" dat is zo'n enorme dooddoener dat we daar verder maar niet op
in gaan.

Ook kun je dankzij die rapporten zien dat er bijvoorbeeld spammers of phishers of joe-jobbers aan het werk zijn die
helemaal niet aan de SPF en DKIM vereisten voldoen (en die er vanuit gaan dat de ontvanger het niet checked) zodat
je daar je aandacht op kunt vestigen en bijvoorbeeld een waarschuwing kunt laten uitgaan naar je klanten.
Sterker nog, "vroeger" hebben we op het werk een paar keer last gehad van phishers die mail "van ons domein"
stuurden (merkbaar aan de vele non-delivery reports die er ineens binnenkomen) en nadat er een DMARC policy
is ingericht is dat een stuk minder geworden (nog 1 keer voorgekomen). Ik denk dat phishers bij het kiezen van een
afzenderadres ook wel kijken of er DMARC op zit en zo ja dan maar een andere pakken. Daarbij kijken ze vast niet
wat er voor p= in het DMARC record staat, dus zelfs een p=none record geeft je al phishing bescherming.

Ik denk niet dat ik wat vergeet op dit punt. Jij vergeet mijn eerdere bijdrage te lezen waarin ik schrijf dat ik al ten minste sinds 14 Jun 2018 meerdere "dmarc=fail" mails van msdp1.com namens eneco.com heb ontvangen, en dat Eneco dit kennelijk nul-komma-niets interesseert.

Sterker, dmarcanalyzer.com zou wel eens bestookt kunnen worden met phishing-alerts (1 voor elke verzonden mail), want Eneco heeft ook een "ruf=" gespecificeerd (voor de consequenties zie https://dmarc.org/wiki/FAQ#Do_I_want_to_receive_Failure_Reports_.28ruf.3D.29.3F). Waarbij mogelijk nog een partij de e-mail adressen van Eneco-klanten in handen krijgt (iets met privacy en AVG).

Hoezo "we"?

Veel informatiebeveiligingsincidenten worden veroorzaakt doordat partijen vergeten tijdig te handelen (domeinregistraties, verlengen van certificaten, afsluiten van oude accounts etc). Nog veel lastiger is het als je verantwoordelijkheid delegeert en vergeet bij te houden of de betreffende partij nog steeds betrouwbaar is, o.a. dat hun domeinregistraties niet te hijacken zijn - of al gehijacked zijn. Ik vind dit allesbehalve een dooddoener.

Beste DMARC-expert, heb jij soms ook een bordje "verboden in te breken" op jouw voordeur?

Daarom adviseer ik klanten waar ik kom ook altijd om een default spf, dmarc config in sub domeinen te plaatsen.
Een melding van mij aan het adres van de overheid ( NCSC ) omtrent een hoofd domein van de overheid die te hijacking IS kwam als antwoord terug: dat is geen probleem en gaan we niet fixen. Hoe dom kun je als overheid zijn ?

Maar dan nog: je kunt naar dergelijke gehijackte domeinen geen antwoord terug mailen, dus moet je als gebruiker gewoon ook dan OPLETTEN..

Ik kwam net dit plaatje tegen over het DMARC gebruik bij .nl domeinnamen (het 4e plaatje):

https://stats.sidnlabs.nl/nl/mail.html#domeinnamen#dmarc

In deze statistieken dan SIDN zie je dat er in de 2e helft 2018 een sterke toename van het gebruik van DMARC gekomen is. (tot ca een derde van alle domeinnamen van mail). En in 2019 stopt het in gebruik nemen van DMARC.

Je ziet ook dat de policy verhouding none/reject ongeveer 50/50 is. Ik zie in de statistiek niet dat er in 2019 serieus van een none policy naar een reject policy overgestapt wordt.

Ook bij de scherpe sprongen omhoog in de toename van een reject policy, zie ik geen daling bij de none policy's. Dus zijn dit domeinen die vrijwel direct met een reject policy begonnen zijn
Bij SPF-qualifiers zie je b.v. wel dat bij een scherpe policy verandering evenveel omlaag gaan als omhoog. Daar zijn het dus echte aanpassingen van een reeds bestaande policy

@Briolet: interessant, dank voor de info en link!

Dat is bijna altijd met technieken die even hip zijn maar die toch niet echt goed werken.
In het begin is er een groep die erover leest en het oppakt, soms ook onder aansporing van "check uw internet veiligheid"
websites die rode kruisjes laten zien ipv groene vinkjes op allerlei plekken (bijv internet.nl) maar als je die eerste groep
van technisch geinteresseerden binnen hebt en je gaat door naar de grote groep van "wat kost het, wat brengt het op?"
gebruikers dan vallen er voor dit soort technieken geen gebruikers meer te verzamelen.
Je houdt dan alleen degenen binnen boord die echt wat (menen) te hebben aan de toegevoegde waarde, of die het
maar invoeren als een desperate stap om de spamfilters van grote maildiensten een plezier te doen (zodat er hopelijk
minder van hun mail onterecht als spam geweigerd wordt).

Het idee achter DMARC was leuk maar het was gebaseerd op een verkeerd uitgangspunt: dat een organisatie herkenbaar is aan de domeinnaam die ze gebruiken, en omgekeerd. Dat was ooit het uitgangspunt achter domeinnamen, maar in de praktijk is dat helemaal niet meer zo.
Als de helft van de wereld voor alles wat ze verzinnen een andere domeinnaam gebruikt, en daardoor de ontvanger van mail niet meer raar opkijkt als een mail van een bedrijf wat ze kennen ineens van een heel ander domein komt, dan werkt DMARC ook niet meer (voor het doel waar het voor bedoeld was).
En tja, dan gaat de acceptatie en implementatie ervan ook achteruit.

Ik raad je aan om voordat je dit soort claims doet eerst eens te bestuderen hoe dt werkt met die RUF en RUA settings
en de reports die je dan krijgt!

Hoezo "in het begin"? DMARC is al in 2011 geïntroduceerd. Wij gebruiken het sinds 2015 op onze mailservers. Die duidelijke piek in gebruik is nog maar van recent. Blijkbaar is er in 2e helft 2018 pas consensus ontstaan dat dit protocol toch zinvol is.

Ik ben er niet mee eens dat het uitganspunt niet klopt. Oude protocollen controleerden op domeinnamen die de gebruiker soms niet eens te zien kreeg. (Dit om het grote mailverzenders gemakkelijker te maken om vanuit hun eigen domein mail te verzenden). Dit DMARC protocol controleert het domein wat ook de gebruiker als afzender ziet. In mijn optiek is dat de enige zinvolle controle.

Het antwoord op een vraag in de FAQ waar ik naar verwijs begint met:
Wat klopt er volgens jou niet aan deze FAQ? En als jij vindt dat er iets niet klopt, waarom zou ik jou (Anoniem) moeten geloven in plaats van de auteur(s) van deze FAQ?

Wat er in ieder geval in de praktijk niet aan klopt is het volgende:
- je krijgt niet A LOT of messages, je krijgt 1 message per dag per bestemmings service, bijv gmail of hotmail met daarin alles van die dag, in een gzipped format.
- je krijgt geen copie van het bericht. je krijgt een bestand met daarin statistiek, namelijk het IP adres waarvan berichten gestuurd zijn, het aantal berichten wat er vanaf dat adres gestuurd is, wat er uiteindelijk met die berichten gedaan is, en wat de DKIM en SPF resultaten waren.

Wat er daar in die FAQ staat is wellicht iets wat ooit in de standaard gezet is, maar het is in ieder geval nergens geimplementeerd, wellicht ook nadat men de privacy consequenties ervan bedacht had.
Wat je nu aan rapportage binnen krijgt is zelfs onvoldoende om te bepalen wat de afzender en ontvanger mail adressen waren (je krijgt alleen het domein te zien niet de user) wat soms best wel frustrerend is omdat je daardoor ook de mensen niet kunt informeren als ze iets onhandigs doen en dat wellicht zouden kunnen fixen.

Dat geldt, voor zover ik weet, voor "rua".

RFC 7489 heeft het, m.b.t. "ruf", over "Per-message failure reports" en "Per-message reports".

Als veel partijen zich niet aan RFC's houden is dat m.i. tekenend voor het "succes" van dit soort protocollen.

Zoals Erik hierboven al aangeeft, haal je rua en ruf door elkaar...
Je krijgt voor ruf wel degelijk een kopie van de originele mail.
Staat tegenover dat deze maar zelden wordt verstuurd... ik krijg van Google wel rua's maar geen ruf's.
Overigens krijg ik van MS (hotmail, outlook, enz.) géén rapporten toegestuurd (terwijl ze er zelf wel om vragen).
Policy op reject zetten, dan merken ze het vanzelf en komen ze wel naar jou toe.

In de info van dmarc.org (zie eerdere links) staat de volgende tekst:


Ik heb de RFC niet doorgespit, maar dmarc.org schrijft dat de standaard het zenden van een ruf niet verplicht.

Ik heb het voor ons nu eens aangezet om het zelf te zien. De ervaring met de gewone reports leert dat een failure toch een uitzondering zal blijven voor ons domein.