Als u op deze pagina bent en deze blog leest, is de kans groot dat u een van de volgende vragen bent tegengekomen:

  • Geen SPF record gevonden
  • SPF record ontbreekt
  • Geen SPF record
  • SPF record niet gevonden
  • Geen SPF record gepubliceerd
  • Kan SPF record niet vinden

De prompt betekent simpelweg dat uw domein niet is geconfigureerd met SPF e-mail authenticatie standaard. Een SPF record is een DNS TXT record dat wordt gepubliceerd in de DNS van uw domein om berichten te authenticeren door ze te vergelijken met de geautoriseerde IP adressen die namens uw domein e-mails mogen versturen, opgenomen in uw SPF record. Dus als uw domein niet is geauthenticeerd met het SPF protocol kunt u natuurlijk een "Geen SPF record gevonden" bericht tegenkomen.

Wat is Sender Policy Framework (SPF)?

SPF e-mailverificatiestandaard is een mechanisme dat wordt gebruikt om te voorkomen dat spammers e-mails vervalsen. Het gebruikt DNS records om te verifiëren dat de verzendende server toestemming heeft om emails van de domeinnaam te verzenden. SPF, wat staat voor Sender Policy Framework, maakt het mogelijk om toegestane verzenders van emails op uw domein te identificeren.

SPF is een "pad-gebaseerd" authenticatiesysteem, wat betekent dat het gerelateerd is aan het pad dat de e-mail aflegt van de oorspronkelijke verzendende server naar de ontvangende server. SPF stelt organisaties niet alleen in staat IP-adressen te machtigen hun domeinnamen te gebruiken bij het verzenden van e-mails, maar biedt ook een manier waarop een ontvangende e-mailserver die machtiging kan controleren.

Moet ik SPF configureren?

Er is u waarschijnlijk verteld dat u SPF (Sender Policy Framework) e-mailverificatie nodig hebt. Maar heeft een bedrijf dit echt nodig? En zo ja, zijn er nog andere voordelen? Die vraag wordt meestal begrepen als de onderneming een grote e-mail uitwisselaar wordt voor hun organisatie. Met SPF kunt u e-mailgedrag volgen om frauduleuze berichten op te sporen en uw bedrijf te beschermen tegen spam-gerelateerde problemen, spoofing en phishing-aanvallen. SPF helpt u maximale deliverability en merkbescherming te bereiken door de identiteit van de afzenders te verifiëren.

Hoe werkt SPF?

  • SPF-records zijn speciaal geformatteerde DNS-records (Domain Name System) die door domeinbeheerders worden gepubliceerd en die bepalen welke mailservers gemachtigd zijn om namens dat domein mail te verzenden.
  • Als SPF voor uw domein is geconfigureerd, zoekt de mailserver van de ontvanger, telkens wanneer een e-mail vanaf uw domein wordt verzonden, de specificaties voor het retourpaddomein op in het
  • DNS. Vervolgens wordt geprobeerd het IP-adres van de afzender te koppelen aan de geautoriseerde adressen die in uw SPF-record zijn gedefinieerd.
  • Volgens de SPF-beleidsspecificaties beslist de ontvangende server dan of de e-mail moet worden afgeleverd, geweigerd of gemarkeerd indien de authenticatie mislukt.

De syntax van een SPF record uitsplitsen

Laten we het voorbeeld nemen van een SPF record voor een dummy domein met de correcte syntax:

v=spf1 ip4:29.337.148 include:domain.com -all

 

Het bericht "Geen SPF record gevonden" stoppen

Als u niet langer de vervelende melding "Geen SPF record gevonden" wilt krijgen, hoeft u alleen maar SPF voor uw domein te configureren door een DNS TXT record te publiceren. U kunt onze gratis SPF record generator gebruiken om direct een record met de juiste syntaxis te maken, om in uw DNS te publiceren.

Alles wat je hoeft te doen is:

  • Kies of u wilt toestaan dat als MX vermelde servers e-mails voor uw domein verzenden
  • Kies of u wilt toestaan dat het huidige IP-adres van het domein e-mail verstuurt voor dit domein
  • Vul de IP adressen in die gemachtigd zijn om emails te versturen vanaf uw domein
  • Voeg alle andere server hostnamen of domeinen toe die mail kunnen afleveren of doorsturen voor uw domein
  • Kies uw SPF beleid modus of het niveau van strengheid van de ontvangende server uit Fail (niet-conforme emails worden geweigerd), Soft-fail (niet-conforme emails worden geaccepteerd maar gemarkeerd), en Neutral (Mails worden waarschijnlijk wel geaccepteerd)
  • Klik op SPF-record genereren om onmiddellijk uw record aan te maken

Indien u SPF al heeft geconfigureerd voor uw domein, kunt u ook onze gratis SPF record checker gebruiken om uw SPF record op te zoeken, te valideren en problemen op te sporen.

