Wanneer een e-mail van de verzendende server rechtstreeks naar de ontvangende server wordt gestuurd, authenticeren SPF en DKIM (als ze correct zijn ingesteld) de e-mail normaal gesproken en valideren ze gewoonlijk effectief of de e-mail legitiem of ongeautoriseerd is. Dat is echter niet het geval als de e-mail via een tussenliggende mailserver passeert voordat deze bij de ontvanger wordt afgeleverd, zoals in het geval van doorgestuurde berichten. Deze blog is bedoeld om u mee te nemen door de impact van e-mail forwarding op DMARC authenticatie-resultaten.

Zoals we al weten, maakt DMARC gebruik van twee standaard e-mail authenticatie protocollen, namelijk SPF (Sender Policy Framework) en DKIM (DomainKeys Identified Mail), om inkomende berichten te valideren. Laten we ze in het kort bespreken om een beter begrip te krijgen van hoe ze werken voordat we verder gaan met hoe forwarding ze kan beïnvloeden.

Beleidskader afzender

SPF is in uw DNS aanwezig als een TXT record, dat alle geldige bronnen weergeeft die geautoriseerd zijn om emails van uw domein te versturen. Elke e-mail die uw domein verlaat, heeft een IP-adres dat uw server en de door uw domein gebruikte e-mail service provider identificeert en dat in uw DNS is opgenomen als een SPF record. De mailserver van de ontvanger valideert de e-mail aan de hand van uw SPF record om deze te verifiëren en markeert de e-mail als SPF pass of fail.

DomainKeys Geïdentificeerde Mail

DKIM is een standaard e-mailauthenticatieprotocol dat een cryptografische handtekening, gemaakt met een privésleutel, toekent om e-mails in de ontvangende server te valideren, waarbij de ontvanger de publieke sleutel kan opvragen bij de DNS van de afzender om de berichten te authenticeren. Net als SPF bestaat ook de DKIM publieke sleutel als een TXT record in de DNS van de domeineigenaar.

De impact van e-mail doorsturen op uw DMARC-authenticatieresultaten

Bij het doorsturen van e-mail passeert de e-mail een tussenliggende server voordat hij uiteindelijk bij de ontvangende server wordt afgeleverd. Ten eerste is het belangrijk te beseffen dat e-mail doorsturen op twee manieren kan gebeuren: e-mail kan handmatig worden doorgestuurd, wat geen invloed heeft op de verificatieresultaten, of het kan automatisch worden doorgestuurd, in welk geval de verificatieprocedure wel een klap krijgt als het domein het record voor de intermediaire verzendende bron niet in hun SPF heeft staan.

Uiteraard mislukt de SPF controle meestal tijdens het doorsturen van emails omdat het IP adres van de tussenliggende server niet overeenkomt met dat van de verzendende server, en dit nieuwe IP adres wordt meestal niet opgenomen in het SPF record van de originele server. Daarentegen heeft het doorsturen van emails meestal geen invloed op de DKIM email authenticatie, tenzij de tussenliggende server of de doorsturende entiteit bepaalde wijzigingen aanbrengt in de inhoud van het bericht.

Om DMARC authenticatie te doorstaan, moet een e-mail voldoen aan SPF of DKIM authenticatie en uitlijning. Aangezien wij weten dat SPF onvermijdelijk faalt bij het doorsturen van e-mail, zal in het geval dat de verzendende bron DKIM neutraal is en alleen op SPF vertrouwt voor validatie, de doorgestuurde e-mail bij DMARC verificatie als onwettig worden beschouwd.

De oplossing? Simpel. U dient onmiddellijk te kiezen voor volledige DMARC compliance binnen uw organisatie door alle inkomende berichten af te stemmen op en te verifiëren tegen zowel SPF als DKIM!

DMARC-naleving bereiken met PowerDMARC

