Behandla sändningsdomänen som en koordinerad Sailthru-lansering
En Sailthru-sändande domän behöver mer än synliga DNS poster innan produktionsposten är klar. Lanseringen bör ansluta sig till domänautentisering, leverantörsaktivering, en fungerande avsändarbrevlåda och ett kontrollerat leveranstest. Börja med den exakta domänen efter at-tecknet i den avsedda Från-adressen. Registrera vilka konto- och affärsmeddelanden som kommer att använda det, och separera marknadsföringskampanjer från alla transaktionsvägar vars konfiguration skiljer sig.
Sailthru's vägledning för ny sändande domän kräver DNS installation och en rampplan som granskas med sitt team. Den tillämpar även denna recension på en domän som redan finns på ett konto men som inte används aktivt. En vilande domän med register på plats ska inte behandlas som att den har ett etablerat sändningsrykte. Autentiseringsberedskap och produktionsvolymberedskap är separata beslut.
Den här guiden täcker inställning av autentisering och bevisinsamling, inte ett löfte om placering i inkorgen eller ett universellt schema för sändningsvolymer. Använd det aktuella kontots godkända konfiguration och leverantörskontakt för att lösa eventuella missmatchningar. Live-konto, DNS och header-verifiering förblir väntande tills organisationen slutför kalkylbladet och testerna nedan.
Kontrollera strikt justering innan du gör ändringen
Läs det befintliga DMARC policy och registrera dess inriktning lägen innan du registrerar domänen. Sailthru's Guide för konfigurering av DNS -poster anger uttryckligen att strikt adkim eller aspf inte stöds. Om organisationens nödvändiga policy använder antingen strikt läge, behandla kompatibilitet som ett öppet designbeslut med Sailthru och säkerhetsägaren. Ta inte tyst bort dessa taggar eller försvaga policyn för att slutföra en checklista för installationen.
Överväg den avsedda avsändardomänen och den bredare organisationens legitima e-postrutter tillsammans. En isolerad justering av en delad domäns policy kan påverka anställdas e-post, ekonomiapplikationer och andra tjänster. Om en annan sändande domän föreslås, utvärdera dess policykontext och affärskonsekvenser innan du använder den. En underdomän är inte automatiskt ett säkert undantag från alla ärvda policyer eller avsändarens rykte.
Under RFC 9989, ett DMARC pass kräver framgångsrikt SPF eller DKIM autentisering med en identitet anpassad till From-domänen. Avslappnade och strikta jämförelser skiljer sig åt, så det måste stå i acceptansarket vilket läge som gäller. Rapportera inte ett autentiseringspass som ett anpassningspass bara för att leverantören har känt igen DNS posten.
Förbered rekordet och inspektera beroenden
Skaffa de aktuella Sailthru-instruktionerna för domänen och bevara en baslinje över alla berörda DNS ägare. Den publicerade installationen inkluderar en SPF inkludering, två DKIM CNAMEs och en avvisningsdomän CNAME. Granska deras fullständiga namn och mål mot den faktiska avsändardomänen. En underdomänavsändare kräver motsvarande fullständiga namn; Om du utelämnar en etikett kan du konfigurera en annan identitet än den som kampanjen använder.
För SPF , granska hela policyn hos den relevanta ägaren under RFC 7208. Behåll en SPF policy, behåll andra nödvändiga avsändare och ta hänsyn till kapslade DNS-förfrågningstermer. En leverantör inkluderar är en fortsatt auktorisering, inte en ofarlig kommentar. Infoga inte alla historiska exempel från olika guider eller byt ut en befintlig terminalkvalificerare utan godkännande.
Särskilj DNS uppgifterna efter syfte. DKIM verifierar en signatur. Bounce-domänkonfigurationen stöder kuvertidentiteten. Äganderätts- eller återkopplings-verifieringsposter har sina egna funktioner. Länk- och spårningsdomäner är separata operativa beroenden. En framgångsrik länkomdirigering bevisar inte att DKIM är aktivt, och ett autentiserat meddelande bevisar inte att alla gamla kampanjlänkar förblir användbara.
Publicera både DKIM -delegationer och fullständig leverantörsaktivering
Den aktuella Sailthru-guiden specificerar två DKIM CNAMEs och kräver att leverantören slutför installationen innan de blir aktiva för sändning. Använd de exakta aktuella ägarna och målen för From-domänen och kontrollera båda posterna efter publicering. Anta inte att det verkar fungera att skapa en väljare räcker eller att DNS närvaro utlöser aktivering automatiskt.
Inspektera befintliga poster vid de föreslagna namnen innan du sparar. En CNAME konflikt behöver lösas med administratörerna för de beroende tjänsterna. Kombinera inte inkompatibel data hos samma ägare eller uppfinn en annan väljare utan support från leverantören. Kontrollera DNS redigerarens automatiska suffixhantering och jämför de slutgiltiga fullt kvalificerade svaren med instruktionerna.
Håll ett tydligt register över leverantörens aktiveringsbekräftelse. Fråga vilken tid nya meddelanden ska börja använda konfigurationen och skicka sedan ett nytt test efter den tidpunkten. Återanvändning av ett gammalt meddelande kan visa den tidigare konfigurationen och vilseleda granskningen. Upprepade DNS redigeringar i väntan kan skapa flera överlappande cachelägen och göra diagnosen svårare.
Verifiera avvisningsidentiteten och avsändarens brevlåda separat
Bekräfta avvisningsdomänen CNAME i kontots installationsinstruktioner och den faktiska Return-Path observeras efter aktivering. Ett publicerat alias är inte ett bevis på att en viss sändningsrutt använder det. Om den mottagna kuvertidentiteten skiljer sig, bevara resultatet och fråga Sailthru vilken inställning eller provisioneringssteg som styr den rutten. Ändra inte root SPF policyn upprepade gånger för att kompensera för en oförklarlig kuvertidentitet.
Efter aktivering av leverantören sker den dokumenterade verifieringen av avsändaradress via inställningar och verifierade e-postmeddelanden. Avsändarens brevlåda måste kunna ta emot verifieringsmeddelandet. Använd en brevlåda som kontrolleras av organisationen och identifiera den person som är ansvarig för att svara på kundsvar. Ett visningsnamn eller marknadsföringsalias utan en fungerande inkorg kan skapa driftsproblem även när autentiseringen lyckas.
När du ordnar åtkomst till Google Postmaster eller feedback-loop, separera den tekniska posten från åtkomstgodkännande. Installationsguiden inkluderar steg för leverantörssamarbete, men att dela övervakningsåtkomst är fortfarande ett organisatoriskt beslut. Ge endast godkänd åtkomst till verifierade mottagare. Placera inte autentiseringsuppgifter eller icke-relaterad domäninformation i ett startkalkylblad bara för att påskynda onboarding.
Bevisa anpassning med hjälp av en riktig kampanjväg
Skicka ett ofarligt test via samma konto, avsändarval och bearbetningsväg som den avsedda kampanjen. Använd kontrollerade externa mottagare vars fullständiga rubriker är tillgängliga. Upprepa för alla väsentligt annorlunda transaktions- eller varumärkesrutt. Spela in meddelande-ID, UTC-tid och relevant kampanj eller testreferens, utan att behålla onödigt mottagarinnehåll.
Fånga de synliga From, Return-Path , varje DKIM d= och s= värde och betrodda mottagarresultat. RFC 6376 ansluter DKIM -signeringsdomänen och väljaren till DNS verifieringsnyckeln. Kontrollera om en passerande signatur tillhör en anpassad domän snarare än att förlita sig på ett generiskt grönt resultat. Om det finns mer än en signatur, identifiera vilken som tillhandahåller det relevanta passet.
Jämför den observerade kuvertdomänen med den avsedda avvisningskonfigurationen och Från-domänen. Registrera om SPF godkändes, om den var justerad och om DKIM levererade inriktning oberoende. Behåll dessa som separata fält så att en senare ändring av en mekanism inte raderar kunskapen om den andra. Autentiseringsframgång är nödvändigt bevis, men innehåll, mottagarens förväntningar och avsändarens rykte kan fortfarande påverka leveransen.
Bevara fungerande länkar och diagnostisera snävt
Om lanseringen också ändrar en länkdomän, inventera gamla kampanjberoenden innan du tar bort någon tidigare inställning. Sailthrus DNS guide varnar för att radering av en gammal länkdomän kan bryta länkar i äldre meddelanden. Autentiseringsrensning bör därför begränsas till de poster vars pensionering har godkänts, inte en bred utrensning av alla okända Sailthru-relaterade namn.
För frånvarande DKIM , kontrollera först leverantörsaktiveringen och den valda avsändardomänen. För en misslyckad signatur, kontrollera den faktiska väljaren, DNS svaret och eventuella senare meddelandeändringar. För DMARC fel med en passerande mekanism, inspektera inriktningen och hållet kompatibilitet i strikt läge. För e-post som aldrig har skickats, kontrollera konto- och kampanjbevis innan du antar att DNS orsakade problemet.
Behåll rampbeslutet hos leveransägaren. En tekniskt autentiserad ny avsändare behöver fortfarande den överenskomna volym- och kadensplanen. Släpp inte en hel publik eftersom ett test kommer fram framgångsrikt. Spara testbevisen, öppna undantag och leverantörskorrespondens så att produktionsbeslutet kan granskas.
Sailthru launch arbetsblad
- Konto, varumärke, arbetsflöde och avsedd Från domän: ____.
- Företagsägare, DNS administratör och leverantörskontakt: ____.
- Befintlig DMARC -policy och kompatibilitetsbeslut för strikt läge: ____.
- SPF -policygranskning och kapslad uppslagsbedömning: ____.
- Både utfärdade DKIM CNAMEs och offentliga uppslagsresultat: ____.
- Bounce-domänkonfiguration och observerad Return-Path : ____.
- Leverantörsaktivering och verifiering av avsändaradress: ____.
- Övervaka åtkomstgodkännanden och eventuella separata länkdomänändringar: ____.
- Testmeddelande-ID, betrodda resultat och anpassad mekanism: ____.
- Rampplan, olösta undantag och releasegodkännare: ____.
Fiktivt exempel på ett för tidigt lanseringsbeslut
Endast fiktivt skriftligt fall: ST-01 antar Från offers@news.example.org , en befintlig policy som kräver adkim=s, och DNS poster på en vilande avsändare. Inget undantag för leverantörskompatibilitet, aktuell rampplan eller mottagna meddelanderesultat finns. Lanseringsägaren måste lösa den dokumenterade inkompatibiliteten i strikt läge med säkerhetsägaren och leverantören innan volymschemaläggning, utan att tyst ändra policyn. DNS närvaro stänger inte någon av grindarna. Ingen domän, konto eller kampanj inspekterades.
Se till att omfattningen och frigöringsgrindarna inte stöds
Implementering av strikt justering förblir utanför den här guidens stödda konfiguration om inte Sailthru tillhandahåller en aktuell upplösning. Live granskning av hyresgäster, kontoutfärdade poster, DNS och rubrikverifiering, visuell granskning och mänskligt godkännande av små och medelstora företag kvarstår. Detta är ett opublicerat implementeringsutkast, inte en slutförd domänlansering.
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.