Når en e -post sendes fra sendingsserveren, direkte til den mottakende serveren, godkjenner SPF og DKIM (hvis den er konfigurert riktig) e -posten normalt og validerer den vanligvis som legitim eller uautorisert. Imidlertid er det ikke tilfelle hvis e -posten passerer gjennom en mellomliggende e -postserver før den blir levert til mottakeren, for eksempel ved videresendte meldinger. Denne bloggen er ment å ta deg gjennom virkningen av videresending av e-post på DMARC-autentiseringsresultater.

Som vi allerede vet, bruker DMARC to standard e -postgodkjenningsprotokoller, nemlig SPF (Sender Policy Framework) og DKIM (DomainKeys Identified Mail), for å validere inngående meldinger. La oss diskutere dem kort for å få en bedre forståelse av hvordan de fungerer før vi går videre til hvordan videresending kan påvirke dem.

Avsenderpolitikkramme

SPF er tilstede i DNS som en TXT -post, og viser alle gyldige kilder som er autorisert til å sende e -post fra domenet ditt. Hver e -post som forlater domenet ditt har en IP -adresse som identifiserer serveren din og e -posttjenesteleverandøren som brukes av domenet ditt, som er oppført i DNS som en SPF -post. Mottakerens e -postserver validerer e -posten mot SPF -posten for å autentisere den og markerer derfor e -posten som SPF -passering eller mislykket.

DomainKeys Identified Mail

DKIM er en standard e -postgodkjenningsprotokoll som tilordner en kryptografisk signatur, opprettet ved hjelp av en privat nøkkel, for å validere e -postmeldinger på den mottakende serveren, der mottakeren kan hente den offentlige nøkkelen fra avsenderens DNS for å autentisere meldingene. I likhet med SPF, eksisterer DKIMs offentlige nøkkel også som en TXT -post i domeneeierens DNS.

Virkningen av videresending av e -post på DMARC -godkjenningsresultatene

Under videresending av e -post passerer e -posten gjennom en mellomtjener før den til slutt blir levert til den mottakende serveren. For det første er det viktig å innse at videresending av e-post kan gjøres på to måter- enten kan e-post videresendes manuelt , noe som ikke påvirker godkjenningsresultatene, eller at det kan videresendes automatisk , i så fall godkjenningsprosedyren treffer hvis domenet har ikke posten for den mellomliggende senderkilden i SPF.

Naturligvis mislykkes vanligvis SPF -sjekk under videresending av e -post, siden IP -adressen til mellomserveren ikke samsvarer med den som sender serveren, og denne nye IP -adressen er vanligvis ikke inkludert i den opprinnelige serverens SPF -post. Tvert imot påvirker videresending av e -post vanligvis ikke DKIM -e -postgodkjenning, med mindre mellomtjeneren eller videresendingsenheten foretar visse endringer i innholdet i meldingen.

Vær oppmerksom på at for at en e -post skal kunne passere DMARC -godkjenning, må e -posten være godkjent for SPF- eller DKIM -godkjenning og justering. Som vi vet at SPF uunngåelig mislykkes under videresending av e -post, hvis sendekilden er DKIM -nøytral og utelukkende er avhengig av SPF for validering, blir den videresendte e -posten uekte under DMARC -godkjenning.

Løsningen? Enkel. Du bør umiddelbart velge full DMARC -samsvar i organisasjonen din ved å justere og autentisere alle innkommende meldinger mot både SPF og DKIM!

Oppnå DMARC -samsvar med PowerDMARC

Det er viktig å merke seg at for å oppnå DMARC -samsvar må e -post godkjennes mot enten SPF eller DKIM eller begge deler. Imidlertid, med mindre de videresendte meldingene blir validert mot DKIM, og bare er avhengige av SPF for autentisering, vil DMARC uunngåelig mislykkes som diskutert i vår forrige seksjon. Dette er grunnen til at PowerDMARC hjelper deg med å oppnå fullstendig DMARC -samsvar ved å effektivt justere og autentisere e -postmeldinger mot både SPF- og DKIM -godkjenningsprotokoller. På denne måten, selv om autentiske videresendte meldinger mislykkes med SPF, kan DKIM -signaturen brukes til å validere den som legitim, og e -posten passerer DMARC -godkjenning, og lander deretter i mottakerens innboks.

