När ett e-postmeddelande skickas från den sändande servern autentiserar SPF och DKIM (om det är korrekt konfigurerat) e-postmeddelandet normalt och validerar det vanligtvis effektivt som legitimt eller obehörigt. Så är dock inte fallet om e-postmeddelandet passerar via en mellanliggande e-postserver innan det levereras till mottagaren, till exempel vid vidarebefordrade meddelanden. Den här bloggen är avsedd att ta dig igenom effekten av vidarebefordran av e-post på DMARC-autentiseringsresultat.

Som vi redan vet använder DMARC två standardprotokoll för e-postautentisering, nämligen SPF (Sender Policy Framework) och DKIM (DomainKeys Identified Mail), för att validera inkommande meddelanden. Låt oss diskutera dem i korthet för att få en bättre förståelse för hur de fungerar innan vi hoppar vidare till hur vidarebefordran kan påverka dem.

Policyram för avsändare

SPF finns i din DNS som en TXT-post och visar alla giltiga källor som har behörighet att skicka e-post från din domän. Varje e-postmeddelande som lämnar din domän har en IP-adress som identifierar din server och den e-postleverantör som används av din domän och som är värvad i din DNS som en SPF-post. Mottagarens e-postserver validerar e-postmeddelandet mot din SPF-post för att autentisera den och markerar därför e-postmeddelandet som SPF-pass eller misslyckas.

Domäntangenter identifierad e-post

DKIM är ett standardprotokoll för e-postautentisering som tilldelar en kryptografisk signatur, skapad med en privat nyckel, för att validera e-postmeddelanden på den mottagande servern, där mottagaren kan hämta den offentliga nyckeln från avsändarens DNS för att autentisera meddelandena. Precis som SPF finns DKIM-den offentliga nyckeln också som en TXT-post i domänägarens DNS.

Effekten av vidarebefordran av e-post på dina DMARC-autentiseringsresultat

Under vidarebefordran av e-post skickas e-postmeddelandet via en mellanliggande server innan det slutligen levereras till den mottagande servern. För det första är det viktigt att inse att vidarebefordran av e-post kan göras på två sätt - antingen kan e-postmeddelanden vidarebefordrasmanuellt , vilket inte påverkar autentiseringsresultaten, eller det kan vidarebefordrasautomatiskt , i vilket fall autentiseringsproceduren tar en träff om domänen inte har posten för den mellanliggande sändande källan i deras SPF.

Naturligtvis misslyckas vanligtvis SPF-kontrollen under vidarebefordran av e-post eftersom IP-adressen för mellanliggande server inte matchar den sändande serverns, och den nya IP-adressen ingår vanligtvis inte i den ursprungliga serverns SPF-post. Tvärtom påverkar vidarebefordran av e-postmeddelanden vanligtvis inte DKIM-e-postautentisering, såvida inte mellanhandsservern eller vidarespedyrenheten gör vissa ändringar i meddelandets innehåll.

Observera att för att ett e-postmeddelande ska kunna skicka DMARC-autentisering måste e-postmeddelandet skicka antingen SPF- eller DKIM-autentisering och justering. Eftersom vi vet att SPF oundvikligen misslyckas under vidarebefordran av e-post, om den sändande källan är DKIM-neutral och enbart förlitar sig på SPF för validering, kommer den vidarebefordrade e-postmeddelandet att göras olagligt under DMARC-autentisering.

Lösningen? Enkel. Du bör omedelbart välja fullständig DMARC-efterlevnad hos din organisation genom att justera och autentisera alla inkommande meddelanden mot både SPF och DKIM!

Uppnå DMARC-överensstämmelse med PowerDMARC

Det är viktigt att notera att för att uppnå DMARC-efterlevnad måste e-postmeddelanden autentiseras mot antingen SPF eller DKIM eller båda. Men om inte de vidarebefordrade meddelandena valideras mot DKIM och endast förlitar sig på SPF för autentisering, kommer DMARC oundvikligen att misslyckas som diskuterats i vårt tidigare avsnitt. Därför hjälper PowerDMARC dig att uppnå fullständig DMARC-efterlevnad genom att effektivt justera och autentisera e-postmeddelanden mot både SPF- och DKIM-autentiseringsprotokoll. På detta sätt, även om autentiska vidarebefordrade meddelanden misslyckas SPF, kan DKIM-signaturen användas för att validera den som legitim och e-postmeddelandet skickar DMARC-autentisering och landar sedan i mottagarens inkorg.