Is het publiceren van een SPF Record voldoende?

Het antwoord is nee. SPF alleen kan niet voorkomen dat uw merk wordt nagebootst. Voor optimale bescherming tegen direct-domain spoofing, phishing aanvallen en BEC, moet u DKIM en DMARC configureren voor uw domein.

Bovendien heeft SPF een limiet van 10 DNS lookups. Als je deze limiet overschrijdt zal je SPF breken en zal de authenticatie falen voor zelfs legitieme emails. Daarom heb je een dynamische SPF flattener nodig die je helpt onder de 10 DNS lookup limiet te blijven, en die je op de hoogte houdt van wijzigingen die door je e-mail exchange providers worden gemaakt.

Hopelijk heeft deze blog u geholpen uw probleem op te lossen en hoeft u zich nooit meer zorgen te maken dat u last heeft van de melding "Geen SPF record gevonden". Meld u vandaag nog aan voor een gratis proefversie van e-mailverificatie om uw e-maildeliverability en e-mailbeveiliging te verbeteren!

 

Een zich steeds verder ontwikkelende en welig tierende vorm van cybercriminaliteit die zich richt op e-mails als mogelijk medium om fraude te plegen, staat bekend als Business Email Compromise. BEC-aanvallen zijn gericht op commerciële, overheids- en non-profitorganisaties en kunnen leiden tot enorme verliezen van gegevens, inbreuken op de beveiliging en compromittering van financiële activa. Het is een gangbare misvatting dat cybercriminelen zich meestal richten op multinationals en organisaties op ondernemingsniveau. Kleine en middelgrote ondernemingen zijn tegenwoordig net zo goed een doelwit voor e-mailfraude als de grotere spelers in de sector. 

Hoe kan BEC organisaties beïnvloeden?

Voorbeelden van BEC-aanvallen zijn geavanceerde social engineering-aanvallen zoals phishing, CEO-fraude, valse facturen en e-mail spoofing, om er maar een paar te noemen. Het kan ook worden omschreven als een imitatieaanval waarbij een aanvaller een bedrijf wil bedriegen door zich voor te doen als mensen in autoritaire posities. Het succes van deze aanvallen is te danken aan het feit dat mensen als de CFO of CEO, een zakenpartner of iemand die je blindelings vertrouwt, zich voordoen als zodanig.

In februari van 2021 werden de activiteiten van de Russische cyberbende Cosmic Lynx vastgelegd, toen zij BEC op geraffineerde wijze aanpakten. De groep was al in verband gebracht met het uitvoeren van meer dan 200 BEC-campagnes sinds juli 2019, gericht op meer dan 46 landen wereldwijd, met de nadruk op gigantische MNC's die wereldwijd aanwezig zijn. Met extreem goed geschreven phishingmails maken ze het mensen onmogelijk om onderscheid te maken tussen echte en nepberichten.

Door telewerken zijn videoconferentietoepassingen onmisbare entiteiten geworden, post-pandemie. Cybercriminelen maken misbruik van deze situatie door frauduleuze e-mails te sturen die zich voordoen als een kennisgeving van het videoconferentieplatform Zoom. Het doel hiervan is om inloggegevens te stelen en zo massale inbreuken op bedrijfsgegevens te plegen.

Het is duidelijk dat de relevantie van BEC de laatste tijd snel opduikt en toeneemt, nu bedreigers met geavanceerdere en innovatievere manieren komen om weg te komen met fraude. BEC-aanvallen treffen meer dan 70% organisaties wereldwijd en leiden tot een verlies van miljarden dollars per jaar. Daarom komen deskundigen uit de sector met e-mailverificatieprotocollen zoals DMARC, om een hoog niveau van bescherming te bieden tegen impersonatie.

Wat is e-mailauthenticatie?

E-mailauthenticatie kan worden omschreven als een reeks technieken die worden toegepast om verifieerbare informatie te verstrekken over de herkomst van e-mails. Dit wordt gedaan door het domeinbezit van de bij de berichtenoverdracht betrokken mail transfer agent(en) te verifiëren.

Simple Mail Transfer Protocol (SMTP), de industriestandaard voor e-mailoverdracht, heeft geen ingebouwde functie voor berichtauthenticatie. Daarom wordt het voor cybercriminelen bijzonder gemakkelijk om misbruik te maken van dit gebrek aan beveiliging voor het lanceren van e-mail phishing en domain spoofing aanvallen. Dit onderstreept de noodzaak van effectieve e-mailverificatieprotocollen zoals DMARC, dat zijn claims ook waarmaakt!

Stappen om BEC aanvallen te voorkomen met DMARC

 

Stap 1: Uitvoering 

