Er was mij niets bijzonder opgevallen.
De mail met de vraag om de meterstand door te geven kwam hier gewoon binnen. (Ziggo)
Maar ik vul nooit iets in via een link in een mail bericht maar log dan even apart in, bij in dit geval Vitens, om de meterstand door te geven.

Bij mijn weten wordt mail met ongeldige SPF gewoon in het putje gemikt en niet geretourneerd.

Dat zal van de implementatie afhangen. Correct zou zijn om de SPF te checken in de mailserver tijdens de SMTP transactie
en een foutcode te geven. Dus niet "het mailtje terug sturen naar het geclaimde verzendadres".
Of het dan in het putje gemikt wordt dat hangt er vanaf wat er bij de verzender ingeregeld is.
Zelf heb ik om dit soort ellende te voorkomen de boel zo ingericht dat dergelijke mail rood gemarkeerd wordt in het mail
programma maar dus wel gewoon "afgeleverd" wordt (modulo de normale spamcriteria). En het komt best wel vaak voor
dat er mail rood gemarkeerd is! (dit gebeurt ook bi DKIM fouten overigens)

Helaas

Inderdaad. Er is teveel "valide" mail met SPF of DKIM fouten om blindelings te weigeren , dan is fors markeren de betere keuze.

Deze draad bevestigt mijn stelling dat SPF, DKIM, DMARC, ARC en whatever een grote mislukking is. Iedereen geeft er zijn of haar eigen invulling aan (zoals Microsoft, https://security.nl/posting/767981) en legt het probleem bij de ontvanger van de e-mail.

[zucht]
Intro, uit https://www.kvk.nl/service-en-contact/e-mail-van-kvk/:
Advies: lees alle webpagina's van de KVK om te zien welke legitieme "e-mail extensies" (afzenderdomeinen) er nog meer zijn (dan de nu gevonden 5). Aan de andere kant heb je daar niets aan, want "e-mailextensies kunnen ook nagemaakt worden".

Gelukkig geeft de KVK advies: https://www.kvk.nl/service-en-contact/hoe-controleer-ik-of-een-mail-van-kvk-komt/. Je kunt bellen, maar de kans lijkt mij erg groot dat de persoon, die je aan de lijn krijgt, niet weet of de mail die jij ontving daadwerkelijk door de KVK (of één van hun opdrachtnemers) is verzonden.

Plan B in die pagina is headers kopiëren naar mktoolbox.com. Overigens zou daar uit blijken dat de door Briolet genoemde Vitens-mail gespoofed is.

Uiterst vaag in die (m.i. voor leken onbegrijpelijke) pagina vind ik de uitleg over de gedeeltelijke DKIM faal:
Mijn uitleg: als in de DKIM signature ook de authenticiteit van de mail zelf wordt meegenomen, ga je geen match krijgen als je alleen de headers laat checken (de mail zelf ook laten checken via copy/paste is echter erg foutgevoelig, één regeleinde meer of minder maakt de handtekening al ongeldig).

De vraag die mij bekruipt is wel hoeveel er rood moet zijn als het om spoofing gaat.

De pagina eindigt met:
Vaak? Hoe weet je of de door jou ontvangen mail onder "vaak" valt of juist niet? Russisch roulette anyone?
[/zucht]

SPF, DKIM en DMARC zijn in de praktijk simpelweg onbetrouwbaar. De voorstanders ervan geven eindgebruikers een vals gevoel van veiligheid.

Maar dat is ook de enige scope van deze mechanismen: de ontvanger van de mail een mechanisme bieden om te
checken of de verzender van de mail legitiem is. De ontvanger moet er op acteren, de verzender kan daar niet aan
bijdragen.
Dit is ook de reden dat ik zelf mijn mail ben gaan hosten: ik kan niet leven met de situatie dat een of andere mailhoster
voor mij gaat bepalen welke mail wel en welke niet binnen komt, in de situatie dat er met een mail "iets mis is".
En faciliteiten om voor de gebruiker instelbaar te maken wat er met een mail als hierboven precies gebeurt, dat had zelfs
een kwaliteitsprovider als XS4ALL (toen die nog bestond) niet! Die weigerden dergelijke mail ook. Of die voor jou
belangrijk was daar keken ze niet naar.
Nu host ik de mail zelf, breng bij SPF/DKIM/DMARC fouten een lokale extra header aan, en in Thunderbird match ik
op die header en zet de berichtkleur op rood (in een berichtfilter). Nu werkt het zoals ik wil.

In een pessimistische bui zeg ik dat dat geldt voor _alle_ modellen van feitelijk erg complexe software bouwwerken met een veelheid aan beheerders van soms matige competentie .

Dezelfde redenering kun je houden (sterker - aimgh houd jij die al) over het hele TLS/SSL verhaal - tussen vergeten/verlopen , gesigned door dubieuze CAs en de summiere garantie van domain validated certs .
(DANE heb ik dan ook niet meteen veel hoop voor , hoe technisch fraai het ook is ).

In het alternatieve universum waarin PGP (voor email) wel een succes geworden was hadden we beslist ook vage net-niet namen en signers gezien, en lang geleuter over wat signers en trust nu betekenen , en keyserver vervuiling.

En helaas - in de walled garden van een google, fb speelt dat probleem minder : gmail-to-gmail is wel een strakke controle op afzender .

Maar dan gaan verzenders ook nooit hun fouten aanpassen. Als verzender kun je een 'soft fail' en een 'fail' instellen. Als je als verzender niet op je systeem durft te vertrouwen, dan kies je voor 'soft fail'. Maar als je voor een fail kies, dan wil je ook echt dat ontvangende mailservers dit soort foute mail gaan weigeren, want je wilt voorkomen dan vervalste false mail bij de ontvangers aankomt. Waarom gebruik je anders spf en een fail instelling?

Als een bedrijf als Ziggo en KPN dit soort mail direct zouden weigeren en dus de wens van de verzender zouden volgen, dan lossen de afzenders dit probleem direct op omdat ze merken dat het gros van de mail niet af te leveren is.

@Erik, Ik heb best wel veel vertrouwen in DKIM. Zelf open ik direct de header van dubieuze mail en kijk of hij dkim ondertekend is door het domein zelf. (Anders zegt het idd weinig)

Ik kreeg afgelopen week b.v mail van de kvk en als ik dan in de header lees:


dan heb ik er wel vertrouwen in.

Goedgekeurde authentieke (en geblokkeerde gespoofde) mails zijn niet het probleem. Het probleem is de rest, waaronder ontvangende partijen die afzenderverzoeken zoals SPF "-all" negeren, waardoor spoofers hun gang kunnen gaan - met als bijwerking dat ontvangers met correcte instellingen verweten wordt dat hun (uit jouw bovenste post) "mailadres niet werkte".

Je klaagt zelf dat het systeem niet altijd werkt, hoe kun je er dan vertrouwen in hebben?

Correct en veilig gedaan. NOOIT iets doen mbv een link!!