Undantagsfall: DKIM Misslyckas och hur man löser det?

I vissa fall kan den vidarebefordrande entiteten ändra posttexten genom att göra justeringar i MIME-gränser,implementering av antivirusprogram eller kodning av meddelandet igen. I sådana fall misslyckas både SPF- och DKIM-autentisering och legitima e-postmeddelanden levereras inte.

Om både SPF och DKIM misslyckas kan PowerDMARC identifiera och visa att i våra detaljerade aggregerade vyer och protokoll som Autentiserad mottagen kedja kan utnyttjas av e-postservrar för att autentisera sådana e-postmeddelanden. I ARC kan autentiseringsresultathuvudet överföras till nästa hopp i raden för meddelandeleveransen, för att effektivt minska autentiseringsproblemen vid vidarebefordran av e-post.

Om ett vidarebefordrat meddelande, när mottagarens e-postserver får ett meddelande som hade misslyckats med DMARC-autentisering, försöker den validera e-postmeddelandet en andra gång, mot den autentiserade mottagna kedjan för e-postmeddelandet genom att extrahera ARC-autentiseringsresultaten för det första hoppet, för att kontrollera om det validerades för att vara legitimt innan mellanhandsservern vidarebefordrade det till den mottagande servern.

registrera dig med PowerDMARC idag och uppnå DMARC-efterlevnad på din organisation!

 

ARC eller Autentiserad mottagen kedja är ett e-postautentiseringssystem som visar ett e-postmeddelandes autentiseringsbedömning varje steg på vägen, under hela hanteringen. I enklare termer kan kedjan Autentiserad mottagen kallas en " depåkedja" för e-postmeddelanden som gör det möjligt för varje entitet som hanterar meddelandena att effektivt se alla entiteter som tidigare hanterade den. Som ett relativt nytt protokoll publicerat och dokumenterat som "Experimentellt" i RFC 8617 i juli 2019 gör ARC det möjligt för den mottagande servern att validera e-postmeddelanden även när SPF och DKIM blir ogiltiga av en mellanliggande server.

Hur kan autentiserad mottagen kedjehjälp?

Som vi redan vet tillåter DMARC att ett e-postmeddelande autentiseras mot SPF- och DKIM-e-postautentiseringsstandarderna, vilket anger för mottagaren hur man hanterar e-postmeddelanden som misslyckas eller passerar autentisering. Men om du implementerar DMARC-verkställighet på din organisation till en strikt DMARC-policy finns det chanser att även legitima e-postmeddelanden som de som skickas via en e-postlista eller en vidarebefordrare kan misslyckas med autentisering och inte levereras till mottagaren! Autentiserad mottagen kedja hjälper till att minska problemet effektivt. Låt oss lära oss hur i följande avsnitt:

Situationer där ARC kan hjälpa

  • E-postlistor 

Som medlem i en e-postlista har du befogenhet att skicka meddelanden till alla medlemmar i listan på en gång genom att adressera själva e-postlistan. Den mottagande adressen vidarebefordrar sedan meddelandet till alla listmedlemmar. I den aktuella situationen kan DMARC inte validera dessa typer av meddelanden och autentiseringen misslyckas trots att e-postmeddelandet har skickats från en legitim källa! Detta beror på att SPF bryts när ett meddelande vidarebefordras. Eftersom e-postlistan ofta fortsätter att innehålla extra information i e-posttexten kan DKIM-signaturen också ogiltigförklaras på grund av ändringar i e-postinnehållet.

  • Vidarebefordra meddelanden 

När det finns ett indirekt e-postflöde, till exempel att du får ett e-postmeddelande från en mellanliggande server och inte direkt från den sändande servern som i fallet med vidarebefordrade meddelanden, bryts SPF och din e-post automatiskt misslyckas DMARC-autentisering. Vissa vidarebefordrare ändrar också e-postinnehållet, varför DKIM-signaturerna också ogiltigförklaras.

 

 

I sådana situationer kommer Autentiserad mottagen kedja till undsättning! Hur? Låt oss ta reda på:

Hur fungerar ARC?

