[ Palveluoppaiden lähettäminen ]

Todenna E-goin kautta lähetetty sähköposti: määritys ja vahvistus

Suunnittele E-goi-lähettäjän todennus annettujen SPF , DKIM ja CNAME ohjeiden avulla säilyttäen samalla dokumentoidut edellytykset ja ratkaisemattoman tilin soveltuvuuden.

EmailAuth -tutkimusryhmä · 8 min lukuaika

[Avainkohdat]

  • Käytä omistetun verkkotunnuksen lähettäjää ja todellisia luotuja DNS ohjeita.
  • Julkaistu julkinen WHOIS-ehto vaatii valtuutetun tietosuojatietoisen päätöksen, ei keksittyä kiertotapaa.
  • Palveluntarjoajan vahvistus ja todelliset kohdistetut viestitulokset ovat erillisiä todisteita.
Tällä sivulla

Varmista E-goi-lähettäjän kelpoisuus ennen DNS työtä

E-goi on virallinen Sähköpostin lähettäjän oppaani todentaminen, päivitetty 13. elokuuta 2025, kuvaa lähettäjän todennusta ja erillisen toimialueen CNAME vaatimus. Tämä artikkeli kattaa tämän E-goi-työnkulun. Se ei oleta, että postilaatikon tarjoajan omat todennusasetukset kattavat E-goin kautta lähetetyn markkinointiviestin tai että yhden lähettäjän toimialueen onnistunut testi kattaa toisen. Aloita varsinaisesta tilistä, lähettäjän osoitteesta, verkkotunnuksesta ja tarkoitetusta viestireitistä.

Oppaassa vaaditaan lähettäjän osoite verkkotunnuksessa, jota asiakas hallitsee; se sanoo, että henkilökohtaisia ​​freemail-osoitteita ei voida todentaa tällä prosessilla. Siinä on myös julkisen WHOIS-kelpoisuusehto verkkotunnuksen todennusta ja CNAME määrityksiä varten. Säilytä se dokumentoituna palveluntarjoajana, joka vaatii nykyisen tilin vahvistuksen, ei yleisenä DNS , SPF tai DKIM sääntö. Älä vaikeuta sitä hiljaa valinnaiseksi suositukseksi tai päättele, että rekisteröinnin yksityisyys tekee verkkotunnuksesta haitallisen.

Jos tämä ehto on ristiriidassa organisaation tietosuojavaatimusten kanssa, pidä käyttöönotto estettynä palveluntarjoajan selventämistä ja valtuutettua päätöstä varten. Älä paljasta henkilökohtaisia ​​rekisteröintitietoja vain tehdäksesi tarkistuslistan vihreäksi. Tämä käsikirjoitus ei muuta rekisteröinnin yksityisyyttä, kerää henkilökohtaisia ​​yhteystietoja tai lähetä tukipyyntöä. Lähteen laajempia väitteitä yksityisistä verkkotunnuksista ja omistusriskistä ei käytetä tässä teknisinä johtopäätöksinä.

Valitse valtuutettu konfigurointireitti

Dokumentoitu polku alkaa oikean yläkulman valikosta Lähettäjät. Lisää haluttu lähettäjä tarvittaessa ja valitse sen vierestä Todennus. E-goi esittelee kolme reittiä: palveluntarjoajan avustama asennus, ohjeiden lähettäminen tekniselle yhteyshenkilölle tai konfiguroinnin tekeminen itse. Näillä reiteillä on erilaiset luvat ja tiedon jakamisen seuraukset. Palveluntarjoajan avun valitseminen tai ohjeiden lähettäminen sähköpostitse on ulkoinen toimenpide, ei pelkkä ohjesivun katseleminen.

Jos haluat ehdottaa itsepalvelutyönkulkua, tunnista DNS järjestelmänvalvoja ja vahvista pääsy valtuutetulle vyöhykkeelle. Oppaassa neuvotaan valitsemaan verkkotunnuksen isännöintiyritys niin, että E-goi näyttää SPF , DKIM ja DMARC lisättävät merkinnät. Käytä nykyisen tilin näyttöön tulevia ohjeita sen sijaan, että keksit yleisen tietuejoukon. Jos toinen tiimi toteuttaa muutokset, anna vain tarvittavat julkiset tiedot hyväksytyn kanavan kautta ja säilytä pyynnön laajuus.

Ennen muutosta selvitä olemassa olevat todennustietueet ja muut lailliset lähettäjät. Tallenna, mitkä merkinnät ovat uusia, jotka muokkaavat olemassa olevaa käytäntöä ja mitkä olisivat ristiriidassa aktiivisen riippuvuuden kanssa. Säilytä kopio hyväksytystä edellisestä kokoonpanosta palautusta varten. Tililiittymä voi näyttää pyydetyt tietueet, mutta tämä näkymä ei vahvista, että julkinen vyöhyke todella julkaisee ne.