Het is belangrijk op te merken dat om DMARC compliance te bereiken, emails geauthenticeerd moeten worden tegen SPF of DKIM of beide. Echter, tenzij de doorgestuurde berichten worden gevalideerd tegen DKIM, en alleen vertrouwen op SPF voor authenticatie, zal DMARC onvermijdelijk falen zoals besproken in onze vorige paragraaf. Daarom helpt PowerDMARC u volledige DMARC compliance te bereiken door e-mails effectief af te stemmen op en te authenticeren tegen zowel SPF als DKIM authenticatieprotocollen. Op deze manier, zelfs als authentieke doorgestuurde berichten SPF niet halen, kan de DKIM handtekening worden gebruikt om het als legitiem te valideren en de e-mail passeert de DMARC verificatie en belandt vervolgens in de inbox van de ontvanger.

Uitzonderlijke gevallen: DKIM mislukt en hoe op te lossen?

In bepaalde gevallen kan de doorsturende entiteit de mailbody wijzigen door aanpassingen in MIME-grenzen, implementatie van anti-virusprogramma's of hercodering van het bericht. In dergelijke gevallen faalt zowel de SPF als de DKIM authenticatie en worden legitieme emails niet afgeleverd.

In het geval dat SPF en DKIM beide falen, kan PowerDMARC dit identificeren en weergeven in onze gedetailleerde overzichten. Protocollen zoals Authenticated Received Chain kunnen door mailservers worden gebruikt om dergelijke e-mails te authenticeren. In ARC kan de header Authentication-Results worden doorgegeven aan de volgende 'hop' in de lijn van de berichtaflevering, om authenticatieproblemen tijdens het doorsturen van e-mail effectief te beperken.

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.

Meld u dus vandaag nog aan bij PowerDMARC, en bereik DMARC compliance bij uw organisatie!

 

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!

 

Mail Transfer Agent-Strict Transport Security (MTA-STS) is een nieuwe standaard die aanbieders van e-maildiensten in staat stelt Transport Layer Security (TLS) af te dwingen om SMTP-verbindingen te beveiligen, en te specificeren of de verzendende SMTP-servers moeten weigeren e-mails af te leveren bij MX-hosts die geen TLS met een betrouwbaar servercertificaat bieden. Het is bewezen dat TLS downgrade aanvallen en Man-In-The-Middle (MITM) aanvallen met succes worden tegengegaan.

Eenvoudiger gezegd is MTA-STS een internetstandaard die verbindingen tussen SMTP-mailservers beveiligt. Het meest opvallende probleem met SMTP is dat versleuteling volledig optioneel is en niet wordt afgedwongen tijdens de mailoverdracht. Daarom heeft SMTP het STARTTLS commando aangenomen om van platte tekst naar versleuteling over te gaan. Dit was een waardevolle stap om passieve aanvallen tegen te gaan, maar het aanpakken van aanvallen via actieve netwerken en MITM-aanvallen was nog steeds niet aangepakt.

Het probleem dat MTA-STS oplost is dat SMTP gebruik maakt van opportunistische versleuteling, d.w.z. als er geen versleuteld communicatiekanaal tot stand kan worden gebracht, valt de verbinding terug op onversleutelde tekst, waardoor MITM- en downgrade-aanvallen op afstand worden gehouden.

Wat is een TLS Downgrade aanval?

Zoals bekend werd SMTP niet geleverd met een encryptieprotocol en moest encryptie later worden toegevoegd om de veiligheid van het bestaande protocol te verbeteren door het STARTTLS commando toe te voegen. Indien de client versleuteling (TLS) ondersteunt, zal hij het STARTTLS commando begrijpen en een TLS uitwisseling starten voordat de e-mail wordt verzonden om er zeker van te zijn dat deze is versleuteld. Als de client TLS niet kent, negeert hij het STARTTLS-commando en verzendt hij de e-mail zonder opmaak.

Aangezien de versleuteling in het SMTP-protocol moest worden ingebouwd, moet de upgrade voor versleutelde aflevering berusten op een STARTTLS-commando dat in klare tekst wordt verstuurd. Een MITM-aanvaller kan gemakkelijk misbruik maken van deze mogelijkheid door een downgrade-aanval uit te voeren op de SMTP-verbinding door te knoeien met het upgrade-commando. De aanvaller vervangt eenvoudigweg de STARTTLS door een "garbage string" die de client niet kan identificeren. Daardoor valt de client gemakkelijk terug op het verzenden van de e-mail in platte tekst.

