Begin eens bij Wikipedia en (Google of DuckDuckGo); Als je daarna nog vragen hebt over een detail kun je die hier stellen.

Mogelijk is het goed wel eerst zelf even een kleine zoektocht de doen op internet, want er zijn genoeg bronnen die dit echt tot in detail uitleggen, zelfs in het Nederlands:

Begin anders bij:
https://internet.nl/faqs/mailauth/
https://www.ncsc.nl/documenten/factsheets/2019/juni/01/factsheet-bescherm-domeinnamen-tegen-phishing

Hier een korte uitleg:

https://www.sidn.nl/nieuws-en-blogs/waar-dkim-en-dmarc-kunnen-helpen-in-geval-van-phishing

Wat daar wel bij moet: SPF, DKIM en DMARC voorkomen wel spoofing van een DOMEIN maar niet van een BEDRIJF.
Dwz je kunt wel voorkomen dat iemand valse mail kan versturen met een afzender @sidn.nl (uit dat voorbeeld), maar
als iemand dan een domein @sidn-mail.nl of @sidn.eu of whatever registreert en dan mailt uit naam van SIDN dan wordt
dat gewoon geaccepteerd. Het is dan aan de ontvanger om te checken of dit domein ook hoort bij het bedrijf wat geclaimd
wordt de afzender te zijn.

Je zou denken: dat is toch triviaal. Ieder bedrijf in Nederland heeft 1 domain met de naam bedrijfsnaam.nl en dat kun je
dus makkelijk checken. Maar zo simpel is dat helaas niet, vooral ook omdat vele bedrijven aparte domeinen registreren
voor ieder wissewasje wat in ze opkomt, vaak ook zelfs apart voor mail. Dus als je een site www.bedrijf.nl bezocht hebt
en als gevolg daarvan een mailtje krijgt, moet je helemaal niet raar opkijken als dat niet van iemand@bedrijf.nl komt maar
van iemand@bedrijf-mail.nl ofzo.

Onder die omstandigheden is SPF, DKIM en DMARC waardeloos.

Goed leesvoer inderdaad!

Notitie: het werkt alleen bij ontvangende mail-servers die dit geïmplementeerd hebben.

Dus als ik een mail zou krijgen dan zou ik moeten kunnen zien dat de mail die ik ontvang gespoofd is?

Je zoveelste 1-2 line topic?

Zou je niet beter de vraag kunnen stellen: Hoe voorkom ik topics, die ik met een paar seconden google kan vinden?

Nee, je kunt niet voorkomen dat iemand je domein spooft, iedereen kan jouw domein spoofen. Wat je bedoelt te zeggen is dat als je maatregelen zoals SPF, DKIM en DMARC neemt, dat je dan (op een geautomatiseerde wijze) kunt ontdekken dat er een bericht gespooft is. Handmatig kun je spoofing altijd detecteren door de headers van een bericht te lezen, met name received headers. Eventueel nog aanwezige DKIM headers kunnen alsnog worden gecontroleerd en hetzelfde geldt voor controle van SPF records en DMARC.

Met de juiste DMARC configuratie en de juiste setup van ontvangende mailservers wordt gespoofte mail gewoon keihard gebounced en hoeft de ontvanger niets te doen. Met een iets lossere configuratie kun je het ook "flaggen".
Echter wat met deze methoden NIET kan is "voorkomen dat iemand valse mail stuurt uit name van SIDN" want daarvoor
ontbreekt de mogelijkheid om de bedrijfsnaam SIDN te linken aan het maildomein @sidn.nl.
Daar moet dan weer een volgend protocol voor bedacht worden.

Waar heb jij het over?
Mijn laatste vraag was een paar maanden geleden.....

DKIM headers behoor je op de mailserver zelf te controleren. Daarna kan de ontvangende mailserver een aanpassing gedaan hebben waardoor hij door de mail-cliënt niet meer eenduidig te controleren is. Onze mailserver verwijderd b.v. de zogenaamde webbugs uit mal (Een vorm van trackers die toch best vaak in commerciële mail voorkomen).

Maar in de header schrijft hij wel hoe DKIM gevalideerd is.

Verder klopt het dat er zulke uitgebreide artikelen over gepubliceerd zijn dat je hier alleen aan schemel aftreksel als antwoord zult krijgen.

Ik heb op het Ziggo forum eens uitgelegd hoe dit bij Ziggo mail via de header te lezen is. (de eerste 4 posts)
https://ziggoforum.nl/topics/mail-controle-met-spf-dkim-en-dmarc-uitgelegd.92195/