Pidä CNAME lisävaatimus näkyvissä

E-goi-oppaassa todetaan toistuvasti, että todennusta on täydennettävä lisäämällä sen CNAME verkkotunnukseen. Sen vianetsintäesimerkki kuvaa nimeä, joka alkaa yleensä mkt:llä, mutta tarkan nimen ja kohteen pitäisi tulla tilin asetuksista. Älä oleta, että tämä CNAME on identtinen a:n kanssa DKIM valitsin tallenna tai luo havainnollinen mkt-nimi tarkistamatta annettua kokoonpanoa. Anna jokaiselle tietueelle selkeä tarkoitus muutostietueessa.

Vertaa koko omistajaa ja kohdetta DNS editorin käytäntöihin. Paneeli voi liittää vyöhykkeen jälkiliitteen suhteelliseen tarraan, joten näennäisesti täydellinen syöttö voi tuottaa tahattoman kaksoisliitteen. Myös olemassa olevat aliakset on tarkistettava ennen vaihtamista. Säilytä lähettäjän todennustietueet ja ylimääräinen verkkotunnus CNAME erillisinä hyväksymiskohteina; yhden onnistunut tarkistus ei osoita, että toinen on olemassa tai sopiva.

Oppaan manuaalinen tarkistusosio nimeää egoi DKIM valitsin esimerkkinä. Tämä on hyödyllinen konteksti dokumentoidulle asetukselle, mutta todellisten viestien todisteiden tulisi määrittää hyväksytyn reitin käyttämä valitsin ja allekirjoitusalue. Älä pidä onnistunutta hakua tutulla tunnisteella todisteena siitä, että jokainen kampanja käyttää tätä avainta. RFC 6376 , kohta 3.5 määrittää vertailuun tarvittavat allekirjoituskentät.

Tarkista SPF ja DMARC verkkotunnuksen laajuisina päätöksinä

Tilin SPF ohje on sovitettava yhteen olemassa olevan laillisen lähettäjän inventaarion kanssa. Älä julkaise toista SPF -käytäntöä tai vaihda siihen liittyviä valtuutuksia sokeasti. RFC 7208 , kohdat 2.4, 3.2 ja 4.6.4 määritellä POSTIA LÄHETTÄJÄ identiteetti, useiden tietueiden käyttäytyminen ja arvioidut DNS-riippuvaiset termirajat. Laske asiaankuuluvat sisäkkäiset riippuvuudet sen sijaan, että olettaisit, että näkyvien osien määrä on kokonaiskustannukset.

Palveluntarjoaja sisällyttää DMARC asennusohjeisiinsa, mutta verkkotunnuksen laajuisen käytännön valitseminen edellyttää silti muiden lähettäjien ja aiottujen raportointijärjestelyjen tarkistamista. Älä korvaa toimivaa käytäntöä yleisellä näytteellä vain yhden palvelun asetusnäytön tyydyttämiseksi. Raporttien kohteet ovat tietojen jakamispäätöksiä, eikä niitä tule lisätä automaattisesti esimerkeistä. Nykyinen protokolla säilyy v=DMARC1; ei ole tarvetta keksiä uutta versiomerkkijonoa nykyisen standardin tarkistusta varten.

RFC 9989 , kohta 4.4 selittää linjaus näkyvän tekijän verkkotunnuksen ja ohittavan todennusidentiteetin välillä. SPF välittäminen riippumattomalle kirjekuorialueelle ei tuota automaattisesti tasattua tulosta. Samoin allekirjoitus riippumattomalle toimialueelle ei riitä vain siksi, että salaustarkistus onnistuu. Arvioi todellinen reitti ja henkilöllisyydet sen sijaan, että vertaisit vihreää merkkiä täydelliseen DMARC hyväksyntään.

Tulkitse Verify- ja DNS viiveet huolellisesti

DNS muutosten tallentamisen jälkeen opas ohjaa käyttäjät takaisin vielä auki olevaan E-goi-ikkunaan valitsemaan Vahvista. Se kuvaa, että SPF ja DKIM ilmaisimet muuttuvat vihreiksi, kun tarkastukset ovat läpäisseet, ja punaisena, kun asetukset ovat väärät. Säilytä tarkka tulos ja aika. Tämä on palveluntarjoajan määritysten tarkistus, ei todiste toimituksesta jokaiselle vastaanottajalle tai todiste siitä, että kaikki tulevat viestit todennetaan.