I de situationer som anges ovan hade vidarebefordrarna ursprungligen fått e-postmeddelanden som hade validerats mot DMARC-installationen, från en auktoriserad källa. Autentiserad mottagen kedja utvecklas som en specifikation som gör att huvudet Autentiseringsresultat kan vidarebefordras till nästa "hopp" på raden för meddelandeleveransen.

Om ett vidarebefordrat meddelande, när mottagarens e-postserver får ett meddelande som hade misslyckats med DMARC-autentisering, försöker den validera e-postmeddelandet en andra gång, mot den autentiserade mottagna kedjan för e-postmeddelandet genom att extrahera ARC-autentiseringsresultaten för det första hoppet, för att kontrollera om det validerades för att vara legitimt innan mellanhandsservern vidarebefordrade det till den mottagande servern.

På grundval av den information som extraheras beslutar mottagaren om ARC-resultaten ska åsidosätta DMARC-policyn och därmed skicka e-postmeddelandet som autentiskt och giltigt och låta det levereras normalt i mottagarens inkorg.

Med ARC-implementering kan mottagaren effektivt autentisera e-postmeddelandet med hjälp av följande information:

  • Autentiseringsresultaten som bevittnas av mellanservern, tillsammans med hela historiken för SPF- och DKIM-valideringsresultat i det första hoppet.
  • Nödvändig information för att autentisera skickade data.
  • Information för att länka den skickade signaturen till mellanhandsservern så att e-postmeddelandet valideras på den mottagande servern även om mellanhanden ändrar innehållet, så länge de vidarebefordrar en ny och giltig DKIM-signatur.

Implementering av autentiserad mottagen kedja

ARC definierar tre nya e-postrubriker:

  • ARC-Authentication-Results (AAR): Först bland e-posthuvudena är AAR som kapslar in autentiseringsresultaten som SPF, DKIM och DMARC.

  • ARC-Seal (AS) – AS är en enklare version av en DKIM-signatur som innehåller information om autentiseringshuvudresultat och ARC-signatur.

  • ARC-Message-Signature (AMS) – AMS liknar också en DKIM-signatur, som tar en bild av meddelandehuvudet som innehåller allt utom ARC-Seal-rubriker som fälten Till: och Från: fält, ämne och hela meddelandets brödtext.

Steg som utförs av mellanservern för att signera en ändring:

Steg 1: Servern kopierar fältet Autentiseringsresultat till ett nytt AAR-fält och föregår det med meddelandet

Steg 2: servern formulerar AMS för meddelandet (med AAR) och förbereder det till meddelandet.

Steg 3: Servern formulerar AS för de tidigare ARC-Seal-rubrikerna och lägger till det i meddelandet.

Slutligen, för att validera den autentiserade mottagna kedjan och ta reda på om ett vidarebefordrat meddelande är legitimt eller inte, validerar mottagaren kedjan eller ARC Seal-headers och den senaste ARC-Message-Signature. Om ARC-rubrikerna har ändrats på något sätt misslyckas E-postmeddelandet följaktligen DKIM-autentisering. Men om alla e-postservrar som är involverade i överföringen av meddelandet korrekt signerar och överför ARC bevarar e-postmeddelandet DKIM-autentiseringsresultaten och skickar DMARC-autentisering, vilket resulterar i framgångsrik leverans av meddelandet i mottagarens inkorg!

ARC-implementering säkerhetskopierar och stöder DMARC-implementering i organisationer för att se till att varje legitim e-post autentiseras utan ett enda förfall. Registrera dig för din kostnadsfria DMARC-provperiod idag!

 

Mail Transfer Agent-Strict Transport Security (MTA-STS) är en ny standard som gör det möjligt för e-posttjänstleverantörer med möjlighet att genomdriva Transport Layer Security (TLS) för att säkra SMTP-anslutningar och för att ange om de sändande SMTP-servrarna ska vägra att leverera e-postmeddelanden till MX-värdar som inte erbjuder TLS med ett tillförlitligt servercertifikat. Det har visat sig framgångsrikt mildra TLS nedgraderingsattacker och Man-In-The-Middle (MITM) attacker.

