Begynd med klientdomænet, ikke en kopieret post
Instillers bureau-orienterede afsendelsesmodel gør domæneejerskab til et praktisk udrulningsproblem. Dens politik for acceptabel brug kræver SPF og DKIM og opfordrer til tilpasset afsendelse og klikdomæner for hver klient. Godkendelsesarbejde bør derfor starte med en navngiven klient, afsendende domæne og ansvarlig DNS administrator, snarere end et bureaudækkende eksempel kopieret ind i hver zone. Krav til afsendelse af instiller.
Denne vejledning dækker e-mail-kampagner sendt gennem Instiller. Den etablerer ikke en identisk opsætning for hver white-label-implementering, transaktionsintegration eller brugerdefinerede kuvertmulighed. Indfang den eksisterende Fra-adresse, afsendelsesworkflow, kliksporingsdomæne og kendt afvisningshåndtering. Disse identiteter kan tjene forskellige formål; et fungerende sporingsværtsnavn er ikke et bevis på, at selve meddelelsen er autentificeret.
Bed udbyderen, der administrerer kontoen, om at bekræfte det fulde rekordsæt og de påtænkte signerings- og konvolutdomæner. Gem dette svar med den planlagte ændring. Hvis DNS ejes af klienten, skal du acceptere et vedligeholdelsesvindue og undgå at acceptere et skærmbillede af en ikke-gemt editor som fuldførelsesbevis.
Anskaf og udgiv DKIM bevidst
Instillers DKIM artikel fortæller brugere af hostede tjenester, at de skal hente den nødvendige offentlige nøgle fra deres udbyder. Den beskriver TXT registreringer under vælgers _domainkey navn og skelner mellem roddomæne og underdomæneplacering. Det giver ikke en universel kontovælger eller en komplet produktionsnøgle for hver kunde. Instiller DKIM vejledning.
Anmod om vælgeren, den fulde ejer, posttype, komplet offentlig nøgleværdi, aktiveringskrav og rotationsprocedure. Udgiv kun det offentlige materiale, der er leveret til det godkendte domæne. Generer ikke en erstatningsnøgle lokalt, medmindre udbyderen specifikt understøtter denne arbejdsgang: en ny offentlig nøgle er ubrugelig, hvis afsendertjenesten stadig signerer med en anden privat nøgle.
Før udgivelse skal du kontrollere eksisterende poster ved vælgernavnet og bestemme, hvordan DNS værten repræsenterer lange TXT data. Sørg for, at det endelige DNS svar bevarer hele nøglen uden at indsætte utilsigtede tegn. Den offentlige artikel diskuterer ældre nøglestørrelses- og rotationsvejledning; bede om kontoens nuværende understøttede indstillinger i stedet for at behandle disse historiske udsagn som en moderne sikkerhedsgrundlinje. DKIM rekord vejledning.
Afstem SPF og DMARC for den faktiske rute
Førsteparts SPF artiklen siger, at politikken afhænger af de afsendende IP-områder og betegner dens registrering som et eksempel. Få den aktuelle godkendelse for denne konto i stedet for at udgive eksempeladresseintervallet. Hold én SPF -politik hos hver relevant ejer, og bevar andre legitime afsendere. Instiller SPF vejledning.
SPF kontrolleres mod SMTP kuvertidentiteten. Spørg udtrykkeligt, om den påtænkte kampagne bruger klientdomænet, et klientunderdomæne eller et udbyderdomæne der; den hentede offentlige opsætning beviser ikke dette valg for en live-konto. Kontospecifik bekræftelse er især vigtig, når en partner driver tjenesten, eller flere klientdomæner eksisterer side om side.
DMARC evaluerer, om et bestået SPF eller DKIM domæne stemmer overens med det synlige Fra-domæne. Begge teknologier kan passere, mens ingen af dem stemmer overens. Omvendt kan én tilpasset passeringssti opfylde DMARC , selvom Instiller separat kræver begge teknologier operationelt. Dens bulk-afsender vejledning identificerer også justering og en DMARC -politik som krav. Instiller bulk-afsender vejledning og DMARC.
Planlæg håndhævelse på tværs af alle legitime afsendere, der bruger domænet. En ny kampagneintegration retfærdiggør ikke at erstatte en eksisterende karantæne- eller afvisningspolitik med overvågning, og en vellykket DNS publicering retfærdiggør heller ikke at øge håndhævelsen uden at gennemgå andre mailkilder.
Accepter kampagnen med budskabsbeviser
Original testplan: Send en lille, harmløs kampagne gennem det nøjagtige klient-workflow til kontrollerede eksterne modtagere. Fang tiden, klientkontoen, fra domænet, Return-Path, betroet SPF -identitet og resultat, alle DKIM d=/s= -par og betroet DMARC resultat. Sammenlign disse observationer med udbyderens lovede konfiguration. Bekræft, at svar- og afvisningshåndtering stadig når deres tilsigtede destinationer.
Hvis nøglen ikke findes, skal du kontrollere vælgerens stavning, underdomæneplacering og offentlige DNS svar. Hvis signaturen mislykkes, skal du involvere udbyderen med en redigeret meddelelseskilde i stedet for at erstatte vilkårlige nøgler. Hvis godkendelsen bestå, men justeringen mislykkes, skal du spørge, hvilken understøttet identitetsindstilling der skal ændres. Sæt den nye klientafsender på pause, indtil årsagen er forstået, og bevar den tidligere godkendte konfiguration til tilbagerulning.
Ingen live Instiller-konto, DNS udgivelse eller kampagne blev testet. Aktuelle kontospecifikke optegnelser, kuvertadfærd og ende-til-ende-resultater forbliver bevishuller, med menneskelig SMV-godkendelse stadig påkrævet.
Aflever én klientpost ad gangen
Brug et separat foreslået acceptkort for hver klient: udbyderkontakt, afsendende domæne, udstedt vælger og nøgle, SPF ejer og -autorisation, forventet konvolut, aktiveringskrav og testworkflow. Registrer lovede identiteter adskilt fra observerede. Et manglende svar fra udbyderen efterlader den berørte klient i venteposition; det retfærdiggør ikke at låne en anden kundes nøgle eller udvide den delte SPF . Intet kort er udfyldt for en rigtig konto i denne artikel.