Tekoälyjärjestelmän luoma posti kulkee edelleen sovelluksen, lähetyspalvelun ja verkkotunnuksen identiteetin kautta. Inventoi nämä komponentit sen sijaan, että käsittelisit tekoälyn luomaa uutta todennusluokkaa. Vastaanotin arvioi protokollan identiteetit ja allekirjoitukset, ei sitä, onko tekstin kirjoittanut ihminen vai malli.
Erottele identiteetit postikulussa
Tallenna näkyvä From domain, SMTP kirjekuoren lähettäjä verkkotunnus, DKIM verkkotunnuksen allekirjoittaminen ja valitsin, palveluntarjoajan tilin ja sovelluksen kirjautumistietojen omistaja. Kolme ensimmäistä palvelevat erilaisia protokollarooleja. RFC 9989 määrittelee DMARCsuhde Lähettäjä-verkkotunnukseen ja tasattu SPF tai DKIM tuloksia. Paikallinen osa ja näyttönimi eivät ole DMARC :n perusta verkkotunnuksen kohdistus.
Palveluntarjoajan infrastruktuuritoimialue voi todentaa onnistuneesti ilman, että se on linjassa organisaation näkyvän From-verkkotunnuksen kanssa. Päinvastoin tasainen DKIM -allekirjoitus voi tukea DMARC ia, kun SPF polku ei ole kohdistettu. Älä diagnosoi tulosta yhden passin tunnisteen perusteella tunnistamatta, minkä toimialueen tulos todentaa.
Määritä organisaation omistajuus erikseen
Kartoita viesti todelliselle palveluntarjoajan vuokralaiselle, sovellukselle, liiketoiminnalle ja vastuulliselle tiimille. Jaetut IP-osoitteet ja palveluntarjoajan nimet ovat vihjeitä, eivät riittävät todisteet siitä, että tietty lähettäjä kuuluu organisaatioon. Pyydä sovelluksen omistajaa vahvistamaan, miten palvelu tarjotaan ja mitä tunnistetietoja tai allekirjoitusasetuksia se käyttää.
DKIM erottaa allekirjoittaneen verkkotunnuksen vastuun väitetystä tekijästä. Kelvollinen allekirjoitus ei tunnista ihmistä, joka on hyväksynyt viestin, validoi tekoälymallia tai varmentaa sen sisältöä. Säilytä sovellustason tarkastustietueita näitä kysymyksiä varten.
Vertaa kolmea hypoteettista identiteettitapausta
Oletetaan tiukka kohdistus ja From alerts.example . Tapauksessa A, SPF hyväksynnät riippumattomalle palveluntarjoajalle ja kelvollinen DKIM -allekirjoitus käyttää d=alerts.example: tasattu DKIM polku antaa DMARC passin. Tapauksessa B, SPF ja jokainen kelvollinen DKIM -allekirjoitus käyttävät toisiinsa liittymättömiä palveluntarjoajan verkkotunnuksia, joten kumpikaan polku ei tasaa. Tapauksessa C vain markkinoinnin näyttönimi muuttuu, kun taas verkkotunnuksen identiteetit ja todennustulokset pysyvät ennallaan; verkkotunnuksen kohdistus ei muutu.
Nämä ovat käsin tehtyjä identiteettivertailuja, eivät suoritettua arvioijaa tai allekirjoitustestiä. He olettavat, että kaikki asiaankuuluvat polut huomioidaan, eivätkä ne toteuta rentoa kohdistusta, käytäntöjen löytämistä tai vastaanottimen sijoittelua. Under RFC 9989 kohdat 7.4 ja 8, p=reject Käyttöönotto erikseen edellyttää kelvollisia DKIM -allekirjoituksia ja kieltää luottamuksen yksinomaan SPF ään. Sanomatason passi ei vapauta tätä velvoitetta.
Tarkista määritykset tarrojen uudelleenkirjoittamisen sijaan
Tallennetun kentän muuttaminen palveluntarjoajan toimialueesta kenttään alerts.example ei tee palvelumerkkiä kyseiseksi toimialueeksi. Käytä palveluntarjoajan tuettuja tilimäärityksiä ja valtuutettuja DNS arvoja ja testaa sitten todellista reittiä ja luotettavaa vastaanottimen näyttöä. Jos kokoonpanon uudelleenluku täsmää, mutta esimerkki käyttää edelleen vanhaa allekirjoitusidentiteettiä, jätä sanomapolun tulos epäonnistuneeksi tai ratkaisematta sen sijaan, että käsittelet tiedoston muokkausta korjattuna todentamisena. Tämä on hypoteettinen diagnostinen raja, ei paikallinen muunnos, todellinen hyväksyntä tai DNS julkaisu.
Valitse ylläpidettävä lähetysmuoto
Käytä dokumentoitua lähetystunnusta, jota organisaatio voi valvoa, kiertää ja peruuttaa. Erottele virrat tai aliverkkotunnukset, kun se parantaa omistajuutta ja toiminnallista eristystä, mutta älä vaadi aliverkkotunnusta takaa maineen eristämisen tai toimituksen. Tarkista palveluntarjoajakohtainen verkkotunnus ja allekirjoitusmääritykset nykyisten ensimmäisen osapuolen ohjeiden perusteella ennen käyttöönottoa.
Seuraa jokaista agenttia tai sovellusta, joka jakaa lähettäjän tunnistetiedot. Jos yksi avain palvelee useita toisiinsa liittymättömiä palveluita, todennusraportti ei välttämättä tunnista, mikä sovellus loi viestin. Paranna sovellusten kirjaamista ja tunnistetietojen erottelua sen sijaan, että liioittelet sitä, mitä DMARC voi paljastaa.
Kun sovellus lakkaa toimimasta, peruuta sen lähetysoikeudet, tarkista sen palveluntarjoajan kokoonpano ja poista vanhentunut valtuutus vasta, kun olet tarkistanut jaetut riippuvuudet. Ylläpidä testattavaa inventaariota, joka yhdistää verkkotunnuksen todisteet yrityksen omistukseen. Nämä suositukset ovat toimittajariippumattomia eivätkä vaadi erityistä EmailAuth integraatiota tai automaattista attribuutiokykyä.