Enklare uttryckt är MTA-STS en internetstandard som säkrar anslutningar mellan SMTP-e-postservrar. Det mest framträdande problemet med SMTP är att kryptering är helt valfritt och inte tillämpas under e-postöverföring. Det är därför SMTP antog STARTTLS-kommandot för att uppgradera från klartext till kryptering. Detta var ett värdefullt steg mot att mildra passiva attacker, men att ta itu med attacker via aktiva nätverk och MITM-attacker förblev fortfarande oadresserat.

Därför är problemet MTA-STS löser att SMTP använder opportunistisk kryptering, det vill säga om en krypterad kommunikationskanal inte kan upprättas faller anslutningen tillbaka till klartext och därmed håller MITM och nedgraderar attacker i schack.

Vad är en TLS-nedgraderingsattack?

Som vi redan vet kom SMTP inte med ett krypteringsprotokoll och kryptering måste eftermonteras senare för att förbättra säkerheten för det befintliga protokollet genom att lägga till STARTTLS-kommandot. Om klienten stöder kryptering (TLS) kommer den att förstå STARTTLS-verbet och initierar ett TLS-utbyte innan e-postmeddelandet skickas för att säkerställa att det är krypterat. Om klienten inte känner till TLS ignorerar den helt enkelt STARTTLS-kommandot och skickar e-postmeddelandet i klartext.

Eftersom kryptering måste eftermonteras till SMTP-protokoll måste uppgraderingen för krypterad leverans därför förlita sig på ett STARTTLS-kommando som skickas med klartext. En MITM-angripare kan enkelt utnyttja den här funktionen genom att utföra en nedgraderingsattack på SMTP-anslutningen genom att manipulera uppgraderingskommandot. Angriparen ersatte helt enkelt STARTTLS med en skräpsträng som klienten inte kan identifiera. Därför faller klienten lätt tillbaka till att skicka e-postmeddelandet i klartext.

Angriparen ersätter vanligtvis kommandot med skräpsträngen som innehåller samma antal tecken, i stället för att kasta ut det, eftersom det bevarar paketstorleken och därför gör det enklare. De åtta bokstäverna i skräpsträngen i alternativkommandot gör det möjligt för oss att upptäcka och identifiera att en TLS-nedgraderingsattack har utförts av en cyberbrottslig, och vi kan mäta dess prevalens.

Kort sagt, en nedgraderingsattack startas ofta som en del av en MITM-attack, för att skapa en väg för att aktivera en kryptografisk attack som inte skulle vara möjlig i händelse av en anslutning som krypteras över den senaste versionen av TLS-protokollet, genom att ersätta eller ta bort STARTTLS-kommandot och rulla tillbaka kommunikationen till klartext.

Även om det är möjligt att genomdriva TLS för kommunikation mellan klienter och servrar, som för de anslutningar vi vet att apparna och servern stöder det. Men för server-till-server-kommunikation måste vi misslyckas öppna för att tillåta äldre servrar att skicka e-postmeddelanden. Kruxet med problemet är att vi inte har någon aning om servern på andra sidan stöder TLS eller inte. MTA-STS tillåter servrar att indikera att de stöder TLS, vilket gör det möjligt för dem att misslyckas nära (dvs. inte skicka e-postmeddelandet) om uppgraderingsförhandlingen inte äger rum, vilket gör det omöjligt för en TLS-nedgraderingsattack att äga rum.

tls rapportering

Hur kommer MTA-STS till undsättning?

MTA-STS fungerar genom att öka EXO- eller Exchange Online-e-postsäkerheten och är den ultimata lösningen på ett brett utbud av SMTP-säkerhets nackdelar och problem. Den löser problem i SMTP-säkerhet, till exempel brist på stöd för säkra protokoll, utgångna TLS-certifikat och certifikat som inte utfärdas av pålitliga tredje parter.

När e-postservrar fortsätter att skicka ut e-postmeddelanden är SMTP-anslutningen sårbar för kryptografiska attacker som nedgraderingsattacker och MITM. Nedgraderingsattacker kan startas genom att TA BORT STARTTLS-svaret och därmed leverera meddelandet i klartext. På samma sätt kan MITM-attacker också startas genom att omdirigera meddelandet till en serverintrångare över en osäker anslutning. MTA-STS gör det möjligt för din domän att publicera en policy som gör det obligatoriskt att skicka ett e-postmeddelande med krypterad TLS. Om den mottagande servern av någon anledning inte har stöd för STARTTLS skickas inte e-postmeddelandet alls. Detta gör det omöjligt att starta en TLS-nedgraderingsattack.

