Fastslå hvilket Notifii-produkt som sender meldingen
Behandle en Notifii-varsling som en distinkt forretningssenderute før du endrer DNS . Notifii LLC-utvikleroppføringen beskriver Notifii Connect som et kommunikasjonssenter for eiendomsforvaltere for å sende e-post eller tekst til enkeltpersoner, grupper og beboersamfunn. Som identifiserer produktet og dets varslingsformål; den dokumenterer ikke en kundekontrollert DKIM velger, SPF autorisasjon eller tilpasset returdomene. Notifii Connect-utvikleroppføring.
Denne artikkelen er en veiledning for bevisinnsamling og betinget implementering. Tilpasset domenekonfigurasjon forblir på vent. Den tidligere dokumentarundersøkelsen registrerte mislykkede nettside- og støtteinnhentinger. Denne anmeldelsen oppdaterte kun den lesbare utvikleroppføringen; den gjenopprettet ikke en autentiseringsprosedyre eller prøvde de begrensede sidene på nytt. Dette bevisgapet fastslår ikke at en funksjon er fraværende. De betyr at artikkelen ikke på en ansvarlig måte kan levere en Notifii-inkludering, velger, offentlig nøkkel, menybane eller aktiveringsløfte.
Bekreft det nøyaktige programmets navn, konto, eiendom eller campus, varslingstype og domene organisasjonen vil at innbyggerne skal se. Ikke erstatt dokumentasjon med Notifi, en tjeneste med et annet navn, bare fordi søkeresultatet diskuterer tilpassede e-postdomener. Likeledes, en rekord funnet i en annen kundes sone er ikke bevis på at den samme posten er passende for denne leietakeren.
Det praktiske resultatet er en klar beslutning: enten bruker meldingen allerede en leverandøreid identitet og trenger leverandørundersøkelse, eller så støtter leieren en organisasjonseid identitet hvis konfigurasjon må innhentes og verifiseres. Ingen av beslutningene krever spekulative DNS endringer.
Fang en harmløs grunnlinje fra hver varslingsarbeidsflyt
Be appeieren om å velge en testmottaker under organisasjonens kontroll. Bruk en syntetisk melding uten beboerinformasjon, pakkedetaljer, enhetsnummer eller tilgangsinstruksjoner. Utløs den samme arbeidsflyten som feiler, i stedet for å sende en ny melding fra kontorets postkasse. Registrer om det er en kunngjøring, en individuell melding eller et annet programgenerert varsel. Hvis mer enn ett Notifii-produkt er i bruk, ta hvert av dem separat.
Lagre den mottatte originale meldingen sikkert. Kopier bare minimumsoverskriftsbeviset til gjennomgangsregnearket: synlig fra domene, Return-Path domene, hver DKIM signeringsdomene og velger, pålitelige mottakerautentiseringsresultater, meldingsidentifikator og UTC-tidsstempel. Et vennlig visningsnavn, for eksempel eiendomsnavnet, er ikke det autentiserte domenet. En svar-til-adresse for ledelseskontoret fastslår heller ikke hvilket domene som ble evaluert for SPF eller DMARC.
Dokumenter den tiltenkte destinasjonen for svar som et eget driftskrav. Det er nyttig at en beboer kan svare, men det kan ikke bevise at det opprinnelige varselet ble justert. På samme måte sier en SMS som ankommer ingenting om e-postbanen. Behold leveringsresultater, svarhåndtering og autentisering resulterer i distinkte felt, slik at én suksess ikke skjuler en annen feil.
Hvis det ikke kommer noen meldinger, hold resultatet som ikke levert eller ikke observert. Sjekk applikasjonens tilgjengelige leveringsbevis og mottakssystemets logger gjennom eierne deres. Ikke lag en overskrifttolkning fra en skjerm som bare sier at et varsel ble sendt.
Få et leietakerspesifikt svar før du godkjenner DNS
Forbered en kort teknisk forespørsel for den bekreftede Notifii-støtteruten som er tilgjengelig i kontoen eller utvikleroppføringen. Inkluder produkt- og leietakeridentifikatoren, sendearbeidsflyten, tiltenkt Fra-domene, et renset tidsstempel og de observerte autentiseringsdomenene. Ikke send beboerlister eller fullstendige meldingsorganer med mindre det er spesifikt nødvendig og godkjent.
Be om skriftlig bekreftelse på fem punkter:
- Hvorvidt dette eksakte produktet og leietakeren kan sende ved hjelp av organisasjonens synlige Fra-domene, og om konfigurasjonen er selvbetjent eller støtteoperert.
- Om det kan gi en pasning DKIM signatur på linje med det Fra-domenet, inkludert den eksakte offentlige DNS eieren, typen og verdien for denne leietakeren.
- Hvorvidt konvoluttavsender er leverandøreid eller kan tilpasses, og hvilket domene trenger SPF autorisasjon hvis tilpasning støttes.
- Om avvisningshåndtering eller sporing krever ytterligere poster, og hvilke poster som trygt kan eksistere side om side med organisasjonens nåværende posttjeneste.
- Hvordan aktivering, verifisering, nøkkelrotasjon og tilbakerulling fungerer, inkludert forventet identitet hvis tilpasning mislykkes.
Et svar som bare sier «legg oss til SPF » er ufullstendig. Spør hvilken SMTP konvoluttidentitet som vil bruke den autorisasjonen. Et svar som bare gir en merkevarebygging eller klikksporing CNAME er også ufullstendig med mindre den forklarer forholdet til den faktiske signeringsruten. Behold skriftlig svar, dato og leietakeromfang med endringsforespørselen. En fremtidig operatør bør kunne fortelle hvorfor hver DNS endring eksisterer.
Bruk bekreftede poster uten å endre urelatert e-post
Når et gjeldende førstepartssvar identifiserer den støttede ruten, sammenligner du postene med den autoritative DNS sonen før du redigerer. La DNS eieren lagre de tidligere verdiene og identifisere eventuelle kollisjoner. Et CNAME ved et foreslått navn kan komme i konflikt med en annen post som allerede er der. A etterspurt MX post må evalueres ved sitt eksakte vertsnavn; den må ikke erstatte organisasjonens hovedpostkasseruting etter antagelse.
For enhver SPF endring, bevar de legitime avsendere som fortsatt bruker det samme konvoluttdomenet. Publiser én enkelt SPF policy hos den eieren og vurder hele evalueringsbanen, inkludert nestede inkluderinger og andre DNS-spørringstermer. Det er utilstrekkelig å telle bare inkluderte som er synlige på én linje. Ikke legg til en tjeneste til rotdomenet bare fordi selskapet bruker det domenet i sin logo. RFC 7208 , SPF -evaluering og DNS -oppslagsgrenser.
For DKIM publiserer du bare den offentlige verdien eller delegeringen som er bekreftet av leverandøren. Aldri be om eller plasser en privat signeringsnøkkel i DNS , en støtte-e-post eller dette regnearket. Bekreft DNS editorens håndtering av relative navn og vedlagte sone-suffikser. Den endelige eieren må være den som forespørres, ikke et doblet domene. La så Notifii fullføre den aktiveringen dens skriftlige instruksjoner krever. En publisert nøkkel alene viser ikke at tjenesten bruker den. RFC 6376 , signatur- og verifiseringsmodell.
Legg igjen et bevisst hold hvis støtte ikke kan etablere en støttet justert rute. En operativt tilgjengelig leverandøreid avsender kan være det riktige alternativet, men bedriftseieren må godkjenne den synlige identiteten. Ikke representer det som autentisering av organisasjonens eget Fra-domene.
Fyll ut Notifii-rutearbeidsarket
Bruk ett eksemplar per arbeidsflyt for produkt, leietaker og varsling. Feltene nedenfor er en foreslått akseptprosedyre, ikke registrerte testresultater.
- Produkt og leietaker: nøyaktig applikasjonsnavn, kontoidentifikator, eiendom eller campus, arbeidsflyt og applikasjonseier.
- Tiltenkt identitet: godkjent synlig Fra domene, visningsnavn og svardestinasjon.
- Leverandørbevis: støttesak eller dokumentasjons-URL, svardato, egendefinert domenefunksjon, eksakte offentlige DNS instruksjoner og aktiveringsansvar.
- Grunnlinjemelding: UTC-tid, meldingsidentifikator, kontrollert mottaker og observert leveringsutfall.
- Autentiseringsidentiteter: Fra domene, konvoluttdomene, hvert DKIM d- og s-par, og klarerte mottakerresultater for SPF , DKIM og DMARC .
- DNS bevis: autoritativ navneservere, eksakt eier/type/verdi, oppslagstid, tidligere konfigurasjon og konfliktgjennomgang.
- Melding etter endring: ny kjøring av arbeidsflyt, nylig observerte domener, justering konklusjon og forventet svaradferd.
- Utgivelsesbeslutning: bedriftseier, DNS -eier, støttebekreftelse, gjenopprettingsrute, uavklart bevis og menneskelig anmelder.
En justert bestått DKIM signatur kan etablere DMARC suksess selv når SPF bruker et ujustert leverandørdomene. Motsatt kan både SPF og DKIM passere for leverandøreide identiteter mens DMARC mislykkes for organisasjonens Fra-domene. Bruk den faktiske justeringsmodusen og policyen; ikke utlede justering fra samsvarende visningsnavn. RFC 9989 , identifikatorjustering og DMARC -evaluering.
Diagnostiser en fiktiv beboerkunngjøring
Kun fiktiv illustrasjon. Ingen notifii-leietaker, DNS sone eller melding ble testet. En eiendomsforvalter forventer en kunngjøring fra notices@cedarcourt.example . Den forestilte mottatte meldingen har det fra-domenet, men dets SPF-autentiserte konvolutt og bestått DKIM signeringsdomene tilhører et annet hypotetisk tjenestedomene. Den fiktive mottakeren rapporterer DMARC feil.
Diagnosen er en identitetsfeil, ikke et bevis på at all e-postautentisering er ødelagt. Overføringsmekanismene stemmer ikke overens med det synlige Fra-domenet i denne illustrasjonen. Å legge til en gjettet SPF -inkludering på cedarcourt.example vil ikke nødvendigvis endre konvoluttidentiteten som er vurdert av mottakeren. Den neste handlingen er å skaffe den eksakte leietakerens støttede tilpassede domene-rute, eller å bruke en godkjent støttet avsenderidentitet. Ingen av disse eksempelnavnene eller konklusjonene etablerer Notifiis reelle infrastruktur.
Hvis den samme hypotetiske meldingen i stedet fikk en bestått DKIM signatur på linje med From-domenet, ville det tilfredsstille DKIM banen for DMARC . Det vil fortsatt ikke bevise innboksplassering, vellykkede innbyggersvar eller dekning av et annet produkts pakkevarsler. Hvert driftskrav trenger sine egne bevis.
Gjenopprett og avgjør om guiden kan frigis
Hvis en autorisert endring forstyrrer varslinger, stopp videre utrulling og bruk den leverandørbekreftede tilbakeføringsprosedyren. Gjenopprett bare postene som er endret for denne ruten når gjenoppretting er nødvendig, og beholder ikke-relaterte avsendertillatelser. Test en kontrollert melding på nytt etter gjenoppretting. Ikke senk en organisasjonsomfattende DMARC policy bare for å skjule én uløst rute.
Artikkelen forblir upublisert og holdt tilbake for leverandørkonfigurasjonsbevis inntil en gjeldende førstepartsprosedyre eller leietakerspesifikt støttesvar løser spørsmålene om tilpasset domene. Live inspeksjon av leietakere, autoritative DNS sjekker, reell testing av mottatte meldinger, visuell gjennomgang og godkjenning av menneskelig gjenstand venter også. Det utfylte regnearket og støttesvaret er de nødvendige neste inputene; fraværet av dokumentasjon er ikke tillatelse til å fylle hullene med en annen leverandørs innstillinger.
Hold støttesvaret og den observerte ruten tilkoblet
Fil det daterte svaret mot det eksakte produktet og arbeidsflyten, og sammenlign deretter dets forventede identiteter med en ny kontrollert melding. En uttalelse om et annet produkt eller en vellykket tekstmelding kan ikke lukke e-postdomenespørsmålet. Den foreslåtte forespørselen er ikke sendt, og ingen leietakerspesifikk funksjon er sertifisert her.
Separat meldingsgodkjenning fra utrulling av retningslinjer
Et bestått justert SPF resultat kan tilfredsstille en meldingsevaluering, men rettferdiggjør ikke alene å flytte et helt domene for å avvise. RFC 9989 Seksjon 7.4 krever gyldig DKIM for domener som publiserer p=reject og advarer om interoperabilitet med indirekte e-post. Inventar alle legitime avsendere og indirekte ruter før policyeieren godkjenner håndhevelse. Ingen DNS endring, leietakeroperasjon eller test av mottatte meldinger ble utført for denne artikkelen.