De aanvaller vervangt het commando meestal door de garbage string met hetzelfde aantal karakters, in plaats van het weg te gooien, omdat de pakketgrootte dan behouden blijft en het dus makkelijker is. Met de acht letters in de garbage string in het optie commando kunnen we detecteren en identificeren dat een TLS downgrade aanval is uitgevoerd door een cybercrimineel, en kunnen we de prevalentie meten.

Kortom, een downgrade-aanval wordt vaak uitgevoerd als onderdeel van een MITM-aanval, om een pad te creëren voor het mogelijk maken van een cryptografische aanval die niet mogelijk zou zijn in het geval van een verbinding die is versleuteld over de laatste versie van het TLS-protocol, door het STARTTLS-commando te vervangen of te verwijderen en de communicatie terug te draaien naar klare tekst.

Hoewel het mogelijk is om TLS af te dwingen voor client-naar-server communicatie, omdat we voor die verbindingen weten dat de apps en de server het ondersteunen. Echter, voor server-naar-server communicatie moeten we fail open om legacy servers toe te staan emails te versturen. De kern van het probleem is dat we geen idee hebben of de server aan de andere kant TLS ondersteunt of niet. MTA-STS staat servers toe om aan te geven dat ze TLS ondersteunen, waardoor ze fail close kunnen gaan (d.w.z. de email niet versturen) als de upgrade onderhandeling niet plaatsvindt, waardoor het onmogelijk wordt voor een TLS downgrade aanval om plaats te vinden.

tls rapportage

Hoe schiet MTA-STS te hulp?

MTA-STS werkt door het verhogen van de EXO of Exchange Online e-mail beveiliging en is de ultieme oplossing voor een breed scala van SMTP beveiligings nadelen en problemen. Het lost problemen op in SMTP beveiliging zoals gebrek aan ondersteuning voor veilige protocollen, verlopen TLS certificaten, en certificaten die niet zijn uitgegeven door betrouwbare derde partijen.

Terwijl mailservers overgaan tot het verzenden van e-mails, is de SMTP-verbinding kwetsbaar voor cryptografische aanvallen, zoals downgrade-aanvallen en MITM. Downgrade-aanvallen kunnen worden uitgevoerd door de STARTTLS-respons te verwijderen, waardoor het bericht in ongecodeerde tekst wordt afgeleverd. MITM-aanvallen kunnen ook worden uitgevoerd door het bericht via een onveilige verbinding om te leiden naar een indringer op de server. Met MTA-STS kan uw domein een beleid publiceren dat het verzenden van een e-mail met versleutelde TLS verplicht stelt. Als om een of andere reden de ontvangende server geen STARTTLS blijkt te ondersteunen, zal de e-mail helemaal niet worden verzonden. Dit maakt het onmogelijk om een TLS downgrade aanval uit te voeren.

De laatste tijd hebben de meeste leveranciers van e-maildiensten MTA-STS ingevoerd, waardoor de verbindingen tussen de servers veiliger zijn geworden en versleuteld via het TLS-protocol van een bijgewerkte versie, waardoor TLS-downgrade-aanvallen met succes worden tegengegaan en de mazen in de servercommunicatie worden gedicht.

PowerDMARC biedt u snelle en eenvoudige hosted MTA-STS diensten die uw leven een stuk gemakkelijker maken omdat wij zorg dragen voor alle specificaties die MTA-STS vereist tijdens en na de implementatie, zoals een HTTPS-enabled web server met een geldig certificaat, DNS records, en voortdurend onderhoud. PowerDMARC beheert dit alles volledig op de achtergrond, zodat u er, nadat wij u hebben geholpen met het opzetten, zelfs nooit meer aan hoeft te denken!

Met de hulp van PowerDMARC, kunt u Hosted MTA-STS inzetten in uw organisatie zonder gedoe en in een zeer snel tempo, met de hulp waarvan u kunt afdwingen dat emails naar uw domein worden verzonden over een TLS versleutelde verbinding, waardoor uw verbinding veilig is en TLS downgrade aanvallen op afstand worden gehouden.

 

Een algemeen bekende internetnorm die de beveiliging van verbindingen tussen SMTP-servers (Simple Mail Transfer Protocol) vergemakkelijkt door deze te verbeteren, is de SMTP Mail Transfer Agent-Strict Transport Security (MTA-STS).