De eerste stap in het bestrijden van BEC aanvallen is het configureren van DMARC voor uw domein. Domain-based Message Authentication, Reporting and Conformance (DMARC) maakt gebruik van SPF en DKIM verificatiestandaarden om e-mails te valideren die vanaf uw domein worden verzonden. Het specificeert aan ontvangende servers hoe te reageren op e-mails die niet voldoen aan een van beide controles, waardoor de domeineigenaar controle heeft over het antwoord van de ontvanger. Dus voor het implementeren van DMARC, zou u het volgende moeten doen:

  • Identificeer alle geldige e-mailbronnen die geautoriseerd zijn voor uw domein
  • Publiceer SPF record in uw DNS om SPF voor uw domein te configureren
  • Publiceer DKIM record in uw DNS om DKIM voor uw domein te configureren
  • Publiceer DMARC record in uw DNS om DMARC voor uw domein te configureren

Om complexiteit te vermijden, kunt u de gratis tools van PowerDMARC gebruiken ( gratis SPF record generator, gratis DKIM record generator, gratis DMARC record generator) om records met de juiste syntaxis te genereren, onmiddellijk, om in de DNS van uw domein te publiceren.

Stap 2: Handhaving 

Uw DMARC beleid kan worden ingesteld op:

  • p=none (DMARC alleen bij controle; berichten die niet geauthenticeerd worden, worden nog steeds afgeleverd)
  • p=quarantaine (DMARC bij handhaving; berichten die niet geauthenticeerd kunnen worden, worden in quarantaine geplaatst)
  • p=afwijzen (DMARC op maximum handhaving; berichten die niet geauthenticeerd worden, worden helemaal niet afgeleverd)

Wij raden u aan DMARC te gaan gebruiken met een beleid dat alleen monitoring toestaat, zodat u de e-mailstroom en afleveringsproblemen in de gaten kunt houden. Een dergelijk beleid zou echter geen bescherming bieden tegen BEC. Daarom zou u uiteindelijk moeten overstappen op DMARC enforcement. PowerDMARC helpt u naadloos over te schakelen van monitoring naar enforcement in een handomdraai met een policy van p=reject die helpt om aan ontvangende servers te specificeren dat een e-mail, verzonden van een kwaadwillige bron die uw domein gebruikt, helemaal niet in de inbox van uw ontvanger zal worden afgeleverd.

Stap 3: Toezicht en rapportage 

U heeft uw DMARC beleid op enforcement gezet en met succes de BEC aanval geminimaliseerd, maar is dat genoeg? Het antwoord is nee. U heeft nog steeds een uitgebreid en effectief rapportage mechanisme nodig om de e-mailstroom te monitoren en te reageren op eventuele afleveringsproblemen. PowerDMARC's multi-tenant SaaS platform helpt u daarbij:

  • blijf de baas over uw domein
  • visueel de verificatieresultaten volgen voor elke e-mail, gebruiker en domein die voor u is geregistreerd
  • het uitschakelen van misbruik makende IP-adressen die zich proberen voor te doen als uw merk

DMARC rapporten zijn beschikbaar op het PowerDMARC dashboard in twee belangrijke formaten:

  • DMARC geaggregeerde rapporten (beschikbaar in 7 verschillende weergaven)
  • DMARC forensische rapporten (met encryptie voor verbeterde privacy)

Een combinatie van DMARC-implementatie, -handhaving en -rapportage helpt u de kans drastisch te verkleinen dat u ten prooi valt aan BEC-aanvallen en impersonatie. 

Heb ik met Anti-Spam Filters nog DMARC nodig?

Ja! DMARC werkt heel anders dan uw gewone anti-spam filters en e-mail security gateways. Hoewel deze oplossingen meestal geïntegreerd zijn met uw cloud-gebaseerde e-mailuitwisselingsdiensten, kunnen ze alleen bescherming bieden tegen inkomende phishingpogingen. Berichten die vanuit uw domein worden verzonden, blijven nog steeds onder de dreiging van impersonatie. Dit is waar DMARC in het spel komt.

Extra tips voor een betere beveiliging van e-mail

 

Blijf altijd onder de 10 DNS Lookup Limiet 

Het overschrijden van de SPF 10 lookup limiet kan je SPF record volledig ongeldig maken en er voor zorgen dat zelfs legitieme emails niet geauthenticeerd kunnen worden. In zulke gevallen, als u uw DMARC heeft ingesteld op reject, zullen authentieke emails niet worden afgeleverd. PowerSPF is uw automatische en dynamische SPF record flattener die SPF permerror vermindert door u te helpen onder de SPF hard limit te blijven. Het werkt netblocks automatisch bij en scant voortdurend op wijzigingen die door uw e-mail service providers worden aangebracht in hun IP-adressen, zonder enige tussenkomst van uw kant.

Zorg voor TLS-versleuteling van e-mails in doorvoer

