[ Yritystoiminta ]

Pysäköityjen, puolustavien ja hankittujen verkkotunnusten hallinta yhdessä

Käytä yhtä portfoliorekisteriä säilyttäen samalla erilliset lähetys- ja vastaanottopäätökset kullekin verkkotunnukselle.

EmailAuth -tutkimusryhmä · 3 min lukuaika

[Avainkohdat]

  • Käytä yhtä portfoliorekisteriä säilyttäen samalla erilliset lähetys- ja vastaanottopäätökset kullekin verkkotunnukselle.
  • Vahvista lähettäminen ja vastaanottaminen erikseen; tuntematon käyttö ei voi oikeuttaa kumpaankaan suuntaan poistamista käytöstä.
Tällä sivulla

Varatut, puolustavat ja hankitut verkkotunnukset kuuluvat yhteen omistusohjelmaan, mutta ne eivät saa periä yhtä testaamatonta DNS mallia. Selvitä ensin, kuka hallitsee kutakin verkkotunnusta ja lähettää tai vastaanottaako se laillista postia. Hankintatunniste kertoo, kuinka verkkotunnus saapui, ei se, onko sen sähköpostipalvelut turvallista poistaa käytöstä.

Tallenteen tarkoitus ennen tietueiden valintaa

Dokumentoi rekisterinpitäjä ja DNS -tilin omistaja, yrityksen sponsori, uusimisvastuu, lähetystarkoitus, vastaanottotarkoitus ja tunnetut aliverkkotunnukset. Pidä tilisalaisuudet poissa rekisteristä. Sisällytä hankitun verkkotunnuksen entinen järjestelmänvalvoja ja ratkaisemattomat sovellusriippuvuudet. Puolustava rekisteröinti voi silti vastaanottaa juridista tai palautusta koskevaa kirjeenvaihtoa, joten vahvista käytön vastaanottaminen käytön lähettämisestä riippumatta.

Käytä kussakin kysymyksessä vähintään kolmea tilaa: kyllä, ei tarkastelun jälkeen ja tuntematon. Tyhjästä kentästä ei saa tulla ei. Sisällytä ajoitetut työt, verkkosivustolomakkeet, toimittajien ilmoitukset, lepäävät katastrofipalautusjärjestelmät ja kausiluonteiset kampanjat piilotetun virran katsaukseen. Tämä on suositeltu toiminnan tarkistuslista, ei DNS tietueen suorittama testi.

Valitse säätimet oikeaan suuntaan

Null MX on single MX tietue mieluummin nolla ja juurinimikkeen vaihto, joka esitetään tavallisesti 0:na; se ilmoittaa, ettei kyseiselle toimialueelle hyväksy postia, eikä se saa olla rinnakkain muiden MX tietueiden kanssa. Se ei tarkoita, että verkkotunnus ei lähetä sähköpostia. RFC 7505 , kohdat 3 ja 4. Älä vaihda toimivia saapuvia MX tietueita, koska lähtevä liikenne näyttää puuttuvan. RFC 7505 osio 4.2 sanoo myös, että järjestelmien EI PIDÄ julkaista Null MX ää verkkotunnuksille, joita käytetään POSTIA LÄHETTÄJÄ tai näkyvissä osoitteista, koska posti on vaarassa hylätä. Kampanjaverkkotunnukselle, joka lähettää mutta ei vastaanota, ei siksi tule määrittää Null MX automaattisesti.

Vahvistusta varten ei-lähettävä verkkotunnus, tarkkaan SPF ennätys v=spf1 -all, with no positive mechanisms, expresses that no sending hosts are authorised for the evaluated SPF identiteetti. Ennätys aiemmilla positiivisilla mekanismeilla voi valtuuttaa vastaavat isännät, vaikka se päättyy -all . DMARC ilmaisee erikseen käytännön näkyvän From-toimialueen käyttämiselle, kun kohdistettu todennus epäonnistuu. Kumpikaan ei estä esiintymistä näyttönimen toisena henkilönä tai samankaltaisia ​​verkkotunnuksia. RFC 7208 , kohta 5.1 ja RFC 9989. Tarkista aliverkkotunnusten ja käytäntöjen löytämiskäyttäytyminen sen sijaan, että olettaisit, että jokaisella lapsen nimellä on sama kokoonpano.

