Viesti voi kulkea DMARC ja silti epäonnistuvat postilaatikon tarjoajan lähettäjävaatimuksissa. Se ei välttämättä ole ristiriita. DMARC vastaa tiettyyn identiteettikysymykseen; vastaanottaja voi myös vaatia toimivia mekanismeja, turvallista kuljetusta, sopivaa viestin rakennetta ja vastuullista lähetyskäyttäytymistä.
Aloita protokollapäätöksestä
Viitteet: RFC 9989 §4.1, RFC 9989 §4.4, RFC 9989 §4.10, RFC 9989 §5.3.5.
RFC 9989, julkaistu toukokuussa 2026, vanhenee vanhat RFC:t 7489 ja 9091. Osissaan 4.1 DMARC läpäisee, kun Author Domainille on olemassa käytäntötietue ja tämä toimialue vastaa viestissä olevaa todennettua tunnistetta. Kohdistetun passin periaate säilyy: vähintään yhden tuetun todennusmekanismin on läpäistävä linjaus näkyvään Lähettäjä-verkkotunnukseen. varten SPF DMARC relevantti identiteetti on SMTP POSTIA LÄHETTÄJÄ RFC 9989 §4.4.2 alainen verkkotunnus; erillinen HELO-pohjainen SPF tulos ei korvaa tätä DMARC identiteettiä. varten DKIM, se on kelvollisen allekirjoituksen d=-alue. Onnistunut mekanismi ilman vaadittua kohdistusta ei edistä DMARC hyväksyntää. RFC 9989 kohdat 3.2.10 ja 4.1–4.3.
Kohdistuksessa on tiukat ja rennot tilat. Strict vertaa soveltuvia verkkotunnuksia tarkasti; rento käyttää organisaation ja toimialueen suhdettaan. RFC 9989 jakso 4.10 määrittelee DNS -puukävely löytö mieluummin kuin perinteinen julkisen pääteluettelon lähestymistapa. Tarkista vastaanottimen tai arvioijan toteuttama versio ennen kuin otat sen etsintäkäyttäytymisen. Älä käytä rentoa tasausta tarkistamalla, päättyykö yksi verkkotunnusmerkkijono vain toiseen. Harhaanjohtava jälkiliite tai virheellinen organisaatiotason laskelma voi tuottaa väärän tuloksen.
Lisää palveluntarjoajan vaatimukset erillisenä tasona
Microsoftin kuluttajatuen ohjeistus vaatii sekä SPF että DKIM läpäisemisen sekä DMARC . Yahoo joukkovaatimukset vaativat sekä mekanismeja että DMARC läpäisemistä. Nämä ovat toimintaportteja protokollan joko kohdistetun mekanismin logiikan lisäksi. Tarkista kohteen nykyinen lähde sen sijaan, että päättelet yhden palveluntarjoajan universaalista säännöstä. Microsoftin tuki ja Yahoo vaatimukset.
Luo yksi sarake DMARC -tulokselle ja erilliset sarakkeet vaaditulle todennus-, DNS , siirto-, muotoilu- ja tilauksen peruutussäätimille. Vihreä yleisilmaisin ilman näitä sarakkeita tekee vaikeaksi erottaa, arvioiko ohjelmisto protokollaa, toimittajan tarkistuslistaa vai vain julkaistua DNS syntaksia.
Käytä totuustaulukkoa eron paljastamiseksi
Viitteet: RFC 9989 §5.3.5.
Yksityinen arvostelupaketti sisältää kahden kotelon synteettisen valaisimen. Ensinnäkin SPF ja DKIM läpäisevät molemmat, mutta kumpikaan ei tasaa: DMARC epäonnistuu. Toiseksi SPF epäonnistuu, kun DKIM läpäisee ja kohdistaa: DMARC läpäisee. Toinen tapaus voi silti epäonnistua palveluntarjoajan portissa, joka itsenäisesti edellyttää SPF menestystä.
Nämä syötteet ovat tarkoituksella yksinkertaisia booleaneja, eivät DNS Tree Walk -etsinnän, vanhan julkiseen päätepohjaiseen etsintään, SPF arviointiin tai DKIM salaukseen toteutettua toteutusta. Molemmissa tapauksissa oletetaan, että soveltuva DMARC käytäntötietue on olemassa. Ne tekevät loogisen eron toistettavissa teeskentelemättä testaavansa palveluntarjoajaa. Korvaa todellisessa tutkimuksessa jokainen boolean luotetulla havaitulla tuloksella ja sen arvioidulla identiteetillä.
Älä sekoita julkaisua arviointiin
Viitteet: RFC 9989 §5.4.
Julkaiseminen p=none määrittää pyydetyn valvontakäytännön, ei onnistuneen viestin todennustuloksen. Julkisen DKIM -avaimen julkaiseminen ei allekirjoita lähtevää postia. Lisäämällä an SPF ennätys ei todista, että todellinen yhteys käytettiin valtuutettua osoitetta. Jokainen konfigurointiartefakti tarvitsee vastaavan havainnon aiotulta lähetysreitiltä.
Samoin siirrytään arvosta p=none kohtaan p=reject ei korjaa suuntausta. Se muuttaa verkkotunnuksen omistajan pyytämää käsittelyä virheiden varalta. Varastoi lailliset reitit ennen täytäntöönpanon muuttamista, säilytä palautussuunnitelma ja arvioi vaikutus epäsuoriin virtoihin. Vastaanotin soveltaa edelleen omaa paikallista hävityskäytäntöään; pyydetty DMARC -toiminto ei ole toimitustakuu.
Luo hyödyllinen sulkemistietue
Viitteet: RFC 8601 §5.
Säilytä jokaisen tutkitun näytteen osalta Lähettäjä, kirjekuoren lähettäjä, yhdistävä IP, DKIM allekirjoittaja ja valitsin, mekanismin tulokset, kohdistustila ja lopullinen vastaanottovaste. Tunnista tulosten luotettava lähde. Älä hyväksy mielivaltaisia kopioituja otsikoita vain siksi, että ne sisältävät sanan "hyväksyä".
Sulje protokollahavainto ja palveluntarjoajan yhteensopivuushaku erikseen. Näin voidaan sanoa tarkasti, että DMARC läpäisi, kun toinen vaatimus jäi ratkaisematta, ja määrittää korjaus oikealle omistajalle heikentämättä asiaankuulumattomia ohjaimia.