Jaa

Sähköpostitodennus Microsoft 365:ssä

Vihje

Tiesitkö, että voit kokeilla Microsoft Defender for Office 365 palvelupaketin 2 ominaisuuksia maksutta? Käytä 90 päivän Defender for Office 365 kokeiluversiota Microsoft Defender-portaalin kokeilukeskuksessa. Lisätietoja siitä, ketkä voivat rekisteröityä ja kokeilla käyttöehtoja, on artikkelissa Kokeile Microsoft Defender for Office 365.

Microsoft 365 -organisaationa, jolla on postilaatikoita Exchange Online, tai erillisenä Exchange Online Protection (EOP) organisaationa, jolla ei ole Exchange Online postilaatikoita, sähköpostiviestien eheyden suojaaminen toimialueiden lähettäjiltä on tärkeää. Vastaanottajien tulisi olla varmoja siitä, että toimialueesi lähettäjien viestit ovat peräisin toimialueesi lähettäjiltä.

Sähköpostin todennus (tunnetaan myös sähköpostin vahvistuksena) on standardien ryhmä, jonka avulla tunnistetaan ja estetään taottujen lähettäjien sähköpostiviestien toimittaminen (kutsutaan myös huijaukseksi). Spoofed-lähettäjiä käytetään yleisesti yrityssähköpostiratkaisuissa (BEC), tietojenkalastelussa ja muissa sähköpostihyökkäyksissä. Näitä standardeja ovat esimerkiksi seuraavat:

  • Lähettäjän käytäntökehys (SPF): Määrittää lähdesähköpostipalvelimet, joilla on oikeus lähettää toimialueen sähköpostia.
  • DomainKeys Identified Mail (DKIM): Käyttää toimialuetta viestin tärkeiden elementtien digitaaliseen allekirjoittamiseen varmistaakseen, ettei viestiä ole muutettu kuljetuksen aikana.
  • Toimialuepohjainen viestien todennus, raportointi ja vaatimustenmukaisuus (DMARC): Määrittää toiminnon viesteille, jotka eivät läpäise SPF:tä tai DKIM:tä, tarkistaa lähettäjät toimialueella ja määrittää, minne DMARC-tulokset lähetetään (raportointi).
  • Todennettu vastaanotettu ketju (ARC): säilyttää alkuperäiset sähköpostin todennustiedot tunnetuissa palveluissa, jotka muokkaavat siirrettävia viestejä. Kohdesähköpostipalvelin voi näiden tietojen avulla todentaa viestit, jotka muussa tapauksessa epäonnistuisivat DMARC:ssä.

On tärkeää ymmärtää, että nämä standardit ovat toisiinsa liittyviä rakenneosia , jotka toimivat yhdessä tarjotakseen parhaan mahdollisen sähköpostisuojan huijaus- ja tietojenkalasteluhyökkäyksiä vastaan. Jos jokin muu kuin kaikki sähköpostin todennusmenetelmät johtavat aliarvostumattomaan suojaukseen.

Jos haluat määrittää sähköpostitodennuksen microsoft 365 -organisaatioista lähetetyille sähköposteille, joissa on postilaatikoita Exchange Online tai erillisissä Exchange Online Protection (EOP) organisaatioissa, joissa ei ole Exchange Online postilaatikoita, tutustu seuraaviin artikkeleihin:

Jos haluat estää sähköpostin todennusvirheet niiden palvelujen vuoksi, jotka muokkaavat Microsoft 365 -organisaatioosi lähetettyjä saapuvia viestejä, katso Luotettujen ARC-sinettien määrittäminen.

Tämän artikkelin loppuosassa selitetään:

Vihje

Tämän artikkelin kumppanina tutustu Microsoft Defender for Office 365 määritysoppaaseen, jossa voit tarkastella parhaita käytäntöjä ja suojautua sähköposti-, linkki- ja yhteistyöuhkia vastaan. Ominaisuuksiin kuuluvat esimerkiksi Turvalliset linkit ja Turvalliset liitteet. Ympäristöösi perustuvan mukautetun käyttökokemuksen saat Microsoft 365 -hallintakeskus Microsoft Defender for Office 365 automaattisen määritysoppaan kautta.