In 1982 werd SMTP voor het eerst gespecificeerd en het bevatte geen mechanisme om beveiliging te bieden op het transportniveau om de communicatie tussen de mail transfer agents te beveiligen. In 1999 werd echter het STARTTLS-commando aan SMTP toegevoegd, dat op zijn beurt de versleuteling van e-mail tussen de servers ondersteunde en de mogelijkheid bood om een niet-veilige verbinding om te zetten in een veilige verbinding die is versleuteld met gebruikmaking van het TLS-protocol.

In dat geval vraag je je vast af: als SMTP STARTTLS gebruikt om verbindingen tussen servers te beveiligen, waarom was de overstap naar MTA-STS dan nodig? Laten we daar in het volgende deel van deze blog op ingaan!

De noodzaak om over te schakelen op MTA-STS

STARTTLS was niet perfect en slaagde er niet in twee grote problemen aan te pakken: het eerste is dat het een optionele maatregel is, waardoor STARTTLS er niet in slaagt man-in-the-middle (MITM)-aanvallen te voorkomen. Dit komt doordat een MITM-aanvaller gemakkelijk een verbinding kan wijzigen en kan voorkomen dat de encryptie-update plaatsvindt. Het tweede probleem is dat, zelfs als STARTTLS is geïmplementeerd, er geen manier is om de identiteit van de verzendende server te verifiëren, aangezien SMTP-mailservers geen certificaten valideren.

Hoewel de meeste uitgaande e-mails tegenwoordig worden beveiligd met TLS-encryptie (Transport Layer Security), een industrienorm die zelfs door e-mail voor consumenten wordt gehanteerd, kunnen aanvallers uw e-mail nog steeds belemmeren en ermee knoeien nog voordat deze wordt versleuteld. Als u e-mailt om uw e-mails over een beveiligde verbinding te transporteren, kunnen uw gegevens worden gecompromitteerd of zelfs worden gewijzigd en gemanipuleerd door een cyberaanvaller. Hier komt MTA-STS om de hoek kijken en lost dit probleem op door een veilige doorvoer van uw e-mails te garanderen en MITM-aanvallen met succes te onderdrukken. Bovendien slaan MTA's MTA-STS-beleidsbestanden op, waardoor het voor aanvallers moeilijker wordt om een DNS-spoofingaanval uit te voeren.

MTA-STS biedt bescherming tegen :

  • Aanvallen op downgrades
  • Man-In-The-Middle (MITM) -aanvallen
  • Het lost meerdere SMTP beveiligingsproblemen op, waaronder verlopen TLS certificaten en gebrek aan ondersteuning voor veilige protocollen.

Hoe werkt MTA-STS?

Het MTA-STS protocol wordt toegepast door een DNS record dat specificeert dat een mailserver een beleidsbestand kan ophalen van een specifiek subdomein. Dit beleidsbestand wordt opgehaald via HTTPS en geauthenticeerd met certificaten, samen met de lijst met namen van de mailservers van de ontvangers. De implementatie van MTA-STS is eenvoudiger aan de kant van de ontvanger dan aan de kant van de zender, omdat het door de mailserversoftware moet worden ondersteund. Hoewel sommige mailservers MTA-STS ondersteunen, zoals PostFix, doen ze dat niet allemaal.

gehost MTA STS

Grote aanbieders van e-maildiensten, zoals Microsoft, Oath en Google, ondersteunen MTA-STS. Google's Gmail heeft het MTA-STS-beleid de afgelopen tijd al overgenomen. MTA-STS heeft de nadelen van de beveiliging van e-mailverbindingen weggenomen door het proces van het beveiligen van verbindingen eenvoudig en toegankelijk te maken voor ondersteunde mailservers.

Verbindingen van de gebruikers naar de mailservers worden gewoonlijk beschermd en versleuteld met het TLS-protocol, maar desondanks bestond er vóór de invoering van MTA-STS een gebrek aan veiligheid in de verbindingen tussen de mailservers. Nu het bewustzijn over e-mailbeveiliging de laatste tijd toeneemt en grote mailproviders over de hele wereld dit ondersteunen, wordt verwacht dat de meerderheid van de serververbindingen in de nabije toekomst versleuteld zal zijn. Bovendien zorgt MTA-STS er effectief voor dat cybercriminelen op de netwerken niet in staat zijn e-mailinhoud te lezen.

