Hold kontoengasjement atskilt fra andre Salesforce -e-postprodukter
Salesforce Account Engagement har sin egen arbeidsflyt for domeneadministrasjon. Begynn med å bekrefte at meldingen sendes via Account Engagement, tidligere kalt Pardot, i stedet for kjernen Salesforce -e-post eller Marketing Cloud Engagement. En DNS oppskrift for et annet Salesforce produkt kan bruke forskjellige kontroller og bør ikke importeres bare fordi organisasjonen bruker samme leverandør. Denne veiledningen dekker verifisering av kontoengasjement som sender domene, DKIM og den valgfrie støtteassisterte tilpassede returbanen.
List opp hver forretningsenhet, merkevare og tiltenkt Fra-domene som brukes av kontoen. Ta med den faktiske avsenderen valgt av kampanje- og automatiseringsinnstillinger. Et domene som vises i en brukers postboksadresse, konfigureres ikke automatisk for hver rute for kontoengasjement. Tildel en markedsføringseier og DNS administrator til å gjennomgå beholdningen sammen før du endrer postene til et delt domene.
Akseptmålet er en kontrollert mottatt melding med en justert bestått autentiseringsmekanisme. Validering av domeneeierskap, DNS publisering og en grønn administrasjonsstatus er nyttige mellomliggende bevis. Ingen beviser alene at en spesifikk kampanje brukte den tiltenkte identiteten eller at en mottakende server godtok autentiseringen.
Forstå standard SPF -bane før du redigerer root- DNS
Salesforce's Account Engagement DNS veiledning oppgir at Account Engagement-e-posten går SPF gjennom den kontrollerte sendeinfrastrukturen og krever ikke en endring av kundens SPF for det standardoppsettet. Ikke legg til en generisk Salesforce SPF -inkludering i organisasjonens rotdomene bare fordi produktnavnet vises i en DMARC rapportere. Bekreft den faktiske ruten og evaluerte identiteten først.
SPF autentiserer SMTP POST FRA identitet, med egen håndtering for HELO, under RFC 7208. Resultatet er forskjellig fra justering med den synlige Fra. En vellykket SPF -sjekk av leverandørdomene kan eksistere side om side med ikke-justert SPF . Endring av et annet domenes policy endrer ikke hvilket konvoluttdomene en melding bruker.
Bevar SPF policyen som trengs av organisasjonens andre tjenester. Hvis et separat autorisert tilpasset oppsett krever en policyendring, må du gjennomgå én fullstendig policy hos den eieren, inkludert nestede DNS-spørringstermer og grensen for protokolloppslag. Ikke lag et sekund SPF rekord eller fjern urelaterte avsendere for å gi plass til et ubekreftet krav.
Bekreft eierskap og DKIM som separate poster
Bruk domeneadministrasjon for å identifisere det tiltenkte domene for e-postsending og dets forventede DNS oppføringer. De DNS -veiledning skiller domenets valideringsnøkkel fra domenenøkkelen. Valideringsverdien etablerer eierskap for sending; DKIM verdien støtter meldingssignering. Bevar begge formålene i regnearket i stedet for å behandle noen TXT post som inneholder en Salesforce verdi som utskiftbare bevis.
Kopier verdier fra den faktiske kontoen. Lagre hele posteier, type, verdi og instruksjonsdato før du gjør DNS endringen. Sjekk om en annen Account Engagement-konto eller en annen tjeneste allerede avhenger av samme eier. Ikke overskriv en motstridende oppføring, gjenbruk en annen kundes verdi eller endre en velger til et oppfunnet navn. Be om støtte for en støttet løsning når kontoordninger kolliderer.
Hold e-postsendedomenet forskjellig fra sporingsdomenet. Salesforce advarer eksplisitt mot å bruke det identiske domenet for disse to funksjonene. Et merket sporingsvertsnavn er ikke det samme som From-domenet, selv når begge deler en forelder. Beholdningssporingsavhengigheter separat, slik at autentiseringsarbeid ikke utilsiktet endrer nettadresser eller kampanjekoblinger.
Publiser DomainKey gjennom den dokumenterte arbeidsflyten
Salesforce's DKIM implementeringsinstruksjoner krever rollen Account Engagement Administrator. I Lightning-appen åpner du Account Engagement Settings og deretter Domain Management. I det alternative Account Engagement-grensesnittet er det dokumenterte utgangspunktet Admin. Under Email Sending Domains, åpne Forventede DNS oppføringer for det valgte domenet og kopier DomainKey-verdien for publisering som TXT .
Bruk eieren og verdien som vises for den kontoen og domenet. Den nåværende artikkelen sier å tillate opptil 24 timer for signering å tre i kraft etter at posten er lagt til. Betrakt det som leverandørens tidsveiledning, ikke en garanti for at hver DNS buffer eller mottaker vil oppdateres på samme øyeblikk. Registrer publiseringstiden og vent på forventet tilstand før du bedømmer en ny test.
Bekreft det offentlige DNS svaret, inkludert den nøyaktige fullt kvalifiserte eieren. DNS redaktører legger noen ganger sonenavnet til vertsfeltet, og lager et duplisert suffiks når et fullt navn legges inn. Se gjennom det resulterende svaret i stedet for å stole på inndataskjemaet. Lagre eventuelle domeneadministrasjonsfeil og dens detaljer slik at støtten kan undersøke den faktiske feilen i stedet for en omskrevet status.
Bestem om en egendefinert returbane er nødvendig
Salesforce's DMARC støtteartikkel beskriver justert DKIM som den normale DMARC banen og forklarer at standarden retur-sti domenet stemmer ikke overens med den synlige Fra. Den dokumenterer også en støtteassistert tilpasset returbaneforespørsel. Den angitte begrensningen er ett fast tilpasset returbanedomene per forretningsenhet, i stedet for et variabelt domene valgt for hver melding.
Før du ber om dette alternativet, identifiser forretningskravet. En organisasjon som trenger justert SPF samt DKIM bør evaluere det faktiske domenearrangementet og justeringsmodusen med støtte. En forretningsenhet som sender for ikke-relaterte merkevarer, bør ikke anta at én fast returbane kan samsvare med hvert From-domene. Hold designspørsmålet åpent til de observerte identitetene og støttede konfigurasjonen løser det.
Få de eksakte DNS -postene fra støttesaken, og få DNS eieren til å gjennomgå konflikter og avhengigheter. Denne artikkelen gir ingen universell tilpasset returbanemål eller aktiveringsbryter. Å publisere gjettede poster eller kopiere et annet produkts avvisningsdomenekonfigurasjon kan bryte en arbeidsrute uten å tilfredsstille kravet.
Test den valgte avsenderen gjennom selve meldingsflyten
Send harmløse kontrollerte meldinger gjennom hver vesentlig forskjellige sendedomene og forretningsenhetsrute. Bruk samme avsendervalg som den planlagte kampanjen eller automatiseringen. Registrer kampanjereferansen, meldings-ID, UTC-tid og ekstern testmottaker. Hvis en forhåndsvisnings- eller testfunksjon bruker en annen bane enn produksjonen, må du løse den forskjellen før du behandler den som representativt bevis.
På det pålitelige mottakssystemet kan du registrere From, Return-Path og alle DKIM signeringsdomener og -velgere. RFC 6376 definerer d=- og s=-verdiene som brukes til å finne den offentlige verifikasjonsnøkkelen. Sammenlign det observerte signeringsdomenet med det konfigurerte sendedomenet. En DNS post kan være korrekt mens en melding fortsatt bruker en uventet avsender eller en annen rute.
Søke RFC 9989 til de faktiske resultatene. DMARC kan passere gjennom en passering justert DKIM signatur eller passerer justert SPF . Registrer hvilken mekanisme som ga resultatet og hvilken justeringsmodus som ble brukt. Hold SPF autentisering, SPF justering, DKIM autentisering og DKIM -justering i separate felt. Dette forhindrer at en enkelt grønn status skjuler et uprøvd krav.
Feilsøk den sviktende grensen i stedet for å endre alle kontroller
Hvis avsenderdomenet er ubekreftet, sammenligner du valideringsnøkkelen og den eksakte DNS eieren med Forventede DNS oppføringer. Hvis DKIM mangler etter den forventede aktiveringsperioden, bekrefter du valgt Fra domene og konto, og kontrollerer deretter feilene for domeneadministrasjon. Hvis en signatur mislykkes, verifiser velgeren og den offentlige verdien og inspiser ethvert nedstrømssystem som endrer meldingen etter signering.
Hvis DMARC mislykkes mens SPF passerer, undersøk justeringen og om justert DKIM ble konfigurert for den avsenderen. Ikke behandle standard SPF suksess som et løfte om DMARC suksess. Hvis en tilpasset returbane er involvert, sammenligner du den observerte konvoluttidentiteten med den faste forretningsenhetsinnstillingen og instruksjonene som er gitt av støtte. Behold en representativ mislykket melding for diagnose.
Hold organisasjonens DMARC policy og rapporteringsdestinasjoner under deres eksisterende eierskap. Salesforce artikkelen beskriver et behov for ekstern DMARC overvåking i stedet for Account Engagement som samler inn disse feilrapporter. DNS autentiseringsarbeid bør ikke i det stille erstatte rapporteringsdestinasjoner eller redusere håndhevelsen på tvers av ikke-relaterte avsendere. Gjennomgå eventuelle foreslåtte endringer i retningslinjene separat med e-post- og sikkerhetseierne.
Regneark for domene for kontoengasjement
- Konto, forretningsenhet, merkevare og sendingsarbeidsflyt: ____.
- Valgt Fra-adresse og konfigurert e-postsendingsdomene: ____.
- Separat sporingsdomene og dets eksisterende avhengigheter: ____.
- Valideringsnøkkel og DKIM -postreferanser fra forventede DNS oppføringer: ____.
- Offentlige DNS svar, publiseringstidspunkt og administrasjonsstatus: ____.
- Standard eller støtteassistert tilpasset returbanedesign: ____.
- Egendefinert returbanebegrensning og støttebekreftelse der det er relevant: ____.
- Test meldings-ID, UTC-tid, fra, Return-Path og DKIM identiteter: ____.
- Pålitelige autentiseringsresultater og justert DMARC mekanisme: ____.
- Unntak, overvåkingseier og godkjent gjenoppretting: ____.
Fiktivt eksempel på SPF suksess uten justering
Kun fiktiv skriftlig sak: AE-01 antar at forretningsenhet Nord sender som news@example.org og forretningsenhet Sør sender som news@example.net . En foreslått fast tilpasset returbane under bounce.example.org kan være på linje med den første under avslappet SPF justering, men kan ikke antas å være på linje med den ikke-relaterte andre. DKIM signaturer og SPF resultater forblir ukjente, så ingen av rutene har en påstått DMARC -dom. Markedsførings- og e-posteierne bør skille innstillingene for forretningsenhet og validere justert DKIM per valgt Fra-domene før de ber om noen rot- SPF redigering. Alle identiteter og arrangementer er oppfunnet; ingen støttesak, DNS -spørring eller melding ble utført.
Hold fullføring knyttet til levende bevis
Den dokumenterte arbeidsflyten verifiserer ikke en ekte leietakers tillatelser, genererte verdier eller egendefinerte returbanemuligheter. Disse kontosjekkene, live DNS og topptekstverifisering, visuell gjennomgang og menneskelig SMB-godkjenning gjenstår. Denne veiledningen er upublisert og må ikke presenteres som bevis på at en organisasjons kampanjer er autentisert i produksjon.
Skille en bestått melding fra håndhevingsberedskap
RFC 9989 Seksjon 7.4 krever gyldig DKIM for et domene som publiserer p=reject og advarer om interoperabilitet med indirekte e-post. Et enkelt justert SPF resultat rettferdiggjør ikke i seg selv en utrulling av avvisningspolicy. Gå gjennom alle legitime ruter og policyeierskap separat fra dette leverandøroppsettet.