Miksi Internet-sähköposti tarvitsee todennuksen

SmTP (Simple Mail Transfer Protocol) -sähköposti Internetissä ei pyri vahvistamaan, että viestin lähettäjä on se, joksi hän väittää olevansa.

SmtP-vakiosähköpostiviesti koostuu viestikuoresta ja viestin sisällöstä:

  • Viestikuori sisältää tietoja viestin lähettämiseen ja vastaanottamiseen SMTP-palvelimien välillä. Viestikuori on kuvattu kohdassa RFC 5321. Vastaanottajat eivät koskaan näe viestin kirjekuorta, koska se luodaan viestin lähetysprosessin aikana.
  • Viestin sisältö sisältää viestin otsikkokenttiä (joita kutsutaan yhteisesti viestin otsikoksi) ja viestin leipätekstin. Viestin otsikko on kuvattu kohdassa RFC 5322.

Tämän rakenteen vuoksi viestissä on useita lähettäjäarvoja:

  • MAIL FROM -osoite (jota kutsutaan myös osoitteeksi, P1-lähettäjäksi tai kirjekuoren lähettäjäksi 5321.MailFrom ) on sähköpostiosoite, jota käytetään viestin lähettämisessä SMTP-sähköpostipalvelimien välillä. Tämä osoite tallennetaan yleensä viestin otsikon Palautuspolku-otsikkokenttään (vaikka lähdesähköpostipalvelin voi määrittää toisen palautuspolun sähköpostiosoitteen). Tätä sähköpostiosoitetta käytetään toimitusten ulkopuolisissa raporteissa (NDR-raporteissa tai pomppuviesteissä).
  • Lähettäjä-osoite (tunnetaan myös nimellä 5322.From osoite tai P2-lähettäjä) on Lähettäjä-otsikko-kentän sähköpostiosoite, ja se on lähettäjän sähköpostiosoite, joka näkyy sähköpostiohjelmissa.

Seuraavassa esimerkissä näytetään yksinkertaistettu tallenne kelvollisesta viestinsiirrosta kahden SMTP-sähköpostipalvelimen välillä:

S: HELO woodgrovebank.com
S: MAIL FROM: dubious@proseware.com
S: RCPT TO: astobes@tailspintoys.com
S: DATA
S: To: "Andrew Stobes" <astobes@tailspintoys.com>
S: From: "Woodgrove Bank Security" <security@woodgrovebank.com>
S: Subject: Woodgrove Bank - Action required
S:
S: Greetings,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that we have the right information for your account.
S:
S: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .

Tässä esimerkissä:

  • Lähdesähköpostipalvelin tunnistaa itsensä helo-komennossa woodgrovebank.com kohdesähköpostipalvelimen tailspintoys.com.
  • Viestin vastaanottaja on astobes@tailspintoys.com.
  • Viestikuoren MAIL FROM -osoite (käytetään viestin välittämiseen SMTP-sähköpostipalvelimien välillä) on dubious@proseware.com.
  • Vastaanottajan sähköpostiohjelmassa näkyvä Lähettäjä-osoite on security@woodgrovebank.com.

Vaikka tämä viesti on SMTP:n mukaan kelvollinen, MAIL FROM -osoitteen (proseware.com) toimialue ei vastaa Lähettäjä-osoitteen (woodgrovebank.com) toimialuetta. Tämä viesti on perinteinen esimerkki väärentämisestä, jossa tarkoitus on todennäköisesti pettää vastaanottaja peittelemällä viestin todellinen lähde tietojenkalasteluhyökkäyksessä käytettäväksi.

SMTP-sähköpostin avulla on selvästikin varmistettava, että viestin lähettäjät ovat ne, jotka he väittävät olevansa!

Miten SPF, DKIM ja DMARC toimivat yhdessä sähköpostiviestien lähettäjien todentamisen kanssa

