Start med produktet og domænebeslutningen
Webpowers nuværende dokumentationsspor fører til Spotler MailPro. Embedsmanden rebranding side udtrykkeligt identificerer MailPro som det fortsatte Webpower marketing automation-produkt. Denne forbindelse tillader en produktspecifik vejledning; det gør ikke instruktionerne udskiftelige med Spotler Mail+, SendPro eller alle konti, der engang brugte Webpower-navnet. Bekræft den faktiske licens og grænseflade før planlægning af implementering.
Denne artikel bruger offentlige instruktioner gennemgået den 9. november 2026. Det drejer sig om at vælge en autoriseret afsendende identitet i MailPro, forberede de tilsvarende DNS ændringer og indsamle beviser fra den rigtige kampagnesti. Ingen konto blev inspiceret, og ingen poster eller meddelelser blev testet. Den første beslutning er, om den synlige afsender bruger et dedikeret lokalt domæne eller organisationens hoveddomæne, fordi disse valg har forskellige afhængigheder.
Adskil det lokale domæne fra den synlige adresse
MailPro'er lokal-domæne forklaring beskriver et organisationsejet domæne eller underdomæne, der understøtter tekniske elementer såsom links og sider. Det adskiller denne rolle fra indstillingen afsender-domæne. En hoveddomæneafsender kan stadig være afhængig af et separat konfigureret lokalt domæne. Identificer hvert navn og dets ejer i stedet for at placere hvert domæne i én "godkendt" kolonne.
Siden bruger også "Mail-Fra"-terminologi. Oversæt ikke denne formulering direkte til en påstand om SMTP konvolutten, der udsendes af en bestemt kampagne. Registrer den synlige Fra-adresse, påtænkt svarhåndtering, linkdomæne og faktisk kuvertidentitet som separate felter. De tre første kan gennemgås under forberedelsen; den sidste kræver passende rutedokumentation eller en observation af modtaget meddelelse. Produktetiketter er ikke en erstatning for protokolbevis.
Vælg den relevante opsætningsgren
For hoveddomænegrenen er Afsender domæne instruktioner kræver et eksisterende lokalt domæne og adgang til opsætningsfunktionen. De specificerer to licensspecifikke DKIM CNAME'er, verifikation via en adresse på det valgte domæne og et sidste udbyderkonfigurationstrin. Disse indstillinger påvirker licensen, ikke kun den kampagne, der vises i øjeblikket. Verifikationsmodtageren skal have den dokumenterede kontoadgang.
Behandl den bredde som et forandringsledelseskrav. List de kampagner, der bruger licensen, identificer deres ejere og beslut, hvornår en ændring kan accepteres eller fortrydes. Forbered de nøjagtige domæne- og licensspecifikke mål, men send ikke en bekræftelses-e-mail eller anmod om aktivering uden autorisation. Yderligere levering af lokalt domæne kan involvere en kommerciel beslutning; denne artikel fastslår hverken berettigelse eller pris.
Anvend ikke lokale domæneposter på ikke-relateret infrastruktur
Den adskilte Siden med afsenderadresser leverer en foretrukken lokal domænepostpakke, inklusive A, MX , SPF, DKIM og DMARC eksempler. Denne pakke er ikke en universel recept for organisationens hoveddomæne. En A-ændring kan påvirke hjemmesidens routing; en MX ændring kan påvirke indgående mail. Etabler formålet med det valgte domæne og eksisterende afhængigheder, før du medtager enten i en ændring.
Konfigurationskortet nedenfor adskiller de dokumenterede grene. Dens DKIM destinationer indeholder det faktiske licensnavn, som skal komme fra den tilsigtede konto. En pladsholder, en anden kundes værdi eller en gammel vælger fra en ikke-relateret tutorial kan ikke fastslå dette forhold. Under RFC 6376 , afsnit 3.6, verifikation bruger vælgeren og signeringsdomænet til at hente offentlig nøglemateriale; et DNS alias alene beviser ikke, at en udgående besked blev underskrevet.
Evaluer SPF og DMARC ved de korrekte identiteter
Før du foreslår en SPF redigering, skal du bestemme, hvilken domænes politik den udgående rute faktisk evaluerer. SPF vedrører normalt SMTP MAIL FRA identitet, ikke hvilken adresse en mail-klient viser tydeligt. Hvis en ændring er nødvendig, skal du bevare legitim eksisterende godkendelse og evaluere den kombinerede politiks DNS-forespørgselsvilkår. RFC 7208 , afsnit 2.4 og 4.6.4 leverer protokolgrundlaget. Udgiv ikke en anden uafhængig SPF -politik med samme navn.
Vurder DMARC separat. Dets godkendelsesresultat afhænger af en bestået SPF eller DKIM sti, der flugter med det synlige From-domæne, som defineret i RFC 9989 , afsnit 4.4. Begge mekanismer behøver ikke passere for dette resultat. Et politikeksempel er ikke autoritet til at erstatte eksisterende håndhævelse, og tilføjelse af en politik uden en passende rapportdestination opretter ikke automatisk en rapporteringsproces. Hold disposition, justering og rapporteringsbeslutninger adskilte.
Udbyderens 24-timers DKIM TTL-anbefaling er en dokumenteret indstillingspræference, ikke et løfte om, at enhver resolver eller postkasseudbyder vil opføre sig identisk. Heller ikke at vente en dag viser en vellykket godkendelse. Bevar eksisterende politik og DNS bevis, indhent godkendelser for de specifikke forskelle, og verificer resultater i stedet for at behandle forløbet tid som accept.
Indsaml en kampagnespecifik acceptrekord
En accepttabel skal identificere licensen, den valgte afsenderadresse, kampagnens arbejdsgang, tidspunkt, modtagesystem og bevisplacering. Tilføj det observerede From-domæne, kuvertidentitet, alle DKIM d=- og s=-værdier, betroede godkendelsesresultater og justeringsafslutningen. Hold uobserverede celler eksplicit tomme eller markeret med "ikke indsamlet". Et forhåndsvisningsskærmbillede kan ikke udfylde et meddelelseshovedfelt.
Overvej en fiktiv invitation fra events@harbor.example . En modtagerverificeret signatur med d=harbor.example leverer en nøjagtigt justeret DKIM identitet. Et link, der peger på mail.harbor.example , beviser intet om den signatur. På samme måde beviser blot at se en wps-vælger i en header ikke, at dens kryptografiske verifikation bestod. Disse eksempler illustrerer kun beslutningsreglen; de er ikke fanget Webpower-trafik.
Efter en godkendt ændring og den nødvendige udbyderoverdragelse skal du inspicere en kontrolleret meddelelse fra den valgte arbejdsgang. Bestem, hvilken modtager der har produceret godkendelsesvurderingen, i stedet for at stole på en påstand indsat af en opstrøms afsender. RFC 8601 , afsnit 7.1 forklarer den tillidsgrænse. Hold uventede resultater og diagnostik med sagen, og undgå at udvide en kampagnes konklusion til hver licens-workflow.
Bevar det ufærdige beviskrav
Det nøjagtige katalogkrav er: Aktuelt Webpower førstepartsopsætningsbevis og en identitetstabel med modtaget meddelelse fra det nøjagtige produkt og rute.
Det aktuelle produkt- og dokumentar-workflow understøttes. Den originale identitetstabel, kontoanvendelse, udbyderaktivering og autoriseret operationel verifikation er ikke fuldstændige. Gendannelsesplanlægning skal dække berørte kampagner og enhver ændret routing eller tillid, med afhængigheder kontrolleret, før gamle registreringer trækkes tilbage. Uafhængig teknisk gennemgang, webstedspræsentation, ejeraccept og publiceringsgodkendelse forbliver åbne. Intet her bekræfter levering eller en gennemført implementering.