Eksepsjonelle tilfeller: DKIM mislykkes og hvordan løses det?

I visse tilfeller kan videresendingsenheten endre postdelen ved å gjøre justeringer i MIME-grenser , implementering av antivirusprogrammer eller omkoding av meldingen. I slike tilfeller mislykkes både SPF- og DKIM -autentisering og legitime e -poster blir ikke levert.

I tilfelle både SPF og DKIM mislykkes, er PowerDMARC i stand til å identifisere og vise at i våre detaljerte samlede visninger og protokoller som Autentisert mottatt kjede kan utnyttes av e -postservere for å autentisere slike e -poster. I ARC kan Authentication-Results-overskriften sendes videre til neste "hop" på linjen i meldingsleveringen, for effektivt å dempe autentiseringsproblemer mens e-post videresendes.

I tilfelle en videresendt melding, når mottakerens e-postserver mottar en melding som mislyktes med DMARC-godkjenning, prøver den å validere e-posten for andre gang, mot den oppgitte autentiserte mottatte kjeden for e-posten ved å trekke ut ARC-autentiseringsresultatene for første hopp, for å sjekke om den ble validert for å være legitim før mellommannsserveren videresendte den til den mottakende serveren.

registrer deg hos PowerDMARC i dag, og oppnå DMARC -samsvar i din organisasjon!

 

ARC eller Autentisert mottatt kjede er et e -postgodkjenningssystem som viser en e -posts autentiseringsvurdering hvert trinn på veien under hele håndteringen. I enklere termer kan kjeden Autentisert mottatt betegnes som en "kjede av forvaring" for e -postmeldinger som gjør at hver enhet som håndterer meldingene effektivt kan se alle enhetene som tidligere håndterte den. Som en relativt ny protokoll publisert og dokumentert som "eksperimentell" i RFC 8617 juli 2019, gjør ARC det mulig for den mottakende serveren å validere e -post selv når SPF og DKIM blir ugyldig av en mellomliggende server.

Hvordan kan autentisert mottatt kjedehjelp?

Som vi allerede vet, tillater DMARC en e-post som skal autentiseres mot SPF og DKIM e-autentiserings standarder, spesifiserer til mottakeren hvordan å håndtere e-post som ikke klarer eller passerer autentisering. Imidlertid, hvis du implementerer DMARC -håndhevelse i organisasjonen din etter en streng DMARC -policy, er det sjanser for at selv legitime e -poster som dem som sendes via en adresseliste eller en videresender, kan mislykkes i autentisering og ikke bli levert til mottakeren! Godkjent mottatt kjede bidrar til å redusere dette problemet effektivt. La oss lære hvordan i følgende seksjon:

Situasjoner der ARC kan hjelpe

  • Postlister 

Som medlem av en e -postliste har du makt til å sende meldinger til alle medlemmer på listen på en gang ved å adressere selve e -postlisten. Mottakeradressen videresender deretter meldingen din til alle listemedlemmer. I dagens situasjon unnlater DMARC å validere denne typen meldinger, og autentiseringen mislykkes, selv om e -posten er sendt fra en legitim kilde! Dette er fordi SPF går i stykker når en melding videresendes. Siden e -postlisten ofte inneholder ekstra informasjon i e -postteksten, kan DKIM -signaturen også ugyldiggjøres på grunn av endringer i e -postinnholdet.

  • Videresende meldinger 

Når det er en indirekte e -postflyt, for eksempel at du mottar en e -post fra en mellomtjener og ikke direkte fra avsendingsserveren som ved videresendte meldinger, brytes SPF og e -posten din vil automatisk mislykkes med DMARC -godkjenning. Noen speditører endrer også e -postinnholdet, og derfor blir DKIM -signaturene også ugyldige.

 

 

I slike situasjoner kommer Autentisert mottatt kjede til unnsetning! Hvordan? La oss finne det ut:

Hvordan fungerer ARC?

I situasjonene ovenfor hadde speditørene i utgangspunktet mottatt e -postmeldinger som hadde blitt bekreftet mot DMARC -oppsett, fra en autorisert kilde. Autentisert mottatt kjede er utviklet som en spesifikasjon som gjør at overskriften Authentication-Results kan videreføres til neste "hopp" i linjen for meldingsleveringen.