Tässä osiossa kuvataan, miksi internet-toimialueisiin tarvitaan SPF, DKIM ja DMARC.

  • SPF: Kuten artikkelissa SPF:n määrittäminen Microsoft 365 -toimialueen kelvollisten sähköpostilähteiden tunnistamiseksi on selitetty, SPF käyttää DNS:n TXT-tietuetta tunnistaakseen kelvolliset sähköpostilähteet MAIL FROM -toimialueelta ja mitä tehdä, jos kohdesähköpostipalvelin vastaanottaa sähköpostia määrittämättömästä lähteestä ("vaikea epäonnistua" viestin hylkääminen; hyväksy ja merkitse viesti pehmeällä virhesanomalla).

    SPF-ongelmat:

    • SPF vahvistaa lähettäjän lähteet vain MAIL FROM -toimialueella. SPF ei ota huomioon lähettäjän osoitteen tai MAIL FROM- ja From-toimialueiden välistä toimialuetta:

      • Hyökkääjä voi lähettää sähköpostia, joka läpäisee SPF-todennuksen (epätosi-negatiivinen), toimimalla seuraavasti:
        • Rekisteröi toimialue (esimerkiksi proseware.com) ja määritä toimialueelle SPF.
        • Lähetä sähköpostia rekisteröidyn toimialueen kelvollisen lähteen lähettäjältä käyttämällä Eri toimialueen (esimerkiksi woodgrovebank.com) Lähettäjä-sähköpostiosoitteita.
      • Kelvollinen sähköpostipalvelu, joka lähettää sähköpostia muiden toimialueiden puolesta, voi hallita MAIL FROM -osoitetta. Muut toimialueet ja MAIL FROM -toimialue eivät vastaa toisiaan, joten viestit eivät voi välittää SPF-todennusta (epätosi-positiivinen).

    • SPF katkeaa sen jälkeen, kun viestit kohtaavat palvelinpohjaisia edelleenlähetyssähköposteja, jotka ohjaavat tai välittävät viestejä.

      • Palvelinpohjainen sähköpostinsiirto muuttaa viestin lähteen alkuperäisestä palvelimesta edelleenlähetyspalvelimeen.
      • Edelleenlähetyspalvelimella ei ole oikeuksia lähettää alkuperäisen MAIL FROM -toimialueen sähköpostia, joten viesti ei voi välittää SPF-todennusta (epätosi-positiivinen).

    • Jokainen toimialue ja mahdollinen alitoimialue edellyttävät omia yksittäisiä SPF-tietueitaan. Alitoimialueet eivät peri päätoimialueen SPF-tietuetta. Tästä käyttäytymisestä tulee ongelmallista, jos haluat sallia sähköpostin määritetyistä ja käytetyistä alitoimialueista, mutta estää sähköpostin määrittämättömiltä ja käyttämättömistä alitoimialueista.

  • DKIM: Kuten artikkelissa DKIM:n määrittäminen microsoft 365 -toimialueen sähköpostin allekirjoittamista varten on selitetty, DKIM käyttää toimialuetta viestin tärkeiden elementtien digitaaliseen allekirjoittamiseen (mukaan lukien Lähettäjä-osoite) ja tallentaa allekirjoituksen viestin otsikkoon. Kohdepalvelin tarkistaa, että viestin allekirjoitettuja elementtejä ei muutettu.

    Miten DKIM auttaa SPF:tä: DKIM voi vahvistaa viestit, jotka epäonnistuvat SPF:ssä. Esimerkki:

    • Viestit sähköpostin isännöintipalvelusta, jossa samaa MAIL FROM -osoitetta käytetään muista toimialueista peräisin olevaan sähköpostiin.
    • Viestit, joissa ilmenee palvelinpohjaista sähköpostin edelleenlähetystä.

    Koska tämä ei vaikuta viestin otsikon DKIM-allekirjoitukseen tai sitä ei muuteta näissä tilanteissa, nämä viestit voivat välittää DKIM:n.

    DKIM-ongelmat: Toimialueen, jota DKIM käyttää viestin allekirjoittamiseen, ei tarvitse vastata sähköpostiohjelmissa näkyvää Lähettäjä-osoitteen toimialuetta.

    SPF:n tavoin hyökkääjä voi lähettää DKIM-todennuksen läpäisevän sähköpostiviestin (epätosi-negatiivinen) noudattamalla seuraavia vaiheita:

    • Rekisteröi toimialue (esimerkiksi proseware.com) ja määritä toimialueelle DKIM.
    • Lähetä sähköpostiviesti, jossa on Lähettäjä-sähköpostiosoitteet eri toimialueella (esimerkiksi woodgrovebank.com).

  • DMARC: Kuten artikkelissa DMARC:n määrittäminen vahvistamaan Lähettäjän osoite -toimialue microsoft 365:ssä lähettäjille on selitetty, DMARC tarkistaa SPF:n ja DKIM:n avulla, onko MAIL FROM- ja From-osoitteiden toimialueiden välinen tasaus. DMARC määrittää myös toiminnon, joka kohdesähköpostijärjestelmän tulee suorittaa viesteille, jotka eivät täytä DMARC-yhteyttä, ja määrittää, mihin DMARC-tulokset lähetetään (sekä läpäisy että epäonnistuminen).

    Miten DMARC auttaa SPF:tä ja DKIM:tä: Kuten aiemmin kuvattiin, SPF ei yritä vastata MAIL FROM -toimialueen ja Lähettäjä-osoitteiden toimialuetta. DKIM ei välitä, vastaako viestin allekirjoittanut toimialue Lähettäjä-osoitteen toimialuetta.

    DMARC korjaa nämä puutteet käyttämällä SPF:tä ja DKIM:tä varmistaakseen, että MAIL FROM- ja From-osoitteiden toimialueet vastaavat toisiaan.

    DMARC-ongelmat: Lailliset palvelut, jotka muokkaavat siirrettäviä viestejä ennen toimitusta rikkovat SPF:n, DKIM:n ja siten DMARC-tarkistukset.

  • ARC: Kuten kohdassa Luotettujen ARC-sinettien määrittäminen on selitetty, läpikulussa olevia viestejä muokkaavat lailliset palvelut voivat käyttää ARC:ia muokattujen viestien alkuperäisten sähköpostin todennustietojen säilyttämiseen.

    Arcin apu DMARC:ssä: Kohdesähköpostijärjestelmä voi tunnistaa palvelun luotetuksi ARC-tiivistimeksi. ARC voi sitten vahvistaa viestin käyttämällä säilytetyissä sähköpostin todennustiedoissa olevia tietoja.