På senare tid har majoriteten av e-posttjänstleverantörer antagit MTA-STS och därigenom gjort anslutningar mellan servrar säkrare och krypterade via TLS-protokollet i en uppdaterad version, vilket framgångsrikt mildrar TLS-nedgraderingsattacker och upphäver kryphålen i serverkommunikationen.

PowerDMARC ger dig snabba och enkla MTA-STS-tjänster som gör ditt liv mycket enklare eftersom vi tar hand om alla specifikationer som krävs av MTA-STS under och efter implementeringen, till exempel en HTTPS-aktiverad webbserver med ett giltigt certifikat, DNS-poster och konstant underhåll. PowerDMARC hanterar allt detta helt i bakgrunden så att när vi hjälper dig att ställa in det behöver du aldrig ens tänka på det igen!

Med hjälp av PowerDMARC kan du distribuera Värdbaserad MTA-STS i din organisation utan krångel och i mycket snabb takt, med hjälp av vilken du kan genomdriva e-postmeddelanden som ska skickas till din domän via en TLS-krypterad anslutning, vilket gör din anslutning säker och håller TLS-nedgraderingsattacker i schack.

 

En allmänt känd internetstandard som underlättar genom att förbättra säkerheten för anslutningar mellan SMTP-servrar (Simple Mail Transfer Protocol) är SMTP Mail Transfer Agent-Strict Transport Security (MTA-STS).

År 1982 specificerades FÖRST SMTP och innehöll ingen mekanism för att tillhandahålla säkerhet på transportnivå för att säkra kommunikationen mellan postöverföringsombuden. Men 1999 lades STARTTLS-kommandot till SMTP som i sin tur stödde kryptering av e-postmeddelanden mellan servrarna, vilket ger möjlighet att konvertera en icke-säker anslutning till en säker som krypteras med TLS-protokoll.

I så fall måste du undra att om SMTP antog STARTTLS för att säkra anslutningar mellan servrar, varför krävdes övergången till MTA-STS? Låt oss hoppa in i det i följande avsnitt av den här bloggen!

Behovet av att byta till MTA-STS

STARTTLS var inte perfekt, och det misslyckades med att ta itu med två stora problem: det första är att det är en valfri åtgärd, därför misslyckas STARTTLS med att förhindra MITM-attacker (man-in-the-middle). Detta beror på att en MITM-angripare enkelt kan ändra en anslutning och förhindra att krypteringsuppdateringen sker. Det andra problemet med det är att även om STARTTLS implementeras finns det inget sätt att autentisera den sändande serverns identitet eftersom SMTP-e-postservrar inte validerar certifikat.

Medan de flesta utgående e-postmeddelanden idag är säkrade med TLS-kryptering (Transport Layer Security), en branschstandard som antagits även av konsumentmeddelande, kan angripare fortfarande blockera och manipulera din e-post redan innan den krypteras. Om du skickar e-post för att transportera dina e-postmeddelanden via en säker anslutning kan dina data äventyras eller till och med ändras och manipuleras av en cyberanfallare. Här kliver MTA-STS in och åtgärdar problemet, garanterar säker transitering för dina e-postmeddelanden samt framgångsrikt mildrar MITM-attacker. Dessutom lagrar MTA-STS-principfiler, vilket gör det svårare för angripare att starta en DNS-förfalskningsattack.

MTA-STS erbjuder skydd mot:

  • Nedgradera attacker
  • Man-in-the-Middle (MITM) attacker
  • Det löser flera SMTP-säkerhetsproblem, inklusive utgångna TLS-certifikat och brist på stöd för säkra protokoll.

Hur fungerar MTA-STS?

MTA-STS-protokollet distribueras genom att ha en DNS-post som anger att en e-postserver kan hämta en principfil från en viss underdomän. Den här principfilen hämtas via HTTPS och autentiseras med certifikat, tillsammans med listan med namn på mottagarnas e-postservrar. Implementering av MTA-STS är enklare från mottagarens sida jämfört med den sändande sidan eftersom det måste stödjas av e-postserverprogramvaran. Vissa e-postservrar stöder MTA-STS, till exempel PostFix.

