Brug den forbedrede servicearbejdsgang for det faktiske afsenderdomæne
Sage Intaccts forbedrede e-mail-leveringstjeneste har et domæne-workflow, der inkluderer kontogenererede DNS poster og et separat valideringstrin. Start med den økonomiske kommunikation, som organisationen skal sende, såsom en kontrolleret faktura eller betalingsmeddelelsestest, og identificer derefter det tilsigtede afsenderdomæne. Antag ikke en gammel SPF autorisations- eller e-mail-afsendernøgle beviser, at den forbedrede rute er klar. Denne vejledning dækker domænetilmelding, registreringsgennemgang og accept på meddelelsesniveau, mens aktiv kontobekræftelse stadig afventer.
Den nuværende guide til domæneindstillinger siger eksplicit, at hoveddomæner og underdomæner skal have separat godkendelse. Det adskiller også godkendt fra valideret: førstnævnte kræver stadig validering, før autentificeret afsendelse er klar. Brug disse workflow-sætninger i stedet for at fortolke et velkendt domænenavn eller en vellykket tidligere e-mail som fuldførelse. Samme sides generiske feltbeskrivelser nævner også afsendelse fra underdomæner; fordi denne formulering adskiller sig fra dens eksplicitte separat-godkendelsesinstruktioner, skal du løse enhver lejerspecifik tvetydighed med Sage i stedet for at antage nedarvet underdomænegodkendelse.
Inventar afsenderadresserne, der bruges af hver relevant virksomhed og arbejdsgang. Registrer hvilken administrator der ejer konfigurationen, hvilken person der kan ændre DNS , og hvem der kan godkende en harmløs økonomisystemtest. Undgå at sende rigtige fakturaer eller betalingsinstruktioner udelukkende for at teste autentificering. En test skal bruge den rigtige applikationsrute, mens der bruges kontrollerede modtagere og ikke-følsomt prøveindhold.
Etabler virksomheds- og konsolejerskab før redigering
Åbn Firma, Opsætning, Firma, derefter fanen Sikkerhed og E-mail-afsenderdomæneindstillinger, som beskrevet i udbyderens vejledning. Tjek hvilket firma eller hvilken konsol der ejer domænekonfigurationen. Aktuel dokumentation beskriver konsoladministreret nedarvning, så et domæne vist i en virksomhed kan administreres højere i hierarkiet. Opret ikke dublerede konfigurationer på virksomhedsniveau eller fjern poster, før du har identificeret den pågældende ejer.
Registrer den nøjagtige viste tilstand og datoen. Hvis kontoen afviger fra de offentlige instruktioner, skal du stoppe ved uoverensstemmelsen og spørge den autoriserede administrator eller Sage-support om den aktuelle arbejdsgang. En produktartikel kan ikke etablere tilladelser eller hierarki for organisationens lejer. Sørg for, at arvede indstillinger, selvstændige virksomhedsindstillinger og ældre optegnelser kan skelnes i ændringsanmodningen.
Planlæg tilbagerulning med finansejeren. At sætte en test på pause er anderledes end at afbryde en fakturakørsel, og ændring af en afsender kan påvirke kundegenkendelse eller svarhåndtering. Bevar den tidligere godkendte konfiguration, og vælg et vindue, der undgår kritisk faktureringsaktivitet. Autentificeringsoprydning bør ikke stille og roligt ændre, hvem der ser ud til at have sendt en økonomisk meddelelse.
Generer og bevar den domænespecifikke posttabel
For et godkendt nyt domæne skal du bruge den dokumenterede tilføjelse-og-godkend-arbejdsgang og gemme den DNS tabel, der er genereret for det pågældende domæne. Den offentlige vejledning beskriver en tabel med en SPF CNAME, to DKIM CNAME'er, afsender-sikkerhed TXT indgange og en ældre SPF indgang for kompatibilitet. Kopier den faktiske kontos ejere, posttyper og værdier. Ingen prøve vælger, lang token eller skærmbilledeværdi i denne artikel er en genbrugelig konfiguration.
Behold den genererede tabel med ændringsbilletten og anmærk, hvilket formål hver række tjener. Skeln den forbedrede tjenestes delegerede SPF ejer fra den ældre SPF -politik på hoveddomænet. Behandl virksomhedens bekræftelses- TXT værdi som sin egen post i stedet for at folde den ind i en SPF streng. Forskellige kontroller kan dele DNS zonen uden at dele en syntaks eller et operationelt formål.
De DNS valideringsvejledning forklarer kontrol af afsender-sikkerhedsalternativer og bemærker, at en af disse poster er tilstrækkelig til den beskrevne kontrol. Bekræft det relevante valg i forhold til den genererede tabel, især for konsolstyret konfiguration. Bevar usikkerhed, hvis den faktiske konto kræver en anden ordning; Brug ikke et eksempel til at tilsidesætte dets nuværende instruktioner.
Udgiv poster, mens du bevarer eksisterende posttjenester
Eksportér først de berørte DNS poster. Sammenlign hver udstedt ejer med eksisterende optegnelser og delegationer. En CNAME konflikt kræver en administrators understøttet løsning, ikke en anden post af en anden type hos samme ejer. Tjek, om DNS editoren forventer en relativ etiket eller et fuldt kvalificeret navn, og bekræft det resulterende offentlige navn efter lagring. Det endelige DNS svar er beviset, der betyder noget.
Hvor SPF -indgangen til bagudkompatibilitet kræver en ændring af en eksisterende politik, skal du gennemgå hele politikken under RFC 7208. Hold én SPF politik hos den evaluerede ejer, bevar andre aktive afsendere, og tag hensyn til indlejrede DNS-forespørgselsvilkår. Indsæt ikke en ekstra SPF rekord ved siden af den eksisterende. Fjern ikke ældre godkendelse, blot fordi de forbedrede registreringer er til stede; Find først ud af, om et live-workflow stadig afhænger af det.
Hold offentlige optegnelser adskilt fra legitimationsoplysninger og ansøgningshemmeligheder. DNS tabellen er egnet til den autoriserede DNS administrator, men en bevispakke behøver ikke ubegrænset lejereksport eller kundedata. Rediger unødvendige transaktionsdetaljer, mens du bevarer tilstrækkelig kontekst til at knytte en test til dens workflow og virksomhed.
Tjek de udstedte ejere og fuldfør valideringen
Tjek hver CNAME nøjagtige ejer og mål, og bekræft derefter, at det delegerede opslag løser sig som forventet. Tjek DKIM ved hjælp af de faktiske vælgere vist i den genererede tabel. Udbyderens valideringsvejledning indeholder illustrative vælgerformater; kopiering af disse eksempler til en anden lejer er ikke en gyldig test. Registrer opslagstid, resolver og returneret værdi, så en senere korrekturlæser kan skelne forældede data fra en transskriptionsfejl.
Vend tilbage til det valgte domæne i e-mail-afsenderdomæneindstillinger og brug Valider domæne. Bevar den resulterende tilstand eller fejl. DNS caches og udbydertjek kan forsinke genkendelsen, så undgå gentagne gange at regenerere konfigurationen, mens posterne stadig afvikles. Hvis valideringen mislykkes, skal du først sammenligne de offentliggjorte navne, typer og værdier og derefter undersøge den præcise række, der ikke er løst.
En valideret tilstand er nyttigt tilmeldingsbevis, men det beviser ikke, at den påtænkte faktura eller meddelelse brugte denne identitet. Behold den næste test på meddelelsesniveau som en separat gate. En administrator bør være i stand til at vise både domænets parathed og modtagerens resultat for en repræsentativ besked fra virksomhedens arbejdsgang.
Bekræft økonomimeddelelser hos en kontrolleret ekstern modtager
Udløs en autoriseret test fra hver væsentligt forskellig virksomhed eller afsendende workflow. Gem besked-id, UTC-tid, tilsigtet afsender og applikationshandlingen, der producerede beskeden. Notér også, hvor svaret går hen. En svaradresse kan være operationelt vigtig uden at være det domæne, som SPF evaluerer eller DKIM signerer.
Undersøg det modtagende systems betroede godkendelsesresultater. Optag den synlige fra, Return-Path og hvert DKIM d= signeringsdomæne og s= selector. RFC 6376 definerer forholdet mellem disse DKIM felter og DNS bekræftelsesnøglen. En vellykket DNS kontrol for en konfigureret vælger fastslår ikke, at meddelelsen brugte den; selve signaturen løser det spørgsmål.
Under RFC 9989, DMARC kræver et bestået SPF eller DKIM -resultat med den relevante relation til From-domænet. Anvend domænets konfigurerede justering tilstand og noter, hvilken mekanisme der leverer den justerede pas. En betalingsmeddelelse, der lander i en indbakke, beviser ikke justering, og autentificering beviser ikke nøjagtigheden eller legitimiteten af en finansiel instruktion. Det er separate forretningskontroller.
Undersøg fejl ved hjælp af både ansøgningen og meddelelsesbeviset
Hvis der ikke kommer en testmeddelelse, skal du fastslå, om applikationen forsøgte at sende den, før den ændrede DNS . Bevar den relevante leveringshistorikindtastning eller fejl. Domæneguiden identificerer forskellige historievisninger afhængigt af domænets valideringstilstand; bruge det synspunkt, der passer til den pågældende tilstand, i stedet for at fortolke et tomt syn som bevis på, at der ikke er sket noget.
Hvis meddelelsen ankommer med en uventet Fra, skal du afstemme arbejdsgangens afsendervalg med den godkendte domænebeholdning. Hvis DKIM er fraværende eller fejler, skal du sammenligne den faktiske vælger og det offentlige svar og kontrollere, om en downstream-gateway har ændret meddelelsen. Hvis SPF består, men DMARC fejler, skal du undersøge justeringen. En yderligere root-godkendelse vil ikke reparere enhver konvolut-domæne-uoverensstemmelse.
Eskaler med firma- eller konsolidentifikator, domænetilstand, berørte DNS rækker, testtid og redigeret godkendelsesbevis. Hold reelle kundeoplysninger ude af supporteksemplet. Bevar den eksisterende DMARC -politik, medmindre ejeren godkender en bredere ændring, der dækker alle legitime afsendere.
Sage Intacct domæne arbejdsark
- Firma- eller konsolejer og ansvarlige administratorer: ____.
- Forretningsarbejdsgang, påtænkt afsender- og svarpostkasse: ____.
- Hoveddomæne eller separat tilmeldt underdomæne: ____.
- Genereret DNS tabelreference og instruktionsdato: ____.
- Forbedret SPF delegering og begge DKIM -posttjek: ____.
- Afsender-sikkerhedsvalg og ældre SPF afhængighedsgennemgang: ____.
- Vist domænetilstand før og efter validering: ____.
- Testmeddelelse-ID, UTC-tid og leveringshistorikreference: ____.
- Observeret fra, Return-Path , DKIM identiteter og justeret resultat: ____.
- Undtagelser, godkendt inddrivelse og korrekturlæser: ____.
Fiktivt eksempel på at stoppe ved den forkerte status
Kun fiktiv skriftlig sag: SI-01 antager, at det overordnede domæne example.org er valideret på ejerkonsollen, men fakturaworkflowet er beregnet til From invoices@billing.example.org . Tilmelding til billing.example.org er ukendt, og der findes ingen modtagne resultater. Økonomiadministratoren skal verificere det særskilt autentificerede underdomæne og faktiske arbejdsgang, før den planlægger den harmløse test; forældre-domæne-status kan ikke etablere dækning. Hvis den viste status kun er godkendt, skal du først fuldføre DNS valideringen. Ingen reel faktura, lejer eller transaktion blev efterset.
Behold de resterende udløsningslåger
Nuværende lejerinspektion, genereret registreringsgennemgang, live DNS og header-verifikation, visuel gennemgang og menneskelig SMV-godkendelse afventer stadig. Løs enhver uoverensstemmelse mellem offentlig dokumentation og den faktiske virksomhed eller konsol før offentliggørelse. Denne artikel er et upubliceret implementeringsudkast, ikke en bekræftelse af, at en organisations økonomimeddelelser er klar til produktion.
Adskil en forbigående meddelelse fra håndhævelsesberedskab
RFC 9989 Afsnit 7.4 kræver gyldig DKIM for en domæneudgivelse p=reject og advarsler om interoperabilitet med indirekte mail. Et enkelt tilpasset SPF resultat retfærdiggør ikke i sig selv en udrulning af afvisningspolitik. Gennemgå alle lovlige ruter og politikejerskab separat fra denne udbyderopsætning.