Microsoft 365:een lähetettyjen sähköpostien saapuvan sähköpostin todennus

Tietojenkalasteluun liittyvien huolenaiheiden ja vahvojen sähköpostin todennuskäytäntöjen täydellisen käyttöönoton vuoksi Internetissä lähettäjien toimesta Microsoft 365 käyttää implisiittistä sähköpostitodennusta saapuvan sähköpostin tarkistamiseen. Implisiittinen sähköpostitodennus laajentaa tavallisia SPF-, DKIM- ja DMARC-tarkistuksia käyttämällä muiden lähteiden signaaleja saapuvan sähköpostin arvioimiseksi. Näitä lähteitä ovat esimerkiksi seuraavat:

  • Lähettäjän maine.
  • Lähettäjän historia.
  • Vastaanottajahistoria.
  • Käyttäytymisanalyysi.
  • Muita kehittyneitä tekniikoita.

Jos haluat nähdä Microsoftin alkuperäisen ilmoituksen implisiittisestä todentamisesta, lue artikkeli Tietojenkalastelun meri 2 – Parannettu väärentämisen torjunta Microsoft 365:ssä.

Käyttämällä näitä muita signaaleja viestit, jotka muuten epäonnistuisivat perinteisissä sähköpostitodennustarkistuksissa, voivat välittää implisiittisen todennuksen ja ne sallitaan Microsoft 365:een.

Yhdistelmätodentaminen

