Uskottava DMARC merkkijono voi epäonnistua, koska se on julkaistu väärällä nimellä, jaettu erillisiin tietueisiin tai editorin muuttama. Se voi myös sisältää virheellisen käytäntöarvon, jolla on erityinen varatoiminto operaattorin odottaman yleisen virheen sijaan.
Tarkista tarkka palautettu arvo vaiheittain. Säilytä DNS esitys ja tietueen rajat ensin ja tarkista sitten tunniste, kielioppi ja käytäntöjen semantiikka. Tämä lähestymistapa tekee korjauksesta tarkistettavan ja välttää tarpeettomat politiikan muutokset.
Vahvista omistaja ja kirjaa rajat
Kysy todellisen Lähettäjä-verkkotunnuksen soveltuvasta _dmarc nimestä. Tallenna koko TXT tietue joukko, auktoriteetti, aika ja TTL. Toimialueen juuressa oleva arvo ei täytä odotettua julkaisun nimeä.
TXT -resurssitietue voi sisältää useita merkkijonoja. DMARC yhdistää merkkijonot kyseisessä tietueessa järjestyksessä ennen jäsentämistä RFC 9989 §4.5. Se ei yhdistä erillisiä resurssitietueita yhdeksi käytännöksi.
Tämä on esimerkiksi yksi synteettinen vyöhyketyyppinen tietue:
_dmarc.example.com. 300 IN TXT "v=DMARC1; " "p=none"Lainausmerkit rajaavat vyöhyketiedoston esityksen. Tarkista, mitä DNS palveluntarjoaja todella tallentaa ja palauttaa, ennen kuin päätät, että lainaukset ovat kirjaimellista tietuesisältöä.
Tunnista ensin versio
Under RFC 9989 §4.7 ja peritty RFC 6376 §3.2 syntaksia, käytä rekisteröityjä pieniä kirjaimia tunnisteen nimiä ja tarkkaa versioarvoa DMARC1 . V-tunnisteen tulee näkyä ensin. Puuttuva versio, eri arvo tai versio, joka näkyy vain toisen tagin jälkeen, aiheuttaa tietueen huomioimisen RFC 9989.
Älä luota tunnisteen nimien kirjainkoon vaihtamiseen saadaksesi vastaavan tunnistetun tunnisteen. Arvoilla on myös tunnistekohtaisia vaatimuksia; versioarvo on nimenomaisesti isokokoinen.
Tämä eroaa DNS nimien tapauskäyttäytymisestä. Vältä yleisen DNS-nimisäännön laajentamista DMARC -käytännön tekstiin.
Tarkasta erottimet ja välilyönnit tarkasti
Tunniste-arvoparit käyttävät puolipisteitä erottimina. Pilkuilla on eri rooli raportoinnin kohdeluettelossa, eivätkä ne voi korvata tietueen jokaista puolipistettä.
Tyhjät eivät ole yleisesti kiellettyjä. Peritty RFC 6376 §3.2 tag-value kielioppi sallii välilyönnit tunnisteen syntaksin ympärillä, mutta se ei salli välilyöntejä sellaisen tunnuksen sisällä, jonka oma arvokielioppi kieltää ne.
Kopioi ja liitä -toiminto voi aiheuttaa typografisia lainausmerkkejä, epätyypillisiä välimerkkejä tai tahattoman rivinvaihdon. Vertaa tarkasti tallennettuja merkkejä kielioppiin sen sijaan, että korjaat arvoa silmäyksellä. Säilytä sekä alkuperäinen että ehdotettu korjattu muoto.
Käytä kiinnittimiä, jotka nimeävät käsittelyvaiheen
Seuraavat synteettiset kalusteet havainnollistavat erillisiä ongelmia ja päätöksiä. Ne eivät ole reaaliaikaisia testituloksia tai lupauksia identtisistä diagnostisista merkinnöistä jokaisesta toteutuksesta.
- Kiinnitys yhdellä omistajan nimellä: v=DMARC1; p=none; rua=mailto:reports@example.com; Tarkastelulöydös: selkeä ei mitään käytäntö- ja raportointipyyntö
- Kiinnitys yhden omistajan nimeen: p=none; v=DMARC1; Arvostelulöydös: Versio ei ole ensimmäinen; ohita tämä tietue
- Kiinnitys yhdellä omistajalla: v=DMARC2; p=none; Tarkista löydös: Ei nykyinen määritetty versio; ohita tämä tietue
- Kiinnitys yhdellä omistajan nimellä: v=DMARC1; p=invalid; rua=mailto:reports@example.com; Tarkista löydös: Käytä nykyistä ehdollisen käytännön varavaihtoehtoa
- Kiinnitys yhdellä omistajan nimellä: v=DMARC1; p=invalid; Tarkista löydös: Ei kelvollista rua URI:tä tälle varalle
- Kiinnitys yhdellä omistajan nimellä: v=DMARC1; p=none; p=reject; Tarkista löydös: Päällekkäinen tunnisteen nimi; korjaa virheellinen tunnisteluettelo yhden arvon valitsemisen sijaan
- Kiinnitys yhteen omistajan nimeen: Kaksi erillistä tietuetta, joista jokainen alkaa v=DMARC1; Tarkistuksen löydös: Useita politiikan ehdokkaita; tarkasta tietuejoukon suodatus ja etsiminen
- Kiinnitys yhdellä omistajan nimellä: v=DMARC1; p=none; xnote=example; Tarkista löydös: Tuntematon tunniste ohitetaan nykyisten sääntöjen mukaan
Mukautetun tuntemattoman tagin ei pitäisi tulla osaksi toimintapolitiikkasopimusta vain siksi, että jäsentäjä jättää sen huomiotta. Käytä dokumentoituja kenttiä ja säilytä hallinnollisia muistiinpanoja muutostietueessa.
Erota päällekkäiset nimet useista tietueista
Kaksoistunniste on toistuva nimi yhdessä tunnisteluettelossa. Peritty RFC 6376 §3.2 DKIM tag-value -syntaksi estää päällekkäiset nimet ja pitää luetteloa virheellisenä. Älä oleta, että viimeinen p-arvo ohittaa ensimmäisen tai yhdistä kahta rua-tunnistetta ilman suunniteltua korjausta.
Useat käytäntötietueet ovat eri taso. Under RFC 9989 §4.10, nykyinen DNS -puun käsittely hylkää useita DMARC -käytäntötietueita yhdessä kohteessa. Discovery voi sitten löytää toisen sovellettavan käytännön. Valaisin, joka testaa vain etunimeä, ei ole vahvistanut täydellistä vastaanottimen tulosta.
Pidä nämä havainnot erillään virheraportissa: tarkka tietueiden määrä, ketjutettu yhden tietueen arvo, päällekkäiset nimet ja myöhempi löytö.
Käytä nykyisen politiikan varavaihtoehtoa yleistämättä sitä liikaa
Under RFC 9989 §4.10.1, puuttuva tai virheellinen p tai virheellinen sp tai np, aiheuttaa käsittelyn jatkamisen muodossa p=none vain, jos rua sisältää vähintään yhden syntaktisesti kelvollisen raportointi-URI:n. Muutoin viestiin ei sovelleta DMARC -käsittelyä näiden sääntöjen mukaisesti.
Tämä ehto ei vahvista jokaista mielivaltaisesti rikkoutunutta tunnisteluetteloa. Ennätys ohitettu versiotunnistuksessa ei tule käyttökelpoiseksi vain siksi, että se sisältää osoitteen myöhemmin. Sovella sääntöjä siinä vaiheessa, johon ne kuuluvat.
Under RFC 9990 §4, syntaktisesti kelvollinen raportointi-URI ei myöskään todista ulkoisen kohteen valtuutusta, tavoitettavuutta tai todellista keräämistä. Ei raportteja -opas kattaa nämä erilliset riippuvuudet.
Tarkista hyväksytty korjaus
Tee yksi johdonmukainen tarkoitettu tietuesarja tarkalle omistajan nimelle. Tarkista määritetyt tagisäännöt RFC 9989 §4.7, rekisteriviittaus RFC 9989 §9.3 ja täydellinen semanttinen muutos. Älä lisää toista käytäntötietuetta ohitukseksi.
Tallenna asetusero ja vanha arvo tutkimusta ja palautusta varten. Tarkista arvovaltaiset vastaukset muutoksen jälkeen, vertaa asiaankuuluvia rekursiivisia näkymiä ja ota huomioon välimuistissa olevat aikaisemmat tiedot. Ennätystyönkulku yhdistää nämä tarkastukset edustavaan postin testaukseen.
Lähetä lopuksi valvottu viesti varsinaisen sovellusreitin kautta. Syntaktisesti pätevä käytäntö ei todista sitä SPF tai DKIM on linjassa From. Säilytä DNS -korjaus ja lähettäjän todennus yhdessä, tarvittaessa erillisillä löydöillä.
Hyödyllinen tulos on tarkka selitys viasta, sen käsittelyvaiheesta, korjatusta arvosta ja postin vahvistuksesta. Se on kestävämpää kuin jokaisen virheellisen näköisen merkkijonon julistaminen pysyväksi virheeksi.
Pidä päätös ja todisteet erillään
v=DMARC1; p=invalid kelvollisen rua-URI:n kanssa, käytä ilmoitettua ehdollista varamuutosta vasta, kun tietue on saavuttanut asianmukaisen vaiheen. Älä käytä tätä korjaussääntöä hylättyjen versioiden tai kaksoistunnisteiden luetteloon. Säilytä politiikan tarkoitus ja varsinainen viestitesti erillisenä hyväksyntätodisteena. RFC 8767 §4 sallii kelvolliset vanhentuneet vastaukset TTL:n päättymisen jälkeen; syntaksin muuttaminen ei korvaa välittömästi jokaista välimuistia. Jäsennystä, DNS tai sähköpostitestiä ei suoritettu.