var värd för MTA STS

Stora leverantörer av e-posttjänster som Microsoft, Oath och Google stöder MTA-STS. Googles Gmail har redan antagit MTA-STS-policyer på senare tid. MTA-STS har tagit bort nackdelarna med e-postanslutningssäkerhet genom att göra processen för att skydda anslutningar enkel och tillgänglig för e-postservrar som stöds.

Anslutningar från användare till e-postservrarna är vanligtvis skyddade och krypterade med TLS-protokollet, men trots att det fanns en befintlig brist på säkerhet i anslutningarna mellan e-postservrar före implementeringen av MTA-STS. Med en ökad medvetenhet om e-postsäkerhet på senare tid och stöd från stora e-postleverantörer över hela världen förväntas majoriteten av serveranslutningarna krypteras under den senaste framtiden. Dessutom säkerställer MTA-STS effektivt att cyberbrottslingar på nätverken inte kan läsa e-postinnehåll.

Enkel och snabb driftsättning av värdbaserade MTA-STS-tjänster från PowerDMARC

MTA-STS kräver en HTTPS-aktiverad webbserver med ett giltigt certifikat, DNS-poster och konstant underhåll. PowerDMARC gör ditt liv mycket enklare genom att hantera allt detta för dig, helt i bakgrunden. När vi hjälper dig att ställa in det, behöver du aldrig ens tänka på det igen.

Med hjälp av PowerDMARC kan du distribuera värdbaserade MTA-STS på din organisation utan krångel och i mycket snabb takt, med hjälp av vilken du kan genomdriva e-postmeddelanden som ska skickas till din domän via en TLS-krypterad anslutning, vilket gör din anslutning säker och håller MITM-attacker i schack.

 

 

Med den pågående ökningen av phishing-attacker, e-post- och domänförfalskningsattacker, BEC och andra bedrägliga aktiviteter av cyberbrottslingar är ett extra lager av säkerhet och e-postskydd alltid en bra idé! Mottagare av e-postmeddelanden blir allt mer misstänksamma mot meddelandena som landar i deras inkorgar på grund av ökningen av cyberattacker. Lösningen? En väl avrundad e-postsäkerhetssvit som innehåller BIMI-implementering.

En nyligen genomförd undersökning utförd av säkerhetspersonal i USA avslöjade att 60% av amerikanska medborgare hävdar att de har fallit offer för en cyberbluff eller känner till någon som har påverkats av samma, i sin nära cirkel, efter pandemin. För att ge sina e-postmeddelanden ytterligare ett skyddslager måste företag därför implementera en ny standard som brand indicators for message identification (BIMI), eftersom det lovar att ta konsumenternas förtroende till nästa nivå.

Vad är BIMI?

BIMI står för Brand Indicators for Message Identification, som är en nyformad standard för e-postautentisering som fäster ditt varumärkes logotyp på alla e-postmeddelanden som du har godkänt. Detta kan kännas som ett mycket litet steg, men visuell verifiering kan faktiskt öka ditt varumärkes trovärdighet genom att tillåta mottagare att känna igen och lita på de e-postmeddelanden du skickar ut från din företags e-postdomän.

Du kanske undrar, om du redan har DMARC implementerat i din organisation, som använder SPF- och DKIM-autentiseringsstandarder, behöver du ens BIMI? Låt oss diskutera i korthet hur var och en av dessa standarder fungerar för att autentisera inkommande e-postmeddelanden:

  • SPF autentiserar dina e-postmeddelanden för att identifiera de e-postservrar som får skicka e-post från din e-postdomän, som finns med i SPF-posten.
  • DKIM autentiserar e-postmeddelanden genom att lägga till en digital signatur till dem, så att mottagaren kan kontrollera om ett e-postmeddelande som påstår sig komma från en viss domän verkligen godkändes av ägaren till den domänen.
  • DMARC anger för inkorgsleverantörer hur man svarar på e-postmeddelanden som misslyckas med SPF- och DKIM-e-postautentisering.
  •  BIMI fäster ditt varumärkes logotyp på de e-postmeddelanden du skickar ut till dina anställda, partners och kunder så att de snabbt kan identifiera att det kommer från en auktoriserad källa.