Microsoft 365:n implisiittisten todennustarkistusten tulokset yhdistetään ja tallennetaan yhteen arvoon nimeltä yhdistelmätodennus tai compauth lyhyesti. Arvo compauth on leimattu viestin otsikoiden Todennustulokset-otsikkoon . Authentication-Results-otsikko käyttää seuraavaa syntaksia:

Authentication-Results:
   compauth=<fail | pass | softpass | none> reason=<yyy>

Nämä arvot selitetään todennustulosten sanomaotsikossa.

Järjestelmänvalvojat ja käyttäjät voivat tarkastella viestin otsikkotietoja selvittääkseen, miten Microsoft 365 tunnisti lähettäjän epäilyttäväksi huijatuksi lähettäjäksi tai lailliseksi.

Vihje

On tärkeää ymmärtää, että yhdistelmätodennusvirhe ei suoraan estä viestiä. Järjestelmämme käyttää kokonaisvaltaista arviointistrategiaa, joka ottaa huomioon viestin yleisen epäilyttävän luonteen yhdessä yhdistelmätodennustulosten kanssa. Tämä menetelmä on suunniteltu pienentämään riskiä estää virheellisesti laillinen sähköposti toimialueilta, jotka eivät ehkä noudata tiukasti sähköpostin todennusprotokollia. Tämä tasapainoinen lähestymistapa auttaa erottamaan aidon pahantahtoiset sähköpostiviestit viestien lähettäjistä, jotka eivät yksinkertaisesti noudata tavallisia sähköpostin todennuskäytäntöjä.

Seuraavissa esimerkeissä keskitytään vain sähköpostin todennuksen tuloksiin ( compauth arvo ja syy). Muut Microsoft 365 -suojaustekniikat voivat tunnistaa sähköpostiviestit, jotka läpäisevät sähköpostin todentamisen huijatuksi, tai tunnistaa viestit, jotka eivät hyväksy sähköpostin todennusta, laillisiksi.

  • Skenaario: SPF-tietueen tai DKIM-allekirjoituksen toimialue ei vastaa Lähettäjä-osoitteen toimialuetta.

  • Tulos: Viesti voi epäonnistua yhdistelmätodennuksessa. Yhdistelmätodennusvirheestä huolimatta viesti saattaa silti olla sallittu, jos muut arvioinnit eivät osoita epäilyttävää luonnetta:

    Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

  • Skenaario: fabrikam.com toimialueella ei ole SPF-, DKIM- tai DMARC-tietueita.

  • Tulos: fabrikam.com toimialueen lähettäjien viestit voivat epäonnistua yhdistelmätodennuksessa:

    Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=none
  action=none header.from=fabrikam.com; compauth=fail reason=001