DMARC kan u weliswaar beschermen tegen social engineering aanvallen en BEC, maar u moet zich nog steeds wapenen tegen alomtegenwoordige controleaanvallen zoals Man-in-the-middle (MITM). Dit kan worden gedaan door ervoor te zorgen dat telkens wanneer een e-mail naar uw domein wordt verzonden, een via TLS beveiligde verbinding tussen SMTP-servers wordt tot stand gebracht. PowerDMARC's hosted MTA-STS maakt TLS encryptie verplicht in SMTP en wordt geleverd met een eenvoudige implementatie procedure.

Rapporten ontvangen over problemen bij de aflevering van e-mail

U kunt ook SMTP TLS rapportage inschakelen om diagnostische rapporten te krijgen over e-mail afleveringsproblemen na het configureren van MTA-STS voor uw domein. TLS-RPT helpt u inzicht te krijgen in uw e-mail ecosysteem, en beter te reageren op problemen bij het onderhandelen van een beveiligde verbinding die leiden tot afleveringsfouten. TLS-rapporten zijn beschikbaar in twee weergaven (geaggregeerde rapporten per resultaat en per verzendbron) op het PowerDMARC-dashboard.

Versterk uw merkherinnering met BIMI 

Met BIMI (Brand Indicators for Message Identification) kunt u uw merkbekendheid naar een geheel nieuw niveau tillen door uw ontvangers te helpen u visueel te identificeren in hun inbox. BIMI werkt door uw unieke merklogo toe te voegen aan elke e-mail die u vanaf uw domein verstuurt. PowerDMARC maakt de implementatie van BIMI eenvoudig met slechts 3 eenvoudige stappen van de kant van de gebruiker.

PowerDMARC is uw one-stop bestemming voor een scala aan e-mail authenticatie protocollen, waaronder DMARC, SPF, DKIM, BIMI, MTA-STS, en TLS-RPT. Meld u vandaag nog aan voor uw gratis DMARC Analyzer proefversie!

Een veel voorkomend probleem waar SPF gebruikers dagelijks mee te maken hebben is het risico van het genereren van te veel DNS lookups waardoor de SPF hard limit gemakkelijk overschreden wordt. Dit geeft een SPF PermError resultaat wanneer DMARC monitoring is ingeschakeld en veroorzaakt email deliverability problemen. Met industrie-experts die met oplossingen komen zoals SPF flattening services om dit probleem te verminderen, maakt PowerSPF zijn claims waar en overtreft het de verwachtingen. Lees verder om te leren hoe!

Te veel DNS Lookups: Waarom gebeurt dit?

Het eerste wat u moet begrijpen is waarom u uiteindelijk te veel DNS lookups genereert. Dit komt omdat, ongeacht welke email exchanger oplossing u gebruikt, uw service provider meer mechanismen toevoegt aan uw record wat resulteert in meer lookups.

Bijvoorbeeld, als je Google's email exchanger gebruikt, of Gmail, dan genereert een SPF record zoals v=spf1 include:[email protected] -all genereert in feite een totaal van 4 DNS lookups. Geneste inclusies initiëren ook meer lookups en als u verschillende derde partijen gebruikt om emails te versturen met uw domein, kunt u gemakkelijk de 10 DNS lookup limiet overschrijden.

Is SPF afvlakken de oplossing? Nee!

Het antwoord is nee. SPF handmatig flatten kan u helpen onder de SPF 10 lookup limiet te blijven, maar het heeft zijn eigen set van beperkingen en uitdagingen. Als u uw SPF handmatig flatten, vervangt u gewoon de include statements in uw SPF record door hun overeenkomstige IP adressen om de noodzaak voor lookups te elimineren. Dit zorgt ervoor dat u in de eerste plaats niet te veel DNS lookups genereert, waardoor u onder de 10 lookup SPF limiet blijft en permerror vermijdt. Maar problemen met manuele SPF flattening oplossingen zijn:

  • De lengte van het SPF-record kan te lang zijn (meer dan 255 tekens)
  • Uw e-mail service provider kan IP adressen wijzigen of toevoegen zonder u daarvan op de hoogte te stellen
  • Er is geen dashboard om de e-mailstroom te controleren, uw domeinen en mechanismen te wijzigen of bij te werken, en activiteiten te volgen
  • U moet voortdurend wijzigingen aanbrengen in uw DNS om uw SPF-record bij te werken
  • De bezorgbaarheid van uw e-mail kan worden beïnvloed door de frequente IP-wijzigingen

Wat zijn de gevolgen voor u? Nou, als je SPF record niet is bijgewerkt op de nieuwe IP adressen die je email service providers gebruiken, zullen je emails af en toe, wanneer deze IP adressen worden gebruikt, onvermijdelijk SPF falen aan de kant van de ontvanger.

Dynamische SPF afvlakking om te veel DNS Lookups op te lossen

