[ DNS ja verkkotunnukset ]

Nolla- MX tietueet verkkotunnuksille, jotka eivät hyväksy sähköpostia

Ilmoita, että verkkotunnus ei hyväksy sähköpostia ilman, että annat vahingossa ymmärtää, että se ei voi lähettää tai että sen aliverkkotunnukset perivät ilmoituksen.

EmailAuth -tutkimusryhmä

[Avainkohdat]

  • Ainoa MX 0 -piste ilmoittaa, että juuri tämä verkkotunnus ei hyväksy postia.
  • Poissaolevalla MX llä ja Null MX on erilainen SMTP reitityskäyttäytyminen.
  • Varaston vastaanottotarpeet ja lähetysohjaimet on tarkasteltava erikseen.
Tällä sivulla

Verkkotunnus, jonka numero MX tietue ei välttämättä ole verkkotunnus, joka kieltää postin. SMTP voi palata osoitteenhakuun, kun MX tietoja ei ole. Null MX on olemassa ilmaisemaan, että verkkotunnus ei hyväksy sähköpostia, ja välttämään tämän epäselvän varapuheenvuoron.

Julkaise selkeä ei-palveluvastaus

Viitteet: RFC 7505 §3.

RFC 7505 määrittelee Null MX yhdeksi MX -tietueeksi, jonka etusija on nolla, ja juuriverkkotunnuksen sen vaihdoksi: example.com . 300 IN MX 0 .. Piste on merkityksellinen. Se ei ole paikkamerkki isäntänimelle ja paikallinen isäntä ei ole vastaava. Null MX ää mainostava verkkotunnus ei saa mainostaa myös toista MX tietuetta.

Käytä Null MX vasta sen jälkeen, kun olet varmistanut, ettei kyseisen toimialueen osoitteiden tarvitse vastaanottaa postia. Sisällytä luetteloon tilin palautus, hankinnat, oikeudelliset ilmoitukset, roolitilit ja vähäisen määrän operatiiviset osoitteet. Näennäisesti passiivinen verkkotunnus voi silti olla jonkun palautusosoite.

Erilliset vastaanotto- ja lähetysohjaimet

Viitteet: RFC 7505 §4.2, RFC 7208 §5.1, RFC 9989 §4.10.1.

Null MX on vastaanottava ilmoitus. Se ei todenna lähtevää postia, julkaise SPF käytäntöä tai tehdä verkkotunnuksesta immuuni toisena henkilönä esiintymiselle. RFC 7505 suosittelee olemaan käyttämättä Null MX ää toimialueille, joita käytetään SMTP MailFrom - tai viestin Lähettäjä-osoitteissa, koska vastaanottajat voivat hylätä kyseisen postin. Käytä tarkistettua vastaanotto- ja palautusosoitesuunnittelua laillisille lähettäjille sen sijaan, että käsittelisit Null MX vaarattomana lähtevän viestinä.

Jos toimialueelle ei ole tarkoitus lähettää eikä vastaanottaa, arvioi eksplisiittiset lähtevät ohjaimet erillisenä muutoksena. SPF v=spf1 -all on havainnollistava SPF identiteetin epääminen, kun lähettäjää ei ole valtuutettu. A DMARC politiikka edellyttää politiikan laajuuden, aliverkkotunnusten ja raportoinnin nimenomaista arviointia. Älä liitä yleistä ohjausjoukkoa toimialueeseen, jonka lähetysluettelo on epätäydellinen.

Testaa negatiivista reittiä tarkoituksella

Viitteet: RFC 5321 §5.1, RFC 7505 §3.

Eristetyllä vyöhykkeellä kiinnikkeellä A on noreceive.example . IN MX 0 . ja an Ennätys sen verkkosivuille. Odotettu postin reititys tunnistaa Null MX sen sijaan, että palaisi kyseiseen verkko-osoitteeseen. Ottelussa B on A-tietue, mutta ei MX ; SMTP :n implisiittinen MX-käyttäytyminen on eri tapaus. Fixture C yhdistää Null MX tavalliseen vaihtoon, ja se on virheellinen kokoonpano, ei tuettu vikasietosuunnitelma.

Kysely dig @AUTH noreceive.example . MX +norecurse jokaiselle voimassa olevalle ottelulle ja säilytä täydellinen vastaus. Varmista, että Null MX -tapaus palauttaa täsmälleen tarkoitetun yksittäisen tietueen. Tarkista sitten sen käsittely ohjatun SMTP lähettimen avulla lähettämättä ei-toivottua liikennettä asiaankuulumattomaan infrastruktuuriin. DNS tapaukset ovat testimäärityksiä tässä; todellinen lähettäjän toiminta odottaa suoritusta.

Vahvista tarkka laajuus

Viitteet: RFC 4592 §3.3, RFC 8767 §4.

Null MX klo example.com ei ole automaattisesti MX tietue osoitteessa sub.example.com. Testaa nimet erikseen, mukaan lukien jokerimerkit ja delegoidut haarat. DNS puute, jokerimerkkisynteesi ja eksplisiittiset tietueet voivat johtaa erilaisiin reitteihin.

Dokumentoi vastaanottamatta jättämistä koskeva päätös yrityksen omistajalle ja pyydä toista tarkistajaa tarkistamaan tarvittaessa valvontasuunnitelma, jossa ei ole lähetetty. Tämä opas ei väitä, että tällainen hyväksyntä olisi tapahtunut. Palaa hyväksytyn DNS prosessin läpi, jos vaadittu osoite löytyy, jolloin välimuistissa olevat tietueet sallitaan. Sulkeminen vaatii suunnitellun julkaistun reitin ja itsenäisesti tarkistetun inventaarion, ei vain onnistunutta DNS tallennusta.

