Ja hoor, het SPF record van kpnmail.nl is

En
geeft
Dat is 205 bytes.

Bij SPF wordt vaak een "include" gebruikt. Die soms ook weer naar een "include" doorverwijst. Dan past het dus nog steeds gemakkelijk.

Waarom denk je dat dit niet zou passen?

Heb je toevallig al als eens zelf wat bekeken of uitgezocht hoe SPF werkt?
Want een SPF record gaan voornamelijk over uitgaande mail servers, en dat is niet een DNS records zoals smtp.kpnmail.nl.
Daarnaast kan een SPF records ook includes richting andere TXT records krijgen. Of gewoon IP ranges/CIDR rechords gebruiken.

Maar als we het SPF record even bekijken voor kpnmail.nl
https://mxtoolbox.com/SuperTool.aspx?action=spf%3akpnmail.nl&run=toolpage

Dan zien we verwijzingen naar het TXT record spf.ews.kpnxchange.com
https://mxtoolbox.com/SuperTool.aspx?action=txt%3aspf.ews.kpnxchange.com&run=toolpage
https://mxtoolbox.com/SuperTool.aspx?action=spf%3aspf.ews.kpnxchange.com&run=toolpage


Ofwel we zien een IP's die de Email mogen afleveren. Daar kunnen natuurlijk nog veel meer servers achter zitten icm NAT translaties.

Checken we Telfort.com mail, zien we dat dit al bijna uit de zelfde IP range komt.

Checken we even planet.nl emails, iets wat KPN ook al jaren geleden overgenomen heeft: https://mxtoolbox.com/SuperTool.aspx?action=spf%3aplanet.nl&run=toolpage. Dan zien we al direct de overeenkomst met kpnmail.com.

Conclusie is dus: Er is geen probleem.

SPF heeft een limiet van 10 DNS mechanisme en 10 lookups per mechanisme per string.
IP's vergen geen DNS lookup en tellen niet mee aan dit totaal en je kunt altijd een subnetmask toevoegen zoals je soms moet doen met Office 365 bijvoorbeeld (/15 en /16) voor de IP'S om het leesbaar te houden.

Daarnaast zoals aangegeven door Briolet maakt men vaak gebruik van include voor SPF (De nette manier)
Vanwege het limiet aan 10 DNS mechanisme per string zie je dus ook vaak een include naar een include om zo het limiet verder op te rekken.

Daarnaast is er ook altijd nog de plakband oplossing van meerdere strings in het TXT record
Rekening waar je mee daarbij moet houden strings mogen maximaal 255 tekens bevatten. En hoogste limiet op de gehele TXT record is 65535 tekens. Als is dit absoluut niet hoe je het hoort te doen het werkt meestal wel.

Dus maak je geen zorgen ze weten wat ze doen.

Dank! TS

Beetje jammer die ?all aaan het einde... Eigenlijk zeggen ze ja we hebben een record en we geven een lijstje met IP's maar we weten het ook niet zeker. Kortom als je deze include doet op je domein dan kan je mail dus overal vandaan komen is is je SPF in feite compleet zinloos.

Erg jammer om dit soort gepruts te zien bij Neerlands grootste ISP.

Nee, SPF is gepruts. Vandaar die ?all. Dkim is de betere oplossing.

The all setting is an important aspect of the record and has the following basic markers:

-all: Any server that is not previously listed is not authorized to send email.

~all: If mail is received from a server that is not previously listed, it is marked as a soft fail, which allows the email to be scrutinized further.

+all: Allows any server to send email from your domain.

Jammer dat je zo'n geprutste opmerking maakt. Je hebt duidelijk geen idee waarover je praat in dit soort omgevingen. Overduidelijk.

KPN heeft namelijk helemaal geen controle waarvandaan alle email voor kpnmail.com afkomstig is. Er zijn duidenwebsites die bijvoorbeeld mailen namelijk pietjepuk@kpnmail.com. Die sites staan allemaal niet in het SPF records en zouden dus niet aan kunnen komen. Met klagende gebruikers overal.