Oppaassa ehdotetaan, että puuttuva odotusarvo voi viitata etenemiseen, mutta sen ei pitäisi olla ainoa diagnoosi. Väärä omistaja, väärä vyöhyke tai jätetty arvo voi aiheuttaa saman ilmeisen poissaolon. Vertaa arvovaltaista julkaisua ja tilille myönnettyä arvoa ennen kuin oletat, että odotus riittää. Sen ajoitusarviot ovat ohjeellisia eivätkä yleisiä määräaikoja. Tälle käsikirjoitukselle ei suoritettu DNS kyselyä tai vahvistusta.

Erikseen valtuutetussa hyväksymisharjoituksessa tulisi käyttää vaaratonta viestin sisältöä ja tarkastaa luotettujen vastaanottajien tulokset tarkoitetulle lähettäjäalueelle. Kirjaa kirjekuoren todellinen identiteetti, allekirjoitusalue ja valitsin, tekijän toimialue ja havaittu reitti. Vältä oikeiden yhteystietoluetteloiden tai luottamuksellisten viestien lataamista kolmannen osapuolen tarkistajille. E-goi itse toteaa, että autentikointi ei yksin riitä parantamaan toimitusta: sitoutuminen ja muut tekijät ovat edelleen tärkeitä. Täällä ei vaadita taattua postilaatikkoa tai kampanjan vastaustulosta.

Kuvitteellinen diagnoosi ja tyhjä hyväksymistaulukko

Kuvitteellinen taideorganisaatio Willow Stage täydentää lähettäjän todennusmerkinnät, mutta jättää huomiotta ylimääräisen CNAME kohteen. Sen kampanjan omistaja merkitsee asennuksen valmiiksi pelkästään SPF ja DKIM indikaattoreiden perusteella. Katsauksessa verrataan täyttä tarkistuslistaa julkisiin todisteisiin ja havaitaan, että ylimääräistä verkkotunnusriippuvuutta ei ole käsitelty. Ehdotettu korjaus on kattava DNS tarkistus ja uusi hyväksymistodistus, ei tukkumyyntikäytännön korvaaminen. Skenaario on kuvitteellinen, eikä se sisällä todellista tilitulosta, kampanjaa tai kyselyä.

  • Tili, lähettäjän verkkotunnus ja todellinen viestin reitti: ______
  • Nykyinen kelpoisuusvahvistus, mukaan lukien dokumentoitu WHOIS-ehto: ______
  • Tietosuojapäätös tai ratkaisematon palveluntarjoajan selvennys: ______
  • Tilin myöntämät SPF , DKIM , DMARC ja erilliset CNAME vaatimukset: ______
  • Olemassa olevat riippuvuudet, arvovaltainen DNS omistaja ja hyväksyntä: ______
  • Tarkista tulos ja julkiset todisteet kohteittain: ______
  • Luotetut vastaanotettujen viestien identiteetit ja tasaustulos: ______
  • Omistajan palautus, muut poikkeukset ja julkaisupäätös: ______

Alkuperäiset toteutustodisteet, ihmisen aiheen tarkastelu, nykyinen soveltuvuus, tuotantoreitit, visuaalinen saavutettavuus ja omistajan vapauttaminen ovat avoinna. Tietueita, rekisteröintiasetuksia tai tilin hallintaa ei muutettu. Laajempi luettelon toteutusvaatimus on edelleen riippuvainen valtuutetusta vuokralaisesta ja viestistä.

[ Takeaway ]

Vahvista ensin kelpoisuus ja nykyiset edellytykset ja tarkista sitten myönnetyt tietueet ja valtuutetut viestitodisteet olettamatta, että todennus takaa toimituksen.

[ Roolin mukaan ]

Mitä tämä tarkoittaa sinulle

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

Tilin ylläpitäjä

Vahvista kelpoisuus ensin

Estetystä edellytyksestä ei pitäisi tulla improvisoitu DNS muutos.

Seuraavat vaiheet

  1. Tunnista omistetun verkkotunnuksen lähettäjä.
  2. Selvitä nykyinen WHOIS-soveltuvuus valtuutettujen omistajien kanssa.

DNS operaattori

Käytä luotuja arvoja

Huolto-ohjeet ja olemassa oleva vyöhyke on sovitettava yhteen.

Seuraavat vaiheet

  1. Säilytä lailliset SPF -lähettäjät.
  2. Tarkista DKIM ja muut CNAME omistajien nimet.

Yksityisyyden ja turvallisuuden omistaja

Ratkaise ilmoitettu ehto selkeästi

Julkiset rekisteröintitiedot voivat olla ristiriidassa organisaation vaatimusten kanssa.

Seuraavat vaiheet

  1. Arvioi dokumentoitu edellytys.
  2. Vaadi selvennyksiä spekulatiivisen paljastamisen tai poikkeuksien sijaan.

[ UKK ]

Usein kysytyt kysymykset

Voiko freemailin lähettäjä käyttää tätä omistetun verkkotunnuksen asetuksia?