I tilfelle en videresendt melding, når mottakerens e-postserver mottar en melding som mislyktes med DMARC-godkjenning, prøver den å validere e-posten for andre gang, mot den oppgitte autentiserte mottatte kjeden for e-posten ved å trekke ut ARC-autentiseringsresultatene for første hopp, for å sjekke om den ble validert for å være legitim før mellommannsserveren videresendte den til den mottakende serveren.

På grunnlag av informasjonen som er trukket ut, bestemmer mottakeren om ARC -resultatene skal tillates å overstyre DMARC -retningslinjene, og dermed sende e -posten som autentisk og gyldig og la den leveres normalt i mottakerens innboks.

Med ARC -implementering kan mottakeren effektivt autentisere e -posten ved hjelp av følgende informasjon:

  • Autentiseringsresultatene som den mellomliggende serveren er vitne til, sammen med hele historien til SPF- og DKIM -valideringsresultater i det første hoppet.
  • Nødvendig informasjon for å autentisere de sendte dataene.
  • Informasjon for å koble den sendte signaturen til mellomserveren slik at e -posten blir validert i den mottakende serveren, selv om mellommannen endrer innholdet, så lenge de videresender en ny og gyldig DKIM -signatur.

Implementering av autentisert mottatt kjede

ARC definerer tre nye postoverskrifter:

  • ARC-autentiseringsresultater (AAR) : Først blant e-posthodene er AAR som omslutter autentiseringsresultatene som SPF, DKIM og DMARC.

  • ARC-Seal (AS)-AS er en enklere versjon av en DKIM-signatur, som inneholder informasjon om autentiseringsoverskriftsresultater og ARC-signatur.

  • ARC-Message-Signature (AMS) -AMS ligner også en DKIM-signatur, som tar et bilde av meldingshodet som inneholder alt bortsett fra ARC-Seal-overskrifter som Til: og Fra: feltene, emnet og hele meldingsdelen.

Trinn utført av mellomserveren for å signere en endring:

Trinn 1: serveren kopierer autentiseringsresultatfeltet til et nytt AAR-felt og prefikser det til meldingen

Trinn 2: Serveren formulerer AMS for meldingen (med AAR) og legger den på forhånd til meldingen.

Trinn 3: Serveren formulerer AS for de forrige ARC-Seal-overskriftene og legger den til meldingen.

Til slutt, for å validere den godkjente mottatte kjeden og finne ut om en videresendt melding er legitim eller ikke, validerer mottakeren kjeden eller ARC Seal-headers og den nyeste ARC-melding-signaturen. Hvis ARC -topptekstene er blitt endret på en eller annen måte, mislykkes e -posten følgelig med DKIM -godkjenning. Imidlertid, hvis alle e -postservere som er involvert i overføringen av meldingen, signerer og sender ARC riktig, beholder e -posten DKIM -autentiseringsresultatene og sender DMARC -godkjenning, noe som resulterer i vellykket levering av meldingen i mottakerens innboks!

ARC-implementering sikkerhetskopierer og støtter DMARC-adopsjon i organisasjoner for å sikre at hver legitime e-post blir godkjent uten et eneste bortfall. Registrer deg for din gratis DMARC -prøveperiode i dag!

 

Mail Transfer Agent-Strict Transport Security (MTA-STS) er en ny standard som gjør det mulig for e-postleverandører å håndheve Transport Layer Security (TLS) for å sikre SMTP-tilkoblinger, og angi om de sender SMTP-serverne skal nekte å levere e-post til MX -verter som ikke tilbyr TLS med et pålitelig serversertifikat. Det har vist seg å lykkes med å redusere TLS-nedgraderingsangrep og Man-In-The-Middle (MITM) -angrep.

I enklere termer er MTA-STS en internettstandard som sikrer tilkoblinger mellom SMTP-postservere. Det mest fremtredende problemet med SMTP er at kryptering er helt valgfri og ikke håndheves under postoverføring. Det er derfor SMTP vedtok STARTTLS -kommandoen for å oppgradere fra ren tekst til kryptering. Dette var et verdifullt skritt mot å dempe passive angrep, men angrep via aktive nettverk og MITM -angrep forble fortsatt uadressert.

