Välj inbyggd leverans eller anpassad SMTP först
Customer.io:s dokumentation för e-postautentisering skiljer dess inbyggda leveranstjänst från anpassad SMTP . För inbyggd leverans krävs domänautentisering med hjälp av SPF och DKIM. För anpassad SMTP riktar den autentiseringsansvaret till SMTP leverantören istället för att kräva samma domänautentiseringsinställning inuti Customer.io. Detta är det första beslutet i konfigurationsplanen.
Spela in arbetsytan, leveransväg, avsedd Från domän och meddelandekategorier. Identifiera om en migrering eller ett undantag gör att vissa meddelanden använder en annan transport. En enskild applikation kan orkestrera flera leveransvägar, så en verifierad sändningsdomän i en sökväg är inte bevis för varje meddelande som utlöses av den applikationen.
Den här guiden beskriver det dokumenterade inbyggda arbetsflödet och gränsen för anpassad SMTP . Den hävdar inte att en viss Customer.io-arbetsyta är konfigurerad, att några referenser har angetts eller att någon mottagare har fått ett testmeddelande. Den bredare acceptansen för implementering är fortfarande öppen. Customer.io E-postautentisering
Använd de genererade underdomänposterna
Den inbyggda tjänsten tillhandahåller domänautentiseringsposter kopplade till den valda sändningsdomänen. Customer.io förklarar att dess konfiguration använder en Customer.io-specifik underdomän, illustrerad med en kontospecifik cio-identifierare, snarare än att ta över rotdomänen. Bevara de faktiska genererade ägarnamnen och värdena från arbetsytan; illustrationen är inte ett värde att kopiera till varje kunds zon.
Dokumentationen skiljer uttryckligen denna SPF konfiguration från rotdomänens SPF policy. Lägg inte till en gissad Customer.io-inkludering i rotposten helt enkelt för att det är där andra sändningstjänster har konfigurerats. Kartlägg den kontogenererade underdomänen och varje posts syfte innan du skickar in DNS ändringen.
DNS administratören bör kontrollera den auktoritativa zonen, befintliga poster och redaktörskonventioner för fullständigt kvalificerade namn. Granska hela den föreslagna postuppsättningen, inte bara den publika nyckeln som ser mest uppenbart relaterad till DKIM . En framgångsrik plan bevarar icke-relaterad e-postinfrastruktur samtidigt som de avsedda leverantörsspecifika beroenden upprättas. Vi kommer inte att ta över din rotdomän; manuell autentisering
Välj ett kontrollerat publiceringsarbetsflöde
Customer.io dokumenterar både ett automatiskt autentiseringsalternativ och manuell DNS publicering. En automatisk hjälpare kan innebära åtkomst till en DNS leverantör; att åtkomst är ett separat säkerhetsbeslut, inte ett underförstått tillstånd som ges genom att läsa en installationsguide. Detta manuskript föreslår manuell granskning av den genererade ändringen så att den befintliga DNS ägaren kan godkänna och tillämpa de avsedda posterna genom etablerade kontroller.
Kopiera posttyperna, ägarnamnen och värdena exakt från den valda domänens instruktioner. Behåll före-tillståndet och en ändringsreferens. För långa DKIM TXT data, särskilj flera citattecken i en TXT post från flera oberoende register. Trunkera inte en nyckel för att passa en antagen gränssnittsgräns eller publicera flera motstridiga nyckelposter eftersom en skärm omsluter texten.
Det korrekta acceptansmålet är publicerad data vid det avsedda namnet. Skärmdumpar av en DNS redigerare kan stödja ändringshistoriken, men de fastställer inte i sig vad en extern mottagare kan hämta. Autentisera din domän manuellt; Vanliga frågor om DNS leverantörer; RFC 1035 , avsnitt 3.3.14
Stäm av DMARC -justeringsinställningarna före aktivering
Customer.ios inbyggda leveransvägledning kräver avslappnade aspf- och adkim-inställningar för den dokumenterade installationen. Den noterar också att utelämnats inriktning taggar använder avslappnade standardinställningar. Om organisationens nuvarande DMARC policyn kräver uttryckligen strikt anpassning, se det som en designkonflikt som kräver domänägarens beslut, inte en tagg att ta bort av misstag för att uppfylla en produktchecklista.
Använd protokollterminologin noggrant. Den synliga författarens adress finns i fältet RFC5322 Från. SPF utvärderar SMTP identiteter, inklusive MAIL FRÅN, medan DKIM har en signeringsdomän som identifieras av d=. DMARC jämför den relevanta passerande identiteten med författarens domän under tillämpligt justeringsläge. Returvägen och synlig Från-adress bör inte bytas ut i bevisarbetsbladet.
En policyändring kan påverka annan e-post som använder samma domän. Tänk på befintlig avsändarinventering, underdomändesign och säkerhetskrav innan du bestämmer dig för hur rutten ska hanteras. Leverantörskravet bevisar inte att det är tillåtet eller lämpligt att lätta på en organisations policy i alla fall. Slappna av dina aspf- och adkim-taggar; RFC 9989 , avsnitt 4.4; RFC 7208 , avsnitt 2.4
Begär verifiering och håll länkspårning separat
När de nödvändiga uppgifterna har publicerats, använd Verifiera domän i Customer.io. Dokumentationen säger att verifiering sker på begäran snarare än genom kontinuerlig polling. Ett team som väntar på att gränssnittet ska upptäcka en ändring automatiskt kan därför missta en oönskad kontroll för ett DNS fel. Registrera kontrolltiden och det faktiska resultatet innan du undersöker vidare.
Branded länkspårning är en annan konfiguration med sin egen domän och CNAME verifieringskrav. Det är inte identiskt med autentisering av e-postmeddelandets signering eller kuvertidentitet. På samma sätt kan anpassad SMTP fortfarande involvera en separat konfiguration av spårningsdomän även om SMTP leverantören hanterar e-postautentisering. Behåll dessa statusindikatorer i separata kalkylbladsrader.
När en kontroll misslyckas, jämför först den valda arbetsytan, domänen och den genererade postlistan med den faktiska föreslagna DNS ändringen. Ändra inte orelaterade rotposter upprepade gånger eller ändra en DMARC -policy bara för att en spårningsstatus är ofullständig. Eskalera den specifika olösta komponenten med minimerade bevis. Verifiera domän; anpassad SMTP och länkspårningsvägledning
Acceptans arbetsblad för en arbetsyta överlämning
Använd det här föreslagna kalkylbladet för att förhindra att flera gröna statusindikatorer komprimeras till ett påstående om beredskap som inte stöds.
- Transportinventering: lista inbyggd leverans, anpassade SMTP undantag och meddelanden som tilldelats varje rutt.
- Sändande domän: behåll den valda arbetsytan, Från domän och faktiskt genererade underdomänidentifierare.
- DNS plan: registrera alla nödvändiga ägare, typ och värde, den auktoritativa zonen och godkännandereferensen.
- Justeringsbeslut: registrera befintliga aspf/adkim-inställningar och domänägarens lösning av eventuell strikt anpassningskonflikt.
- Providerkontroll: behåll tiden för att verifiera domänen begärdes och dess returnerade resultat.
- Spårningskontroll: registrera separat om en varumärkesspårningsdomän används och vilken verifiering som gäller.
- Meddelandebevis: behåll ett minimerat auktoriserat prov med författare, kuvert och signeringsidentiteter plus betrodda valideringsresultat.
- Släpp ägarskap: identifiera vem som ska granska ruttändringar, ta bort oanvända beroenden och godkänna produktionsberedskap.
Detta kalkylblad är en ursprunglig föreslagen kontroll. Ingen av dess rader är fullbordad av existensen av detta manuskript.
Fiktiv diagnos: väntar på en kontroll som aldrig efterfrågades
En fiktiv utbildningsplattform publicerar posterna som genereras för sin inbyggda Customer.io-rutt. Administratören kontrollerar gränssnittet flera timmar senare och ser att domänen fortfarande inte är verifierad. Utgår från roten SPF rekord är fel, föreslår en kollega att lägga till en annan mekanism där. Ändringsbegäran innehåller inga bevis som kopplar den rotpolicyn till den genererade underdomänen.
Granskaren bekräftar istället att ingen valt Verifiera domän efter publicering. Det föreslagna nästa steget är att begära den dokumenterade verifieringen, inspektera dess faktiska resultat och sedan undersöka endast de olösta uppgifterna. Märkesspårning förblir en separat ofullständig uppgift, och inga anspråk görs på anpassning av mottagna meddelanden förrän ett auktoriserat prov har granskats. Denna fiktiva diagnos rapporterar inte en verklig kontohändelse, en live DNS fråga eller ett lyckat test.