Börja med produkten och domänbeslutet
Webpowers nuvarande dokumentationsspår leder till Spotler MailPro. Den officiella rebranding sida identifierar uttryckligen MailPro som den fortsatta Webpower-marknadsföringsautomationsprodukten. Den anslutningen tillåter en produktspecifik guide; det gör inte instruktionerna utbytbara med Spotler Mail+, SendPro eller alla konton som en gång använde Webpower-namnet. Bekräfta den faktiska licensen och gränssnittet innan du planerar implementering.
Den här artikeln använder offentliga instruktioner som granskades den 9 november 2026. Det handlar om att välja en auktoriserad sändningsidentitet inom MailPro, förbereda motsvarande DNS ändringar och samla bevis från den verkliga kampanjvägen. Inget konto inspekterades och inga poster eller meddelanden testades. Det första beslutet är om den synliga avsändaren använder en dedikerad lokal domän eller organisationens huvuddomän, eftersom dessa val har olika beroenden.
Separera den lokala domänen från den synliga adressen
MailPros lokal domän förklaring beskriver en organisationsägd domän eller underdomän som stödjer tekniska element som länkar och sidor. Det skiljer den rollen från inställningen avsändare-domän. En huvuddomänavsändare kan fortfarande vara beroende av en separat konfigurerad lokal domän. Identifiera varje namn och dess ägare istället för att placera varje domän i en "autentiserad" kolumn.
Sidan använder också "Mail-From"-terminologi. Översätt inte den formuleringen direkt till ett påstående om SMTP kuvertet som sänds ut av en viss kampanj. Anteckna den synliga Från-adressen, avsedd svarshantering, länkdomän och faktisk kuvertidentitet som separata fält. De tre första kan granskas under förberedelserna; den sista kräver lämplig ruttdokumentation eller en observation av mottagna meddelanden. Produktetiketter är inte en ersättning för protokollbevis.
Välj lämplig inställningsgren
För huvuddomängrenen Avsändarens domäninstruktioner kräver en befintlig lokal domän och tillgång till inställningsfunktionen. De anger två licensspecifika DKIM CNAMEs, verifiering genom en adress på den valda domänen och ett sista steg för konfiguration av leverantören. Dessa inställningar påverkar licensen, inte bara kampanjen som visas för närvarande. Verifieringsmottagaren måste ha den dokumenterade kontoåtkomsten.
Behandla den bredden som ett krav på förändringsledning. Lista kampanjerna som använder licensen, identifiera deras ägare och bestäm när en ändring kan accepteras eller ångras. Förbered de exakta domän- och licensspecifika målen, men skicka inte ett verifieringsmail eller begär aktivering utan tillstånd. Ytterligare lokal domänadministration kan innebära ett kommersiellt beslut; denna artikel fastställer varken rättighet eller pris.
Använd inte lokala domänposter på icke-relaterad infrastruktur
Den separata Sidan med avsändaradresser tillhandahåller ett föredraget postpaket för lokal domän, inklusive A, MX , SPF, DKIM och DMARC exempel. Det paketet är inte ett universellt recept för organisationens huvuddomän. En A-ändring kan påverka webbplatsens routing; en MX ändring kan påverka inkommande e-post. Fastställ syftet med den valda domänen och befintliga beroenden innan du inkluderar någon av dem i en ändring.
Konfigurationskartan nedan särskiljer de dokumenterade grenarna. Dess DKIM destinationer innehåller det faktiska licensnamnet, som måste komma från det avsedda kontot. En platshållare, en annan kunds värde eller en gammal väljare från en icke-relaterad handledning kan inte fastställa det förhållandet. Under RFC 6376 , avsnitt 3.6, verifiering använder väljaren och signeringsdomänen för att hämta publikt nyckelmaterial; enbart ett DNS alias bevisar inte att ett utgående meddelande signerades.
Utvärdera SPF och DMARC vid rätt identiteter
Innan du föreslår en SPF -redigering, bestäm vilken domäns policy den utgående rutten faktiskt utvärderar. SPF berör normalt SMTP MAIL FRÅN identitet, inte vilken adress en e-postklient visar tydligt. Om en ändring behövs, bevara legitima befintliga auktoriseringar och utvärdera den kombinerade policyns DNS-förfrågningsvillkor. RFC 7208 , avsnitt 2.4 och 4.6.4 tillhandahåller protokollbasen. Publicera inte en annan oberoende SPF policy med samma namn.
Bedöm DMARC separat. Dess autentiseringsresultat beror på en passerande SPF eller DKIM sökväg som är i linje med den synliga From-domänen, enligt definitionen i RFC 9989 , avsnitt 4.4. Båda mekanismerna behöver inte passera för det resultatet. Ett policyexempel är inte behörighet att ersätta befintlig tillämpning, och att lägga till en policy utan en lämplig rapportdestination skapar inte automatiskt en rapporteringsprocess. Behåll läggning, inriktning och rapporteringsbeslut skilda.
Leverantörens 24-timmars DKIM TTL-rekommendation är en dokumenterad inställningspreferens, inte ett löfte om att alla resolver- eller brevlådeleverantörer kommer att bete sig identiskt. Att vänta en dag visar sig inte heller vara framgångsrik autentisering. Bevara befintlig policy och DNS bevis, erhåll godkännanden för de specifika skillnaderna och verifiera resultat istället för att behandla förfluten tid som acceptans.
Samla in en kampanjspecifik acceptanspost
En accepttabell ska identifiera licensen, vald avsändaradress, kampanjarbetsflöde, tid, mottagningssystem och bevisplats. Lägg till den observerade From-domänen, kuvertidentiteten, alla DKIM d=- och s=-värden, betrodda autentiseringsresultat och justeringens slutsats. Håll oobserverade celler uttryckligen tomma eller märkta som "ej insamlade." En skärmdump för förhandsgranskning kan inte fylla ett meddelandehuvudfält.
Överväg en fiktiv inbjudan från events@harbor.example . En mottagarverifierad signatur med d=harbor.example tillhandahåller en exakt anpassad DKIM identitet. En länk som pekar på mail.harbor.example bevisar ingenting om den signaturen. På samma sätt, att bara se en wps-väljare i en rubrik bevisar inte att dess kryptografiska verifiering godkändes. Dessa exempel illustrerar endast beslutsregeln; de fångas inte upp Webpower-trafik.
Inspektera ett kontrollerat meddelande från det valda arbetsflödet efter en godkänd ändring och den nödvändiga överlämnandet av leverantören. Fastställ vilken mottagare som producerade autentiseringsbedömningen, snarare än att lita på ett påstående som infogats av en uppströmssändare. RFC 8601 , avsnitt 7.1 förklarar den förtroendegränsen. Behåll oväntade resultat och diagnostik med fallet, och undvik att utöka en kampanjs slutsats till varje licensarbetsflöde.
Bevara det oavslutade beviskravet
Det exakta katalogkravet är: Aktuellt Webpower första parts installationsbevis och en identitetstabell för mottagna meddelanden från den exakta produkten och rutten.
Det aktuella arbetsflödet för produkten och dokumentären stöds. Den ursprungliga identitetstabellen, kontotillämplighet, leverantörsaktivering och auktoriserad driftverifiering är inte fullständiga. Återställningsplaneringen måste täcka berörda kampanjer och eventuell ändrad routing eller förtroende, med beroenden kontrollerade innan gamla register tas bort. Oberoende teknisk granskning, webbplatspresentation, ägargodkännande och publiceringsgodkännande förblir öppna. Inget här intygar leverans eller en avslutad implementering.