Säilytetty haku ja tarkistettava ohjaussuunnitelma

Säilytetty historiallinen kaappaus 7. marraskuuta 2026, joka on tarkastettu, mutta sitä ei suoritettu uudelleen tätä tarkistusta varten, tallentaa, että synteettiselle noreceive.example MX palasi täsmälleen 0 .; säilytetty sieppaus sisältää kyselyn, langanvastauksen, UTC-ajan ja auktoriteetin päätepisteen. Mukana oleva konkreettinen ei-lähetyssuunnitelma yhdistää tuon MX yhteen SPF :ään -all käytäntö ja havainnollinen DMARC hylkäyskäytäntö kiinnittimelle, jonka oletetaan olevan laillista postia. Siinä luetellaan palautusosoitteen ja aliverkkotunnuksen esitarkastukset, raportointitietojen rajoitukset, vastaanottimen testausrajat ja palautus. Suunnitelman riippumaton arviointi on tarkistusportti, ei yrityksen omistajan hyväksyntä. Todellinen asiakasvarasto ja mahdollinen julkinen käyttöönotto jäävät vahvistamatta.

Pidä todisteiden laajuus selkeänä

Historiallinen Null MX -vastaus säilytetään lankatavuineen ja takaisinkytkentäpäätepisteineen. Siihen liittyvä ei-lähettämissuunnitelma on synteettinen ehdotus, jossa on varastooletuksia; sen säilyttäminen tai tämä sisällön tarkistus eivät anna asiakkaiden hyväksyntää tai testaa vastaanottimen todellista käsittelyä.

[ Takeaway ]

Ainoa MX 0 -piste ilmoittaa, että juuri tämä verkkotunnus ei hyväksy postia. Poissaolevalla MX llä ja Null MX on erilainen SMTP reitityskäyttäytyminen. Varaston vastaanottotarpeet ja lähetysohjaimet on tarkasteltava erikseen.

[ Roolin mukaan ]

Mitä tämä tarkoittaa sinulle

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

IT / Mail Admin

Julkaise yksiselitteinen reitti

Null- MX on oltava ainoa MX , ja aliverkkotunnukset tarvitsevat oman arvioinnin.

Seuraavat vaiheet

  1. Julkaise täsmälleen yksi MX 0 -pistetietue.
  2. Testaa implisiittisiä MX- ja eksplisiittisiä nollatapauksia.
  3. Tarkista jokainen asiaankuuluva aliverkkotunnus.

CISO / SecOps

Tarkista ei-lähettämissuunnitelma

Vastaanottava ilmoitus ei korvaa lähtevän todennuksen valvontaa.

Seuraavat vaiheet

  1. Erilliset vastaanotto- ja esiintymisohjaimet.
  2. Vaadi itsenäisesti tarkastettu lähetysinventaari.
  3. Kirjaa politiikan laajuus ja poikkeukset.

Perustaja / ei-tekninen

Tarkista huomiotta jääneet vastaanottotarpeet

Palautus ja vähäiset yritysosoitteet voivat tehdä näennäisesti käyttämättömästä verkkotunnuksesta tärkeän.

Seuraavat vaiheet

  1. Varaston palautus ja yritysten osoitteet.
  2. Hyväksy vastaanottopäätös.
  3. Pidä nimetty palautusomistaja.

[ UKK ]

Usein kysytyt kysymykset

Eikö mikään MX ole sama kuin Null MX ?

Ei. Poissa oleva MX voi sallia SMTP osoitteen palautuksen.

RFC 5321 §5.1

Mikä on tarkka Null MX -arvo?

Preference 0 ja vaihtopiste ilmaistuna muodossa MX 0 .

RFC 7505 §3

Voinko säilyttää MX varmuuskopion?

Ei. Null MX ei saa olla rinnakkain muiden kyseisen verkkotunnuksen MX tietueiden kanssa.

RFC 7505 §3

Lopettaako Null MX lähtevän huijauksen?

Ei. Lähetystodennus ja toimialueen käytäntö vaativat erilliset ohjausobjektit.

Voiko verkkotunnus silti isännöidä verkkosivustoa?

Kyllä. Null MX koskee postin vastaanottoa, ei HTTP-palvelua.

RFC 7505 §1

Kattaako ylätason asetus aliverkkotunnukset?

Ei automaattisesti. Tarkista jokainen asiaankuuluva DNS -nimi ja sen tietueet.

RFC 4592 §3.3

Pitäisikö palautusosoitteet tarkistaa ensin?

Kyllä. Pienimääräiset käyttö- ja palautustilit voivat olla helposti hukattu.

Onko ehdotettu lähettämättä jättämissuunnitelma hyväksytty tässä oppaassa?

Ei. Riippumaton tarkistus ja verkkotunnuksen omistajan hyväksyntä vaaditaan.

[ Lähteet ]

Lähteet

  1. RFC 5321

    Osat §5.1

  2. RFC 7505

    Osat §1 · §3 · §4.2

  3. RFC 7208

    Osat §5.1

  4. RFC 9989

    Osat §4.10.1

  5. RFC 8767

    Osat §4

  6. RFC 4592

    Osat §3.3

[ Sanasto ]

Sanasto

Nolla MX
Ainoa MX , jonka etusija on nolla ja vaihtopiste, joka ilmoittaa, että verkkotunnus ei hyväksy postia.

RFC 7505 §3

Implisiittinen MX
puuttuvan MX RRsetin SMTP käsittely implisiittisenä vaihtona, joka osoittaa kyseiseen isäntään; erilainen kuin eksplisiittinen Null MX .

RFC 5321 §5.1

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