Een slimmere oplossing om vaarwel te zeggen tegen de DNS lookups fout is PowerSPF, uw automatische SPF record flattener. PowerSPF is uw real-time SPF flattening oplossing die u helpt:

  • Eenvoudig SPF configureren voor uw domein met slechts een paar klikken
  • Met één muisklik SPF-records afvlakken met één enkele include-instructie voor automatisch beheer van SPF-records
  • Blijf altijd onder de 10 DNS lookup limiet
  • Automatische update van netblock en constante scan op gewijzigde IP adressen om uw SPF record up-to-date te houden
  • U beschikt over een gebruiksvriendelijk dashboard waarin u eenvoudig wijzigingen in uw beleid kunt bijwerken, domeinen en mechanismen kunt toevoegen en de e-mailstroom kunt bewaken.

Waarom vertrouwen op SPF compressie tools die tijdelijke resultaten kunnen leveren met onderliggende beperkingen? Optimaliseer uw SPF Record en verminder de SPF harde limiet met Automatic SPF vandaag nog! Nu aanmelden voor PowerSPF?

Wat is ARC?

ARC of Authenticated Received Chain is een e-mail authenticatiesysteem dat de authenticatiebeoordeling van een e-mailbericht bij elke stap weergeeft, gedurende de hele afhandeling. Eenvoudiger gezegd kan de Authenticated Received Chain worden aangeduid als een "chain of custody" voor e-mailberichten, die elke entiteit die de berichten behandelt in staat stelt om alle entiteiten die de berichten eerder hebben behandeld effectief te zien. Als relatief nieuw protocol, gepubliceerd en gedocumenteerd als "Experimental" in RFC 8617 op juli 2019, stelt ARC de ontvangende server in staat om emails te valideren, zelfs wanneer SPF en DKIM ongeldig zijn gemaakt door een tussenliggende server.

Hoe kan een geauthenticeerde ontvangende keten helpen?

Zoals we al weten, staat DMARC toe dat een e-mail wordt geauthenticeerd tegen de SPF en DKIM e-mail authenticatie standaarden, waarbij de ontvanger wordt gespecificeerd hoe om te gaan met de e-mails die falen of slagen voor de authenticatie. Echter, als u DMARC enforcement in uw organisatie implementeert volgens een strikt DMARC beleid, bestaat de kans dat zelfs legitieme emails, zoals die verzonden zijn via een mailing list of een forwarder, niet geauthenticeerd kunnen worden en niet afgeleverd worden bij de ontvanger! Authenticated Received Chain helpt dit probleem effectief te beperken. Laten we in de volgende sectie leren hoe:

Situaties waarin ARC kan helpen

  • Mailinglijsten 

Als lid van een mailinglijst hebt u de mogelijkheid om in één keer berichten naar alle leden van de lijst te sturen door de mailinglijst zelf te adresseren. Het ontvangende adres stuurt uw bericht vervolgens door naar alle leden van de lijst. In de huidige situatie slaagt DMARC er niet in dit soort berichten te valideren en mislukt de authenticatie, ook al is de e-mail van een legitieme bron verzonden! Dit komt doordat SPF breekt wanneer een bericht wordt doorgestuurd. Omdat de mailinglijst vaak extra informatie in de e-mailbody opneemt, kan de DKIM-handtekening ook ongeldig worden gemaakt door wijzigingen in de e-mailinhoud.

  • Berichten doorsturen 

Wanneer er een indirecte mail flow is, bijvoorbeeld wanneer u een email ontvangt van een tussenliggende server en niet direct van de verzendende server zoals in het geval van doorgestuurde berichten, breekt SPF en zal uw email automatisch DMARC authenticatie falen. Sommige forwarders veranderen ook de inhoud van de e-mail, waardoor de DKIM handtekeningen ook ongeldig worden gemaakt.

 

 

In dergelijke situaties schiet de Authenticated Received Chain te hulp! Hoe? Laten we dat eens uitzoeken:

Hoe werkt ARC?

In de hierboven opgesomde situaties hadden de forwarders aanvankelijk e-mails ontvangen die waren gevalideerd aan de hand van de DMARC-setup, van een geautoriseerde bron. Authenticated Received Chain is ontwikkeld als een specificatie die het mogelijk maakt de Authentication-Results header door te geven aan de volgende "hop" in de lijn van de berichtaflevering.

In het geval van een doorgestuurd bericht probeert de e-mailserver van de ontvanger, wanneer hij een bericht ontvangt dat DMARC-authenticatie niet heeft doorstaan, de e-mail een tweede keer te valideren tegen de verstrekte Authenticated Received Chain voor de e-mail door de ARC Authentication-Results van de eerste "hop" te extraheren, om na te gaan of het bericht als legitiem werd gevalideerd voordat de tussenliggende server het naar de ontvangende server doorstuurde.