Päätä erikseen neljästä verkkotunnuksesta

Harkitse neljää hypoteettista tarkastelun tulosta. Palkanlaskenta lähettää ja vastaanottaa, joten molempien hyväksyttyjen ohjeiden on oltava saatavilla. Kampanjan verkkotunnus lähettää, mutta se ei ole vahvistanut, ettei se ole vastaanottanut käyttöä, joten lähtevän todennus ja kaikki vastaanottopäätökset ovat riippumattomia. Puolustava rekisteröinti ei tee kumpaakaan piilovirtatarkistuksen jälkeen, joten se soveltuu rajoittavaan valvontaan. Peritty verkkotunnuksen tarkoitus on tuntematon, joten sen määritykset jäävät odottamaan tutkimusta.

Nämä ovat oletettuja syötteitä, ei suoritettua koodia, omistajahaastatteluja tai DNS havaintoja. Perityn verkkotunnuksen osalta hiljainen raportointiikkuna ei voi muuttua tuntemattomaksi ei. Anna sovelluksen entinen omistaja ja nykyinen rekisterinpitäjä ratkaisemaan palveluriippuvuudet ennen muutoksen hyväksymistä. Tarkista lasten nimet erikseen; ylätason tietue ei ole todiste siitä, että jokaisella aliverkkotunnuksella on sama käyttötarkoitus.

Pidä portfolio ylläpidettävänä

Ota muutokset käyttöön tallennetun hyväksymis- ja vahvistusprosessin kautta. Säilytä vanhat RRsetit, testaa vaikuttavia palveluita ja vahvista auktoriteetti hyväksytyn mutaation jälkeen. Tallenna verkkotunnuksen elinkaarivaihe, tarkistuspäivämäärä ja seuraava omistajan toiminta. Älä anna hankintapoikkeuksen tulla pysyväksi tuntemattomaksi.

Tarkista tarkoitus uudelleen, kun varatusta verkkotunnuksesta tulee kampanjasivusto, omistajan vaihtuessa tai ennen eläkkeelle siirtymistä. Pidä rekisteröinnit ja uusimiset vastuullisena omistuksessa, vaikka sähköposti olisi poistettu käytöstä. Verkkotunnuksen vähäinen aktiivisuus ei poista sen arvoa yritysidentiteettinä.

[ Takeaway ]

Vahvista lähettäminen ja vastaanottaminen erikseen; tuntematon käyttö ei voi oikeuttaa kumpaankaan suuntaan poistamista käytöstä.

[ Roolin mukaan ]

Mitä tämä tarkoittaa sinulle

Valitse roolisi ja seuraa käytännön toimia.

IT / Mail Admin

Erilliset postiohjeet

Älä johda saapuvan liikenteen asetuksia lähtevän liikenteen hiljaisuudesta.

Seuraavat vaiheet

  1. Tallenna lähetys ja vastaanotto itsenäisesti.
  2. Säilytä tuntemattomat tilat, kunnes ne tutkitaan.
  3. Tarkista lapsiverkkotunnuksen käyttö ennen rajoittavien tietueiden käyttöä.

CISO / SecOps

Hallitse elinkaaren epävarmuutta

Hankitut omaisuuserät tarvitsevat todisteita ennen standardointia.

Seuraavat vaiheet

  1. Seuraa perinnöllisiä omistajuuden puutteita.
  2. Tarkista poikkeukset, kun tarkoitukset muuttuvat.
  3. Seuraa tuntematonta vastaanottotarkoitusta erillään tuntemattomasta lähetyksestä.

Perustaja / ei-tekninen

Pidä puolustusvarat tilivelvollisina

Käyttämätön sähköpostitoiminto vaatii edelleen omistajan ja uusimissuunnitelman.

