[ DMARC ja politiikka ]

Aliverkkotunnuksen DMARC -käytännöt: tarkista käytäntö, jota todella sovelletaan

Ennen kuin muutat aliverkkotunnuksen suojausta, erota lapsen selkeä käytäntö vanhempien löytämisestä ja nykyisestä sp- ja np-käsittelystä.

EmailAuth -tutkimusryhmä · 5 min lukuaika

[Avainkohdat]

  • Aloita tarkasta tekijän verkkotunnuksesta ja suorita käytäntöjen selvitys.
  • Erottele olemassa oleva ja olematon aliverkkotunnushoito.
  • Todista todennus ja käytännön valinta erikseen.
Tällä sivulla

Aliverkkotunnus DMARC tulos riippuu sen näkyvälle lähettäjälle -toimialueelle löydetystä käytännöstä ja viestin kohdistetusta todennusta varten. Vanhemman tietue on hyödyllinen todiste, mutta se ei kerro täydellistä tulosta jokaiselle lapselle.

Aloita tarkasta tekijän verkkotunnuksesta, mikä tarkoittaa näkyvässä Lähettäjä-osoitteessa olevaa verkkotunnusta. Selvitä, onko sillä selkeää sovellettavaa käytäntöä, kuinka etsintä etenee, kun se ei etene, ja mitä nykyistä käytännön semantiikkaa toteutus koskee.

Aloita tarkalla lapsen henkilöllisyydellä

Protokollaviitteet: RFC 9989 §4.10.1, RFC 9989 §5.3.6. Alla olevat toiminnalliset tarkistuslistat ja päätökset ovat toimituksellisia ohjeita.

Tallenna lapsen lailliset palvelut, DNS valtuudet ja edustajaviestit. Erikseen delegoidulla alivyöhykkeellä voi olla eri julkaisutili ja eri omistaja.

Kysy aiottua _dmarc -nimeä ja säilytä koko vastaus. Erottele poissaolo erottelukyvystä. Suoran lapsipolitiikan puuttuminen ei sinänsä tarkoita, etteikö politiikkaa voida löytää.

Käytä nykyistä etsintämääritystä ja toteutusta. Vältä lyhentämästä organisaation rajoja kahteen viimeiseen nimikkeeseen tai olettamasta, että jokaisella vastaanottimella on sama perintö ja päivitetty toimintatapa.

Erottele p, sp ja np

Protokollaviitteet: RFC 9989 §4.7, RFC 9989 §4.10.1. Alla olevat toiminnalliset tarkistuslistat ja päätökset ovat toimituksellisia ohjeita.

Virran alla RFC 9989, sovellettava organisaation verkkotunnuskäytäntö erottaa itse verkkotunnuksen, olemassa olevat aliverkkotunnukset ja ei-olemassa olevat aliverkkotunnukset.

  • Tag: p; Asiaankuuluva laajuus soveltuvin osin: Verkkotunnuksen käytäntö, joka tarjoaa myös sovellettavan varavaihtoehdon
  • Tag: sp; Soveltuva laajuus soveltuvin osin: Vallitsevan verkkotunnuksen nykyiset aliverkkotunnukset organisaation toimialue
  • Tag: np; Asiaankuuluva laajuus soveltuvin osin: Organisaation verkkotunnuksen olemattomat aliverkkotunnukset

Np-varamuutos on sp, kun se on olemassa, muuten p. Nykyinen määrittely selittää myös, miksi aliverkkotunnuksessa julkaistun käytännön sp ei tule yleiseksi ohitukseksi kaikille syvemmille nimille.

An:n puuttuminen MX tietue Yksin ei ole täydellinen verkkotunnuksen olemassaolotesti. Noudata määritettyä etsintä- ja olemassaolokäsittelyä sen sijaan, että luokittelet toimialueen yhdestä lyhyestä DNS näytöstä.

Käy läpi kattava käytäntöesimerkki

Protokollaviitteet: RFC 9989 §4.10.1. Alla olevat toiminnalliset tarkistuslistat ja päätökset ovat toimituksellisia ohjeita.

Oletetaan vain tässä synteettisessä esimerkissä, että example.com on vallitseva organisaation toimialue ja vastaanottaja toteuttaa nykyiset säännöt. Sen politiikka on:

v=DMARC1; p=none; sp=quarantine; np=reject

Oletetaan, että news.example.com on olemassa, eikä sillä ole suoraa käytäntöä, joka muuttaa löydettyä tulosta. Ylätason käytäntöjen sp-arviointi on olennainen, jos posti epäonnistuu kyseisellä olemassa olevalla aliasetuksella. Jos lapsi on sovellettavien sääntöjen mukaan todettu olemattomaksi, np on olennainen.

