De e-mailwereld zag er in 1997 heel anders uit toen het idee van SPF 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 nu, samen met DKIM en DMARC, een van de meest wijdverbreide vormen van e-mailauthenticatie. De nauwkeurigheid van uw gegevens garanderen, was in XNUMX een heel andere uitdaging dan nu.

De nauwkeurigheid van uw SPF-record hangt af van uw begrip en de zichtbaarheid uw e-mail-ecosysteem. Voor veel organisaties bestaat dit ecosysteem uit een direct beheerde infrastructuur die eigendom is van of zich bevindt in een oerwoud van gehoste diensten die e-mails versturen namens uw domeinen. In de afgelopen jaren is deze jungle 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 online omgeving, 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-zoekopdrachtenof 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 niet veel 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-zoekopdrachten van SPF:

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

Laten we eens kijken naar de voor- en nadelen van elk van hen.

SPF-recordafvlakking

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

SPF-afvlakking 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 IPvXNUMX of IPvXNUMX is. De kosten in gebruik zijn eerder tijd gerelateerd, aangezien elke vermelding geregeld nagekeken moet worden en de plaats waar de vervlakking 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 zijn 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, enz. Door de behoeftes te definiëren wordt bepaald welke middelen nodig zijn voor de implementatie en de eventuele kosten die daarmee gepaard gaan. Bovendien moet dit bij de huidige administratieve belasting van uw domeinbeheerteam toegevoegd worden.

Dynamische SPF-oplossingen

Het idee van een dynamisch SPF-record kan verschillende dingen zijn, 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 gevarieerd zijn in de implementatie, 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 wondermiddel. 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 SPF-first deployment, waarbij gebruik wordt gemaakt van een klein aantal domeinen zo niet slecht éé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 maar over één single point of failure beschikken voor alle e-mailstromen

Tot slot

Uiteindelijk gaat er niets boven sterk onderzoek om te bepalen welke oplossing het beste is om uw probleem op te lossen. Ongeacht welke 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 je dat nog niet hebt gedaan, kun je je aanmelden voor een gratis proefperiode hier en ons in staat stellen om u te helpen uw e-maildomeinen te beveiligen.

Wilt u het gesprek voortzetten? Ga naar het dmarcian- forum