SPFTechnische Ondersteuning

Uitdagingen voor SPF-management

By september 24, 2020februari 6th, 2021No Comments

De e-mailwereld zag er heel anders uit toen het idee van SPF in 1997 vorm begon te krijgen. Het ging praktisch onopgemerkt voorbij toen het rond 2000 voor het eerst in het openbaar werd genoemd, maar 20 jaar later is het samen met DKIM en DMARC een van de meest wijdverbreide vormen van e-mailauthenticatie. Het garanderen van de nauwkeurigheid van uw gegevens was toen een heel andere uitdaging dan nu.

De nauwkeurigheid van uw SPF-record hangt af van hoe goed u uw e-mail-ecosysteem begrijpt en van hoe zichtbaar het is. Voor veel organisaties bestaat dit ecosysteem uit een direct beheerde infrastructuur die eigendom is van of zich bevindt in een wirwar van gehoste diensten die e-mails versturen namens uw domeinen. In de afgelopen jaren is dit kluwen alleen maar gegroeid, waardoor de grenzen van SPF, opgelegd door de eigen implementatie, en ook de DNS zelf, snel zijn verlegd en soms overschreden. Het jongleren met deze limieten is een realiteit die moet worden aangepakt en geïntegreerd in de domeinbeheerprocessen van elke organisatie.

In dit artikel spreekt ons Deployment Team hoofdzakelijk over de gemeenschappelijke uitdagingen met betrekking tot het inzetten van SPF in de moderne wereld van e-mailauthenticatie.

Stel, u hebt maar één domein, een hybride ter plaatse geïnstalleerde onlineomgeving, en een tiental gehoste diensten die e-mails versturen namens dat domein. U zou er in eerste instantie aan kunnen denken om gewoon alle relevante vermeldingen aan het SPF-record van uw domein toe te voegen en het daarbij laten. Ze gebruiken immers uw domein om e-mails te versturen, dus het proces moet eenvoudig zijn. In werkelijkheid moet dit proces de volgende aspecten omvatten: de evaluatie van de wijze waarop deze diensten namens u e-mails versturen, het identificeren van de SPF-uitdagingen die u ervaart en het begrijpen van de oplossingen voor elk van hen om een implementatieplan te kunnen uitstippelen.

U kunt over het algemeen de volgende problemen verwachten: u overschrijdt de limiet van 10 DNS lookups of uw record is te groot om in een enkel TXT-record te passen, waarbij de eerste veruit het vaakst voorkomt. Wat kunt u eraan doen? Er zijn een aantal oplossingen, maar geen enkele is perfect. Hoewel het vinden van een oplossing noodzakelijk is, is begrip van het probleem door middel van kennis van het beheer van uw e-mail-ecosysteem het belangrijkste. Dit geeft u meer flexibiliteit bij het nemen van operationele beslissingen voor de domeinbeheerpraktijken van uw organisatie.

Dit zijn de meest gebruikte oplossingen voor het limietprobleem van 10 DNS lookups van SPF:

  • SPF flattening
  • Onnodige DNS-mechanismen vermijden
  • Specifieke subdomeinen van e-mailbronnen
  • Dynamische SPF-oplossingen

SPF flattening

Het afvlakken van een SPF-record is waarschijnlijk een van de oudste benaderingen om het probleem van de 10 DNS-zoekopdrachten lookups aan te pakken en kan op vele manieren effectief zijn. Wilt u weten hoe? Ga naar onze populaire SPF Surveyor en voer uw domein in om te zien hoe dat voor u zou werken.

SPF flattening maakt het gebruik van een specifiek domein veel meer mogelijk dan normaal. De implementatie ervan is relatief eenvoudig en is veel minder afhankelijk van DNS dan andere oplossingen, omdat de belangrijkste mechanismen die hier worden gebruikt IPv4 of IPv6 zijn. De kosten in gebruik zijn eerder tijdgerelateerd, aangezien elke vermelding geregeld nagekeken moet worden en de plaats waar het afvlakken is ontstaan constant gemonitord en duidelijk geregistreerd moet worden.

Onnodige DNS-mechanismen vermijden

Dit lijkt een voor de hand liggend advies, maar er is op het internet veel verkeerde informatie te vinden over wanneer en of een organisatie een specifieke leverancier of dienst aan haar SPF-record moet toevoegen. Laten we niet vergeten dat een verificateur een SPF-record check uitvoert met het domein dat uit het Mail From-e-mailadres uit RFC 5321 wordt gehaald, of als de Mail From niet geldig is, uit de HELO/EHLO-identiteit die door de klant is uitgewisseld tijdens een SMTP-gesprek. Dit e-mailadres (ook bekend als return path, MAIL FROM of bounceadres) is niet hetzelfde als het From: e-mailadres uit de header van RFC 5322. Dit adres wordt vaak ook de Friendly From genoemd; het is het From-e-mailadres dat vaak wordt weergegeven in een e-mailclient. Deze twee adressen komen soms niet overeen, en dat hoeft ook niet.