Opas vaatii lähettäjän omalla verkkotunnuksellasi freemail-osoitteen sijaan. Vahvista ensin verkkotunnuksen hallinta ja tilin kelpoisuus.

E-goi: Sähköpostin lähettäjän todentaminen (päivitetty 13. elokuuta 2025)

Mistä dokumentoitu työnkulku alkaa?

Opas alkaa Lähettäjistä ja lähettäjän todennustoiminnosta. Vahvista nykyisen tilin käyttöliittymä ennen vaiheiden suorittamista.

E-goi: Sähköpostin lähettäjän todentaminen (päivitetty 13. elokuuta 2025)

Ovatko DNS arvot universaaleja?

Ei. Hanki valitun lähettäjän ja DNS-isäntätyönkulun merkinnät; tämä käsikirjoitus ei sisällä uudelleen käytettävää avainta tai tilikohtaista arvoa.

E-goi: Sähköpostin lähettäjän todentaminen (päivitetty 13. elokuuta 2025)

Onko ylimääräinen CNAME valinnainen?

Lainatussa oppaassa kuvataan ylimääräinen CNAME vaatimus. Käytä luotua omistajaa ja kohdetta sen sijaan, että olettaisi, että tavallinen mkt-tunniste on aina oikea.

E-goi: Sähköpostin lähettäjän todentaminen (päivitetty 13. elokuuta 2025)

Mitä meidän pitäisi tehdä julkisen WHOIS-tilan suhteen?

Julkaistu opas kertoo tämän ehdon. Jos se on ristiriidassa tietosuojavaatimusten kanssa, keskeytä palveluntarjoajan selvennys ja valtuutettu päätös. Tämä käsikirjoitus ei sisällä dokumentoitua tietosuojapoikkeusta, eikä se suosittele henkilötietojen paljastamista.

E-goi: Sähköpostin lähettäjän todentaminen (päivitetty 13. elokuuta 2025)

Määrittääkö Verify postilaatikon sijoittelun?

Ei. Palveluntarjoajan DNS tarkistukset eivät takaa vastaanottajan sijoittelua tai jokaista todellista lähetysreittiä.

RFC 9989: DMARC

Voimmeko korvata kaikki olemassa olevat SPF valtuutukset?

Älä hylkää muita laillisia lähettäjiä vain palvelun lisäämiseksi. Tarkista yksi täydellinen SPF käytäntö ja sen arvioidut riippuvuudet.

RFC 7208 : Lähettäjäkäytäntökehys

Onko E-goi todentanut tilin tämän tarkistuksen aikana?

Ei. Tilitoimenpiteet, DNS muutokset, vastaanotettujen viestien tarkistukset ja nykyinen edellytyssoveltuvuus jäävät vahvistamatta.

[ Lähteet ]

Lähteet

  1. RFC 9989: DMARC

    Osat §2.4 Soveltamisalan ulkopuolella · §4.4 Tunnisteen kohdistus selitetty · §5.3 Postin vastaanottajan toiminnot

  2. RFC 6376: DKIM

    Osat §1 Johdanto · §3.5 DKIM-Signature otsikkokenttä · § 3.6.2.2 Resurssitietuetyypit avainten tallennusta varten

  3. RFC 7208 : Lähettäjäkäytäntökehys

    Osat §2.3 HELO identiteetti · §2.4 MAIL FROM Identity · §3.1 DNS resurssitietueet · §3.2 Useat DNS tietueet · §3.3 Useita merkkijonoja yhdessä DNS tietueessa · §4.6.4 DNS -haun rajat · §5.2 "sisältää" · §5.3 "a" · §5.6 "ip"

  4. E-goi: Sähköpostin lähettäjän todentaminen (päivitetty 13. elokuuta 2025)

    Osat Vaatimukset · Sähköpostin lähettäjän todentaminen · Onko todennuksen jälkeen muita asetuksia? · Verkkotunnukseni on yksityinen. Kuinka voin todentaa sen?

[ Sanasto ]

Sanasto

Lähettäjän verkkotunnus
Todennusta varten valittuun lähettäjän identiteettiin liittyvä toimialue.

E-goi: Sähköpostin lähettäjän todentaminen (päivitetty 13. elokuuta 2025)

DKIM -allekirjoitusverkkotunnus
DKIM -allekirjoituksen d= verkkotunnus, joka eroaa visuaalisesta lähettäjän tunnisteesta.

RFC 6376: DKIM

Tasaus
Todistetun tunnisteen ja DMARC käyttämän näkyvän lähettäjän verkkotunnuksen välinen suhde.

RFC 9989: DMARC

Hyväksymistaulukko
Ehdotettu omistajarekisteri, pyydetyt muutokset ja todisteet, joita tarvitaan vielä vapauttamiseen.

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