Oletetaan nyt, että pay.example.com on oma voimassa oleva selkeä käytäntö:

v=DMARC1; p=reject

Tämän lapsen soveltuva suora kirjaus on arvioitava löydön yhteydessä. Vanhemman none-arvo ei ole riittävä kuvaus lapsen käytännöstä. Älä myöskään päättele jokaisen lapsenlapsen tulosta pelkästään liittämällä sp kyseiseen lapsitietueeseen.

Nämä esimerkit kuvaavat politiikan valintaa olettamustensa mukaisesti. He eivät väitä, että kaikki käyttöönotetut vastaanottimet toteuttavat jokaista päivitettyä toimintaa tai että pyydetty sijoittelu tapahtuu yleisesti.

Tarkista todennus lapsen oikeilla reiteillä

Protokollaviitteet: RFC 9989 §4.4.1, RFC 9989 §4.4.2, RFC 9989 §5.3.5. Alla olevat toiminnalliset tarkistuslistat ja päätökset ovat toimituksellisia ohjeita.

Tarkista alkuperäinen vastaanotettu posti jokaisesta tärkeästä alatason verkkotunnuspalvelusta. Vertaa From, SPF identiteettiä ja relevanttia DKIM d= identities under the applicable linjaus tilat.

Lapsikäytäntö ei määritä allekirjoittamista lapselle. Palvelu saattaa todentaa oman riippumattoman toimialueensa, kun taas toisen palvelun tuetut allekirjoitusmääritykset kohdistavat onnistuneesti.

Käytä kohdistusopas kulkevan polun luomiseksi. Testaa lopullisten yhdyskäytävien tai edelleenlähetysreittien jälkeen sen sijaan, että luottaisi vain eristettyyn suoralähetykseen.

Hyväksy käytäntömuutokset alatason verkkotunnuksen käyttöä vastaan

Protokollaviitteet: RFC 9989 §7.4. Alla olevat toiminnalliset tarkistuslistat ja päätökset ovat toimituksellisia ohjeita.

Erillinen sovelluksen aliverkkotunnus voi erota kirjeenvaihto- tai postituslistan toimialueesta. Tarkista nykyiset yhteentoimivuusohjeet ja liiketoiminnan seuraukset ennen kuin ehdotat hylkäämistä.

Säilytä tarkat muutokset, valtuutus, hyväksyjä ja palautusehdot. Jos vanhemman ja lapsen asetuksia muutetaan yhdessä, tallenna riippuvuus ja testaa kutakin tekijän toimialuetta erikseen.

Lausunto, kuten kaikki suojatut aliverkkotunnukset, tarvitsee määritellyn laajuuden ja todisteet. Sisällytä delegoidut vyöhykkeet, lepäävät palvelut ja ratkaisematon omistajuus sen sijaan, että käsittelisit yhtä vanhemman hakua portfolioarviona.

Säilytä tulosten selittämiseen tarvittavat todisteet

Säilytä kunkin arvioidun identiteetin osalta kysytty nimi, tehokas löydetty käytäntö, asiaankuuluva p/sp/np-tulkinta, DNS havainnot, toteutuskonteksti ja vastaanotettujen viestien tulokset.

Arvioi uudelleen, kun lapsivyöhyke on delegoitu, palvelu otetaan käyttöön tai verkkotunnuksen tarkoitus muuttuu. DMARCbis -valmius kattaa päivitetyt etsintäriippuvuudet, kun taas lähettäjän inventaario pitää lailliset reitit vastuullisina.

Käytä todisteita liioittelematta sitä

Vanhemman politiikan järjestelyssä nykyiset uutiset käyttävät karanteenia vain ilmoitettujen löytöoletusten mukaisesti; todetut olemattomat lapsikäytöt hylkäävät ja maksavat voimassa olevat suorat käytännöt hylkäävät. Pyydetty arviointi ei vielä takaa lopullista käsittelyä. Säilytä todellinen kysely ja käytäntöjen valinta sen sijaan, että keksit testituloksia.

[ Takeaway ]

Aloita tarkasta tekijän verkkotunnuksesta ja suorita käytäntöjen selvitys. Erottele olemassa oleva ja olematon aliverkkotunnushoito. Todista todennus ja käytännön valinta erikseen.

[ Roolin mukaan ]

Mitä tämä tarkoittaa sinulle

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

IT / Mail Admin

Jäljityskäytäntö ja todennus erikseen.

Dokumentoi tarkka tekijän verkkotunnus, etsintätulos ja sovellettava p/sp/np-semantiikka ja vahvista sitten itse viestit.

Seuraavat vaiheet

  1. Erottele puuttuvat tietueet DNS virheestä.
  2. Tarkista delegoitu lapsioikeus.
  3. Testaa suoria ja asiaankuuluvia epäsuoria reittejä.