Op basis van de geëxtraheerde informatie beslist de ontvanger of de ARC-resultaten het DMARC-beleid terzijde mogen schuiven, zodat de e-mail als authentiek en geldig wordt beschouwd en normaal in de inbox van de ontvanger kan worden afgeleverd.

Met de ARC-implementatie kan de ontvanger de e-mail effectief authenticeren met behulp van de volgende informatie:

  • De authenticatieresultaten zoals waargenomen door de tussenliggende server, samen met de hele geschiedenis van SPF en DKIM validatieresultaten in de initiële hop.
  • Noodzakelijke informatie om de verzonden gegevens te authenticeren.
  • Informatie om de verzonden handtekening aan de tussenliggende server te koppelen, zodat de e-mail bij de ontvangende server wordt gevalideerd, zelfs als de tussenliggende server de inhoud wijzigt, zolang hij maar een nieuwe en geldige DKIM-handtekening doorstuurt.

Implementatie van geauthenticeerde ontvangen keten

ARC definieert drie nieuwe mail headers:

  • ARC-Authenticatie-Resultaten (AAR): De eerste van de mail headers is de AAR die de authenticatie resultaten zoals SPF, DKIM, en DMARC inkapselt.

  • ARC-Seal (AS) - AS is een eenvoudigere versie van een DKIM-handtekening, die informatie bevat over de resultaten van de authenticatieheader, en ARC-handtekening.

  • ARC-Message-Signature (AMS) - AMS is ook vergelijkbaar met een DKIM handtekening, maar neemt een afbeelding van de header van het bericht waarin alles is opgenomen behalve de ARC-Seal headers zoals de velden To: en From:, onderwerp, en de hele body van het bericht.

Stappen uitgevoerd door de intermediaire server om een wijziging te ondertekenen:

Stap 1: de server kopieert het veld Authentication-Results naar een nieuw AAR-veld en voegt het toe aan het bericht

Stap 2: de server formuleert het AMS voor het bericht (met het AAR) en voegt het toe aan het bericht.

Stap 3: de server formuleert het AS voor de voorgaande ARC-Seal headers en voegt het toe aan het bericht.

Tenslotte, om de Authenticated Received Chain te valideren en uit te vinden of een doorgestuurd bericht legitiem is of niet, valideert de ontvanger de chain of ARC Seal-headers en de nieuwste ARC-Message-Signature. Als de ARC headers op enigerlei wijze zijn gewijzigd faalt de email bijgevolg bij de DKIM authenticatie. Echter, als alle mailservers die betrokken zijn bij de verzending van het bericht ARC correct ondertekenen en verzenden, dan behoudt de e-mail de DKIM authenticatie resultaten, en slaagt DMARC authenticatie, wat resulteert in de succesvolle aflevering van het bericht in de inbox van de ontvanger!

ARC implementatie ondersteunt DMARC adoptie in organisaties om er zeker van te zijn dat elke legitieme e-mail geauthenticeerd wordt zonder een enkele fout. Meld u vandaag nog aan voor uw gratis DMARC-proefversie!

 

Redenen om SPF afvlakking te vermijden

Sender Policy Framework, of SPF is een alom geprezen e-mail authenticatie protocol dat uw berichten valideert door ze te vergelijken met alle geautoriseerde IP adressen die voor uw domein in uw SPF record zijn geregistreerd. Om emails te valideren, specificeert SPF aan de ontvangende mail server om DNS queries uit te voeren om te controleren op geautoriseerde IP's, wat resulteert in DNS lookups.

Uw SPF record bestaat als een DNS TXT record dat gevormd wordt uit een assemblage van verschillende mechanismen. De meeste van deze mechanismen (zoals include, a, mx, redirect, exists, ptr) genereren DNS lookups. Het maximum aantal DNS-lookups voor SPF-authenticatie is echter beperkt tot 10. Als u verschillende derde partijen gebruikt om emails te versturen met uw domein, kunt u gemakkelijk de harde limiet van SPF overschrijden.

U vraagt zich misschien af wat er gebeurt als u deze limiet overschrijdt? Het overschrijden van de 10 DNS lookup limiet zal leiden tot SPF mislukking en zelfs legitieme berichten verzonden vanaf uw domein ongeldig maken. In zulke gevallen stuurt de ontvangende mail server een SPF PermError rapport terug naar uw domein als u DMARC monitoring heeft ingeschakeld. Dit brengt ons bij het primaire onderwerp van discussie voor deze blog: SPF flattening.

Wat is SPF afvlakking?

SPF record flattening is één van de populaire methodes die gebruikt wordt door industrie experten om uw SPF record te optimaliseren en te vermijden dat de SPF harde limiet overschreden wordt. De procedure voor SPF flattening is vrij eenvoudig. Het flatten van uw SPF record is het proces van het vervangen van alle include mechanismen door hun respectievelijke IP adressen om de noodzaak voor het uitvoeren van DNS lookups te elimineren.

