Använd kontokonfigurationen som utgångspunkt
Sendloop tillhandahåller ett kontoarbetsflöde för avsändardomänautentisering, medan dess offentliga autentiseringsguide också nämner dedikerade DKIM och inriktning inställningar. Dessa sidor fastställer att autentisering är tillgänglig, men de upprättar inte den exakta postuppsättningen, signeringsidentitet eller kuvertkontroller för ett visst konto. Den här guiden tar dig genom det dokumenterade kontoarbetsflödet och en kontrollerad verifieringsplan. Ett dedikerat DKIM arrangemang eller anpassat kuvertkrav förblir ett leverantörsbekräftelseobjekt. Sendloop-autentiseringsguide, DKIM och inställningar för domänjustering.
Identifiera först kontot, godkända Från-domäner och kampanjerna eller automatiseringarna som använder var och en. Registrera om kontot har ett dedikerat leveransarrangemang och vem som kan bekräfta det. Sluta inte härleda till dedikerad infrastruktur från en prisetikett, ett gammalt onboarding-e-postmeddelande eller en tredjepartslista över sändande IP-adresser. Tilldela en Sendloop-administratör, en DNS ägare och en granskare för organisationens DMARC politik.
Innan du gör ändringar, exportera de aktuella DNS posterna för de relevanta ägarna. Behåll ett mottaget meddelande från en representant från den befintliga godkända rutten om tillgängligt. En inventering av vad som redan fungerar förhindrar att ett nytt autentiseringsprojekt av misstag inaktiverar en annan avsändare. Målet är en autentiserad och anpassad Sendloop-rutt, inte en ersättning i grossistledet av domänens e-postkonfiguration.
Öppna avsändarens domänkontrollpanel
Leverantörens guide leder dig genom Inställningar > Avsändardomänautentisering > Autentisera avsändardomän och sedan Lägg till domän. Den resulterande domänkontrollpanelen tillhandahåller kontorelevanta värden och en Check DNS Records-åtgärd. Fånga den utdata innan du redigerar DNS . Om det aktuella gränssnittet skiljer sig, använd den aktuella leverantörens instruktioner eller support istället för att gissa motsvarande knappar. Sendloop-guide, Använda e-postauktoriseringsguiden och kontrollera din autentiseringsinställning.
Registrera varje fullständig ägare, DNS typ, värde och TTL med dess syfte. Behåll den visade postuppsättningen bifogad ändringssedeln. Om panelen visar en saknad post, avgör om den är frånvarande, publicerad hos fel ägare eller finns med ett annat värde. En domän som redan är konfigurerad för ett annat Sendloop-konto kan behöva samordning av leverantören istället för att ersättas.
Den offentliga guiden har en SPF exempel och en befintlig post ändring som inte listar identiska inkluderar. Den beskriver också hur man förbereder textfiler. Förvandla inte någon av detaljerna till ett automatiskt produktionsrecept. DNS måste innehålla den aktuella, tillämpliga policyn; en textfil som sparats på en arbetsstation publicerar den inte. Åtgärda eventuella avvikelser mellan kontopanelen och den offentliga sidan före implementering. Sendloop guide, Ställ in SPF Record.
Granska SPF utan att utöka orelaterade behörigheter
Bestäm vilken kuvertdomän det riktiga Sendloop-meddelandet använder. Det är identiteten att undersöka för SPF snarare än att anta att den synliga From-domänen måste vara utvärderingsägaren. Om det finns ett auktoriserat anpassat kuvertarrangemang, registrera dess utfärdade inställningar och omfattning. Om den inte gör det, registrera den observerade leverantörens kuvertidentitet och utvärdera DKIM justeringen separat.
Behåll en enda SPF -policy och bevara behörigheter som krävs av andra aktiva avsändare när ägaren ändras. Granska kapslade DNS uppslagningar innan du lägger till nya termer. SPF :s tiotidsgräns gäller för mekanismer och modifierare som orsakar DNS uppslagningar under utvärdering, inte för antalet synliga ord i posten. Befintliga tillåtande mekanismer är också värda att se över, men att ta bort dem är ett separat beroendebeslut. RFC 7208 , avsnitt 4.5 och 4.6.4.
Kopiera inte en bred provpolicy som ersättning för den befintliga posten. Om du gör det kan det auktorisera oönskade värdar, ändra felkvalificeringen eller ta bort en annan leverantör. När den nödvändiga auktoriseringen inte kan passa säkert, stanna upp och be postägaren att välja en design som stöds. Lös inte problemet genom att publicera en annan SPF -policy eller ta bort tjänster som råkar vara obekanta.
Publicera endast det publicerade offentliga DKIM materialet
Använd ägaren och det offentliga värdet som tillhandahålls för detta konto. Den offentliga guiden visar en DKIM TXT inställning, men dess demonstrationsnyckel är inte kundens nyckel. Om panelen eller supporten tillhandahåller ett annat formulär som stöds, behåll den instruktionen istället för att konvertera den utan bevis. Sendloop-guide, Konfigurera DKIM posten.
Endast den offentliga verifieringsnyckeln hör hemma i DNS . DKIM skapar en kryptografisk signatur med en privat nyckel; den bäddar inte in den privata nyckeln i det utgående meddelandet. Den offentliga guidens informella förklaring ska inte läsas som en begäran om att dela signeringshemligheter. Meddelandet har en signatur och verifieraren använder den publika nyckeln som identifieras av sin signeringsdomän och väljare. RFC 6376 , avsnitt 3.5 och 6.1.
Kontrollera den föreslagna ägaren efter en aktiv nyckel som tillhör en annan rutt. En kollision kräver koordination; det är inte säkert att skriva över en fungerande väljare bara för att rensa en röd status. Verifiera det fullständigt kvalificerade namnet efter publicering, inklusive domänsuffixet som lagts till av DNS redigeraren. Behåll tidsstämplar och frågeresultat så att senare rapporter kan skilja en inaktuell cache från en felaktig ägare eller nyckel.
Håll länkbranding utanför slutsatsen för anpassningen
Leverantörsguiden beskriver en valfri CNAME för aliasade meddelandelänkar. Syftet är länkvarumärke, inte bevis för att SPF eller DKIM passar ihop. Implementera det endast om den relevanta spårningsändringen godkänns och kontot anger det exakta målet. Sendloop-guide, VALFRITT: Ställ in CNAME posten.
Kontrollera befintlig webbplats eller spåra användning innan du gör anspråk på den föreslagna ägaren. Rikta inte rotwebbplatsen eller ett live-applikationsvärdnamn mot ett spårningsmål. Håll en ofarlig testlänk i den kontrollerade kampanjen så att granskaren kan verifiera både dess destination och dess visade värdnamn. Autentisering och länkfunktion är separata acceptanskontroller; en varumärkeslänk som fungerar skapar inte en giltig signatur.
Återgå till kontots DNS kontroll efter publicering. Jämför alla visade resultat med en oberoende offentlig sökning. Registrera väntande stater ärligt talat. Om ett konto visar sig verifierat medan det externa testet fortfarande misslyckas, lämna ändringen öppen och använd meddelandebeviset för att lokalisera den återstående gränsen.
Samla in en mottagen meddelandeidentitetspost
Skicka igenom själva kampanjarbetsflödet till kontrollerade externa brevlådor utan kunddata. Upprepa för väsentligt olika From-domäner eller leveranskonfigurationer. Bevara det ursprungliga meddelandet och betrodda mottagarresultaten, tillsammans med ett meddelande-ID och UTC-tidsstämpel. Spela in alla DKIM signaturer istället för att stanna vid den första signaturen som passerar.
Bevisposten bör innehålla den synliga Från-domänen, autentiserad kuvertidentitet, Return-Path, DKIM d= och s= värden, SPF och DKIM utfall och mottagarens DMARC resultat. Fastställ vilken överföringsmekanism som är i linje med From-domänen. Avslappnad och strikt anpassning kräver olika domänjämförelser; registrera vilket läge som används. RFC 9989 , Identifier Alignment Explained.
Om den enda passerande signaturen använder en icke-relaterad leverantörsdomän, begär det stödda kunddomänsigneringsalternativet och dess aktiveringsvillkor. Den offentliga guidens dedikerade DKIM-kontaktanteckning bevisar inte att alternativet är aktiverat, gratis, tillgängligt på varje plan eller konfigurerat automatiskt. Få dessa svar för det exakta kontot. Representera inte ett spårningsalias som en alternativ kuvertdomän.
Använd felet för att välja nästa kontroll
För en saknad DKIM signatur, bekräfta kontot, välj Från identitet och leverantörsaktivering. För ett signaturfel, jämför den observerade väljaren och den offentliga nyckeln innan du undersöker nedströmsändringar av signerat innehåll. Ett test med en annan avsändaradress kan lyckas medan den berörda kampanjen fortfarande misslyckas, så håll arbetsflödet konstant under diagnosen.
För SPF fel, identifiera den utvärderade domänen och den slutliga sändningskällan. För SPF godkänt med DMARC fel, inspektera inriktningen istället för att lägga till fler SPF inkluderar. Om leverantören inte kan dokumentera det nödvändiga identitetsalternativet, håll det kravet blockerat och bedöm en annan rutt som stöds med företagsägaren. Sänk inte en hel domäns policy bara för att få en leverantörs test att sluta misslyckas.
Förbered ett supportpaket som innehåller kontoidentifikation, den berörda domänen, utfärdade offentliga register, observerade DNS svar, meddelande-ID, tid och relevanta mottagarresultat. Uteslut lösenord, API-nycklar, mottagarlistor och icke-relaterat meddelandeinnehåll. Ett kortfattat reproducerbart fel är mer användbart än flera okorrelerade skärmdumpar av DNS redigeringar.
Arbetsbladsåterställning och acceptans
Använd kalkylbladet för Sendloop-autentisering (skapa en separat granskningspost med fälten som beskrivs här) för att spåra postavvikelsegranskning, bekräftelse av dedikerade funktioner och slutlig identitetsjämförelse. Ett saknat kuvertfunktionssvar kan förbli explicit olöst även när vanlig justerad DKIM fungerar. Definiera acceptans mot affärskravet snarare än att fylla varje tomrum med ett antagande.
Om ändringen misslyckas, pausa berörda sändningar och återställ den tidigare godkända konfigurationen genom den registrerade ändringsplanen. Koordinera DKIM ändringar med leverantörsaktivering; radering av en offentlig nyckel medan tjänsten fortfarande signerar med den skapar ett nytt fel. När du avbryter Sendloop, bekräfta att alla kampanjer och automatiseringar har stoppats och granska delade SPF beroenden innan du tar bort förtroende eller spårningsposter.
Fiktivt fungerat exempel på en SPF avvikelse
Endast fiktivt skriftligt fall: SLP-01 antar avsett Från offers@workshop.example . Det offentliga exemplet innehåller två provider inkluderar medan dess befintliga policyinstruktion namnger en; kontoauktorisering, kuvertidentitet och DKIM / SPF -resultat är okända. DNS ägaren håller ändringen och ber kontoägaren att få ruttspecifik bekräftelse. En textfil och en varumärkeslänk upprättar inte autentisering. Efter förtydligande skulle teamet granska en policy och samla in ett kontrollerat kampanjmeddelande. Inget konto, DNS eller sändningstest utfördes.
Dokumentär täckning och återstående portar
Detta utkast täcker arbetsflödet för offentliga konton och säker verifiering. Den upprättar inte en universell dedikerad DKIM eller anpassad Return-Path , och den hävdar inte att ett livejusterat Sendloop-meddelande har inspekterats. Dessa kontoberoende detaljer, live DNS och header-bevis, oberoende granskning, visuell granskning och mänskligt SME-godkännande förblir väntande. Behåll det ursprungliga fullständiga implementeringsomfånget på is tills det nödvändiga kontobeviset täpper till luckorna.
Separera ett passerande meddelande från verkställighetsberedskap
RFC 9989 Avsnitt 7.4 kräver giltig DKIM för en domänpublicering p=reject och varningar om interoperabilitet med indirekt e-post. Ett enda anpassat SPF resultat motiverar inte i sig en utrullning av avvisningspolicy. Granska alla legitima rutter och policyägande separat från denna leverantörskonfiguration.