Eenvoudige en snelle implementatie van gehoste MTA-STS-diensten door PowerDMARC

MTA-STS vereist een HTTPS-geschikte webserver met een geldig certificaat, DNS records, en voortdurend onderhoud. PowerDMARC maakt uw leven een stuk eenvoudiger door dat allemaal voor u te regelen, volledig op de achtergrond. Zodra wij u helpen het op te zetten, hoeft u er zelfs nooit meer aan te denken.

Met behulp van PowerDMARC, kunt u Hosted MTA-STS implementeren in uw organisatie zonder gedoe en in een zeer snel tempo, met de hulp waarvan u kunt afdwingen dat e-mails worden verzonden naar uw domein over een TLS versleutelde verbinding, waardoor uw verbinding veilig is en MITM-aanvallen op afstand worden gehouden.

 

 

Met de voortdurende toename van phishing-aanvallen, e-mail- en domein-spoofingaanvallen, BEC en andere frauduleuze activiteiten van cybercriminelen is een extra laag beveiliging en e-mailbeveiliging altijd een goed idee! Ontvangers van e-mails worden door de toename van cyberaanvallen steeds wantrouwiger ten aanzien van de berichten die in hun inbox belanden. De oplossing? Een veelzijdig pakket voor e-mailbeveiliging, inclusief BIMI-implementatie.

Uit een recente enquête van beveiligingsprofessionals in de VS is gebleken dat 60% van de Amerikaanse burgers beweert het slachtoffer te zijn geworden van een cyberzwendel of iemand in zijn naaste omgeving kent die er het slachtoffer van is geworden. Om hun e-mails van een extra beschermingslaag te voorzien, moeten bedrijven daarom een nieuwe standaard zoals Brand Indicators for Message Identification (BIMI) implementeren, omdat deze belooft het consumentenvertrouwen naar een hoger niveau te tillen.

Wat is BIMI?

BIMI staat voor Brand Indicators for Message Identification, en is een nieuw gevormde standaard voor e-mailverificatie waarbij het logo van uw merk wordt aangebracht op alle door u geautoriseerde e-mails. Dit lijkt misschien een kleine stap, maar visuele verificatie kan de geloofwaardigheid van uw merk vergroten doordat ontvangers de e-mails die u vanuit uw zakelijke e-maildomein verstuurt, kunnen herkennen en vertrouwen.

U vraagt zich misschien af, als u al DMARC geïmplementeerd heeft in uw organisatie, dat gebruik maakt van SPF en DKIM authenticatie standaarden, heeft u dan BIMI nog wel nodig? Laten we in het kort bespreken hoe elk van deze standaarden functioneert om inkomende emails te authenticeren:

  • SPF verifieert uw emails om de mailservers te identificeren die emails mogen versturen van uw email domein, vermeld in het SPF record.
  • DKIM authenticeert e-mails door er een digitale handtekening aan toe te voegen, zodat de ontvanger kan controleren of een e-mail die beweert van een bepaald domein afkomstig te zijn, inderdaad door de eigenaar van dat domein is geautoriseerd.
  • DMARC specificeert aan inbox providers hoe te reageren op emails die SPF en DKIM email authenticatie niet halen.
  •  BIMI brengt het logo van uw merk aan op de e-mails die u naar uw werknemers, partners en klanten stuurt, zodat zij onmiddellijk kunnen zien dat deze van een geautoriseerde bron afkomstig zijn.

Uit de bovenstaande bespreking blijkt dan ook duidelijk dat van alle e-mailauthenticatieprotocollen BIMI de enige norm is die ruimte biedt voor visuele identificatie, zodat e-mailontvangers een visuele aanwijzing krijgen om de e-mailbron te identificeren en de authenticiteit ervan te herkennen.

PowerDMARC Logo Mobiel

BIMI-implementatie - een beknopte gids