Bijvoorbeeld, als uw SPF record er oorspronkelijk zo uitzag:

v=spf1 include:spf.domain.com -all

Een afgevlakt SPF record ziet er ongeveer zo uit:

v=spf1 ip4:168.191.1.1 ip6:3a02:8c7:aaca:645::1 -all

Dit afgevlakte record genereert slechts één DNS lookup, in plaats van meerdere lookups uit te voeren. Het verminderen van het aantal DNS-queries dat door de ontvangende server wordt uitgevoerd tijdens e-mailauthenticatie helpt om onder de limiet van 10 DNS-lookups te blijven, maar heeft zo zijn eigen problemen.

Het probleem met SPF afvlakking

Afgezien van het feit dat uw handmatig afgevlakte SPF record te lang kan worden om te publiceren op de DNS van uw domein (het overschrijden van de 255 karakter limiet), moet u er rekening mee houden dat uw email service provider zijn IP adressen kan wijzigen of toevoegen zonder u als gebruiker daarvan op de hoogte te stellen. Wanneer uw provider af en toe wijzigingen aanbrengt aan hun infrastructuur, worden deze wijzigingen niet weerspiegeld in uw SPF record. Wanneer deze gewijzigde of nieuwe IP adressen dus door uw mail server worden gebruikt, zal de e-mail SPF aan de kant van de ontvanger falen.

PowerSPF: Uw dynamische SPF Record Generator

Het uiteindelijke doel van PowerDMARC was om met een oplossing te komen die kan voorkomen dat domeineigenaren tegen de 10 DNS lookup limiet aanlopen, alsmede het optimaliseren van uw SPF record om altijd op de hoogte te blijven van de laatste IP adressen die uw email service providers gebruiken. PowerSPF is uw geautomatiseerde SPF flattening oplossing die uw SPF record doorzoekt om een enkele include verklaring te genereren. PowerSPF helpt u:

  • Gemakkelijk IP's en mechanismen toevoegen of verwijderen
  • Automatische update van netblokkades om ervoor te zorgen dat uw geautoriseerde IP's altijd up-to-date zijn
  • Blijf met gemak onder de 10 DNS lookup limiet
  • Verkrijg een geoptimaliseerd SPF-record met een enkele klik
  • Permerror' permanent verslaan
  • Foutloze SPF implementeren

Meld u vandaag nog aan bij PowerDMARC voor een betere bezorgbaarheid en authenticatie van e-mail, terwijl u onder de limiet van 10 DNS SPF-lookups blijft.

Als domeineigenaar moet u altijd uitkijken voor bedreigers die domain spoofing-aanvallen en phishing-aanvallen uitvoeren om uw domein of merknaam te gebruiken voor het uitvoeren van kwaadaardige activiteiten. Welke oplossing voor e-mailuitwisseling u ook gebruikt, het beschermen van uw domein tegen spoofing en impersonatie is van essentieel belang om de geloofwaardigheid van uw merk te waarborgen en het vertrouwen van uw gewaardeerde klanten te behouden. Deze blog neemt u mee door het proces van het instellen van uw DMARC record voor Office 365 gebruikers.

De afgelopen tijd hebben de meeste bedrijven de overstap gemaakt naar het gebruik van effectieve en robuuste cloudgebaseerde platforms en gehoste oplossingen voor e-mailuitwisseling, zoals Office 365. Vervolgens hebben cybercriminelen ook hun kwaadaardige technieken voor het plegen van e-mailfraude geüpgraded door de beveiligingsoplossingen die in het platform zijn geïntegreerd te slim af te zijn. Daarom heeft Microsoft de ondersteuning voor e-mailverificatieprotocollen zoals DMARC uitgebreid naar al zijn e-mailplatforms. Maar u moet weten hoe u DMARC correct implementeert voor Office 365, om de voordelen ervan volledig te benutten.

Waarom DMARC?

De eerste vraag die zou kunnen opkomen is dat, met anti-spam oplossingen en e-mail security gateways die al geïntegreerd zijn in de Office 365 suite om nep e-mails te blokkeren, waarom zou je DMARC nodig hebben voor verificatie? Dat komt omdat deze oplossingen specifiek bescherming bieden tegen inkomende phishing-e-mails die naar uw domein worden gestuurd, maar het DMARC-verificatieprotocol geeft domeineigenaren de macht om aan ontvangende e-mailservers op te geven hoe ze moeten reageren op e-mails die vanaf uw domein worden verzonden en die niet aan de verificatiecontroles voldoen.

DMARC maakt gebruik van twee standaard authenticatiepraktijken, namelijk SPF en DKIM, om e-mails op echtheid te valideren. Met een beleid dat op handhaving is ingesteld, kan DMARC een hoge mate van bescherming bieden tegen impersonatieaanvallen en direct-domain spoofing.