Dus nee, die ?all staat er met een redenen. Gelukkig heeft onze Neerlands grootste ISP meer kennis dan onze anoniem hier, die denkt ergens verstand van te hebben.

Ofwel, je maakt een pruts opmerking zonder enig idee te hebben, wat de impact is van jouw oplossing, en hoeveel problemen die zal opleveren.

Tegenwoordig gebruiken we dmarc, en voor dmarc heb je een SPF record nodig, ongeacht hoe ie eruit ziet. dmarc heeft naast spf ook dkim nodig, wat het belangrijkste is.

Strikt genomen heb je niet beide nodig, want er hoeft maar één geldig te zijn.

"deutschepost.de" stuurt b.v. tracking mailtjes over verzonden pakjes zonder dkim in de header. Terwijl ze wel een dmarc policy op reject hebben staan. (Deze mail is dus niet meer te forwarden als origineel want alleen dkim in de header overleeft dat en spf niet).

"dhl.de" schijnt hetzelfde te doen. ("dhl.de" is hetzelfde bedrijf als "deutschepost.de" )

is er niet een standaard aantal spf lookups die je op kunt nemen in je DNS record? Dat limiet is 10. Als hij teveel lookups moet doen krijg je een error, ongeacht of ie 'goed' ingesteld staat. https://tools.ietf.org/html/rfc7208 -> 'DNS lookup limits'. Daarnaast zijn DKIM en DMARC zeker van belang in het hebben van goede email security.

Dank, ik wilde al een vergelijkbare opmerking maken over het verschil tussen kpn.nl (alle thuisgebruikers waar een ISP geen zeggenschap over heeft) en kpn.com (alle medewerkers van KPN), maar zag dat je het duidelijk verwoord had :-)

Niet de poster van het eerdere, maar heb hier ook een mening over.

Elke aanpassing levert natuurlijk problemen op, maar dat is niet een reden om niet stappen te maken op het gebied van e-mail.
KPN lijkt die problemen (nog) niet te willen aanpakken en laat het probleem nu erger worden (want niets doen is over 10 jaar het probleem nog erger dan vandaag).

@kpnmail.nl: ?all (dus eigenlijk: geen spf)
@xs4all.nl: spf-considered-harmful.xs4all.nl :D (geen spf eigenlijk)
@ziggo.nl: -all (mail komt in je spambox als niet vanuit servers van ziggo.nl verzonden)
@tele2.nl: -all (mail komt in je spambox als niet vanuit servers van ziggo.nl verzonden)

Bij Ziggo en tele2 komt je mail als je die niet netjes verstuurd dus in de spambox van de ontvanger. Dat levert natuurlijk even problemen op in situaties waar e.e.a. niet goed is geconfigureerd, maar als je nooit begint met aanpassen houd je slechte config ook gewoon in stand.

En kom niet aangezet met het 2010 argument: het gaat kapot bij forwarding, een goede forwarding kun je gewoon met ARC fixen tegenwoordig (Google GMail doet dat ook).

Oftwel om de impact te laten zien op veilig e-mailen in Nederland: als jij pietje@kpnmail.nl hebt kan iedereen in de wereld namens jou mailen zonder enige controle. Heb je pietje@tele2.nl dan zijn dat alleen andere tele2 gebruikers (he... wat is misbruik detecteren toch ineens makkelijk dan!... waar zou dat SPF nou toch voor bedoeld zijn!).

Dit klopt niet. Ziggo heeft een ~all instelling en geen -all.

Verder ben ik het met je eens dat er helemaal geen reden voor kpn is om ?all te gebruiken. KPN publiceert smtp instellingen voor de consument en als de klanten gewoon die instellingen gebruiken dan is er geen probleem. Bij gmail.com, icloud.com etc werkt het toch ook probleemloos.