Därför är det ganska uppenbart från diskussionen ovan att bland alla e-postautentiseringsprotokoll är BIMI den enda standarden som ger ett utrymme för visuell identifiering och erbjuder e-postmottagare en visuell ledtråd för att identifiera e-postkällan och känna igen dess äkthet.

PowerDMARC-logotyp mobil

BIMI-implementering - En kort guide

Även om BIMI är en framväxande och fortfarande utvecklande autentiseringsstandard är den fortfarande relativt ny. Hittills har bara Yahoo! Mail officiellt antagit tekniken. Av denna anledning garanterar BIMI inte visningen av din varumärkeslogotyp eftersom den fungerar med endast e-postklienter som stöds. Det finns några viktiga steg att följa, före BIMI-implementeringen, som är:

  • För att implementera BIMI i din organisation måste din domän vara DMARC- autentiserad på en principnivå för verkställighet, dvs. antingen avvisa eller karantän.
  • Du måste skapa och ladda upp en SVG-fil med ditt varumärkes logotyp enligt BIMI-kraven till en server så att den är tillgänglig var som helst.
  • Du måste skapa en BIMI-post, som i likhet med en DMARC-post i huvudsak är en sträng som består av flera taggar, åtskilda av semikolon.
  • Du måste ha tillgång till domänens DNS för att publicera den här nya BIMI-posten.
  • Det är en ganska användbar metod att kontrollera giltigheten för din BIMI-post efter att den har publicerats i din DNS.

Hur kan BIMI-implementering visa sig vara fördelaktigt för ditt företag?

BIMI är ett e-postautentiseringsprotokoll som utövar visuell identifiering för att hjälpa e-postmottagare att känna igen och lita på ditt varumärke i inkorgen. Detta förtroende hindrar kunder och partners från att avregistrera dina tjänster och håller spamklagomål i schack också, vilket senare kan leda till en ökning av e-postens leveransbarhet.

Utan BIMI visas en generisk platshållarlogotyp med varumärkes initialer av e-postklienter. Av denna anledning kan mottagaren ha svårt att känna igen ditt varumärke utan att tillgripa varumärket. Men med BIMI implementerad visas varumärkeslogotypen bredvid ditt e-postmeddelande, vilket ökar varumärkesmedvetenheten.

Utöver detta är det ett extra lager av e-postsäkerhet mot domänförfalskningsattacker, phishing-attacker och andra försök till imitation som mottagare skulle vara mer försiktiga med cyberbrottslingar som utger sig för att vara du.

Dessutom låter BIMI dig marknadsföra ditt varumärke. Ja, du hörde rätt! Ibland har mottagarna inte mycket tid i handen, och din ämnesrad kanske inte är tillräckligt övertygande för att klicka på för tillfället. Oavsett detta kommer dina mottagare att ansluta din avsändaradress, ämnesrad och preheader-text till din logotyp, vilket hjälper till att bygga ditt varumärke ytterligare.

Slutligen har BIMI-implementering också en mycket positiv inverkan på din e-post leveranshastighet! För postlådeleverantörer som stöder BIMI kommer det att lägga till ytterligare ett lager av e-postautentisering i dina meddelanden, vilket ökar chansen att de levererar din e-post snabbare. Utöver detta kan dina e-postmottagare visuellt identifiera och känna igen ditt varumärke, genom den visade logotypen, vilket minskar chansen att de markerar det som skräppost.

Underlätta din BIMI-implementeringsprocess med PowerBIMI

Med PowerBIMI gör vi BIMI-skivpublicering mycket snabb och enkel för dig! Allt du behöver göra är att helt enkelt ladda upp din SVG-bild, vi kommer att vara värd för den säkert och ge dig en DNS-post direkt, så att du kan publicera den i din DNS. Vi tar bort smärtan av att vara värd för bilden och säkra den från din axel.

Med PowerBIMI kan du när som helst uppdatera, ta bort eller göra ändringar i bilden utan att behöva uppdatera DNS-posterna igen. PowerBIMI ger dig en mycket snabb och enkel implementeringsprocedur med ett klick för att ladda upp din logotyp och övergå till BIMI-autentisering framgångsrikt, lägga till den som en del av din e-postsäkerhetssvit efter att ha registrerat dig för gratis BIMI-post.