Houd Account Engagement gescheiden van andere e-mailproducten Salesforce
Salesforce Account Engagement heeft een eigen workflow voor domeinbeheer. Begin met het bevestigen dat het bericht is verzonden via Account Engagement, voorheen Pardot genoemd, in plaats van de kern-e-mail Salesforce of Marketing Cloud Engagement. Een DNS recept voor een ander Salesforce product kan verschillende besturingselementen gebruiken en mag niet worden geïmporteerd simpelweg omdat de organisatie dezelfde leverancier gebruikt. In deze handleiding wordt de verificatie van Account Engagement-verzenddomeinen behandeld, DKIM en het optionele, ondersteunde, aangepaste retourpad.
Vermeld elke bedrijfseenheid, elk merk en het beoogde Van-domein dat door het account wordt gebruikt. Voeg de daadwerkelijke afzender toe die is geselecteerd door de campagne- en automatiseringsinstellingen. Een domein dat voorkomt in het mailboxadres van een gebruiker wordt niet automatisch geconfigureerd voor elke Account Engagement-route. Wijs een marketingeigenaar en DNS beheerder aan om samen de inventaris te controleren voordat de records van een gedeeld domein worden gewijzigd.
Het acceptatiedoel is een gecontroleerd ontvangen bericht met een afgestemd authenticatiemechanisme. Validatie van domeineigendom, DNS publicatie en een groene beheerstatus zijn nuttig tussentijds bewijs. Niets op zichzelf bewijst dat een specifieke campagne de beoogde identiteit gebruikte of dat een ontvangende server de authenticatie ervan accepteerde.
Begrijp het standaard SPF pad voordat u root- DNS bewerkt
Salesforce's DNS -richtlijnen voor accountbetrokkenheid geeft aan dat de Account Engagement-mail passeert SPF via de gecontroleerde verzendinfrastructuur en vereist geen klant SPF wijziging voor die standaardconfiguratie. Voeg geen generieke Salesforce SPF include toe aan het hoofddomein van de organisatie alleen maar omdat de productnaam in een DMARC rapport. Bevestig eerst de daadwerkelijke route en de geëvalueerde identiteit.
SPF verifieert de SMTP MAIL VAN identiteit, met aparte afhandeling voor HELO, onder RFC 7208. Het resultaat ervan verschilt van uitlijning met de zichtbare Van. Een succesvolle SPF -controle van het providerdomein kan naast niet-afgestemde SPF bestaan. Als u het beleid van een ander domein wijzigt, verandert dit niet van welk envelopdomein een bericht gebruikmaakt.
Behoud het SPF beleid dat nodig is voor de andere services van de organisatie. Als een afzonderlijk geautoriseerde aangepaste installatie een beleidswijziging vereist, bekijk dan één volledig beleid bij die eigenaar, inclusief geneste DNS-querytermen en de protocolopzoeklimiet. Maak geen tweede SPF record of verwijder niet-gerelateerde afzenders om ruimte te maken voor een niet-geverifieerde vereiste.
Verifieer eigendom en DKIM als afzonderlijke records
Gebruik Domeinbeheer om het beoogde e-mailverzenddomein en de verwachte DNS vermeldingen te identificeren. De DNS begeleiding onderscheidt de validatiesleutel van het domein van zijn DomainKey. De validatiewaarde bepaalt het eigendom voor verzending; de DKIM waarde ondersteunt het ondertekenen van berichten. Bewaar beide doeleinden in het werkblad in plaats van ze te behandelen TXT record met een Salesforce waarde als uitwisselbaar bewijsmateriaal.
Kopieer waarden uit het daadwerkelijke account. Bewaar de volledige recordeigenaar, type, waarde en instructiedatum voordat u de DNS wijziging doorvoert. Controleer of een ander Account Engagement-account of een andere dienst al afhankelijk is van dezelfde eigenaar. Overschrijf geen conflicterend record, hergebruik de waarde van een andere klant niet en wijzig geen gegevens keuzeschakelaar naar een verzonnen naam. Vraag ondersteuning voor een ondersteunde oplossing als accountafspraken botsen.
Houd het e-mailverzenddomein gescheiden van het trackerdomein. Salesforce waarschuwt expliciet voor het gebruik van hetzelfde domein voor deze twee functies. Een tracking-hostnaam met een merknaam is niet hetzelfde als het Van-domein, zelfs als beide een ouder delen. Afhankelijkheden voor het bijhouden van voorraad worden afzonderlijk beheerd, zodat verificatiewerkzaamheden niet per ongeluk item-URL's of campagnelinks wijzigen.
Publiceer de DomainKey via de gedocumenteerde workflow
Salesforce's DKIM implementatie-instructies de rol Accountbetrokkenheidbeheerder vereist. Open in de Lightning-app Instellingen voor accountbetrokkenheid en vervolgens Domeinbeheer. In de alternatieve Account Engagement-interface is het gedocumenteerde startpunt Beheerder. Open onder Email Sending Domains de Expected DNS Entries voor het gekozen domein en kopieer de DomainKey-waarde voor publicatie als TXT .
Gebruik de eigenaar en waarde die voor dat account en domein worden weergegeven. Het huidige artikel zegt dat het maximaal 24 uur kan duren voordat de ondertekening van kracht wordt nadat het record is toegevoegd. Beschouw dit als een richtlijn voor de timing van de provider, en niet als een garantie dat elke DNS cache of ontvanger op hetzelfde moment wordt bijgewerkt. Noteer de publicatietijd en wacht op de verwachte status voordat u een nieuwe test beoordeelt.
Bevestig het openbare DNS antwoord, inclusief de exacte volledig gekwalificeerde eigenaar. DNS editors voegen soms de zonenaam toe aan het hostveld, waardoor een gedupliceerd achtervoegsel ontstaat wanneer een volledige naam wordt ingevoerd. Bekijk het resulterende antwoord in plaats van het invoerformulier te vertrouwen. Bewaar eventuele domeinbeheerfouten en de details ervan, zodat ondersteuning de daadwerkelijke fout kan onderzoeken in plaats van een geparafraseerde status.
Bepaal of een aangepast retourpad vereist is
Salesforce's DMARC -ondersteuningsartikel beschrijft uitgelijnde DKIM als het normale DMARC pad en legt uit dat dit de standaard is retourpad domein komt niet overeen met de zichtbare Van. Het documenteert ook een door ondersteuning ondersteund, aangepast retourpadverzoek. De aangegeven beperking is één vast aangepast retourpaddomein per bedrijfseenheid, in plaats van een variabel domein dat voor elk bericht wordt geselecteerd.
Voordat u deze optie aanvraagt, moet u de bedrijfsvereiste identificeren. Een organisatie die zowel SPF als DKIM moet afstemmen, moet de feitelijke domeinindeling en afstemmingsmodus met ondersteuning evalueren. Een bedrijfseenheid die niet-gerelateerde merken verzendt, mag er niet vanuit gaan dat één vast retourpad kan worden afgestemd op elk Van-domein. Houd die ontwerpvraag open totdat de waargenomen identiteiten en ondersteunde configuratie deze oplossen.
Haal de exacte DNS records op uit de ondersteuningsaanvraag en laat de DNS eigenaar conflicten en afhankelijkheden beoordelen. Dit artikel levert geen universeel aangepast retourpaddoel of activeringsschakelaar. Het publiceren van geraden records of het kopiëren van de bounce-domeinconfiguratie van een ander product kan een werkroute onderbreken zonder aan de vereiste te voldoen.
Test de geselecteerde afzender via de daadwerkelijke berichtenstroom
Verzend ongevaarlijke, gecontroleerde berichten via elk wezenlijk verschillend verzenddomein en business-unitroute. Gebruik dezelfde afzenderselectie als de geplande campagne of automatisering. Leg de campagnereferentie, bericht-ID, UTC-tijd en externe testontvanger vast. Als een preview- of testfunctie een ander pad gebruikt dan de productie, los dat verschil dan op voordat u het als representatief bewijs behandelt.
Leg op het vertrouwde ontvangstsysteem From, Return-Path en alle DKIM ondertekeningsdomeinen en selectors vast. RFC 6376 definieert de d= en s= waarden die worden gebruikt om de openbare verificatiesleutel te lokaliseren. Vergelijk het waargenomen ondertekeningsdomein met het geconfigureerde verzendende domein. Een DNS record kan kloppen terwijl een bericht toch gebruik maakt van een onverwachte afzender of een andere route.
Toepassen RFC 9989 naar de daadwerkelijke resultaten. DMARC kan door een uitgelijnde passage passeren DKIM -handtekening of het passeren van uitgelijnde SPF . Leg vast welk mechanisme het resultaat opleverde en welke uitlijningsmodus van toepassing was. Bewaar SPF authenticatie, SPF uitlijning, DKIM authenticatie en DKIM uitlijning in aparte velden. Dit voorkomt dat een enkele groene status een niet-geteste vereiste verbergt.
Los problemen met de falende grens op in plaats van elk besturingselement te wijzigen
Als het verzendende domein niet geverifieerd is, vergelijk dan de validatiesleutel en de exacte DNS eigenaar met de verwachte DNS vermeldingen. Als DKIM na de verwachte activeringsperiode ontbreekt, bevestig dan het geselecteerde Van-domein en account en controleer vervolgens Domeinbeheerfouten. Als een handtekening mislukt, verifieer dan de selector en de publieke waarde en inspecteer eventuele downstream-systemen die het bericht na ondertekening wijzigen.
Als DMARC mislukt terwijl SPF slaagt, onderzoek dan de uitlijning en of de uitgelijnde DKIM voor die afzender is geconfigureerd. Beschouw standaard SPF succes niet als een belofte van DMARC succes. Als er sprake is van een aangepast retourpad, vergelijk dan de waargenomen envelopidentiteit met de vaste businessunit-instelling en de door ondersteuning geleverde instructies. Bewaar een representatief mislukt bericht voor diagnose.
Houd het DMARC beleid en de rapportagebestemmingen van de organisatie onder hun bestaande eigendom. Het Salesforce artikel beschrijft de behoefte aan externe DMARC monitoring in plaats van dat Account Engagement deze verzamelt mislukkingsrapporten. DNS authenticatie mag niet stilletjes de rapportagebestemmingen vervangen of de handhaving bij niet-gerelateerde afzenders verminderen. Bespreek elke voorgestelde beleidswijziging afzonderlijk met de e-mail- en beveiligingseigenaren.
Accountbetrokkenheidsdomeinwerkblad
- Account, bedrijfseenheid, merk en verzendworkflow: ____.
- Geselecteerd Van-adres en geconfigureerd E-mailverzenddomein: ____.
- Afzonderlijk trackerdomein en zijn bestaande afhankelijkheden: ____.
- Validatiesleutel en DKIM -recordreferenties van verwachte DNS vermeldingen: ____.
- Openbare DNS antwoorden, publicatietijd en beheerstatus: ____.
- Standaard of door ondersteuning ondersteund, aangepast retourpadontwerp: ____.
- Aangepaste retourpadbeperking en ondersteuningsbevestiging waar relevant: ____.
- Test bericht-ID, UTC-tijd, Van, Return-Path en DKIM identiteiten: ____.
- Betrouwbare authenticatieresultaten en afgestemd DMARC mechanisme: ____.
- Uitzonderingen, controle eigenaar en goedgekeurde terugvordering: ____.
Fictief voorbeeld van SPF succes zonder afstemming
Alleen fictieve schriftelijke casus: AE-01 gaat ervan uit dat business unit Noord verzendt als news@example.org en business unit Zuid verzendt als news@example.net . Een voorgesteld vast aangepast retourpad onder bounce.example.org kan overeenkomen met het eerste onder een ontspannen SPF uitlijning, maar er kan niet van worden uitgegaan dat het overeenkomt met het niet-gerelateerde tweede. DKIM -handtekeningen en SPF resultaten blijven onbekend, dus geen van beide routes heeft een bevestigd DMARC -oordeel. De marketing- en e-maileigenaren moeten de bedrijfsunitinstellingen scheiden en de uitgelijnde DKIM per geselecteerd Van-domein valideren voordat ze een root SPF bewerking aanvragen. Alle identiteiten en arrangementen zijn uitgevonden; er is geen ondersteuningsaanvraag, DNS query of bericht uitgevoerd.
Zorg ervoor dat de voltooiing gekoppeld is aan levend bewijs
De gedocumenteerde werkstroom verifieert niet de machtigingen van een echte tenant, de gegenereerde waarden of de aangepaste retourpadmogelijkheden. Die accountcontroles, live DNS en headerverificatie, visuele beoordeling en menselijke MKB-goedkeuring blijven hangende. Deze gids is niet gepubliceerd en mag niet worden gepresenteerd als bewijs dat de campagnes van een organisatie tijdens de productie zijn geverifieerd.
Scheid een voorbijgaand bericht van de gereedheid voor handhaving
RFC 9989 Sectie 7.4 vereist geldige DKIM voor een domein dat p=reject publiceert en waarschuwt voor de interoperabiliteit van indirecte e-mail. Eén enkel afgestemd SPF resultaat rechtvaardigt op zichzelf geen uitrol van het afwijzingsbeleid. Bekijk alle legitieme routes en beleidseigendom afzonderlijk van deze providerconfiguratie.