Ik denk dat het verstandig is om SPF, DKIM en DMARC aan te zetten op uitgaande mail, maar je moet er niet al te veel val verwachten.

Een spoofer kan DMARC, voor zover ik weet, nog steeds omzeilen door twee afzenderdomeinen op te geven (zie https://www.security.nl/posting/618851/Bellingcat-journalisten+doelwit+van+phishingaanval+met+zeroday).

Daarnaast moet de ontvangende mailserver wel ingesteld zijn om correct met deze protocollen om te gaan, anders is de ontvanger niet beschermd. De meeste mensen hebben geen idee of hun ontvangende mailserver deze checks (goed) uitvoert.

Last but not least tonen veel mail clients het afzenderdomein niet, en als ze dat al doen, kijken mensen er vaak niet naar. Een e-mail van naam@rvim.nl of naam@Rijks0verheid.nl zal door veel gebruikers niet aan de hand van het afzenderdomein als fake worden gezien; geen van de protocollen SPF, DKIM en DMARC beschermt je tegen valse afzenderdomeinen.

Overigens zie ik geen SPF records voor rivm.nl. DMARC vereist dat ofwel SPF ofwel DKIM (of beide) kloppen. Zonder SPF moet DKIM dus kloppen voor "Identifier Alignment". Of rivm.nl DKIM records publiceert weet ik niet, want ik weet niet welke domain selector(s) zij gebruiken.

Ik zie wel SPF records voor RIVM.nl. maar niet voor Rijksoverheid.nl.
Overigens komt bij mij mail voor dit domein binnen met sub noreply.rijksoverheid.nl, waarop wél SPF staat - en DKIM wordt gebruikt.

Als mensen willen mailen "alsof ze rivm zijn" dan registreren ze toch gewoon een domeintje "rivmwaarschuwing.nl" en
sturen het daar vandaan? Dat doet de overheid zelf ook bij iedere scheet die ze laten dus dat valt helemaal niet op.

Ik zie nu SPF records van zowel rivm.nl als rijksoverheid.nl.

Daar hoef je niet eens een domeinnaam voor te registreren, gebruik achter From: gewoon een domeinnaam waar geen DMARC record voor is gepubliceerd (zo te zien kun je "rivmwaarschuwing.nl" probleemloos gebruiken).

Helaas/inderdaad, ook in crisistijd (o.a. "bijzonderebijstandbuitenland.nl", zie https://security.nl/posting/649129).

Nou ja als je een mail from of from: adres gebruikt met een domein wat niet bestaat dan gaat het hier regelrecht de spambak
in, en wellicht ook wel op andere plekken. Er zijn ook providers die je niet eens toelaten om zo'n mail te versturen.

Maar goed, waar het om gaat is: als iedereen per campagne een apart domein registreert dan werkt dit hele systeem niet.

Google doet een reverse lookup als dat niet klopt verdwijnt het in de spambak als spf goed staat. Bij Microsoft kan het in de smapbox verdwijnen als alles wel goed staat. Zij doen nog een reputatie check!

De meeste mailservers (MTA's) checken op het afzenderdomein in het afzenderadres in de SMTP-envelop, ook bekend als "smtp-from" of "smtp.mailfrom" (beschreven in https://tools.ietf.org/html/rfc5321) (een veld dat overigens leeg mag zijn - om loops te voorkomen bijv. als mail niet kan worden afgeleverd). Ook SPF checkt op dit afzenderdomen (indien gespecificeerd).

Daarnaast heb je in een e-mail (normaal gesproken) ook een message From: afzenderadres, ook bekend als "header.from" (beschreven in https://tools.ietf.org/html/rfc5322). Naast dat dit mag afwijken van het envelop-afzenderadres, mag dit From: veld meerdere afzenderadressen bevatten; het optionele veld "Reply-To" trouwens ook. Het optionele "Sender:" veld mag maar één afzenderadres bevatten, maar wordt zelden gebruikt. Al deze e-mail adressen mogen onderling afwijken, en mogen afwijken van envelop-From.

Als voorbeeld de twee gebruikelijke en relevante regels in de laatste "nagelschimmeldodende spray" die ik ontving op één van mijn e-mail aliases:
De volledige afzenderadressen komen hier dus overeen. Overigens kijken SPF en DMARC alleen maar naar het afzenderdomein.

Deze spammers hebben het goed voor elkaar, want in de headers zie ik verder, tussen de bovenstaande twee regels (irrelevante regels laat ik weg):
Een TXT nslookup van hhsmile.co geeft "v=spf1 a mx ip4:217.112.128.0/24 ~all", een TXT lookup van dkim._domainkey.hhsmile.co geeft een DKIM record met RSA public key, en een TXT lookup van _dmarc.hhsmile.co geeft een DMARC record terug.

Stel nu dat deze spammers een phishing mail zouden sturen als volgt:
Het domein rvim.nl bestaat (http://rvim.nl/ is een website van RV Interim Management BV). Echter, je krijgt geen antwoord op een TXT lookup van _dmarc.rvim.nl (zij hebben dus niet zo'n record gepubliceerd, overigens wel een SPF record - maar daar wordt in dit voorbeeld niet naar gekeken).

Ik ben héél benieuwd hoeveel mailservers zo'n e-mail zouden weigeren... (de spammers/phishers hoeven hiervoor dus niet eens een "lijkt-op" domeinnaam te registreren).

Wellicht dat de malservers van Google en Microsoft dat toch doen (ik zie er geen redenen voor) - begrijp ik jou goed dat je dan iedereen aanraadt om een e-mail account bij een van hen te nemen, en voortaan niks anders meer te gebruiken? ;-)

Beste Erik,

E-mail providers zoals Google en Microsoft controleren inkomende e-mail niet op DKIM configuraties. Het zijn vaak de mailservers van bedrijven die extra controle uitvoeren om bijv. malware tegen te gaan.

Hoho eerst even duidelijkheid: SPF/DKIM/DMARC is NIET bedoeld tegen spammen, en werkt daar ook niet tegen.
In ieder geval niet als de spammer "eerlijk" een eigen domein gebruikt als afzender.

Het zou hooguit iets kunnen doen tegen joe-jobben, dwz spammen met een afzender adres van iemand anders.
Ik geloof niet dat dat nog veel voorkomt. Dat zou kunnen komen door de invoering van die maatregelen, maar het zou
ook kunnen dat spammers dat niet meer doen omdat het tegenwoordig zo eenvoudig is om even een domeintje te
registreren voor je spamrun (of je spamrun uit te besteden aan iemand die dat al gedaan heeft).

SPF/DKIM/DMARC is bedoeld tegen phishing en gerelateerde zaken waarbij het van belang is om een mail te kunnen
sturen die afhankelijk lijkt te zijn van een bekende en als betrouwbaar veronderstelde afzender. Echter, om al hierboven
genoemde redenen is het belang hiervan betrekkelijk. Mailprogramma's van Microsoft verbergen het adres van de
afzender en laten alleen de naam zien, mensen weten niet wat het goede adres van de afzender is, en de afzenders
waar het om gaat verpesten het voor zichzelf door steeds van adres te veranderen. Daardoor hebben die maatregelen
nu net zo weinig nut als een certificaat heeft als stempel van betrouwbaarheid en veiligheid.

Dank voor jouw bijdrage, dat wist ik niet.

Belangrijke redenen om DKIM in te zetten zijn:
- Een ontvanger kan niet eenvoudig claimen dat een e-mail een andere inhoud (of ander subject/verzenddatum) had;
- Als, door automatische forwarding (via een server die geen SRS ondersteunt) SPF "kapot gaat", werkt DMARC nog steeds mits DKIM blijft kloppen.

Je houdt er geen malware mee tegen, zeker niet als die vanaf gecompromitteerde accounts wordt verzonden via servers die alles goed voor elkaar hebben, zoals door gehackte Outlook.com klanten (BEC = Business Email Compromise).

Samenvattend uit een reactie van mij van 4 jaar geleden onder https://security.nl/posting/463813:
- SPF specifieert IP-adressen die mogen mailen namens de domainname in envelope-From: (onzichtbaar voor ontvangers)
- DKIM = digitale handtekening gezet namens de domainname (onzichtbaar voor ontvangers) genoemd in de DKIM header
- DMARC checkt of domainname in From: ("zichtbaar" voor ontvangers) overeenkomt met SPF- en DKIM domainname.

Weet ik (en ik heb er op deze site al heel vaak op gewezen dat deze maatregelen, onterecht, als anti-spam worden gepromoot).

Wat ik probeerde te laten zien is dat zo'n spammer redelijk eenvoudig een spoofer kan worden. Ik bedoel dat het achter "header-From:" (al dan niet) getoonde afzenderdomein:

- Ofwel identiek is aan het echte domein: het belangrijkste -zo niet enige- doel van DMARC (in combinatie met SPF en/of DKIM) is bevestigen of ontkennen dat een e-mail geautoriseerd is verzonden namens dat domein. Dit lijkt nu gefixed voor rivm.nl en rijksoverheid.nl (door een DMARC-specificatie-bug is spoofing vermoedelijk nog wel mogelijk door achter "header-From:" een tweede, afwijkend, afzenderdomeinen te specificeren);

- Ofwel lijkt op het echte domein (zoals in mijn voorbeeld): dan ben je afhankelijk van wat er voor dat lijkt-op-afzenderdomein aan DMARC en SPF en/of DKIM is geregeld.

In beide gevallen onder voorwaarde dat de ontvangende mailserver die protocollen correct afhandelt.

Nou en of dat nog veel voorkomt. Sowieso sturen de beruchte "ik-heb-je-porno-zien-kijken-afpersers" mails met als afzender jouw eigen e-mail adres om je ervan te overtuigen dat ze jouw account gehacked hebben.

Daarnaast worden, vermoed ik, verreweg de meeste spams verzonden met spoofed afzender, waarvan de accounts in een deel van de gevallen echt bestaan. Ook als die niet bestaan leidt dat vaak tot "back-scatter" op onschuldige mailservers. SPF helpt inderdaad tegen spoofed afzenders in de SMTP-envelop, mits de targeted mailservers SPF respecteren. Tegen mensen die spam hebben ontvangen (d.w.z. dat DMARC dat niet heeft voorkomen bijv. omdat de ontvangende mailserver er niet op checkt) en een boze reply sturen aan de gespoofde afzender, helpt helemaal niets.

Anders gezegd: DMARC + SPF en/of DKIM helpen beschermen tegen afzender-spoofing, DKIM kan tevens de integriteit en authenticiteit van een e-mail garanderen (beide op domeinniveau).

Als ik me niet vergis toont Outlook, in elk geval als je een mail opent of in preview bekijkt, het SMTP afzenderadres als de mail van buiten jouw eigen domein komt. Mogelijk dat de meeste mensen dit niet weten, en sowieso kijken de meeste mensen daar waarschijnlijk niet naar (laat staan dat het opvalt dat er @rvim.nl staat i.p.v. @rivm.nl).

De triple-standaard DMARC, DKIM en SPF werken maar heel beperkt tegen het versturen van e-mails uit een andere mailserver dan de 'originele'. Alles hangt af van de instellingen van de ontvangende e-mail server en of de beheerder van de verzendende e-mailserver kijkt in de mailbox die is opgegeven in het DMARC-record. Kortom, hier is mi geen sprake van een lek. Ook al heeft de eigenaar van een maildomein (@maildomein.tld) alles conform de aanbevolen standaarden ingesteld, dan kan iemand nog steeds een e-mail sturen met een mailadres waar hij geen eigenaar van is. Niets dat hem tegenhoud. Wat hooguit gebeurd is dat ontvangende mailservers de ontvangen e-mails controleren en een e-mail sturen aan het in het DMAR-record opgegeven e-mailadres. Als dat allemaal goed functioneert, zal de beheerder van de verzendende e-mail snel geïnformeerd worden dat iemand anders ook mails stuur namens zijn maildomein. Geen lek dus.

Microsoft ervaring heb ik niet, maar voor Google klopt dat niet. Als je DMARC controleert, moet je ook DKIM controleren. Een paar jaar geleden kon je in google webmail op de afzender klikken en dan zag je de DKIM resultaten. (blijkbaar snapte niemand dat en is die optie er weer uit gehaald).

Wat Google doet met de controle weet ik echter niet. (bouncen, spammap of niets).

Ziggo bounced de mail als DKIM niet klopt. Een paar jaar geleden forwarde ik een periodieke mailing van mijn mailserver naar een ziggo adres. Mijn mailserver haalt echter webbugs (1-pixel tracking plaatjes) uit inkomende mail. Blijkbaar doet hij dat ook bij geforwarde mail waardoor de DKIM ondertekening niet meer klopt. Die mailings werden nooit op mijn ziggo adres afgeleverd. In het log van mijn mailserver stond dat Ziggo deze mail weigerde.

Gaan we nu echt weer muggeziften?
Niet alleen anti-spam, maar had er wel veel mee te maken, dus het is niet helemaal onterecht.

De bedoeling van SPF was om spoofing tegen te gaan, hetgeen met name door spammers en phishers gebruikt werd. Dat spoofen (met name door die twee partijen) wilde men tegen gaan en daarom is het SPF record ontwikkeld.
Dus heel begrijpelijk en ook terecht dat men dit als anti-spam promoot want daarin lag ook grotendeels het het idee achter de ontwikkeling.
Het is deels mislukt omdat niet iedereen er aan wilde meewerken en teveel gebruik werd gemaakt van niet strikte SPF regels, dus ~all i.p.v. -all. Het lijkt weer aan populariteit te winnen.
Dezelfde grap doet zich voor met DKIM, daar doet ook niet iedereen aan mee.
Nu wordt er nog weinig gespoofed door spammers, maar het komt nog degelijk wel voor.

Echter het boeit allemaal niet zoveel omdat ook spammers netjes een SPF en DKIM aanmaken en klaar.

Als een anoniem met "Hoho eerst even duidelijkheid: SPF/DKIM/DMARC is NIET bedoeld tegen spammen" suggereert dat ik dat claim, en ik reageer daarop, is wat ik doe muggenziften? In 2005 waarschuwde ik hier al voor, zie onderaan deze bijdrage.

De bedoeling van Meng Weng Wong, de bedenker van SPF (dat aanvankelijk stond voor Sender Permitted From) was in de eerste plaats het bestrijden van "Joe-Jobs". Zijn doel was niet ontvangers beschermen tegen spoofing, maar kennelijke afzenders (in envelope-From / return path) tegen NDR's (Non-Delivery Reports).

Ook in die tijd waren er al veel grote e-mail providers die in een front-end mailserver elke binnenkomende mail "aanpakten" en de verbinding verbraken, om vervolgens (tijdrovend, gequeued) op spam en malware te checken - waarna de mail aan de mailbox van de geadresseerde werd toegevoegd - mits die geadresseerde bestond en de mailbox niet te groot was. Bij welk probleem dan ook (inclusief vermeende spam of malware, toen hield men zich nog aan de regel dat mail niet mocht kwijtraken) werd er een NDR teruggestuurd naar (meestal) envelope-From.

Gevolg: bij mails waarin spammers envelope-From vervalsten, werden NDR's "teruggestuurd" naar een mailserver die helemaal niet de afzender was. Voordat SPF bestond beheerde ik een mailservertje die zo soms meer dan 1 NDR per seconde ontving, waarvan een deel in bestaande gebruiker-mailboxen terechtkwam (je kon dan, na het weekend, zomaar honderden NDR's in je mailbox aantreffen).

Met SPF wilde de bedenker dat, zo snel mogelijk na het opzetten van een verbinding - namelijk na ontvangst van envelope-From, de ontvangende mailserver kon checken of die Sender Permitted From het gebruikte IP-adres is. Meng Weng Wong was zich er hoogstwaarschijnlijk van bewust dat SPF niet tegen spoofen van "header-from" zou helpen, maar dat was dan ook niet zijn doel.

Later hebben idioten SPF mooier gemaakt dan het was, o.a. door het om te dopen in Sender Policy Framework en te claimen dat het spam zou bestrijden.

Als iets niet gaat werken zoals geadverteerd neem ik geen blad voor mijn mond. Niet in 2005 (in https://www.security.nl/posting/10403/Waarom+SPF+en+FairUCE+op+termijn+geen+spam+bestrijden) en ook nu niet (zoals in https://www.security.nl/posting/651346/Corona+app+kan+niet+werken).