Bekræft Freshservice mail-server-ruten
Brug denne arbejdsgang til et virksomhedsejet domæne, hvis e-mail sendes gennem Freshservice-mailserveren. Den gennemgåede udbydervejledning udelukker offentlige domæneadresser og tilpassede mailservere. Inden du starter, skal du registrere postkasse, domæne, afsendelsestransport, arbejdsområde, konto og Freshworks-organisation. Disse forskelle har betydning, når flere konti bruger det samme domæne.
Inventar de servicedesk-arbejdsgange, hvis meddelelser skal fungere, inklusive de kundevendte svar, der er relevante for din konfiguration. Giv hver en ejer og forventet Fra og svar destination. En enkelt administrators test er ikke bevis for alle arbejdsområder eller postkasser. Kombiner ikke en transportmigrering, en stramning af domænepolitikken og denne godkendelsesændring til én ikke-sporbar udrulning.
Åbn den korrekte konfigurationsside
For et enkelt arbejdsområde er den dokumenterede sti Admin > Kanaler > E-mail > E-mail-indstillinger og postkasser > Konfigurer SPF og DKIM e-mail-godkendelse. Med flere arbejdsområder skal du bruge Admin > Globale indstillinger > Kontoindstillinger > Service Desk Security. En verificeret brugerdefineret domæne-e-mail ved hjælp af Freshservice-mailserveren leverer domænet automatisk; det er ikke tilføjet eller redigeret på denne side. Kilde: Freshservice, Trin-for-trin guide til at tilføje SPF og DKIM e-mail-godkendelse.
Hvis domænet mangler, skal du undersøge postkassens verifikation og transport i stedet for at indtaste spekulative DNS poster. Bekræft kontoen og organisationen med ejeren af servicedesk. En brugerdefineret SMTP forbindelse kan ligne en almindelig supportadresse, mens du bruger en anden signeringstjeneste. Løs den grænse, før du ændrer en delt domænepost.
Udgiv de genererede poster uden at bryde en anden konto
Vælg Kom i gang, kopier de fire genererede CNAME'er og udgiv dem på autoritativ DNS . Returner, udvid domænet og brug Verify; panelet viser status pr. post. Udbyderen giver også konto- og superadministratorer besked om færdiggørelsen. Kilde: Freshservices opsætningsvejledning.
Før du gemmer DNS , skal du kortlægge hver anmodet ejer til dens aktuelle registrering og afhængige tjeneste. Hvis der er en vælger kollision, overskriv ikke en fungerende konto. Guiden tilbyder regenerering af forskellige vælgertaster, mens dens fjerde rekord forbliver uændret. Instruktioner for flere konti afhænger af, om begge konti tilhører den samme Freshworks-organisation. Brug den nøjagtige dokumenterede filial efter bekræftelse af organisationsmedlemskab, eller spørg support for at løse det tilsigtede rekordsæt. Undlad at improvisere flere mål på en enkelt CNAME ejer.
Regenerering er en ændring af en signeringskonfiguration, ikke en harmløs opdatering. Bevar den tidligere kontos status og DNS og koordiner overgangen. Bestem om en rekord at blive fjernet hører til den nyligt forsøgte opsætning eller en eksisterende fungerende. Hvis det er uklart, skal du stoppe fjernelse og få vejledning fra udbyderen; sletning af delte poster for at rydde en dialog kan forstyrre andre servicedesks.
Sammenlign autoritativ DNS med kontoen
Tjek hver endelig ejer- og alias-mål i forhold til de genererede værdier. En editor, der tilføjer domænet, kræver muligvis kun den relative værtsetiket. Hvis en ejer erhverver zonesuffikset to gange, skal du rette posten i stedet for at vente. Tjek autoritative svar først og rekursiv caching derefter; et anført udbredelsesestimat er ikke en garanti for, at en forkert registrering bliver gyldig.
Antag ikke, at alle CNAME har den samme protokolrolle, blot fordi guiden grupperer SPF og DKIM sammen. Undersøg de modtagne meddelelsesidentiteter for at etablere den effektive godkendelse. Undgå at tilføje en ikke-relateret SPF -inkludering eller udskiftning af en rodpolitik for at rette et mislykket vælgeropslag. Enhver separat SPF opdatering kræver én gennemgået politik, alle legitime afsendere og dens DNS-opslagsafhængigheder.
Bekræft reelle servicedesk-meddelelser
Udløs kontrollerede beskeder fra hvert tilsigtet arbejdsområde og afsendende domæne uden at bruge privat billetindhold. Behold den oprindelige modtagne besked og den betroede modtager Authentication-Results. Registrer den nøjagtige konto/arbejdsområde, Fra domæne, kuvertidentitet, DKIM d=/s= og den forventede svarrute. Bekræft svar-workflowet uafhængigt; en underskrift siger intet om, hvor et kundesvar håndteres.
Syntetisk eksempel: en notifikation fra help@example.com har en gyldig signatur med d=example.com og et modtagerbekræftet DKIM pas. Det nøjagtige signaturdomæne-match kan give det tilpassede DMARC sti. Et andet arbejdsområde, der sender fra help@different.example er ikke blevet godkendt af den første test, selvom den samme medarbejder administrerer begge dele. Domæneejerskab og kontokonfiguration overføres ikke gennem organisatorisk kendskab.
SPF autentificerer kuvertidentiteten; DKIM autentificerer et signeringsdomæne; DMARC har brug for mindst én passerende justeret sti for at være synlig fra under den relevante justering mode. En udbyderejet signatur kan være gyldig uden at stemme overens med din tilpassede Fra. Omvendt kan godkendelse passere, mens en besked stadig lander i spam. Hold protokolresultatet og leveringsresultatet adskilt.
Bevar gendannelses- og eksplicitte færdiggørelsesporte
Hvis produktverifikation mislykkes, skal du beholde de nøjagtige fejl pr. registrering og autoritative output. Hvis signaturen mangler efter verifikation, skal du kontrollere den faktiske transport- og postkassekonfiguration. For en signaturfejl skal du undersøge vælger/nøgleopslag og ændringer efter signering. For at få en afstemt besked med dårlig placering, skal du undersøge leveringsfejlen og modtagerhåndteringen i stedet for at svække politikken.
Gem tidligere optegnelser og postkasseindstillinger og aftal en gendannelsesrute før produktionsændringer. Brug ikke Remove Records tilfældigt på en live delt domæneopsætning. Accept kræver den korrekte produktstatus, DNS svar og modtagne meddelelsesbeviser for hver konto og arbejdsgang inden for rammerne. Denne artikel bevarer det originale krav om live-evidens: ingen lejer-, DNS eller leveringstest blev udført her. Uafhængig gennemgang, menneskelig SMV-godkendelse og offentliggørelse afventer fortsat.
Registrer, hvad der er ukendt, før du genbruger vælgere
Skriftlig sag FS-01 antager, at kontoen Helpdesk-A fungerer for example.com , mens Helpdesk-B foreslår det samme domæne. Deres Freshworks organisationsforhold er ukendt, og de foreslåede rekordværdier er ikke blevet leveret. Administratoren kan ikke vælge kildens samme organisation eller anden organisationsgren fra domænestavning alene. Bekræft medlemskab og hent de nøjagtige genererede ejere før planlægning af ændringer; bevare A's live-konfiguration, mens du løser enhver kollision. Udbyderens uændrede fjerde post er en grund til at inspicere hver post, ikke en garanti for, at regenerering giver et helt rent navneområde. DNS , B's produktvalidering og modtagne meddelelsesresultater er alle ukendte i dette tilfælde. Ingen regenerering, sletning eller meddelelse skete.
Bevar håndhævelsesgrænsen
RFC 9989 Afsnit 7.4 kræver gyldig DKIM , ikke SPF alene, for domæneudgivelse p=reject, og advarer om interoperabilitet mellem indirekte mail og mailinglister. En enkelt vellykket test med direkte beskeder er ikke et bevis på, at enhver legitim rute er klar til en stærkere politik. Behold eksisterende godkendt beskyttelse, mens du diagnosticerer det faktiske hul; enhver politikændring kræver sin egen beslutning.