Hoewel BIMI een verificatiestandaard in opkomst en nog in ontwikkeling is, is hij nog betrekkelijk nieuw. Tot nu toe heeft alleen Yahoo! Mail de technologie officieel overgenomen. Om deze reden garandeert BIMI niet de weergave van uw merklogo, omdat het alleen werkt met ondersteunde e-mailclients. Er zijn een paar essentiële stappen te volgen, voorafgaand aan BIMI implementatie, welke zijn:

  • Om BIMI in uw organisatie te implementeren, moet uw domein DMARC-geauthenticeerd zijn op een beleidsniveau van handhaving, d.w.z. weigeren of in quarantaine plaatsen.
  • U moet een SVG bestand van het logo van uw merk volgens de BIMI-vereisten naar een server uploaden, zodat het van overal toegankelijk is.
  • U moet een BIMI record aanmaken, dat net als een DMARC record in wezen een string is die bestaat uit meerdere tags, gescheiden door puntkomma's.
  • U moet toegang hebben tot de DNS van uw domein om dit nieuwe BIMI-record te publiceren.
  • Het is een vrij nuttige praktijk om de geldigheid van uw BIMI record te controleren nadat het in uw DNS is gepubliceerd.

Hoe kan de implementatie van BIMI voordelig zijn voor uw bedrijf?

BIMI is een e-mailverificatieprotocol dat visuele identificatie toepast om e-mailontvangers te helpen uw merk in de inbox te herkennen en te vertrouwen. Dit vertrouwen voorkomt dat klanten en partners zich afmelden voor uw diensten en houdt ook spamklachten op afstand, wat vervolgens kan leiden tot een boost in e-mail deliverability.

Zonder BIMI wordt door e-mailclients een generiek placeholder-logo met merkinitialen weergegeven. Hierdoor kan het voor de ontvanger moeilijk zijn om uw merk te herkennen zonder de merknaam te gebruiken. Als BIMI echter is geïmplementeerd, wordt het merklogo naast uw e-mailbericht weergegeven, waardoor de merkbekendheid toeneemt.

Bovendien is het een extra laag e-mailbeveiliging tegen domain spoofing attacks, phishing-aanvallen en andere pogingen tot imitatie, aangezien ontvangers meer op hun hoede zouden zijn voor cybercriminelen die zich voordoen als u.

Bovendien kunt u met BIMI uw merk op de markt brengen. Ja, u hoort het goed! Soms hebben ontvangers niet veel tijd, en is uw onderwerpregel misschien niet overtuigend genoeg om er op dat moment op te klikken. Hoe dan ook, uw ontvangers zullen uw afzenderadres, onderwerpregel en preheadertekst in verband brengen met uw logo, waardoor uw merk verder wordt opgebouwd.

Tot slot heeft de implementatie van BIMI ook een zeer positieve impact op uw e-mail deliverability rate! Voor mailbox providers die BIMI ondersteunen, voegt het een extra laag van e-mailauthenticatie toe aan uw berichten, waardoor de kans toeneemt dat ze uw e-mail sneller afleveren. Bovendien kunnen uw e-mailontvangers uw merk visueel identificeren en herkennen via het weergegeven logo, waardoor de kans kleiner wordt dat ze uw e-mail als spam markeren.

Vergemakkelijk uw BIMI-implementatieproces met PowerBIMI

Met PowerBIMI maken we BIMI record publicatie zeer snel en eenvoudig voor u! Het enige wat u moet doen is uw SVG afbeelding uploaden, wij zullen het veilig hosten en u onmiddellijk een DNS record bezorgen, zodat u het in uw DNS kunt publiceren. Wij nemen de pijn van het hosten van het beeld en het beveiligen ervan van uw schouder.

Met PowerBIMI kunt u uw afbeelding bijwerken, verwijderen of wijzigingen aanbrengen, op elk gewenst moment, zonder dat u uw DNS records opnieuw hoeft bij te werken. PowerBIMI biedt u een zeer snelle en eenvoudige implementatieprocedure met één klik om uw logo te uploaden en met succes over te schakelen op BIMI-authenticatie, door het toe te voegen als onderdeel van uw e-mailbeveiligingspakket nadat u zich hebt aangemeld voor een gratis BIMI-record.