Omfang og leverandørspesifikk konfigurasjon
StatusHub har dokumentasjon for ulike postleverandørruter. Denne veiledningen følger dens e-postavsender - Postmark - Ny artikkel; den beholdte eldre Mailgun artikkelen må ikke blandes inn i det oppsettet. Bekreft at Hub viser den matchende ruten før publisering. En migrering eller eldre leietaker kan kreve forskjellige poster.
Åpne Hub Config, Varslingsinnstillinger, E-postavsender. Den dokumenterte standarden er do-not-reply@statushub.io . Skriv inn den tiltenkte tilpassede avsenderen og la siden oppdatere for å vise DNS instruksjonene. Postmark -ruten krever en DKIM TXT post og en returvei CNAME. Kopier navnet og verdien direkte fra kontrollpanelet, i stedet for å bruke eksempelet på den offentlige nøkkelen i hjelpeartikkelen.
De retur-sti eieren er vanligvis et pm-bounces-underdomene, men det faktiske forespurte navnet kontrollerer. Plasser aldri denne CNAME på domenetoppen, bare fordi det er domenet i den synlige Fra-adressen. StatusHub advarer spesifikt om at en apex CNAME kan komme i konflikt med andre poster og svekke ikke-relaterte systemer, inkludert innkommende e-post. Behold postkassen MX poster atskilt fra denne returveidelegasjonen.
Etter å ha publisert begge postene, bruk Recheck DNS poster i StatusHub. Et fullstendig verifisert tilpasset sendedomene tillater den angitte Fra-adressen. Når en tilpasset avsender forblir ubekreftet, dokumenterer StatusHub fallback til do-not-reply@statushub.io i Fra mens den tilpassede adressen plasseres i Svar-Til. Denne forskjellen er nyttig under diagnose: et svar som når teamet ditt, beviser ikke at kundene så avsenderen din.
Hjelpeartikkelen diskuterer escaped og unescaped semikolon for DKIM TXT verdier. Bruk syntaksen som trengs av DNS editoren, og inspiser deretter den publiserte verdien; ikke stikk skråstreker inn i nøkkelen som et teppe. En ny post kan valideres raskt, men artikkelen noterer leverandør- og TTL-forskjeller. Diagnostiser eksakt eier, type og verdi før alle feil tilskrives forplantning.
Avgjørelsen som betyr noe
Bekreft både den aktive e-postleverandørruten og om fallback har flyttet den egendefinerte identiteten til Svar-Til.
Bekreft de publiserte postene og den virkelige sendebanen
Registrer endring av eier, avsenderprodukt, domene, godkjent vedlikeholdsvindu og tidligere DNS svar før redigering. Få de gjeldende postverdiene fra den navngitte kontoen eller den dokumenterte arbeidsflyten for leverandøren. Skill verdier levert av leverandøren fra valg organisasjonen din kontrollerer, som f.eks DMARC policy- og rapporteringsmottakere. Eksisterende postboks- MX , urelaterte TXT verifiseringsposter og aktive DKIM velgere er ikke oppryddingskandidater bare fordi en ny tjeneste blir lagt til.
Spør de autoritative navnetjenerne for hver eksakte eier og posttype etter publisering. Registrer spørretiden, svarserver og komplett svar. Sammenlign TXT strenger som én logisk verdi der DNS svaret deler dem opp i tegnstrenger. Sjekk CNAME -mål samt startaliaset. Sammenlign deretter et rekursivt oppløser-svar for å identifisere caching-forskjeller. En vellykket leverandørvalidering er et nyttig bevis på konfigurasjon, men det fastslår ikke hva en faktisk mottaker mottok.
Send kun en autorisert test til en kontrollert mottaker ved å bruke den tiltenkte produktruten. Behold råmeldingen og det pålitelige mottakssystemets Authentication-Results. Ta opp det synlige Fra-domenet, SMTP POST FRA eller observert Return-Path domene, hver DKIM d= og s= verdi, SPF og DKIM resultater, og mottakerens DMARC resultat. En bestått SPF eller DKIM sjekk støtter DMARC bare når det autentiserte domenet er på linje med det synlige Fra-domenet under gjeldende policy. Reply-To og et merkenavn er ikke det justering identiteter. RFC 7208 , RFC 6376 og RFC 9989 gi protokollgrunnlaget for disse distinksjonene.
Regneark for aksept, gjenoppretting og bevisgrenser
Dette er et originalt godkjenningsark, ikke en rapport om live testing. Merk hver gate som venter inntil bevis eksisterer: kontoomfang bekreftet; tidligere DNS fanget; eksakt ny eier/type/verdi publisert; leverandørverifisering fullført; beregnet rute utøvd; mottatte identiteter registrert; justert autentisering bekreftet; andre avsendere upåvirket. Tildel en person og bevisfil til hver port. En rød port blokkerer utrulling selv når leverandørens dashbord er grønt.
Hvis en test mislykkes, må du først skille mellom manglende publisering, foreldede hurtigbufrede data, inaktiv leverandørkonfigurasjon, feil utgående rute og ikke-justert autentisering. Rett den minste påviste feilen og test på nytt. Ikke svekk DMARC eller slett andre avsenderes poster bare for å få en testbestått. Hvis en endring skader eksisterende e-post, bruk den godkjente gjenopprettingsplanen og den registrerte konfigurasjonen før endringen, og koordiner eventuelle avsenderendringer på leverandørsiden samt DNS . Behold gamle nøkler mens meldinger i kø eller en godkjent overlapping fortsatt krever dem.
Ingen kundeleier, autoritativ før/etter endring eller reell mottatt melding var tilgjengelig for dette manuskriptet. De beholdte kildene støtter dokumentararbeidsflyten; de tilfredsstiller ikke den bestilte live-evidence-porten. Uavhengig kontrollørvurdering og menneskelig SMB-godkjenning gjenstår. Ikke beskriv denne veiledningen som feltvalidert eller publiser den som å ha passert disse portene.
Tolk tilbakefall som et annet identitetsutfall
Skriftlig sak SH-01 antar at den tiltenkte avsenderen er status@example.com , men Poststempel-rutedomenet forblir ubekreftet. Den illustrative varslingen bruker derfor den dokumenterte standarden From do-not-reply@statushub.io og Reply-To status@example.com . Alle SPF / DKIM resultater er ukjente. Et svar som når den egendefinerte adressen vil verken etablere egendefinert Fra-bruk eller justert autentisering for example.com . Hub-eieren må verifisere den aktive leverandørruten, korrigere de nøyaktige genererte DKIM og Return-Path eierne, kontrollere statusen på nytt og inspisere en kontrollert varsling. Ikke flytt Return-Path CNAME til roten eller importer gamle Mailgun instruksjoner. Ingen hendelse, abonnentvarsel, DNS spørring eller konfigurasjonsendring skjedde.
Bevar håndhevingsgrensen
RFC 9989 Seksjon 7.4 krever gyldig DKIM , ikke SPF alene, for domenerpublisering p=reject, og advarer om interoperabilitet mellom indirekte e-post og e-postlister. En enkelt vellykket test med direktemeldinger er ikke et bevis på at alle legitime ruter er klare for sterkere politikk. Behold eksisterende godkjent beskyttelse mens du diagnostiserer det faktiske gapet; enhver politikkendring trenger sin egen beslutning.