Seuraavat vaiheet

  1. Määritä sponsori jokaiselle verkkotunnukselle.
  2. Vahvista liikekirjeenvaihto ennen vastaanoton poistamista.
  3. Määritä uusimisvastuu puolustaville rekisteröinneille.

[ UKK ]

Usein kysytyt kysymykset

Pysäköityvätkö hankitut verkkotunnukset automaattisesti?

Ei. He voivat tukea live-palveluita, joita ei ole vielä inventoitu.

Voiko ei-lähettävä verkkotunnus silti vastaanottaa postia?

Kyllä. Lähetys ja vastaanottaminen ovat itsenäisiä päätöksiä.

Mitä Null MX muuttaa?

Se ilmoittaa, ettei saapuvan postin palvelua, ei lähtevän postin todennusta. RFC 7505 osio 4.2 sanoo, että järjestelmien EI SAA julkaista sitä verkkotunnuksille, joita käytetään MAIL FROM -osoitteissa tai näkyvissä Lähettäjä-osoitteissa, koska lähetetyt viestit hylätään.

Voiko Null MX olla rinnakkain toimivan MX kanssa?

Ei. RFC 7505 määrittää, että Null MX -toimialue ei saa mainostaa muita MX tietueita.

Mitä tuntematon tarkoittaa rekisterissä?

Todisteet eivät riitä hyväksymään tarkoitukseen perustuvaa muutosta.

Pitääkö piilotettujen kulujen sisältää aliverkkotunnuksia?

Kyllä. Dokumentoi alatason nimet ja valtuutetut palvelut erikseen, jos niillä on erillinen käyttötarkoitus.

Lopettaako hylkääminen jokaisen toisena henkilönä esiintymisen?

Ei. DMARC ei poista samankaltaisten verkkotunnusten tai näyttönimien hyökkäyksiä.

Milloin tarkoitusta pitäisi tarkistaa uudelleen?

Katsaus elinkaarimuutoksiin, yritysostoihin, palvelun aktivointiin ja suunniteltuun eläkkeelle siirtymiseen.

[ Lähteet ]

Lähteet

  1. RFC 7505 Nolla MX -resurssitietue verkkotunnuksille, jotka eivät hyväksy postia

    Osat §3 · §4.1 · §4.2

  2. RFC 7208 Sender Policy Framework

    Osat §2.3 · §2.4 · §5.1

  3. RFC 9989 Domain-pohjainen viestien todennus, raportointi ja vaatimustenmukaisuus

    Osat §4.4 · §4.10.1 · §5.3.5 · §5.4 · §7.4 · §8

  4. RFC 9990 DMARC Aggregate Reporting

    Osat §3.1 · §3.1.1

[ Sanasto ]

Sanasto

Varattu verkkotunnus
Rekisteröity verkkotunnus, jota ei tällä hetkellä käytetä sille tarkoitettuun aktiiviseen palveluun; sähköpostin käyttö vaatii vielä vahvistuksen.
SPF
Protokolla, jolla arvioidaan, onko lähettävä isäntä valtuutettu kirjekuoreen tai HELO identiteettiin.

Yrityksen alkuperä

Miksi parhaat rahoituslaitokset ja hallitukset lopettivat sähköpostin suojauksen hallintapaneelinsa.

Perinteiset sähköpostin todennusalustat myyvät sinulle kojelaudan ja pyytävät insinöörejäsi tekemään työtä. Korkeiden panosten ympäristöissä manuaalinen valvonta tarkoittaa viivästynyttä täytäntöönpanoa, konfiguraatioiden siirtymistä ja valvomattomia varjoalueita.

EmailAuth on agentti sähköpostin alkuperäalusta. Agenttimme valvovat p=reject, pidä kolmannen osapuolen lähettäjät kohdakkain ja siirrä verkkotunnuksesi täyteen RFC 9989 noudattaminen, uusi DMARC standardi, jossa on in-the-loop -tarkastettavuus.

hallitukset Suuret yritykset Tason 1 rahoituslaitokset

SaaS · Dedikoitu vuokrasopimus · Ilmarakoinen on-prem · BYOK-salaus

Tietokanta