Behandla e-post och SMTP som separata test av delade inställningar
SendPulse dokumenterar en delad lista över autentiserade domäner för e-post och SMTP . Det tillämpliga domäntillägget är den högre gränsen av de två planerna, och varje underdomän räknas separat; en spårningsdomän förbrukar inte den autentiseringstillägget. Dess nuvarande guide ger ett gratisexempel på en e-postdomän och två SMTP domäner, vilket tillåter två delade poster. Bekräfta livekontots tillåtelse innan du planerar flera varumärken eller underdomäner. SendPulse Email-autentisering, generera dina DKIM och SPF -poster.
Delade inställningar minskar duplicerat DNS arbete, men de bevisar inte att varje applikation väljer den avsedda Från-domänen. Lagermarknadsföringskampanjer, automatiseringar och applikationer som skickas in via SMTP eller ett API. Fånga kontot och den avsedda domänen för varje rutt, företagsägaren, applikationsägaren och DNS administratören. Behåll inlämningsuppgifterna utanför detta kalkylblad.
Den här guiden täcker leverantörens offentliga e-post- och SMTP autentiseringsarbetsflöden. Det förutsätter inte en obegränsad domäntillåtelse, en självständigt valbar anpassad Return-Path eller identiska slutliga identiteter över alla integrationer. Om ett affärskrav beror på strikt inriktning eller en viss kuvertdomän, skaffa en design som stöds från SendPulse innan du bestämmer dig för den.
Kontrollera efter en befintlig domän innan du genererar poster
I e-post är den dokumenterade ingångspunkten Inställningar > Domäninställningar, följt av aktivering i området för autentiserad domän. I SMTP använder du SMTP inställningar > Domäninställningar och sändningsdomänområdet. Båda arbetsflödena genererar SPF och DKIM poster för den angivna domänen. SMTP dokumentationen säger att befintlig e-postautentisering inte kräver en annan DKIM inställning eftersom tjänsterna delar postinställningar. SendPulse SMTP DKIM , Delade postinställningar och Lägga till en ny domän.
Öppna den befintliga domänen först när en redan finns. Registrera dess aktuella anslutningsstatus och offentliga värden. Generera inte ett andra arrangemang bara för att en ny applikation använder SMTP . Om två konton eller team gör anspråk på samma domän, jämför deras nuvarande instruktioner från leverantören och klargör äganderätten innan du ändrar den delade väljare.
Räkna de domäner som behövs för lanseringen, inklusive separat autentiserade underdomäner. Om kontot har rätt, ta inte bort en fungerande domän bara för att avslöja Lägg till-kontrollen. Identifiera vad som använder den domänen och välj en plan eller domänstrategi med kontoägaren. Ett kommersiellt rättighetsbeslut är skilt från ett DNS fel.
Förena SPF -instruktionen med den befintliga policyn
SendPulse SPF guiden instruerar användare med en befintlig SPF rekord för att lägga till leverantörens auktorisering till den posten istället för att skapa en andra. De citerade guidenamnen include:mxsspf.sendpulse.com som tillägg till en befintlig policy. Bekräfta tillämplighet mot det aktuella kontots domäninställningar; exempel a- och mx-termerna är inte automatiska tillägg. Kopiera inte ett exempel på en fullständig policy över den befintliga. SendPulse SMTP SPF , Kopiera en SPF -post och lägg till en post på DNS leverantörens webbplats.
Exportera de aktuella TXT -svaren för den exakta ägaren före redigering. Lista de andra tjänsterna som är beroende av dess SPF -policy och identifiera den faktiska kuvertidentiteten i ett baslinjemeddelande när det är möjligt. Företagets From-domän och den SPF-autentiserade domänen kan skilja sig åt. Att publicera en inkludering vid en godtycklig apex kan inte reparera ett fel som utvärderats någon annanstans.
Granska alla DNS-frågande SPF termer, inklusive kapslade inkluderar, mot utvärderingsgränsen på tio terminer. En DNS post som passar redaktörens längdbegränsning kan fortfarande överskrida protokollets utvärderingsgräns. Bevara legitima auktoriseringar och den godkända avslutande kvalificeringen. Utvidga inte behörigheter med exempel a- eller mx-mekanismer om inte domänägaren har utvärderat vad de godkänner. RFC 7208 , Välja poster och DNS sökningsgränser.
Om leverantörens begäran och organisationens befintliga policy inte kan förenas på ett säkert sätt, stoppa innan publicering. Be e-postägaren att utvärdera en sändande underdomän som stöds eller annan lämplig design. Håll den befintliga arbetsvägen tillgänglig medan beslutet fattas.
Publicera kontots publika nyckel hos rätt ägare
SendPulse instruktioner visar DKIM som en TXT post och uttryckligen särskilja den offentliga demonstrationsnyckeln från kontots eget värde. Guiden illustrerar skylt. _domainkey som TXT ägare; hämta det aktuella fullständiga namnet och det offentliga värdet från domäninställningar snarare än att behandla en illustration som bevis för varje konto. Återanvänd inte den långa provnyckeln i artikeln. SendPulse SMTP DKIM , Kopiera en befintlig domänpost.
Inspektera eventuella befintliga poster hos den föreslagna väljarägaren. En redan existerande nyckel kan stödja ett annat konto, leverantör eller operativ väg. Be om en upplösning som stöds istället för att tyst ersätta den eller uppfinna en ny väljare som tjänsten inte kommer att använda. Att behålla en kopia av den tidigare offentliga posten hjälper granskaren att bedöma återställningen, men det tillåter inte återställning av en föråldrad nyckel utan att koordinera signeringsstatus.
Använd den auktoritativa DNS leverantören, inte nödvändigtvis domänregistratorn. Bekräfta om redaktören förväntar sig en relativ värd eller ett fullt kvalificerat namn. Efter att ha sparat, fråga hela ägaren och jämför hela det offentliga värdet med kontoutdata. TXT strängar kan visas i segment; jämför deras kombinerade innehåll snarare än att infoga mellanslag mellan fragment.
Endast offentligt verifieringsmaterial hör hemma i DNS eller implementeringsarbetsbladet. Privata signeringsnycklar, SMTP lösenord och API-hemligheter behövs inte för en DNS granskning. Ge stöd för den berörda domänen och offentliga register utan att skicka inloggningsuppgifter.
Verifiera anslutningsstatus och val av avsändare
E-postdokumentationen använder Kontrollera DNS poster och ändrar en lyckad post till Ansluten. Dess installationsinstruktioner kräver också att den autentiserade domänen matchar avsändarens adressdomän. SendPulse e-postautentisering, generera dina DKIM och SPF -poster och kontrollera inträdesstatus.
Kontrollera tillämplig status i både tjänstvyer och registrera tidsstämplar. Om ett team ser en annan domänlista, kontrollera att båda teamen finns på det avsedda kontot innan du ändrar DNS . Anta inte en status från ett konto som bevisar att ett annat konto är redo.
Inspektera sedan den konfigurerade avsändaradressen i marknadsföringsarbetsflödet och i varje inskickande ansökan. Granska automatiska mallar och programstandarder som kan behålla en gammal domän efter en migrering. En avsändare som väljs på en förhandsgranskningsskärm kan skilja sig från adressen som används av ett bakgrundsjobb. Fånga de faktiska inställningarna för det produktionsliknande arbetsflödet som testas.
Håll spårningsdomänens konfiguration distinkt. En varumärkesspårningsdomän är användbar för länkar, men den ersätter inte den autentiserade domänen som valts av avsändaren. Acceptansposten ska aldrig härleda DKIM eller SPF anpassning från ett spårningsvärdnamn eller ett uppenbarligen varumärkesmeddelande.
Bevisa e-post- och SMTP -rutter oberoende av varandra
Skicka harmlösa meddelanden genom en representativ kampanj och en representativ ansökan. Lägg till ytterligare fall för olika From-domäner, applikationsöverstyrningar eller routingarrangemang. Använd kontrollerade externa mottagare och behåll de ursprungliga rubrikerna, meddelande-ID, inlämningstid och arbetsflödesidentifierare.
För varje fall, registrera den synliga From, den SPF-autentiserade domänen, Return-Path och varje DKIM d= och s= värde. DKIM -signeringsdomänen och väljaren identifierar uppslagningen av den offentliga nyckeln; en giltig nyckel i DNS enbart bevisar inte det faktiska meddelandet som användes. RFC 6376 , DKIM-Signature och extrahera signaturer från meddelandet.
Använd betrodda mottagarresultat för att skilja ett kryptografiskt pass från ett justerat pass. DMARC kan passera genom ett kvalificerat justerat SPF eller DKIM resultat, och justeringsläget påverkar domänjämförelsen. Registrera vilken mekanism som levererar resultatet istället för att bara skriva "autentisering godkänd." RFC 9989 , Identifier Alignment Explained och DMARC -utvärdering.
Om kampanjen går igenom men applikationen inte gör det, jämför den faktiska avsändaren, kontot och rutten först. Rotera inte den delade nyckeln som första svar. Den ändringen kan påverka en fungerande marknadsföringsström samtidigt som den lämnar programmets felaktiga Från-adress orörd.
Diagnostisera problem med delade poster utan att störa båda tjänsterna
För ett DNS verifieringsfel, inspektera den publicerade ägaren, posttyp, fullständigt värde och auktoritativ leverantör. För en saknad signatur, bekräfta att testet använde den autentiserade domänen och det avsedda SendPulse-kontot. För ett signaturfel, jämför den observerade väljaren och nyckeln och kontrollera om en annan gateway ändrade signerat innehåll.
Om SPF godkänns men DMARC misslyckas, jämför identiteter innan du lägger till auktorisering. Om SMTP inlämning avvisas före leverans, håll inskickningsfelet åtskilt från mottagarautentiseringsresultaten. Ett problem med referenser, kvoter eller programformat kan inte diagnostiseras enbart från en DNS kontroll. Bevara exakta fel utan att kopiera hemligheter till supportpaketet.
Om ett anpassat kuvertkrav förblir ouppfyllt, skaffa SendPulses stödda alternativ för det exakta kontot. De granskade instruktionerna fastställer inte att varje kund kan tilldela en önskad Return-Path domän. Uppfinn inte en MX eller CNAME arrangemang för att uppskatta en funktion som inte har bekräftats.
Återställning av arbetsblad och ett fiktivt testfel
Fyll i kalkylbladet för SendPulse delad domän (skapa en separat granskningspost med fälten som beskrivs här) med en radgrupp per autentiserad domän och en bevisinmatning per e-post- eller SMTP rutt. Registrera plantillägget, befintligt väljarberoende, DNS resultat, avsändarkonfiguration och resultat av mottagna meddelanden. Markera okända uttryckligen.
Fiktivt skriftligt fall SP-01: anta kampanj Från courses@example.org har godkänd d=example.org, men lektionsansökan skickar in From lessons@old.example med DKIM / SPF resultat okända. Ansluten status för example.org upprättar inte autentisering av old.example . Applikationsägaren bör bekräfta den godkända avsändaren, jämföra inventeringen av den delade domänen och testa lektionsvägen utan att rotera arbetsnyckeln. Inget konto eller meddelande nåddes och ingen korrigering eller test utfördes.
Innan en ändring bestämmer du hur du ska pausa varje påverkad stream och återställa den senast godkända avsändarkonfigurationen. Koordinera eventuella nyckelbyten med alla tjänster som delar den. När du går i pension, stoppa alla beroende program och kampanjer innan du tar bort autentiseringsposter. Testa om efter planändringar, kontomigrering, DNS värdändringar eller nya applikationsvägar.
Stäng endast det testade skopet
Acceptans kräver korrekt domänrättighet, kontoutfärdade poster, giltig offentlig DNS , ansluten leverantörsstatus, avsedd avsändarval och betrodd mottagarbevis för varje materialväg. En verifierad kampanj stänger inte en oprövad SMTP integration. Live-konto, DNS och meddelandekontroller, oberoende teknisk granskning, visuell granskning och mänskligt SME-godkännande förblir oavgjorda; detta utkast är opublicerat och gör inte anspråk på en slutförd distribution.
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.