Derfor er problemet MTA-STS løser at SMTP benytter opportunistisk kryptering, dvs. hvis en kryptert kommunikasjonskanal ikke kan etableres, faller forbindelsen tilbake til ren tekst, og holder dermed MITM og nedgraderingsangrep i sjakk.

Hva er et TLS -nedgraderingsangrep?

Som vi allerede vet, kom SMTP ikke med en krypteringsprotokoll, og kryptering måtte ettermonteres senere for å øke sikkerheten til den eksisterende protokollen ved å legge til STARTTLS -kommandoen. Hvis klienten støtter kryptering (TLS), vil den forstå STARTTLS -verbet og starte en TLS -utveksling før du sender e -posten for å sikre at den er kryptert. Hvis klienten ikke kjenner TLS, ignorerer den bare STARTTLS -kommandoen og sender e -posten i ren tekst.

Siden kryptering måtte ettermonteres i SMTP -protokollen, må derfor oppgraderingen for kryptert levering stole på en STARTTLS -kommando som sendes i klar tekst. En MITM -angriper kan enkelt utnytte denne funksjonen ved å utføre et nedgraderingsangrep på SMTP -tilkoblingen ved å manipulere oppgraderingskommandoen. Angriperen erstattet ganske enkelt STARTTLS med en søppelstreng som klienten ikke klarer å identifisere. Derfor faller klienten lett tilbake til å sende e -posten i ren tekst.

Angriperen erstatter vanligvis kommandoen med søppelstrengen som inneholder samme antall tegn, i stedet for å hakke den ut, fordi dette beholder pakkestørrelsen og derfor gjør det lettere. De åtte bokstavene i søppelstrengen i alternativkommandoen lar oss oppdage og identifisere at et TLS -nedgraderingsangrep er utført av en nettkriminell, og vi kan måle utbredelsen av det.

Kort sagt, Et nedgraderingsangrep blir ofte lansert som en del av et MITM -angrep, for å lage en vei for å muliggjøre et kryptografisk angrep som ikke ville være mulig i tilfelle en forbindelse som er kryptert over den siste versjonen av TLS -protokollen, av erstatte eller slette STARTTLS -kommandoen og tilbakestille kommunikasjonen til klar tekst.

Selv om det er mulig å håndheve TLS for klient-til-server-kommunikasjon, så vet vi at appene og serveren støtter det. For kommunikasjon mellom server og server må vi imidlertid ikke åpne for å tillate eldre servere å sende e-post. Kjernen i problemet er at vi ikke aner om serveren på den andre siden støtter TLS eller ikke. MTA-STS lar servere indikere at de støtter TLS, noe som gjør at de ikke kan lukke (dvs. ikke sende e-posten) hvis oppgraderingsforhandlingen ikke finner sted, og dermed gjøre det umulig for et TLS-nedgraderingsangrep å finne sted.

tls rapportering

Hvordan kommer MTA-STS til unnsetning?

MTA-STS fungerer ved å øke EXO eller Exchange Online e-postsikkerhet og er den ultimate løsningen på et stort utvalg av SMTP-sikkerhetsmessige ulemper og problemer. Det løser problemer i SMTP -sikkerhet, for eksempel mangel på støtte for sikre protokoller, utløpte TLS -sertifikater og sertifikater som ikke er utstedt av pålitelige tredjeparter.

Etter hvert som e -postservere fortsetter å sende ut e -post, er SMTP -tilkoblingen sårbar for kryptografiske angrep som nedgraderingsangrep og MITM. Nedgraderingsangrep kan startes ved å slette STARTTLS -svaret, og dermed levere meldingen i klar tekst. På samme måte kan MITM -angrep også startes ved å omdirigere meldingen til en serverinnbrudd via en usikker tilkobling. MTA-STS lar domenet ditt publisere en policy som gjør det nødvendig å sende en e-post med kryptert TLS. Hvis det av en eller annen grunn blir funnet at den mottakende serveren ikke støtter STARTTLS, blir ikke e -posten sendt i det hele tatt. Dette gjør det umulig å sette i gang et TLS -nedgraderingsangrep.