From: chris@fabrikam.com
To: michelle@contoso.com

  • Skenaario: fabrikam.com toimialueella on SPF-tietue eikä DKIM-tietuetta. MAIL FROM- ja From-osoitteiden toimialueet vastaavat toisiaan.

  • Tulos: Viesti voi välittää yhdistelmätodennuksen, koska SPF:n ohittanut toimialue vastaa Lähettäjä-osoitteen toimialuetta:

    Authentication-Results: spf=pass (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=bestguesspass
  action=none header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

  • Skenaario: fabrikam.com toimialueella on DKIM-tietue ilman SPF-tietuetta. Toimialue, jonka DKIM allekirjoitti viestin, vastaa Lähettäjä-osoitteen toimialuetta.

  • Tulos: Viesti voi välittää yhdistelmätodennuksen, koska DKIM-allekirjoituksen toimialue vastaa Lähettäjä-osoitteen toimialuetta:

    Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=pass
  (signature was verified) header.d=outbound.fabrikam.com;
  contoso.com; dmarc=bestguesspass action=none
  header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

  • Skenaario: SPF-tietueen tai DKIM-allekirjoituksen toimialue ei vastaa Lähettäjä-osoitteen toimialuetta.

  • Tulos: Viesti voi epäonnistua yhdistelmätodennuksessa:

    Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

Sähköpostin todennusvirheiden välttäminen lähetettäessä sähköpostia Microsoft 365:een

Vihje

Microsoft 365 -asiakkaat voivat seuraavien menetelmien avulla sallia viestin lähettäjiltä, jotka on tunnistettu huijaus- tai todennusvirheiksi:

  • Määritä SPF-, DKIM- ja DMARC-tietueet toimialueillesi: Käytä toimialuerekisteröijän tai DNS-isännöintipalvelun antamia määritystietoja. On myös kolmannen osapuolen yrityksiä, jotka ovat omistautuneet auttamaan sähköpostin todennustietueiden määrittämisessä.

    Monet yritykset eivät julkaise SPF-tietueita, koska ne eivät tunne toimialueensa viestien kaikkia sähköpostilähteitä.

    1. Aloita julkaisemalla SPF-tietue, joka sisältää kaikki sähköpostilähteet, joista tiedät (erityisesti missä yritysliikenne sijaitsee) ja käytä pakotussäännön arvoa "soft fail" (~all). Esimerkki:

      fabrikam.com IN TXT "v=spf1 include:spf.fabrikam.com ~all"

      Jos luot tämän SPF-tietueen, Microsoft 365 käsittelee yrityksen infrastruktuurista saapuvaa sähköpostia todennettuna, mutta tunnistamattomista lähteistä peräisin oleva sähköpostiviesti saattaa silti olla huijausta, jos yhdistelmätodennus epäonnistuu. Tämä toiminta on kuitenkin yhä parempi kuin kaikkien toimialueen lähettäjien lähettämät sähköpostiviestit, jotka Microsoft 365 on merkinnyt spoofiksi. Kohdesähköpostijärjestelmä hyväksyy yleensä tunnistamattomista lähteistä peräisin olevia toimialueen lähettäjien viestejä, kun SPF:lle on määritetty pehmeän vikasietoisuuden täytäntöönpanosääntö.

    2. Etsi ja sisällytä enemmän sähköpostilähteitä viesteillesi. Esimerkki:

      • Paikalliset sähköpostipalvelimet.
      • Sähköposti lähetetty ohjelmisto palveluna (SaaS) -palveluntarjoajalta.
      • Pilvipalvelusta (kuten Microsoft Azure, GoDaddy, Rackspace, Amazon Web Services) lähetetty sähköposti.

      Kun olet tunnistanut kaikki toimialueesi sähköpostilähteet, voit päivittää SPF-tietueesi käyttämään pakotussäännön arvoa "kova epäonnistuminen" (-all).

    3. Määritä DKIM allekirjoittamaan viestit digitaalisesti.

    4. Määritä DMARC vahvistamaan, että MAIL FROM- ja From-osoitteiden toimialueet vastaavat toisiaan, määrittämään, mitä tehdä viesteille, jotka eivät läpäise DMARC-tarkistuksia (hylkää tai karanteeniin), ja tunnistamaan raportointipalvelut DMARC-tulosten seuraamiseksi.

    5. Jos käytät joukko lähettäjiä sähköpostin lähettämiseen puolestasi, varmista, että Lähettäjä-osoitteen toimialue vastaa TOIMIaluetta, joka välittää SPF: n tai DMARC: n.

  • Isännöit toimialueen sähköpostia tai tarjoat isännöintiinfrastruktuuria, joka voi lähettää sähköpostia:

    • Varmista, että asiakkaillasi on dokumentaatio, jossa kerrotaan, miten SPF määritetään heidän toimialueilleen.
    • Harkitse DKIM-allekirjoittamista DKIM:n lähtevälle sähköpostille, vaikka asiakas ei eksplisiittisesti määritä DKIM:iä toimialueelleen (kirjaudu oletustoimialueella). Voit myös allekirjoittaa sähköpostin DKIM-allekirjoituksella (yrityksesi toimialueella ja asiakkaan toimialueella, jos/kun se on käytettävissä).

    Toimitus Microsoftille ei ole taattu, vaikka todentaisit sähköpostin, joka on peräisin käyttöympäristöstäsi. Sähköpostitodennus kuitenkin varmistaa, että Microsoft ei automaattisesti roskapostia asiakkaan toimialueilta yksinkertaisesti siksi, että sitä ei ole todennettu.