Upprätta Eloquas sändnings- och varumärkesomfång
Behandla en Eloqua-kampanj och ett säljanpassat budskap som potentiellt olika fall från en domän. Identifiera Eloqua-instansen, varumärket och sändningsdomänen innan du ber DNS ägaren att göra ändringar. Oracle beskriver konvertering till en varumärkesdomän innan den första kampanjen för nya prenumerationskonton. Denna varumärkesförutsättning är inte i sig bevis på att en viss kampanj går igenom DMARC. Se Eloqua e-postautentisering och varumärke.
Omfattningen av denna artikel är en Eloqua implementerings- och verifieringsplan baserad på offentlig dokumentation. Exakta nycklar, väljare namn, kuvertdomäner och aktiveringssteg för hyresgäster måste komma från det aktuella Eloqua-introduktions- eller supportarbetsflödet. Kopiera inte poster från OCI Email Delivery eller Responsys bara för att de också är Oracle-produkter.
Bekräfta förutsättningen Från och återvisning
Innan DNS publicering eller en testsändning, bekräfta att den avsedda From-domänen matchar underdomänen för en redan konfigurerad Eloqua bounceback-domän. Oracle uppger att en missmatchning kan ge valideringsfel och blockerade sändningar. Dess exempel parar en sändande underdomän av go.example.com med return@go.example.com eller bounce@go.example.com . Registrera den faktiska konfigurerade bounceback-adressen och domänen för det valda varumärket; behandla inte ett föreslaget avvisningsvärde som en befintlig konfiguration. Se Eloqua e-autentiseringsinställning, Email Bounceback Address och Email Standards: From och Reply-to Address.
Kontrollera både standardinställningar för e-post och eventuella åsidosättningar per e-post. Oracle noterar att bounceback-domänen kan ändras när flera domäner har konfigurerats. Ett redigerbart Från-fält fastställer inte att en godtycklig företagsdomän är tillåten. Om en signaturregel föreslår en annan Från-domän, skaffa kontospecifik bekräftelse på den företagsavsändare som stöds och dess konfigurerade avvisningsparning innan du aktiverar rutten. Håll den kvar om den förutsättningen inte kan verifieras. DKIM Enbart signeringstäckning tar inte bort detta sändningskrav.
Jämför kampanj- och företagsavsändardomäner
Oracles autentiseringsinställningssida beskriver SPF som en del av Eloqua-implementeringen och anropar public-key publicering på företagsdomänen när företagsdomänsignaturregler skickas på uppdrag av säljteamet. Detta gör själva From-domän-inventeringen viktig, särskilt när kampanjer och personliga försäljningsmeddelanden använder olika domäner. Se Eloqua e-autentiseringsinställning.
Lista de tillåtna Från-adresserna, deras bekräftade konfigurerade avvisningsparningar och mallen eller signaturregeln som producerar var och en. Fånga en baslinje från både huvudkampanjvägen och vilken företagsdomän som helst. Ett test som skickas från en marknadsföringsunderdomän kan inte fastställa signeringstäckning för en säljares företagsadress. Bevara Svara-Till separat eftersom svar och autentisering har olika syften.
Skaffa och publicera en kontospecifik ändringsuppsättning
Begär de aktuella Eloqua-instruktionerna för den identifierade instansen och domänerna. Granskningspaketet bör innehålla exakta offentliga DNS ägare, posttyper och värden, den förväntade signeringsdomänen, aktiveringssteg och eventuella förutsättningar för befintliga varumärkesdomäner. Offentlig dokumentation fastställer arbetsflödeskoncepten men tillhandahåller inte en universell kopiera-och-klistra-postuppsättning för varje konto.
Innan publicering, inspektera den aktuella zonen och identifiera befintlig SPF auktorisation. Lägg inte till en andra SPF -policy hos samma ägare. SPF standarden definierar postval och gränser för DNS-frågor; ett föreslaget tillägg måste bedömas med de befintliga mekanismerna, inte som en isolerad sträng. Se RFC 7208 Sender Policy Framework. Bevara orelaterade legitima avsändare och orelaterade DKIM väljare.
Efter att DNS ägaren har publicerat de godkända ändringarna, bekräfta det auktoritativa svaret och be Eloqua-ägaren att slutföra den angivna aktiveringen. Spela in varje sida oberoende. En offentlig nyckel kan vara närvarande medan applikationen fortfarande signerar med en annan identitet, och en applikationsstatus kan visas redo medan en delegerad zon är felkonfigurerad.
Testa varje riktig kampanjväg
Först efter att Från och konfigurerad bounceback-parning har godkänt Eloqua-valideringen, skicka ett litet, samtyckt test från den faktiska kampanjkonfigurationen till kontrollerade mottagare. Inkludera en personlig rutt för företagsdomän först efter det att dess sändningskonfiguration som stöds och parning för avvisning har bekräftats. Om Eloqua blockerar en felaktig avsändare före sändning, lös detta krav innan du diagnostiserar mottagarautentisering. Spela in från, Return-Path, DKIM d= och s=, och det mottagande systemets SPF , DKIM och DMARC resultat. DKIM signatur verifiering och DMARC inriktning är distinkta tester. Se RFC 6376 Domain Keys Identified Mail och RFC 9989 Domänbaserad meddelandeautentiseringsrapportering och överensstämmelse.
Jämför det levererade meddelandet med den godkända domäninventeringen. När en Från-adress ändras dynamiskt, testa mer än ett representativt värde. Dra inte slutledning av allmän täckning från en statisk mallförhandsgranskning. Kontrollera också att svaren går till den avsedda postlådan och att spårade länkar fungerar som förväntat, utan att behandla något av testerna som bevis på autentisering.
Eloqua domänacceptans arbetsblad
Använd en separat rad för kampanjdomänen och varje företagsdomänsignaturfall:
- Förekomst och varumärke: ____; kampanj eller signaturregel: ____.
- Faktisk Från adress och domän: ____; tillåten domänägare: ____; övervakad svar-till: ____.
- Redan konfigurerad avvisningsadress och domän för detta varumärke: ____; bevis på att From matchar den konfigurerade bounceback-underdomänen: ____.
- Standard kontra per e-post Från åsidosättande: ____; vald konfigurerad domän om flera domäner är aktiverade: ____.
- Företagssignatur-regel ruttbekräftelse och konto-/supportreferens: ____; Eloqua avsändarvalideringsresultat före sändning: ____.
- Kontoinstruktion eller supportreferens: ____; utfärdad postägare och typ: ____.
- Befintliga SPF beroenden och föreslagen sammanslagning: ____; DKIM -väljare och signeringsdomän: ____.
- Auktoritativ DNS observation: ____; Eloqua aktiveringsbekräftelse: ____.
- Kontrollerad testtidsstämpel och meddelande-ID: ____; mottagare: ____.
- SPF -identitet och resultat: ____; DKIM identitet och resultat: ____; inriktad mekanism: ____.
- Undantagsägare, återställningsväg och beslut om frigivning: ____.
Avvisa rader med en okonfigurerad eller felmatchad avvisningsparning, en obekräftad företagssignatur-regelrutt, en kopierad väljare från en annan instans eller ett lyckat prov med en annan Från-domän. Markera saknade kontoinstruktioner som olösta istället för att ersätta dem med ett recept från tredje part.
Fiktiv diagnos av ett misslyckande med försäljningssignatur
Endast fiktivt exempel: Riverbend har separat bekräftat den kontostödda företagsavsändarvägen, konfigurerat sin bounceback-parning för example.com och godkänt Eloqua-avsändarvalideringen för försäljningsmeddelanden från salesperson@example.com . Dess kampanjväg från news.example.com har också en giltig konfigurerad bounceback-parning. Dessa är explicita antaganden i exemplet, inte observerade kundinställningar eller tillstånd att välja en godtycklig företags Från-domän.
Ett levererat säljmeddelande passerar DKIM med d=news.example.com men misslyckas med DMARC eftersom den fiktiva domänen använder strikt DKIM justering ( adkim=s), den synliga From-domänen är example.com och det finns inget justerat SPF resultat. Ett framgångsrikt kampanjexempel kan därför inte bevisa denna försäljningsvägs anpassning. Under avslappnad DKIM anpassning kan de relaterade signerings- och From-domänerna anpassas; exemplet får inte generaliseras till det läget.
Teamet behåller den giltiga sändnings- och returkonfigurationen, begär rätt kontospecifik signeringstäckning för den företagsrutt som stöds och verifierar ett nytt försäljningsmeddelande efter aktivering. Om förutsättningen Från och tillbakavisning istället hade varit ogiltigt, skulle den första diagnosen ha varit Eloquas validering eller blockerad sänd-tillstånd, inte detta misslyckande med justering av mottagna meddelande. Inget Riverbend-konto eller meddelande inspekterades.
Stäng driftsslingan
När autentiseringen fungerar, hantera feedback-loop onboarding som en separat operativ uppgift. Oracle beskriver att kontakta support efter DKIM installation och slutföra den relevanta bekräftelseprocessen. Gör inte anspråk på att klagomålsrapportering är aktiverad bara för att ett meddelande är signerat. Se Eloqua e-autentiseringsinställning.
Behåll en återställningsplan för ett misslyckat domänbyte, bevara fungerande väljare tills den avsändande ägaren bekräftar pensionering och testa igen efter ändringar av varumärke, signaturregler eller avsändardomän. Autentisering garanterar inte placering i inkorgen eller auktoriserar en kontaktlista. Kontoutfärdade poster, live DNS , mottagartester, visuell inspektion, mänskligt SME-godkännande och publicering kvarstår för denna dokumentärkandidat.
Separat meddelandeacceptans från policyimplementering
Ett passande justerat SPF resultat kan tillfredsställa en meddelandeutvärdering, men motiverar inte ensamt att flytta en hel domän för att avvisa. RFC 9989 Avsnitt 7.4 kräver giltig DKIM för domänpublicering p=reject och varnar för interoperabilitet med indirekt e-post. Inventera alla legitima avsändare och indirekta rutter innan policyägaren godkänner verkställighet. Ingen DNS ändring, klientdrift eller test av mottagna meddelanden utfördes för den här artikeln.