I nyere tid har flertallet av e-postleverandører tatt i bruk MTA-STS og derved gjort forbindelser mellom servere sikrere og kryptert over TLS-protokollen til en oppdatert versjon, og dermed lykkes med å redusere TLS-nedgraderingsangrep og oppheve hullene i serverkommunikasjon.

PowerDMARC gir deg raske og enkle hostede MTA-STS-tjenester som gjør livet ditt mye enklere da vi tar vare på alle spesifikasjonene som kreves av MTA-STS under og etter implementering, for eksempel en HTTPS-aktivert webserver med en gyldig sertifikat, DNS -poster og konstant vedlikehold. PowerDMARC klarer alt dette helt i bakgrunnen, slik at etter at vi har hjulpet deg med å sette det opp, trenger du ikke engang tenke på det igjen!

Ved hjelp av PowerDMARC kan du distribuere Hosted MTA-STS i organisasjonen din uten problemer og i et veldig raskt tempo, ved hjelp av hvilken du kan håndheve e-post som skal sendes til domenet ditt via en TLS-kryptert tilkobling, og dermed gjøre din tilkobling sikker og holder TLS -nedgraderingsangrep i sjakk.

 

En allment kjent internettstandard som letter ved å forbedre sikkerheten til tilkoblinger mellom SMTP-servere (Simple Mail Transfer Protocol) er SMTP Mail Transfer Agent-Strict Transport Security (MTA-STS).

I 1982 ble SMTP først spesifisert, og den inneholdt ingen mekanisme for å gi sikkerhet på transportnivå for å sikre kommunikasjon mellom postoverføringsagentene. I 1999 ble imidlertid STARTTLS-kommandoen lagt til SMTP som igjen støttet kryptering av e-post mellom serverne, noe som gir muligheten til å konvertere en usikker tilkobling til en sikker som er kryptert ved hjelp av TLS-protokoll.

I så fall må du lure på at hvis SMTP vedtok STARTTLS for å sikre tilkoblinger mellom servere, hvorfor var skiftet til MTA-STS nødvendig? La oss hoppe inn i det i den følgende delen av denne bloggen!

Behovet for å skifte til MTA-STS

STARTTLS var ikke perfekt, og det klarte ikke å løse to store problemer: Det første er at det er et valgfritt tiltak, og derfor klarer STARTTLS ikke å forhindre man-in-the-middle (MITM) angrep. Dette er fordi en MITM -angriper enkelt kan endre en tilkobling og forhindre at krypteringsoppdateringen finner sted. Det andre problemet med det er at selv om STARTTLS er implementert, er det ingen måte å autentisere identiteten til sendingsserveren ettersom SMTP -e -postservere ikke validerer sertifikater.

Selv om de fleste utgående e -poster i dag er sikret med Transport Layer Security (TLS) -kryptering, en bransjestandard som er vedtatt selv av forbrukernes e -post, kan angriperne fortsatt hindre og tukle med e -posten din selv før den blir kryptert. Hvis du sender en e -post for å transportere e -postene dine over en sikker tilkobling, kan dataene dine bli kompromittert eller endret og manipulert av en cyberangriper. Det er her MTA-STS går inn og løser dette problemet, og garanterer trygg transitt for e-postene dine samt vellykket dempende MITM-angrep. Videre lagrer MTAer MTA-STS policy-filer, noe som gjør det vanskeligere for angriperne å starte et DNS-spoofing-angrep.

MTA-STS gir beskyttelse mot:

  • Nedgrader angrep
  • Man-In-The-Middle (MITM) angrep
  • Det løser flere SMTP -sikkerhetsproblemer, inkludert utløpte TLS -sertifikater og mangel på støtte for sikre protokoller.

Hvordan fungerer MTA-STS?

MTA-STS-protokollen distribueres ved å ha en DNS-post som angir at en e-postserver kan hente en policyfil fra et bestemt underdomen. Denne policyfilen hentes via HTTPS og godkjennes med sertifikater, sammen med listen over navn på mottakernes e -postservere. Implementering av MTA-STS er enklere på mottakersiden i forhold til sendersiden, da det krever støtte for e-postserverprogramvaren. Noen e-postservere støtter MTA-STS, for eksempel PostFix, men ikke alle gjør det.