Heb je echt DMARC nodig als je Office 365 gebruikt?

Onder bedrijven heerst de misvatting dat een Office 365-oplossing hen beschermt tegen spam en phishing-aanvallen. In mei 2020 veroorzaakte een reeks phishingaanvallen op verschillende verzekeringsmaatschappijen in het Midden-Oosten die Office 365 gebruikten, echter aanzienlijk gegevensverlies en een ongekend aantal beveiligingsinbreuken. Dit is waarom het simpelweg vertrouwen op de geïntegreerde beveiligingsoplossingen van Microsoft en het niet implementeren van externe inspanningen voor het beschermen van uw domein een enorme fout kan zijn!

Hoewel de geïntegreerde beveiligingsoplossingen van Office 365 bescherming kunnen bieden tegen inkomende beveiligingsrisico's en phishingpogingen, moet u er nog steeds voor zorgen dat uitgaande berichten die vanuit uw eigen domein worden verzonden, effectief worden geverifieerd voordat ze in de inbox van uw klanten en partners belanden. Dit is waar DMARC in het spel komt.

Office 365 beveiligen tegen Spoofing en Impersonatie met DMARC

Beveiligingsoplossingen die worden geleverd bij de Office 365-suite fungeren als spamfilters die uw domein niet kunnen beveiligen tegen impersonatie, wat de noodzaak van DMARC onderstreept. DMARC bestaat als een DNS TXT record in de DNS van uw domein. Om DMARC voor uw domein te configureren, moet u het volgende doen:

Stap 1: Identificeer geldige e-mailbronnen voor uw domein
Stap 2: Stel SPF in voor uw domein
Stap3: DKIM instellen voor uw domein
Stap 4: Publiceer een DMARC TXT record in de DNS van uw domein

U kunt de gratis DMARC record generator van PowerDMARC gebruiken om direct een record te genereren met de juiste syntax om in uw DNS te publiceren en DMARC voor uw domein te configureren. Merk echter op dat alleen een afwijzend handhavingsbeleid u effectief kan helpen impersonatie aanvallen en domein misbruik te beperken.

Maar is het publiceren van een DMARC record voldoende? Het antwoord is nee. Dit brengt ons naar ons laatste en laatste segment, DMARC rapportering en monitoring.

5 Redenen waarom u PowerDMARC nodig heeft tijdens het gebruik van Microsoft Office365

Microsoft Office 365 biedt gebruikers een groot aantal cloud-gebaseerde diensten en oplossingen, samen met geïntegreerde anti-spam filters. Maar ondanks de verschillende voordelen, zijn dit de nadelen waarmee u te maken kunt krijgen bij het gebruik ervan vanuit een beveiligingsperspectief:

  • Geen oplossing voor het valideren van uitgaande berichten die vanuit uw domein worden verzonden
  • Geen rapportagemechanisme voor e-mails die de verificatiecontroles niet doorstaan
  • Geen zicht op uw e-mail ecosysteem
  • Geen dashboard om uw inkomende en uitgaande e-mailstroom te beheren en te controleren
  • Geen mechanisme om ervoor te zorgen dat uw SPF record altijd onder de 10 lookup limiet blijft

DMARC rapportage en monitoring met PowerDMARC

PowerDMARC integreert naadloos met Office 365 om domeineigenaren te voorzien van geavanceerde verificatie-oplossingen die bescherming bieden tegen geavanceerde social engineering aanvallen zoals BEC en direct-domain spoofing. Wanneer u zich aanmeldt bij PowerDMARC tekent u voor een multi-tenant SaaS platform dat niet alleen alle e-mail authenticatie best practices bundelt (SPF, DKIM, DMARC, MTA-STS, TLS-RPT en BIMI), maar ook een uitgebreid en diepgaand dmarc rapportage mechanisme biedt, dat volledig inzicht biedt in uw e-mail ecosysteem. DMARC rapporten op het PowerDMARC dashboard worden in twee formaten gegenereerd:

  • Geaggregeerde rapporten
  • Forensische rapporten

Wij hebben ernaar gestreefd om de authenticatie-ervaring voor u beter te maken door verschillende problemen in de industrie op te lossen. Wij zorgen voor encryptie van uw DMARC forensische rapporten en geven geaggregeerde rapporten weer in 7 verschillende weergaven voor een verbeterde gebruikerservaring en duidelijkheid. PowerDMARC helpt u bij het monitoren van e-mailstromen en mislukte verificaties, en bij het op de zwarte lijst plaatsen van schadelijke IP-adressen van over de hele wereld. Onze DMARC analyzer tool helpt u bij het correct configureren van DMARC voor uw domein, en het overschakelen van monitoring naar handhaving in een mum van tijd!