A DMARC TXT verdi ved feil navn kan skrives perfekt og fortsatt være irrelevant for meldingen du undersøker. Før du endrer policyen, må du bevise at mottakeren kan oppdage den for domenet som brukes i den synlige Fra-adressen.
En vanlig felle er å teste bedriftens nettsteddomene mens applikasjonen sender som et underdomene. En annen er å skrive inn et fullt kvalifisert navn i et DNS felt som legger til sonenavnet. Kuren er en nøyaktig navnesammenligning, etterfulgt av autoritative DNS bevis.
Utled oppslagsnavnet fra meldingen
Ta en mottatt melding fra den berørte arbeidsflyten og identifiser domenet i Fra-adressen. For en syntetisk melding fra notices@billing.example.com , spør innledende policyoppdagelse TXT på _dmarc.billing.example.com . En rekord på example.com , www.example.com eller avsenderleverandørens urelaterte domene er ikke det samme oppslaget. Hvis det første oppslaget ikke finner noen gyldig policy, kan oppdagelsen fortsette under gjeldende DMARC regler. RFC 9989 , avsnitt 4.10.1.
Ikke bytt ut Return-Path domene for det synlige Fra-domenet. Under RFC 7208 §2.4, konvoluttidentiteten betyr noe for SPF, men det bestemmer ikke dette første DMARC -policyoppslaget. Hold de to feltene i separate kolonner mens du diagnostiserer problemet.
Skriv det forventede absolutte eiernavnet før du åpner DNS editoren. Dette lille trinnet forhindrer brukergrensesnittets etiketter fra å bli kilden til sannhet.
Finn den autoritative sonen og inndatamodellen
Identifiser hvilken navneservere betjener den aktuelle sonen. En registrarkonto, hosting-dashboard eller tidligere brukt DNS tjeneste kan vise poster som ikke lenger er autoritative. Hvis billing.example.com er delegert, må du bestemme hvem som kontrollerer den underordnede sonen før du redigerer overordnet.
Sjekk redaktørens hjelp for navn eller vertsfelt. Noen grensesnitt godtar relative navn; noen aksepterer fulle navn og normaliserer dem. En sonefilkonvensjon er ikke et løfte om et nettskjema. I DNS masterfiler er et navn som slutter på en prikk absolutt, mens et relativt navn tolkes ved å bruke gjeldende opprinnelse. RFC 1035 , avsnitt 5.1.
Som et dokumentert UI-eksempel sier Cloudflare gjeldende postarbeidsflyt å velge posttype og fylle ut de nødvendige feltene, som varierer fra post til post. Bruk leverandørens gjeldende registreringsinstruksjoner og bekreft det lagrede resultatet i stedet for å projisere en annen leverandørs feltatferd på det. Cloudflare DNS -postbehandling.
Arbeid gjennom saken med doble navn
Tenk på en illustrativ editor konfigurert for sone example.com som legger til sonen til hver relative navneverdi. Hvis du skriver inn _dmarc.example.com som en relativ verdi, vil det skape _dmarc.example.com.example.com . En validator som pekte på det tilfeldige navnet kunne finne en post, mens det tiltenkte _dmarc.example.com -oppslaget ikke har noen.
Sammenlign tre elementer eksplisitt:
- Tiltenkt absolutt eier: _dmarc.example.com .
- Lagret eier vist av DNS tjenesten eller soneeksporten.
- Autoritative TXT -svar for både tiltenkte og mistenkte tilfeldige navn.
Hvis svaret med feil navn inneholder den tiltenkte policyen, bevar den som bevis. Publiser eller korriger den godkjente posten hos den tiltenkte eieren, pass på at du ikke introduserer en annen DMARC kandidat der. Fjern den feilaktige posten gjennom normal endringskontroll etter å ha kontrollert at den ikke har noen separat tiltenkt bruk. Ikke behandle et eksempelnavn fra denne artikkelen som ditt produksjonsdomene.
Bekreft reparasjonen uten en falsk frist
Spør den autoritative tjenesten om nøyaktig eier og posttype. Sammenlign deretter svaret til en rekursiv resolvers, og merk deg tidsstemplet, responsstatusen og TTL. Hvis det tiltenkte navnet tidligere ikke eksisterte, kan en negativ hurtigbuffer fortsette å returnere det tidligere resultatet for gjenværende levetid. En nylig valgt positiv TXT TTL sletter ikke en eldre negativ buffer. RFC 2308 §3, RFC 2308 §4 og RFC 2308 §5.
Bruk av kvalifisert uaktuelle svar kan fortsette utover TTL-utløpet under RFC 8767 §4, så TTL er ikke en global konvergensfrist. Et dashboard-lagringsvarsel bekrefter skjemahandlingen, ikke global synlighet. På samme måte fastslår ikke et korrekt offentlig DNS svar at tjenesten din signerer e-post med et justert domene. Send en ny melding gjennom den opprinnelige ruten og inspiser mottakersystemets pålitelige resultat.
Lukk navneproblemet separat fra e-postautentisering
Behold det opprinnelige eiernavnet, korrigert eier, godkjent verdi og testtidsstempler i endringsposten. Hvis DMARC nå gjelder, men meldingen mislykkes, fortsett med identitet og alignment diagnose. Det er fremgang: posten kan bli funnet, og det gjenværende problemet tilhører sendebanen.
Hvis det fortsatt ser ut til at mottakere oppdager forskjellige retningslinjer, kan du sammenligne deres observerte From-domener, DNS svar og implementeringsatferd. Ikke fortsett å flytte en korrekt post mellom navn bare for å få to ikke-relaterte brikker til å bli enige.
Ta opp en avgjørelse som kan revurderes
For det doble navnet, sammenligne de tiltenkte og lagrede absolutte navnene før du endrer TXT verdien. En gyldig policy funnet hos den tilfeldige eieren viser ikke at det tiltenkte første oppslaget finner den. Ta vare på den utilsiktede journalen som bevis, og bruk deretter separat godkjente rettings- og fjerningshandlinger. Dette er en illustrativ redigeringsmodell, ikke en påstand om at Cloudflare legger til navn på den måten eller at noen DNS endring ble gjort.