vert for MTA STS

Store e-postleverandører som Microsoft, Oath og Google støtter MTA-STS. Googles Gmail har allerede vedtatt MTA-STS-retningslinjer i nyere tid. MTA-STS har fjernet ulempene med sikkerhet for e-posttilkobling ved å gjøre prosessen med å sikre tilkoblinger enkel og tilgjengelig for støttede e-postservere.

Tilkoblinger fra brukerne til postserverne er vanligvis beskyttet og kryptert med TLS-protokoll, til tross for at det var en eksisterende mangel på sikkerhet i forbindelsene mellom e-postservere før implementeringen av MTA-STS. Med en økende bevissthet om e -postsikkerhet i nyere tid og støtte fra store e -postleverandører over hele verden, forventes flertallet av serverforbindelser å bli kryptert i den siste fremtiden. Videre sikrer MTA-STS effektivt at nettkriminelle på nettverkene ikke klarer å lese e-postinnhold.

Enkel og rask distribusjon av hostede MTA-STS-tjenester av PowerDMARC

MTA-STS krever en HTTPS-aktivert webserver med et gyldig sertifikat, DNS-poster og konstant vedlikehold. PowerDMARC gjør livet ditt mye enklere ved å håndtere alt det for deg, helt i bakgrunnen. Når vi har hjulpet deg med å sette det opp, trenger du ikke engang tenke på det igjen.

Ved hjelp av PowerDMARC kan du distribuere Hosted MTA-STS i organisasjonen din uten problemer og i et veldig raskt tempo, ved hjelp av hvilken du kan håndheve e-post som skal sendes til domenet ditt via en TLS-kryptert tilkobling, og dermed gjøre din tilkoblingen er sikker og holder MITM -angrep i sjakk.

 

 

Med den pågående økningen i phishing -angrep, e -post- og domenespoofing -angrep, BEC og andre uredelige aktiviteter av cyberkriminelle, er et ekstra lag med sikkerhet og e -postbeskyttelse alltid en god idé! Mottakere av e -post blir stadig mer mistenksom overfor meldinger som lander i innboksen på grunn av økningen i cyberangrep. Løsningen? En godt avrundet e-postsikkerhetspakke som inkluderer BIMI- implementering.

En nylig undersøkelse utført av sikkerhetspersonell i USA avslørte at 60% av amerikanske borgere hevder å ha blitt offer for en cyber-svindel eller kjenner til noen som har blitt rammet av det samme, i sin nære krets, etter pandemien. Derfor, for å gi e -postene sine et ekstra lag med beskyttelse, må bedrifter implementere en ny standard som Brand Indicators for Message Identification (BIMI), ettersom den lover å ta forbrukernes tillit til neste nivå.

Hva er BIMI?

BIMI står for Brand Indicators for Message Identification, som er en nyopprettet standard for e -postautentisering som fester merkevarens logo til alle e -poster godkjent av deg. Dette kan føles som et veldig lite skritt, men visuell bekreftelse kan faktisk øke merkevarens troverdighet ved å la mottakere gjenkjenne og stole på e -postene du sender ut fra bedriftens e -postdomene.

Du kan lure på, hvis du allerede har DMARC implementert i organisasjonen, som gjør bruk av SPF og DKIM autentiserings standarder, gjør du selv trenger Bimi? La oss kort diskutere hvordan hver av disse standardene fungerer for å autentisere inngående e -post:

  • SPF autentiserer e -postene dine for å identifisere e -postservere som har lov til å sende e -post fra e -postdomenet ditt, registrert i SPF -posten.
  • DKIM autentiserer e -post ved å legge til en digital signatur til dem, slik at mottakeren kan kontrollere om en e -post som påstår at den kommer fra et bestemt domene, faktisk var godkjent av eieren av domenet.
  • DMARC spesifiserer for innboksleverandører hvordan de skal svare på e -postmeldinger som ikke klarer SPF- og DKIM -e -postautentisering.
  •  BIMI fester merkevarens logo på e -postene du sender til dine ansatte, partnere og kunder, slik at de umiddelbart kan identifisere at det er fra en autorisert kilde.

