Definer først den opsøgende identitet
En pressekampagne kan se korrekt ud i editoren, mens den efterlader en uventet afsenderidentitet. Inden du ændrer DNS , skal du registrere organisationen, den tilsigtede Fra-adresse, den ansvarlige for opsøget, og om ruten er en kampagne eller et individuelt pitch. Inkluder eksisterende kladder og integrationer i denne beholdning. Deres valg af afsender er en del af accepttesten, ikke en detalje at udlede fra nyhedsrummets udseende.
Prezly leverer en prezlymail.com -adresse, der er klar til brug, og understøtter verificerede virksomhedsdomæneadresser. Dens afsender-adresse guide beskriver tilføjelse af adressen, valg af domæne, udgivelse af tre eller fire udstedte CNAME optegnelser og køre statustjekket. Brug de viste værdier for det valgte domæne. Eksemplerne i en offentlig artikel identificerer tjenestens design; de er ikke poster, der skal kopieres til en anden organisations zone.
Hold websteds- og e-mail-konfiguration adskilt
Et fungerende værtsnavn på redaktionen er ikke bevis for, at kampagne-e-mail autentificeres. Prezly adskiller eksplicit websitets brugerdefinerede domæne-opsætning fra afsender-domæne-beredskab i sin udviklervejledning. Giv DNS ændringen et specifikt formål: godkend det godkendte outreach-domæne, i stedet for at reparere hvert brandede værtsnavn i én operation.
Indfang de aktuelle zoneværdier hos hver foreslået postejer. Registrer, om DNS editoren forventer en relativ etiket eller et fuldt kvalificeret navn. Bed administratoren om at sammenligne det resulterende offentlige ejernavn med instruktionen, før du fortsætter. Gentagne suffikser, en rekord placeret i den forkerte zone, eller et eksisterende CNAME hos en inkompatibel ejer kan alle producere en plausibel-lignende post, der ikke klarer den tilsigtede kontrol. Bevar almindelige forretningsmail-poster og ikke-relaterede TXT værdier.
For en organisation med mere end ét offentligt brand skal du forberede én ændringsrække pr. domæne. Antag ikke, at validering af bureauets eget domæne autoriserer alle klientidentiteter. Kontoejeren bør godkende, hvilke personer der må bruge hver identitet, og hvilken postkasse der modtager svar. Denne operationelle beslutning skal registreres, før du vælger en ny standard.
Offentliggør den udstedte delegation uden at udvide den
Prezly dokumenterer en retur-sti underdomæne og CNAME-baseret godkendelsesdelegering. Der står også en eksisterende DMARC rekord behøver ikke at blive genskabt, og Cloudflare poster skal bruge kun DNS-tilstand til denne opsætning. Gennemgå det eksisterende DMARC politik, før du tilføjer noget til sin ejer. Erstat ikke en stærkere godkendt politik med et eksempel på overvågningspolitik, blot for at lave en guide-match. De afsender-adresse instruktioner kræver også, at afsenderdomænet har MX poster; bekræfte, at svar når den tilsigtede postkasse i stedet for at omdirigere indgående post tilfældigt.
Behandl hver CNAME som en løbende delegation. Hold dets udbydermål, forretningsformål, ejer og gendannelsesinstruktioner sammen. En fremtidig DNS oprydning skal skelne et ubrugt webstedsalias fra en mail-godkendelsesafhængighed. Hvis en foreslået ejer er i konflikt med en anden tjeneste, skal du stoppe denne registreringsændring og søge instruktioner for den nøjagtige konto. Gætter på en ny vælger eller mål er ikke en sikker konfliktløsningsmetode.
SPF evaluerer den SMTP identitet, der bruges til meddelelsen, i stedet for det venlige visningsnavn. Hvor en SPF politik faktisk er påkrævet, behold én politik hos den pågældende ejer og gennemgå dens komplette DNS-opslagsomkostninger. Se RFC 7208. Tilføj ikke en bred autorisation til roddomænet, udelukkende fordi en testmeddelelse nævner en ekstern leveringsplatform.
Tjek beredskab i grænsefladen og integrationer
Gem domænestatuskontrollen med et tidsstempel og den anvendte instruktionsrevision. En grøn ansøgningstilstand skal efterfølges af en kontrolleret afsendelse. Den bekræfter en del af konfigurationen, mens den modtagne besked giver bevis for, hvad tjenesten rent faktisk brugte.
For integrationer skal du inspicere det tilsigtede afsender-id, adresse, godkendelsestilstand og domænegyldighed. Prezly advarer om, at dets serialiserede is_verified-felt i øjeblikket altid er sandt og ikke er bevis på godkendelse eller DNS beredskab. Dens API vejledning anbefaler også eksplicitte afsender-id'er i stedet for at antage, at en standardændring omskriver eksisterende udkast. Få integrationsejeren til at bekræfte den valgte identitet uden at afsløre API-legitimationsoplysninger i skærmbilleder eller gennemgå filer.
Hvis en standard ændres, test en nyoprettet kampagne og den relevante eksisterende kladde separat. Et gemt objekt kan bevare sin egen identitet. Hold enhver gendannelsesprocedure præcis: Gendan det godkendte afsendervalg, eller sæt den berørte udstrækning på pause i stedet for at slette alle godkendelsesposter, mens du diagnosticerer en applikationsindstilling.
Læs beskeden, som modtageren har modtaget
Send en harmløs kampagne og et harmløst pitch til kontrollerede eksterne postkasser. Medtag en intern postkasse som en separat test, når intern distribution har betydning. Capture Message-ID, UTC-tid, From, Return-Path , DKIM signering af domæne og vælger, og den endelige modtagers betroede godkendelsesresultater. Rediger modtageroplysninger og kampagneindhold, der er unødvendige til gennemgang.
Et DKIM pas beviser validering for signeringsdomænet. DMARC kræver desuden en tilpasset SPF eller DKIM identitet i forhold til det synlige From-domæne. RFC 6376 definerer signaturfelterne, og RFC 9989 definerer DMARC justering. Registrer den gældende justeringstilstand; et relateret underdomæne er ikke automatisk tilstrækkeligt under streng justering.
Brug ikke et indbakkeplaceringsresultat som hele godkendelsesdommen. En meddelelse kan godkendes og stadig modtage ugunstig filtrering på grund af omdømme, modtagerregler, indhold eller afsendelsesadfærd. Omvendt kan en tilladelseslistet besked vises i en indbakke uden at bevise, at den offentlige godkendelsesrute er korrekt.
Prezly accept arbejdsark
Gennemfør separate rækker for kampagner, pitches og enhver integrationsdrevet rute:
- Organisation, domæne, virksomhedsejer og rute: ____.
- Tiltænkt fra, svarpostkasse og eksplicit afsender-id, hvor det er relevant: ____.
- Eksisterende udkast eller nyoprettet test: ____; standardvalg markeret: ____.
- Udstedte CNAME ejere og målreferencer: ____; konflikter løst: ____.
- Eksisterende DMARC politik bevaret eller godkendt ændringsreference: ____.
- Offentlige DNS svar, ansøgningsstatus og verifikationstider: ____.
- Kontrolleret modtager, meddelelses-id og UTC sendetid: ____.
- Return-Path , DKIM d= og s=, betroede SPF / DKIM / DMARC resultater: ____.
- Observeret justeret mekanisme og intern filtreringsresultat: ____.
- Frigiv ejer, gendannelseshandling og næste bekræftelsesudløser: ____.
Et tomt identitets- eller modtagerfelt efterlader ruten ubekræftet. Udvid kun ud over pilotprojektet, når kommunikationsejeren og mailadministratoren er enige om, at den testede identitet er den, der er beregnet til reel udbredelse.
Fiktiv diagnose af en mislykket intern test
Kun fiktivt eksempel: Alder Press ser sin interne test i junk og foreslår at erstatte domænets SPF politik. Den eksterne kopi har justeret DKIM og et DMARC -pas. Den interne modtager identificerer meddelelsen som eksternt stammende post ved hjælp af en intern Fra-adresse. Prezlys leveringsvejledning diskuterer dette interne testmønster. Holdet undersøger modtagerens politik, før det ændrer offentlig DNS .
En snæver, gennemgået modtagerundtagelse kan være passende for en dokumenteret forretningsrute, men den må ikke præsenteres som en autentificeringsreparation eller en garanti for ekstern levering. Holdet kontrollerer også undertrykkelse og afvisningsbeviser, når en adresse ikke modtager noget. Denne diagnose er illustrativ; ingen Alder-konto, DNS zone eller besked blev observeret.
Hold acceptgrænsen synlig
Tjek igen efter afsenderændringer, DNS migreringer, integrationer, der ændrer identitetsvalg eller en mistet bekræftelsestilstand. Hold registreringsbeholdningen og de redigerede overskrifter sammen, så en anden administrator kan gengive konklusionen. Offentlig dokumentation understøtter denne procedure, men levende lejerinspektion, kontoudstedte værdier, DNS tests, modtagne meddelelsesbeviser, gengivet visuel gennemgang, menneskelig SMV-godkendelse og offentliggørelse forbliver afventende.
Gør integrationsoverdragelsen eksplicit
For en integrationsdrevet kampagne skal du beholde det numeriske afsender-id med udgivelsesposten. Godkendelse og domænegyldighed er separate felter; hverken en vellykket objektoprettelse eller is_verified=true er en erstatning. En integrationsoperatør bør registrere disse tilstande uden at eksportere legitimationsoplysninger og derefter inspicere den faktisk valgte identitet på en kontrolleret kampagne. Dette er et foreslået accepttjek, ikke et API-kald udført for denne artikel.
Adskil meddelelsesaccept fra politikudrulning
Et bestået justeret SPF resultat kan tilfredsstille en meddelelsesevaluering, men retfærdiggør ikke alene at flytte et helt domæne for at afvise. RFC 9989 Afsnit 7.4 kræver gyldig DKIM for domæneudgivelse p=reject og advarer om interoperabilitet med indirekte mail. Inventar alle legitime afsendere og indirekte ruter, før policeindehaveren godkender håndhævelse. Ingen DNS ændring, lejerdrift eller test af modtaget meddelelse blev udført for denne artikel.