Daarom staat er ook: "eventueel nog aanwezige DKIM headers" en "handmatig".

Je moet geen rewriting mailserver gebruiken. Dat is slecht voor spam en malware detectie. Als het in de body van een mail is, maakt het voor DKIM niets uit, DKIM gaat over geselecteerde headers, niet over content. De subject header moet niet worden aangepast, want dat is een van de headers die vaak worden gebruikt in DKIM. Het is veel beter een unieke classificatieheader topside toe te voegen die clients kunnen gebruiken om mail te selecteren. Uitgaand moet die header er niet zijn.

Exim is een van de beste keuzes om rewriting te voorkomen, Sendmail en Postfix zijn stronteigenwijs (excusez let mots) en verbouwen onder bepaalde omstandigheden niet alleen headers, maar ook de body van een bericht, alleen maar om pedant of "Sendmail compliant" te zijn. Was nooit ok, is tegenwoordig om nog veel meer redenen niet ok.

Kies verder mail clients die geen remote onderdelen laden.

Misschien moet je jezelf eerst even inlezen voor je hier een foute uitleg geeft over hoe DKIM [niet] werkt?

DKIM bevat zowel geselecteerde headers als de content... voor de conten kun je wel een bepaalde lengte instellen.

Ik denk dat ook daar het aspect "hoe weet je nou dat de afzender klopt met het bedrijf waarvan je denkt dat de mail komt"
onderbelicht is. Als je een mail krijgt "van je bank" of "van je creditcardmaatschappij" hoe weet je dan of het gebruikte
afzenderdomein daadwerkelijk is wat je bij mail van dat bedrijf mag verwachten, en of dat niet een of ander willekeurig
domein is wat iemand geregistreerd heeft en wat niks met dat bedrijf te maken heeft?
En dat zeker als het gaat om bedrijven uit die categorie, die je normaal gesproken eigenlijk nooit mail sturen zodat je
ook niet kunt vergelijken met eerder ontvangen mails of kunt vertrouwen op je herrinnering.
Daar is, behalve het bewerkelijke WHOIS wat ook nog eens aan alle kanten dichtgezet is "voor de privacy", eigenlijk
geen goed protocol of voorziening voor.

DKIM gebruikt inderdaad de body ook. Het is dus nog een argument om niet met berichten te rommelen.

Je kan de controle ook handmatig aan de clientzijde uitvoeren, maar als er een rewriter tussen zit kan het verificatie verstoren.

Neeeeeeeeeee........ niet mijn geliefde Postfix afkraken.... snik..

Goed verhaal!

Q

Gelukkig is Exim om andere redenen een heel slechte keus, en Postfix een veel betere. ;)

Sendmail compliant is geen schande, het niet compliant zijn wel.

Welke MTA je gebruikt ligt toch echt aan je infrastructuur, klanten en wensen Of je nu Postfix, EXIM, Sendmail, Qmail of een obscure MTA gebruikt je zult er behoorlijk wat tijd aan kwijt zijn dit zijn geen installeer en vergeet systemen.


Voor de gene die implementatie willen van dit alles via Postfix of EXIM, SIDN heeft upto date informatie in onderstaande links.
Ze gebruiken wel CentOS ervoor maar goed met beetje googlen kun je elke unix achtige OS het wel op doorvoeren.

https://www.sidn.nl/nieuws-en-blogs/hands-on-de-implementatie-van-spf-dkim-en-dmarc-voor-postfix
https://www.sidn.nl/nieuws-en-blogs/hands-on-de-implementatie-van-spf-dkim-en-dmarc-in-exim

En dat is ook gelijk mijn antwoord op de vraag van de OP want al deze technieken uitleggen is leuk en aardig maar het is zo vele malen sneller en begrijpelijker als je het gewoon test als implementatie wat het doet wat de voordelen nadelen en de quirks zijn.

Maar daarvoor heb je dan weer certificaten. Die zijn geregistreerd op naam, dus als subject moet daar de naam van SIDN te Arnhem staan.

Ik weet het, een niet-ICT'er ziet door de bomen het bos niet meer....