Wanneer u een nieuwe dienst of leverancier binnenhaalt, is het belangrijk om te begrijpen hoe ze namens uw domeinen e-mails gaan versturen. Welk domein zullen ze precies als return path gebruiken? Is het het geen van uw domeinen? Dan is er vanuit het oogpunt van authenticatie geen reden om ze toe te voegen aan uw SPF-record. Het kan lastig zijn om te begrijpen of te zien hoe bestaande diensten al e-mails versturen en daarbij kan DMARC u helpen, omdat de feedbackrapporten metadata bevatten over welke domeinidentiteit is geverifieerd als onderdeel van de SPF-controle van de ontvanger. Houd uw administratie schoon!

Specifieke subdomeinen van e-mailstromen

We hebben het hier over het creëren van een subdomein dat door een of enkele dienstverleners zal worden gebruikt, bijvoorbeeld sales.example.org voor alle verkoop gerelateerde externe afzenders. Dit is soms onvermijdelijk bij het inzetten van DMARC waarbij u een leverancier hebt die DMARC niet ondersteunt, die u kunt isoleren in zijn eigen subdomein met een eigen DMARC-beleid.

Wanneer een controlemachine een SPF-record check uitvoert, wordt er alleen gekeken naar het domein zoals dat uit de Mail From van RFC 5321 is gehaald. Dit betekent dat als een e-mail wordt verzonden met info@sales.example.org als Mail From-adres, de ontvanger in de DNS alleen bij sales.example.org naar een SPF-record zal zoeken, en nooit bij het hoofddomein. Hiermee krijgt u een gloednieuw domein om een SPF-record aan te maken, een schone lei. Het isoleren van e-mailstromen op deze manier kan dus helpen om de impact van potentieel misbruik van e-mailaccounts alleen tot de accounts die in het subdomein voorkomen te beperken. Omgekeerd kan het ook helpen om de impact van domeinreputatie door misbruik tot het subdomein te beperken, in plaats van dat alle diensten die gebruik maken van uw primaire bedrijfsdomeinidentiteit er last van hebben.

Afhankelijk van de omvang van dit subdomein kunnen er extra kosten verbonden zijn aan de implementatie, zoals het vaststellen of er behoefte is aan extra licenties, web resources, enzovoort.  Door de behoeftes te definiëren wordt bepaald welke middelen nodig zijn voor de implementatie en de eventuele kosten die daarmee gepaard gaan. Bovendien is dit een bijkomende administratieve taak van uw domeinbeheerteam.

Dynamische SPF-oplossingen

Het idee van een dynamisch SPF-record kan verschillende dingen inhouden, zoals het dynamisch afvlakken van een record en vervolgens het publiceren van het resultaat op basis van een gegevensbron. Het kan ook een complexer beheer betekenen door het gebruik van macro’s. Deze oplossingen kunnen op verschillende manieren worden geïmplementeerd, maar ze bieden doorgaans allemaal dezelfde voordelen. In de eerste plaats maakt het een soort automatisering mogelijk en biedt het grotere flexibiliteit en schaalbaarheid. Het doel is om tijd te besparen op de administratie, zonder dat u zich zorgen hoeft te maken over het aantal verzenders dat voor uw domein e-mails verzendt.

Dit kunnen zeer sterke oplossingen zijn, maar ze zijn geen panacee. Ze zouden aanzienlijke interne ontwikkeltijd vergen voor een interne oplossing op maat. Realistischer is dat organisaties een serviceprovider zoeken voor deze functionaliteit, wat kostbaar kan zijn. Ook verschuift hierdoor de mentaliteit naar eerst SPF uitrollen, waarbij gebruik wordt gemaakt van een klein aantal domeinen zo niet slechts één domein. Aangezien veel serviceproviders geen return path van klanten ondersteunen, dus een return path dat uw domein gebruikt in plaats van het hunne, zullen dergelijke oplossingen niet helpen, en zullen ze bij de implementatie van DMARC specifiek op DKIM vertrouwen voor de authenticatie. Sommige implementaties kunnen sterker afhankelijk zijn van DNS omdat ze voor alle e-mailstromen maar over één single point of failure beschikken.

Tot slot

Uiteindelijk gaat er niets boven sterk onderzoek om te bepalen wat het beste is om uw probleem op te lossen. Ongeacht welke oplossing u kiest, een sterk SPF-managementproces is de beste manier om op lange termijn het succes van de inzet van e-mailverificatie te garanderen.

Als je vragen hebt, bezoek dan onze website en chat met een van onze DMARC-adviseurs. Als u dat nog niet hebt gedaan, kun u u aanmelden voor een gratis proefperiode en ons in staat stellen om u te helpen uw e-maildomeinen te beveiligen.