Het is gewoon een kwestie van netjes werken. Ik heb het ook wel gehad dat de ziggo helpdesk mij een mailtje stuurde vanaf een IP adres dat niet in hun spf lijst stond. Waaschijnlijk was die helpdesk uitbesteed aan een externe partij die zijn eigen mailserver gebruikte en de ziggo afzender aan het spoofen was.

Dat is natuurlijk een faal. Die externe helpdesk had de ziggo server moeten gebruiken, of ziggo vragen om ook hun IP toe te voegen aan de spf lijst. Eigenlijk zou dit een standaard protocol moeten zijn bij uitbesteden van mail.

Het is ook een goede mogelijkheid om dit te configureren. Maar dit levert ook een heel hoop ellende bij je klanten op. En je moet goed de vraag stellen, of je dit werkelijk wilt.

Men kan dit zeker configureren, maar gaat heel veel ellende opleveren voor de consumenten en heel veel telefoonjes bij de servicedesk. Wat ook weer een negatief effect heeft.

De poster waar je kritiek op gaf: (tevens eigenaar van een hosting bedrijf, die zijn mailplatform eigenhandig heeft opgebouwd)

De uitleg:


~all: de softfail-methode. Als een e-mail wordt verzonden door een host of IP-adres dat niet in de SPF-record is opgenomen, dan wordt de e-mail wel geaccepteerd, maar mogelijk als spam gemarkeerd;
-all: de hardfail-methode. Als een e-mail wordt verzonden door een host of IP-adres dat niet in de SPF-record is opgenomen, dan wordt de e-mail direct geweigerd;
+all: accepteer alle e-mail. E-mail wordt dus altijd toegelaten, hierdoor heeft het record dus niet het beoogde resultaat;
?all: het SPF-record voert geen extra validatie uit. E-mails vanaf ongeautoriseerde servers worden dus toegelaten.

Kortom ?all is nagenoeg gelijk aan geen SPF. En ja KPN heeft wel degelijk invloed op waar de mail vandaan komt. Je bent namelijk als klant van KPN verplicht om hun uitgaande mailserver te gebruiken. Al dan niet authenticated. De IP nummers van deze SMTP servers zijn toch op zijn minst bekend bij KPN.

Kortom KPN zou een SPF include moeten kunnen publiceren waarin het netjes de IP nummers van hun versturende servers kan vermelden en kan dan ook netjes afsluiten met een -all.

Het wordt erg vaak vergeten: Niets doen levert ook ellende op.
Aan een e-mailadres waarvandaan iedereen zomaar mail kan sturen heb je echt niets.

En die ellende: dat valt voor de gewone gebruiker wel mee, want die stuurt netjes via smtp.kpnmail.com, volgens https://forum.kpn.com/e-mail-10/e-mail-versturen-smtp-server-instellen-360421.

Het zijn degenen die met 'meer verstand' 'bijzondere' dingen doen die het zullen gaan merken, maar die doen toch al iets wat niet zo slim was.

KPN is als een van de eerste die aangesloten is bij de veilige emailcoalitie. Zij hebben met name voor kpn.com DMARC geïmplementeerd (DKIM +/ SPF). Dit hebben ze twee jaar geleden tijdens de oneconf. gepresenteerd.
https://www.sidn.nl/nieuws-en-blogs/veilige-e-mail-coalitie-van-start

Je meldt het toch zelf, ze weten niet wie wat waar allemaal kpnmail.com vandaan komt. Als je dat niet weet, ben je aan het prutsen.

Dan moet je het niet gebruiken. Ik zie al dat je in een restaurant komt en tee besteld. En pruts tee krijgt, en dan zeggen ze daar ja maar onze koffie is goed, had je dat maar moeten drinken.

En? kpn gebruikt de amazon cloud om emails te versturen => kpn is helemaal geen veilige email provider.