Maar wat biedt je dat dan? In je mail staat niet dat certificaat, het zou kunnen dat het bij het bezorgen van de mail
gebruikt is maar dat hoeft helemaal niet. Meestal wordt daar alleen het certificaat van de ontvanger bij gebruikt.
En je wilt toch niet gaan suggereren dat als iemand een mail krijgt van sidn-mail.tv hij dan maar op goed geluk de website
sidn-mail.tv moet gaan bezoeken om te kijken wat voor certificaat daar op zit? Wieweet krijg je dan meteen malware
geserveerd.
Nee, het juiste mechanisme is uiteraard een WHOIS query. Maar ja als je dan een of andere privacy service terug
krijgt wat dan?

[quote[Ik weet het, een niet-ICT'er ziet door de bomen het bos niet meer....[/quote]Voor ICT'ers kennelijk ook, anders was hier wel aan gedacht bij het optuigen van de SPF/DKIM/DMARC kerstboom...

Nog even los van het feit dat DKIM geen gebruik maakt van certificaten, heb je kennelijk nog nooit van DV (Droom Verder) certificaten gehoord?

Ben ik het niet mee eens. WhoIs zegt alleen iets over wie de registratie heeft gedaan en is zeker geen authenticatiemiddel. Certificaten worden (afhankelijk van type) getoetst aan de inschrijving in het handelsregister. Als er later iets wijzigt, dan wordt een certificaat ingetrokken. Een domeinregistratie blijft voor de duur dat je de registratie hebt gedaan geldig. Een WhoIs is niet geschikt voor authenticatie.

https://www.sslcertificaten.nl/support/FAQ/Validatie

Het is ook niet voor authenticatie. Authenticatie gaat in dit protocol met een key die in DNS staat.
Waar het om gaat is "welk domein gebruikt een bedrijf voor mail". Dan heb je niks aan een certificaat zoals al uitgelegd.
Wat zou kunnen is een lijst geregistreerd en gepubliceerd door de KVK. Liefst dan met een handige API erbij natuurlijk
of minstens een zoekmachine. Zodat als je een mail van een bedrijf of bank krijgt je makkelijk kunt checken of dat het
goede domein is om mail te ontvangen van dat bedrijf.

Dit probleem was er in de begindagen van .nl helemaal niet (of bijna niet) want ieder bedrijf kreeg maar 1 domein.
Hadden ze dat maar zo gelaten. Voor verschillende activiteiten en acties bestaan er subdomeinen, gebruik dan als
je je mail onder een ander domein wilt doen mail.domein.nl ipv domein-mail.nl of zo iets!

De initiële vraag in dit artikel ging over het vermijden van spoofing.
Spoofing: 'Spoofing is het vervalsen van kenmerken met als doel om tijdelijk een valse identiteit aan te nemen.'
bron: https://nl.wikipedia.org/wiki/Spoofing

Om valse identiteiten te vermijden, gebruik je authenticatie.
Authenticatie: 'Authenticatie is het proces waarbij iemand nagaat of een gebruiker, een andere computer of applicatie daadwerkelijk is wie hij beweert te zijn.'
bron: https://nl.wikipedia.org/wiki/Authenticatie

Het gaat dus wel degelijk om authenticatie. Op DNS niveau heb je daarvoor DNSSEC, inderdaad een key in DNS. Maar die key is er alleen om te valideren dat je tegen de juiste DNS server praat. Het is dus een authenticatie van de DNS server, het is geen authenticatie van het betreffende bedrijf/organisatie.
Kijken we dan naar het eerder aangehaalde voorbeeld 'sidn-mail.nl'; dan zal je DNS geen alarm slaan als jij de legitieme DNS server van dit domein aanroept. Het domein sidn-mail.nl kan nog steeds door een kwaadwillend persoon geregistreerd zijn en keurig DNSSEC ondersteunen.


Als je spoofing op het hoogste niveau (bedrijf/organisatie) wil tegengaan, zal dus iets moeten gaan doen met gevalideerde (EV) certificaten om vast te stellen dat je daadwerkelijk met SIDN aan het communiceren bent.

Vandaag stond er een volle pagina in mijn krant over hoe de belastingdienst internet criminaliteit probeert te voorkomen. https://www.destentor.nl/binnenland/aantal-fraudemeldingen-explodeert-belastingdienst-bindt-strijdt-aan-met-cybercriminelen~a0dc9eb8/

Het verhaal is vrij oppervlakkig, maar wat er o.a. in stond is dat phishingmails soms met de echte afzender van de belastingdienst verzonden wordt. Dus meestal wordt een andere afzender gebruikt. Daaruit blijkt wel dat bovenstaande technieken goed werken tegen spoofing. Criminelen gebruiken liever een valse naam omdat een gespoofde naam door technische middelen ontdekt kan worden, terwijl een valse naam alleen door een ontvanger ontdekt kan worden. En ontvangers kijken te weinig naar de echte afzender.

Overigens gebruikt de belastingdienst een speciaal SPF record waardoor ze direct kunnen zien dat ergens in de wereld een gespoofed e-mailtje ontvangen wordt en welke mailserver dit foute mailtje verzonden heeft. Bij één mailtje zullen ze niet reageren, maar als dat er plotseling veel zijn, kunnen ze direct reageren. Dit is zelfs effectiever dan DMARC omdat lang niet alle mailservers dit nog ondersteunen. En als ze het al ondersteunen, sturen niet alle mailservers een dagelijks rapport naar de belastingdienst. SPF wordt wel door vrijwel alle mailservers ondersteunt en geeft direct bij ontvangst op de ontvangende mailserver een signaal bij de belastingdienst.

De gebruikte methode is hier beschreven: https://www.security.nl/posting/658016/SPF+fout+bij+mail+belastingdienst.
In eerste instantie viel mij een fout op, maar verder in de discussie blijkt hoe effectief deze methode kan zijn.

DKIM werkt met een key in een DNS record. Je hebt DNSSEC nodig om zeker te weten dat je die key goed ophaalt,
maar het authenticeren van het mailtje dmv DKIM heeft niks met DNSSEC te maken, maar met de DKIM sleutel die
onder de DKIM selector in DNS is opgeslagen (dit is dus geen vaste DNS naam zoals bij SPF en DMARC).

Maar dan nog authenticeer je dus alleen het domain en niet het bedrijf. Als iemand sidn-mail.nl registreert en de hele
kermis goed optuigt dan kan hij mail versturen en dan in de body alleen praten over SIDN en dan zal het de gemiddelde
mail ontvanger niet opvallen dat dit helemaal niet van SIDN komt. Immers dit soort "ander domein voor mail" situaties
kom je overal tegen, ook bij banken enzo. SPF, DKIM en DMARC geven allemaal groene vlaggetjes,
er is een geldig certificaat, het enige wat er "opvallend" is dat is dat het een DV certificaat is. Maar dat is 99% van alle
certificaten tegenwoordig (dankzij de ontwaarding van certificaten) dus dat gaat geen bellen laten rinkelen.

SPF, DKIM en DMARC helpen natuurlijk totaal niet als je als organisatie een derde partij toestaat om namens jouw organisatie mails te verzenden, en die derde partij haar zaakjes niet voor elkaar heeft.

Zo maakt de Britse belastingdienst HMRC kennelijk gebruik van de diensten van de bulk-mailer SendGrid, en heeft in DNS records gepubliceerd die SendGrid toestaan om namens HMRC e-mails te verzenden. Phishing spammers hebben ontdekt dat SendGrid dat vertrouwen niet waard is, want zij kunnen nu phishing mails namens hmrc.gov.uk verzenden met geldige DMARC gegevens.

Dus zelfs als de ontvanger checkt en ziet dat "iemand" @advice.hmrc.gov.uk de afzender is, en weet dat zijn/haar ontvangende mailserver checkt op SPF, DKIM en DMARC, kan het gaan om een mail met vervalste afzender.

Aangezien dit probleem bij SendGrid al een half jaar zou bestaan, en nog steeds zou bestaan, vind ik het bizar dat klanten van SendGrid (in elk geval HMRC) niet onmiddelijk hun trust-records voor SendGrid in DNS verwijderen.

Meer info: https://www.bleepingcomputer.com/news/security/hmrc-phishing-scam-abuses-mail-service-to-bypass-spam-filters/.

Dat is niet helemaal een eenvoudige keuze.

Als je de trust records voor sendgrid verwijderd - maar sendgrid niet kunt vervangen - moet je dus de trust records voor je hele domein verwijderen.

Als ik dat artikel lees, ligt het accent hier anders dan gewoon spoofen. Ze gebruiken de infrastructuur van deze bulk mailer voor het verzenden.


Via die infrastructuur kunnen ze legitiem deze afzender gebruiken. Het dns record van hmrc zal de public key bevatten die deze bulkmailer voor het dkim ondertekenen gebruikt. En het IP van deze bulkmailer zal ook via het spf record toegestaan zijn.

Het is inderdaad kwalijk van deze bulkmailer dat het anderen toegestaan is een afzender te gebruiken die niet van hen is. En ook vreemd dat de overheid niet per direct het vertrouwen opgezegd heeft. (waarschijnlijk omdat het tijd kost een andere partij te vinden die hun belastingmail kan versturen)

Sorry, maar als ik het artikel lees is me niet duidelijk hoe DMARC zou kloppen...


SPF zal dus kloppen, maar tenzij de SendGrid servers ook een geldige DKIM handtekening zet voor advice.hmrc.gov.uk geeft dit nog geen geldige DMARC=pass

Ja en nee: SPF klopt niet, want er is geen "domain aligment" tussen het return path en header from (SPF an sich klopt waarschijnlijk wel). Echter, DMARC vereist dat minstens één van de beide technieken SPF en/of DKIM correct valideren - DKIM zou dus volstaan.

Maar dan zou SendGrid inderdaad een DKIM-signature moeten hebben toegevoegd die geldig is voor HMRC. Het zou kunnen dat SendGrid een setup heeft waarbij zij dat automatisch doet voor uitgaande mails met header from domein "advice.hmrc.gov.uk", maar dat zou wel erg stom zijn.

Je hebt me in elk geval aan het denken gezet; alleen als SendGrid zo'n stomme setup zou hebben, zou DMARC een positief resultaat kunnen geven. Als dat niet zo is heb je gelijk, en was mijn conclusie dat DMARC valideerde onterecht. Neemt niet weg dat SendGrid geen phishingmails (met waarschijnlijk kloppende SPF) zou moeten forwarden.

Hoe dan ook, mijn excuses voor snel iets uit een artikel overnemen, zonder zelf na te denken en geen concrete aanwijzingen te hebben dat DMARC klopte!

Er was onlangs een stevige discussie op de spamassassin maillist over SendGrid. Er is ook een dnsbl plugin uitgebracht om (gehackte?) accounts te blokken.
Zie ook:
https://krebsonsecurity.com/2020/08/sendgrid-under-siege-from-hacked-accounts/

Dit soort bulkmaildiensten hebben in het algemeen de mogelijkheid om DKIM te doen.
Je moet dan ergens een selector en key laten genereren op die site van dat bedrijf, en dan krijg je een tekst terug die
je aan je eigen DNS zone moet toevoegen. Dat kan een TXT record zijn met het public deel van die sleutel, of een
CNAME record wat verwijst naar een TXT record in de DNS zone van die bulkmailer.
Heb je dat ingeregeld dan kunnen zij dus mail versturen namens jou die ook een geldige DKIM ondertekening heeft.
Zonder dat je daarvoor je eigen DKIM secret key aan hen hoeft te geven, en zonder dat zij die aan jou hoeven te geven.
Uiteraard zit je dan wel met het probleem dat je hen moet vertrouwen dat ze alleen mail sturen namens jou waar jij
opdracht voor gegeven hebt, en dat vertrouwen kun je in SendGrid kennelijk niet hebben.

Dat is iets wat wij als techneuten wel snappen en onderkennen, maar je moet bedenken dat het inschakelen van
bedrijven als SendGrid meestal niet door techneuten gedaan wordt maar door de marketing of management laag
van het bedrijf waar men van de mannen in de nette pakken te horen krijgt dat zo iets een prima manier is om dat
lastige versturen van nieuwsbrieven etc te regelen. Het "zet dit even in DNS" komt dan als een opdracht binnen en
het stadium "willen we dat wel?" is dan allang gepasseerd.

Ik weet niet hoe SendGrit het doet, maar op onze mailserver staat maar 1 private key. Ik kan vanuit verschillende domeinen mailen. De 'd=' parameter in de dkim ondertekening bevat het domein vanwaar ik verzend. De 's=' selector is voor alle domeinen gelijk. Als elk domein wat ik gebruik dezelfde public sleutel publiceert in de selector, dan is de dkim ondertekening geldig voor alle domeinen. Ik denk dat iets soortgelijks gebeurd bij SendGrit. Mooier was het natuurlijk als elk domein zijn eigen sleutelpaar gebruikt.

Het "advice.hmrc.gov.uk" domein zal de selector publiceren in hun dns als een CNAME naar de public key die SendGrit gebruikt in hun dns. Dat is de manier waarop het vaak mogelijk gemaakt wordt om externe partijen te laten ondertekenen met je eigen domein. (Check het maar als je zelf ondertekende bulkmail krijgt. De selector is dan vaak een CNAME record en geen TXT record)

Als SendGrid zelf spoofing van de domeinen in hun beheer toestaat, kunnen ze gewoon geldig ondertekenen.

Die reactie van 20:35 zal wellicht geplaatst zijn voor mijn reactie van 18:29 gemodereerd was, maar ik heb daar al
uitgelegd hoe het werkt. Je bent zelf vrij om selectors te gebruiken in mail en je hoeft dus helemaal niet voor je
eigen handmatige mail dezelfde selector te gebruiken als voor de bulkmail via sendgrid. En dus ook de keys niet
te delen. Of je keys wilt delen tussen verschillende domeinen die je zelf host dat moet je zelf weten, maar dit is
geen onderdeel van de beveiliging. De DKIM header geeft aan welke selector uit welk domein er gebruikt is voor
de ondertekening.

Om even een voorbeeld te geven. Ik krijg dagelijks een nieuwsbrief van mijn bank die door tripolis verzonden wordt. Zij gebruiken een selector met de originele naam 'sel2'. Als ik die opzoek bij mijn bank met het host commando, dan zie ik:


Dus ook hier een cname die wijst naar de public key van tripolis. Verder heeft de bank de gehele door tripolis gebruikte IP range 194.88.231.0/24 opgenomen in hun spf record.

Tripolis kan dus geldig ondertekenen namens de abnamro. Dus als tripolis de boel niet in orde heeft kunnen ook daar inbrekers namens de bank mail versturen via de servers van Tripolis. Je moet dus ook zeker weten dat de bulkmailer waar je mee samenwerkt de boel op orde heeft.

Edit:
Ik krijg ook van de Hanos mailings via Tripolis. Alleen gebruikt Trilolis daar zijn eigen domein om dkim te ondertekenen.

Zoals ik zie is dat wel een andere public key. Ze gebruiken wel weer de alias constructie, hoewel ik hier de noodzaak niet zie, anders dan alles uniform te hebben.

Inderdaad - het probleem is blijkbaar dat elke SendGrid klant -ook gehackte accounts - mail kan versturen voor elke andere SendGrid klant .


De meer ervaren techneut snapt ook dat het versturen van echte grote hoeveelheden bulkmail inmiddels een gespecialiseerde bezigheid is.
Een servertje dat mail kan pompen is het probleem niet - lijstbeheer, relaties onderhoudden met de gmail/hotmail van de wereld en allerlei andere bulk-ontvangers maakt het een stuk duurder project met voortdurende beheerlasten .

Dat kan een keuze zijn - maar de techneut die roept 'ik knal ff een VM'tje in de lucht daarvoor, klaar' als het gaat om 'alle UK belastingbetalers' is een klungel. (of - overenthousiaste junior die nog een hoop moet leren buiten het techniek domein)

Bedrijven als Sendgrid bestaan omdat schaalvoordeel zo groot is . De overhead die je hebt voor het eerste grote bulkverzend-domein wordt verdeeld over alle klanten. De tweede en volgende kosten relatief heel weinig extra.
Net zoals housing/hosting typisch uitbesteed wordt.

Het is een grote misvatting (die populair is onder managers) om te denken "als we het uitbesteden dan is het wel goed
geregeld". Ik heb een tijd geleden een mailinglist voor het bedrijf opgezet met een speciaal pakket daarvoor wat keurig
een bevestigingsmail stuurde bij aanmelden, en wat bij 5 achtereenvolgende afleverfouten het adres verwijderde, etc.
Gewoon standaard software. Hoefde je (wat dit betreft) niet naar om te kijken.
Maar sindsdien hebben we een aantal domeinen voor mail opgeheven en daar zie ik 5 jaar later nog dagelijks mail op
binnen komen die keurig iedere dag met een 550 beantwoord wordt maar het blijft doorgaan. En dat zijn gewoon van
diezelfde soort diensten als SendGrid. Prutsers.

Typisch. Kokertje, alleen stukje techniek zien.
Dus jouw advies voor een belastingdienst is om automatisch en ongemerkt een adres na vijf x 550 van de lijst te verwijderen ?

JA dat is mijn advies!!
Net als waneer ze 5 opeeenvolgende brieven retour krijgen met "geaddresseerde onbekend op dit adres".
Zet er dan maar een vlag op dat die persoon niet per mail (of brief) bereikbaar is.
Dat is beter dan je berichten in een zwart gat storten en dan later in de modus "we hebben u bericht gestuurd maar
u heeft niet gereageerd" te gaan. Vind ik.