Derfor er det ganske tydelig fra diskusjonen ovenfor at blant alle e -postgodkjenningsprotokollene er BIMI den eneste standarden som gir et område for visuell identifikasjon, og tilbyr e -postmottakere en visuell ledetråd for å identifisere e -postkilden og gjenkjenne dens ekthet.

PowerDMARC Logo Mobile

BIMI-implementering- en kort guide

Selv om BIMI er en fremvoksende og stadig utviklende autentiseringsstandard, er den fortsatt relativt ny. Foreløpig er det bare Yahoo! Mail har offisielt tatt i bruk teknologien. Av denne grunn garanterer ikke BIMI visningen av merkevarelogoen din, ettersom den bare fungerer med e -postklienter som støttes. Det er noen viktige trinn du må følge før BIMI -implementering , som er:

  • For å implementere BIMI i organisasjonen din, må domenet ditt være DMARC-autentisert på et politisk håndhevelsesnivå, dvs. enten avvisning eller karantene .
  • Du må opprette og laste opp en SVG -fil med merkevarens logo i henhold til BIMI -kravene til en server, slik at den er tilgjengelig hvor som helst.
  • Du må opprette en BIMI -post, som i likhet med en DMARC -post egentlig er en streng som består av flere koder, atskilt med semikolon.
  • Du må ha tilgang til domenets DNS for å publisere denne nye BIMI -posten.
  • Det er en ganske nyttig praksis å kontrollere gyldigheten av BIMI -posten din etter at den er publisert i DNS -en din.

Hvordan kan BIMI -implementering vise seg å være fordelaktig for virksomheten din?

BIMI er en e -postgodkjenningsprotokoll som bruker visuell identifikasjon for å hjelpe e -postmottakere med å gjenkjenne og stole på merkevaren din i innboksen. Denne tilliten forhindrer kunder og partnere i å melde seg på tjenestene dine og holder også spam -klager i sjakk, noe som senere kan føre til et økning i leveransen av e -post.

Uten BIMI vises en generisk plassholderlogo med merkeinitialer av e -postklienter. Av denne grunn kan mottakeren ha vanskelig for å gjenkjenne merkevaren din uten å ty til merkenavnet. Imidlertid, med BIMI implementert, vises merkevarelogoen ved siden av e -postmeldingen, noe som øker merkevarebevisstheten.

I tillegg til det er det et ekstra lag med e -postsikkerhet mot domenespoofing -angrep, phishing -angrep og andre forsøk på etterligning som mottakere ville være mer forsiktige med at nettkriminelle utgir seg for å være deg.

Videre lar BIMI deg markedsføre merkevaren din. Ja, du hørte meg riktig! Noen ganger har mottakere ikke mye tid i hånden, og emnelinjen din er kanskje ikke overbevisende nok til å klikke på for øyeblikket. Uavhengig av det, vil mottakerne koble avsenderadressen din, emnelinjen og teksten til forhåndshodet med logoen din, og hjelpe deg med å bygge merkevaren din ytterligere.

Til slutt har BIMI -implementering også en veldig positiv innvirkning på leveringsgraden for e -post! For postboksleverandører som støtter BIMI, vil det legge til et nytt lag med e -postautentisering i meldingene dine, og dermed øke sjansen for at de leverer e -posten din raskere. I tillegg til det kan e -postmottakerne visuelt identifisere og gjenkjenne merkevaren din, gjennom den viste logoen, og redusere sjansen for at de markerer det som søppelpost.

Gjør BIMI -implementeringsprosessen enklere med PowerBIMI

Med PowerBIMI gjør vi BIMI -plateutgivelse veldig rask og enkel for deg! Alt du trenger å gjøre er å laste opp SVG -bildet ditt. Vi vil være vert for det og gi deg en DNS -post umiddelbart, slik at du kan publisere det i DNS. Vi tar smerten av å være vert for bildet og sikre det fra skulderen.

Med PowerBIMI kan du når som helst oppdatere, slette eller gjøre endringer i bildet ditt, uten at du trenger å oppdatere DNS -postene igjen. PowerBIMI gir deg en veldig rask og enkel ett-klikk implementeringsprosedyre for å laste opp logoen din og bytte til BIMI-godkjenning, og legge den til som en del av din e-postsikkerhetspakke etter å ha registrert deg for gratis BIMI-post.