Bekræft arrangementet med forudsigelig afsendelse
Denne vejledning dækker Predictive Response-kampagne-server-workflowet beskrevet i dets offentlige hjælpecenter. Det antager ikke, at alle prædiktive produkter, virksomheds SMTP arrangementer eller Salesforce e-mailstier opfører sig på samme måde. Registrer konto, kampagnetype, tilsigtet synlig fra domæne og system, der rent faktisk sender beskeden. Udskift ikke Salesforce egen godkendelseskonfiguration med en tredjepartskampagnerute uden bevis for, at det er ruten i brug.
Udbyderens leveringsside adskiller standard udbyder-domæneafsendelse fra brug af en kundes eget domæne. Den instruerer kunderne i at kontakte support efter udgivelsen SPF så sendeserverne kan justeres. DNS publicering er derfor kun en del af den dokumenterede ændring; et support-bekræftet server-side-trin er fortsat nødvendigt. Opsætning af prædiktiv respons levering
Inden du planlægger redigeringer, skal du tage en harmløs kampagnetest og de eksisterende autoritative DNS svar. Identificer de personer, der kontrollerer DNS , virksomhedens afsendende domæne, afvisningsadresse, og den forudsigende konto. Spørg efter de aktuelle kontospecifikke instruktioner, hvor det offentlige materiale lader et spørgsmål stå åbent. Dette manuskript repræsenterer ikke et supportsvar eller bevis på, at en bestemt konto er blevet opdateret.
Integrer SPF uden at erstatte ikke-relaterede afsendere
Udbyderens SPF hjælp identificerer include:spf.predictiveresponse.net som dens autorisationsmekanisme. Dens instruktioner adskiller tilføjelse af autorisation til en eksisterende politik fra oprettelse af en politik, hvor ingen eksisterer, og inkluderer et supportbekræftelsestrin. Brug det som udgangspunkt for den nøjagtige konto og domæne, ikke som bevis på, at den aktuelle konvolut allerede bruger den tilsigtede identitet. Predictive Response SPF opsætning
Bevar én SPF politik ved det relevante ejernavn. Opret ikke et sekund SPF rekord eller indsæt en anden terminal all-mekanisme i en eksisterende politik. Placer de nødvendige autorisationer i den tilsigtede evalueringsrækkefølge og behold andre legitime afsendere. Den eksisterende politiks valg af fejl eller softfail er en separat sikkerhedsbeslutning; et udbydereksempel er ikke godkendelse til at svække den. Gennemgå opslagsgrænser efter ændringer. SPF RFC 7208 afsnit 3.2 og 4.6.4
En validator, der viser syntaktisk gyldig SPF beviser ikke, at en kampagne evaluerer det pågældende domæne, at supporttrinnet er gennemført, eller at DMARC justerer. Registrer den forespurgte ejer, returneringspolitik, afhentningstid og testresultat. Sammenlign dem derefter med det faktiske konvolutdomæne fra en modtaget besked. Den komplette beviskæde skal forbinde autorisation, senderute og synlig identitet.
Bevar afhængigheden af afvisningsbehandling
Forudsigende retur-sti instruktioner bruger en kampagnetest til at identificere den kontospecifikke udbyders afvisningsdestination. Kunden forbereder derefter en returstiadresse på sit eget postsystem, aliaserer den til den identificerede destination og beder support om at opdatere den afsendende applikation. Siden forbinder dette arrangement med afvisningsbehandling i Salesforce . Gæt aldrig det kontospecifikke korte navn eller brug en anden kundes destination. Opsætning af forudsigelig returvej
Behandl dette som en operationel routingændring, ikke blot en kosmetisk afsenderredigering. Dokumenter, hvem der ejer aliasset, hvilken destinationssupport der er bekræftet, og hvad der sker, hvis aliaset ikke kan levere. Koordiner med kampagneejeren, så genforsøg og undertrykkelseshåndtering forstås. Hold det gamle arbejdsarrangement tilgængeligt for en godkendt rollback, indtil både godkendelse og afvisningsbehandling er blevet demonstreret.
Brug kun en kontrolleret, autoriseret afvisningstest eller udbyder-understøttet diagnostik til at evaluere denne arbejdsgang. Send ikke rigtige kampagner til opfundne modtagere eller afbryde undertrykkelsesdata blot for at skaffe beviser. Acceptregistreringen skal vise den forventede statusopdatering eller diagnostiske resultat uden at afsløre modtageradresser offentligt. En vellykket modtagerlevering og en fungerende tilbagemeldingssti er separate tests.
Sæt ikke lighedstegn mellem udbyder DKIM og tilpasset kunde DKIM
Den gennemgåede leveringsside siger DKIM håndteres på udbyderens servere. Den etablerer ikke en aktuel procedure for generering af kundedomænevælger eller beviser, hvilket d=-domæne en specifik kampagne bruger. Denne guide opfinder derfor ikke DKIM CNAME mål, en selvbetjent brugerdefineret domæne-switch eller en ikke-understøttet påstand om, at kundedomæne- DKIM ikke er tilgængelig. Disse spørgsmål forbliver for kontospecifikke beviser. Forudsigende DKIM erklæring
En modtaget besked kan bære en gyldig udbyder-domæne-signatur, uden at denne signatur stemmer overens med kundens synlige Fra-domæne. DKIM -verifikation og DMARC justering besvare forskellige spørgsmål. Optag hver signaturs domæne og vælger, modtagerens resultater, og om en passerende signatur stemmer overens. En justeret forbigående SPF sti kan også opfylde DMARC , men kun hvis det evaluerede konvolutdomæne og Fra-relation opfylder den relevante tilstand. DKIM RFC 6376 DMARC RFC 9989
Ændr ikke den domænedækkende DMARC politik, blot fordi en leverandør siger, at den håndterer DKIM . Spørg hvilken nøjagtig identitet der er autentificeret, og test den. Hvis der ikke er etableret en understøttet tilpasset sti, skal du holde udrulningen af tilpasset domæne afventende og beslutte med virksomhedsejeren, om en autoriseret udbyder-domæne-rute eller en anden understøttet konfiguration er passende.
Arbejdsark til forudsigelig kampagneaccept
Udfyld én post for hver særskilt konto og afsendelsesrute.
- Kampagnekontekst: konto, kampagnetype, virksomhedsejer, faktisk afsendertjeneste og tilsigtet Fra-domæne.
- SPF ændring: aktuel politik, foreslået godkendelse, konvolutdomæne, der kræver det, autoritative DNS svar, opslagsgennemgang og skift ejer.
- Supportkontrolpunkt: billetreference, nøjagtig anmodet serversideændring, supportbekræftet konto og domæne, færdiggørelsestid og uløste spørgsmål.
- Afvisningsrute: kundereturadresse, kontospecifik destination, alias ejer, kontrolleret diagnosticering og forventet Salesforce -behandlingsbevis.
- Modtaget identitet: testtidsstempel, betroet modtager, synlig fra, Return-Path , alle DKIM domæner og -vælgere, SPF resultat, DKIM resultater og tilpasset gennemløbssti.
- Udgivelsesbeslutning: resterende ikke-understøttede funktioner, tilbagerulningsplan, virksomhedsgodkendelse, gennemgang af menneskelig SMV og gennemgang af redaktionel præsentation. Disse er tomme acceptfelter, ikke levende resultater.
Fiktiv diagnose af en gennemført DNS ændring, men ufærdig opsætning
Dette scenarie er fiktivt. En marketingadministrator udgiver den dokumenterede SPF godkendelse, og en DNS validator rapporterer en gyldig politik. Den næste kampagne viser stadig et udbyderkonvolutdomæne og fejler DMARC for kundens Fra-domæne. En gyldig udbyder DKIM signatur vises, men dets signeringsdomæne stemmer heller ikke overens.
Teamet tjekker ændringsposten og opdager, at ingen gennemførte supportcheckpunktet. Det foreslåede næste trin er at bekræfte det understøttede kundekonvolut-arrangement, validere afvisningsaliaset for den pågældende konto og få support til at fuldføre den autoriserede konfiguration. Kun en ny modtaget kampagne og en kontrolleret afvisningsdiagnostik kan fastslå resultatet. Det oprindelige syntakstjek beviste ikke justering eller Salesforce afvisningshåndtering.
Bevis- og offentliggørelsesporte
Offentlig førstepartsopsætningsdokumentation blev hentet og gennemgået. Ingen forudsigelig konto, supportbillet, kunde- DNS , afvisningspostkasse, Salesforce -registrering eller modtaget kundebesked blev inspiceret eller ændret. Aktuel kontoanvendelse, aktivering på serversiden, tilpassede resultater og afvisningsbehandling forbliver live-gates. Menneskelig SMV-godkendelse og gengivet præsentationsgennemgang afventer. Den bredere fulde konfigurationstitel forbliver holdt, indtil DKIM spørgsmålene og den nøjagtige rute er løst; udkastet er upubliceret.
Skelne et alias fra en DNS -retursti-opskrift
Den dokumenterede afvisningsopsætning bruger en kundemail-adresse videresendelse til den kontospecifikke behandlingsadresse. Den leverer ikke en universel DNS CNAME opskrift. Behold aliasejeren og den supportbekræftede applikationsændring i den samme billet, og lad DKIM kapaciteten til det tilpassede domæne være uløst, indtil udbyderen fremlægger relevant bevis.
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.