CISO / SecOps

Laajuus salkun vakuutus huolellisesti.

Vaadi kaikkia aliverkkotunnuksia koskevien vaatimusten määritelmä ja kattavuus. Käytännön soveltuvuus ja laillisen sähköpostin vaikutus voivat vaihdella portfolion välillä.

Seuraavat vaiheet

  1. Tarkista ratkaisemattomat omistajuudet ja delegoidut vyöhykkeet.
  2. Säilytä käyttöönoton yhteensopivuustodisteet.
  3. Hyväksy ja valvo soveltamisalaan kuuluvia poikkeuksia.

Perustaja / ei-tekninen

Kysy, mitä aliverkkotunnuksia yritys todella käyttää.

Yksittäinen päätoimialueen tarkistus ei ole luettelo sovellusidentiteeteistä, delegoiduista vyöhykkeistä tai lepotilasta.

Seuraavat vaiheet

  1. Nimeä yritysten omistajat aktiivisille lapsipalveluille.
  2. Sisällytä ulkoistettu DNS ja sovellusriippuvuudet.
  3. Pyydä kriittisen reitin todisteita.

[ UKK ]

Usein kysytyt kysymykset

Tarkoittaako puuttuva lapsitietue aina sitä, ettei DMARC käytäntöä sovelleta?

Ei. Noudata soveltuvia etsintäsääntöjä. Vanhemmalla tai muulla näiden sääntöjen mukaisella käytännöllä voi olla merkitystä; suora haku on vain osa todisteita.

RFC 9989 §4.10.1

Mitä eroa on sp:n ja np:n välillä?

Nykyisessä DMARC semantiikassa sp koskee sovellettavia olemassa olevia aliverkkotunnuksia ja np koskee organisaation toimialueen soveltuvia ei-olemassa olevia aliverkkotunnuksia.

RFC 9989 §4.7

Mitä tapahtuu, jos np puuttuu?

Nykyisen määrityksen mukaan sovellettava ei-olemassa olevien aliverkkotunnusten käsittely palautuu arvoon sp, kun se on olemassa, muuten p. Tarkista todellinen etsintä- ja toteutuskonteksti.

RFC 9989 §4.7

Voinko tunnistaa olemattoman verkkotunnuksen vain siksi, että sillä ei ole MX ?

Ei. Määritysten vastaanottaminen ei ole täydellinen toimialueen olemassaolon testi. Säilytä DNS vastaukset ja noudata määritettyä olemassaolokäsittelyä.

RFC 9989 §3.2.13

Voiko lapsia koskeva käytäntö poiketa vanhemman käytännöstä?

Kyllä. Määritä sovellettava suora lapsitietue ja etsintätulos sen sijaan, että kuvailisit jokaista lasta pelkästään vanhemman p-arvon perusteella.

RFC 9989 §4.10.1

Hallitseeko lapsitietueen sp automaattisesti jokaista lastenlasta?

Älä oleta sitä. Nykyinen RFC 9989 selittää käytäntöjen löytämisen vaikutuksen aliverkkotunnuksissa julkaistuihin sp:ihin. Tarkista asianmukaisen tekijän verkkotunnuksen todellinen tulos.

RFC 9989 §4.7

Ottaako DMARC alatietue käyttöön DKIM allekirjoituksen?

Ei. Määritä lapsen todellinen lähetyspalvelu ja tarkista vastaanotetun viestin kulkeva kohdistettu polku.

RFC 9989 §5.3.5

Mikä tukee väitettä, että aliverkkotunnus on suojattu?

Säilytä sen palveluluettelo, DNS valtuudet, löydetyt käytännöt ja toteutuskonteksti sekä edustavat luotettavat viestitulokset ja kaikki soveltamisalaan kuuluvat poikkeukset.

[ Lähteet ]

Lähteet

  1. RFC 9989

    Osat §3.2.13 · §3.2.2 · §4.10.1 · §4.4.1 · §4.4.2 · §4.7 · §5.3.5 · §5.3.6 · §5.4 · §7.4

[ Sanasto ]

Sanasto

Tekijän verkkotunnus
Kohdistusviitteenä käytetty toimialue viestin Lähettäjä-kentässä.

RFC 9989 §3.2.2

Politiikka vastaan ​​käsittely
Julkaistu arviointi ja vastaanottajan loppukäsittely ovat erillisiä; paikallinen käytäntö voi vaikuttaa käsittelyyn.

RFC 9989 §5.4

Todisteen laajuus
Toimialueet, reitit, aikaikkuna ja oletukset, jotka tarkastelu todella kattaa; tämä on toiminnallinen tietue, ei protokollatulos.

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