En ny sändande domän behöver en ansvarig driftplan innan den behöver mer trafik. Det första beslutet är vilka legitima meddelanden som hör till den, vem som förväntar sig dem och vilket team som kan stoppa en defekt stream. Enbart domänregistrering etablerar varken framgångsrik autentisering eller mottagarförtroende.
Upprätta identitetskartan
För varje tjänst, registrera den synliga Från-domänen, kuvertsändare, DKIM signeringsdomän och väljare, utgående infrastruktur, svarsbrevlåda och företagsägare. Håll webbplats- och spårningsvärdar i separata kolumner. De kan dela ett varumärke samtidigt som de tjänar olika tekniska syften. RFC 6376 beskriver DKIM som en ansvarsmekanism för signering på domännivå; en signatur ska inte läsas som ett uttalande om att varje meddelande som använder varumärket är eftersökt. DKIM specifikation.
Fråga leverantören om de poster som genererats för det faktiska kontot. Publicera endast godkända värden och behåll de exakta DNS ägarnas namn, svar och frågetider. Testa meddelanden genom varje produktionsväg, inklusive supportverktyg och automatiserade kvitton. Ett godkänt nyhetsbrevstest kan inte rensa en oprövad faktureringsintegrering.
Definiera startporten
Kontrollera de aktuella kraven för mottagande leverantör för den planerade trafiken. Googles vägledning för personlig Gmail skiljer alla avsändare från bulksändare och rekommenderar konsekvent sändning snarare än plötsliga skurar. Behandla dessa leverantörsregler som ett daterat beroende, inte en universell policy för alla e-postsystem. Avsändarvägledning för Gmail.
Den operativa startporten bör innehålla ett autentiserat prov, förväntad mottagarpopulation, fungerande svarsväg, korrekt undertryckningsbeteende där tillämpligt, kösynlighet och en namngiven återställningsägare. Den här checklistan är en redaktionell driftrekommendation, inte en ytterligare Google-certifiering. Undvik att skicka oönskad e-post bara för att generera historik.
Arbeta igenom en hypotetisk jämförelse
Anta att två jämförbara fönster med 500 meddelanden innehåller legitima meddelanden till samma mottagarpopulation och destinationsleverantör. I denna uppfunna övning har det första fönstret 490 meddelanden accepterade vid det första försöket och 10 uppskjutna; den andra har 498 accepterade och två uppskjutna. Antag samma observationsgräns för varje. Aritmetiken är 490/500 = 98 % och 498/500 = 99,6 %, en ökning med 1,6 procentenheter, eller ytterligare åtta initiala acceptanser.
Dessa siffror är undervisningsingångar, inte uppmätt kundtrafik, skriptade mottagarobservationer eller bevis på att en ny domän förbättrats. De fastställer inte placering i inkorgen eller orsakssamband. En verklig jämförelse måste behålla de faktiska datumen, destinationsmixen, autentiseringsidentiteter, köidentifierare, innehållsändringar och relevanta mottagarvillkor. Enbart lika summor gör inte två fönster jämförbara.
Ett övergående SMTP svar är inte en permanent förlust. Följ de initialt uppskjutna meddelandena genom senare försöksresultat, registrera slutgiltigt godkännande eller misslyckande separat från godkännande vid första försöket. Se till att meddelanden fortfarande är i kö vid gränsen synliga istället för att tyst släppa dem från nämnaren. RFC 5321 avsnitt 4.2.1 och 4.5.4 särskiljer tillfälliga fel och försök igen.
Expandera endast med observerbar kontroll
Sätt en recensionspunkt efter varje meningsfull ökning. Undersök distributionen av destinationer, fullständiga SMTP svar, köålder och användarrapporterade fel. Håll små volymer eller frånvarande instrumentpaneldata som okända snarare än att uppfinna ett gynnsamt rykte. Ett stoppvillkor kan vara en ihållande ökning av köåldern eller en konkret autentiseringsdefekt, definierad av teamet före expansion.
Byt inte namn upprepade gånger när klagomål dyker upp. Granska tillstånd, frekvens och innehåll med företagsägaren. En ny domän bör stödja en igenkännbar identitet, inte dölja ett tidigare oönskat program. Håll den tidigare godkända rutten tillgänglig endast om den behåller samma autentiserings- och mottagarkontroller.
Nära lanseringsgranskning med de testade identiteterna, daterade observationer, olösta rutter och nästa beslutspunkt. Framgång innebär att teamet kan förklara och driva den verkliga trafiken; det betyder inte att ett fast antal dagar har garanterat universell leverans.
Skriv lanseringsbeslutet på en sida
- Syfte: identifiera förväntade mottagare, meddelandetyper och varje företagsägare.
- Ruttbevis: behåll genererade DNS värden, mottagna meddelandeidentiteter och betrodda autentiseringsresultat för varje använd tjänst.
- Operationell kontroll: bekräfta svarshantering, undertryckande i förekommande fall, kösynlighet och återställningsägande.
- Mätning: definiera nämnaren, destinationsmixen, gränsen för första försöket och senare försök igen innan du jämför resultaten.
- Stoppvillkor: kom överens om autentiseringsdefekterna eller köförsämringen som pausar expansionen.
- Granska: registrera okända instrumentpaneldata som okända och bestäm nästa ökning från verkliga observationer, inte en fast uppvärmning kalender.