E-pasta piegāde 2026: kāpēc katra trešā vēstule nesasniedz

No aukstajām kampaņām, ko pēdējos divos gados esam vadījuši klientiem, aptuveni katra trešā vēstule tā arī nenonāk iesūtnē. Tā nav atlēkusi. Tā nav noraidīta. Tā klusi nogulsnējas Gmail, Outlook vai saņemošā servera filtra mēstuļu mapē — neredzama adresātam, neuzskaitīta sūtīšanas rīkā, atzīmēta kā „piegādāta“ jebkurā atskaitē, ko jūs atvērsiet. Šī plaisa starp piegādātu un patiešām redzētu ir tas, par ko īstenībā ir runa, kad saka e-pasta piegāde, un tieši šeit lielākā daļa auksto kampaņu nomirst, nevienam to nepamanot.

Lielākā daļa rakstu par šo tēmu 2026. gadā joprojām nokavē reālo mehāniku. Šis ir garais variants. Tā beigās jūs sapratīsiet, kā Gmail un Microsoft patiesībā vērtē jūsu vēstules, kuri autentifikācijas un reputācijas soļi tiešām strādā (un kuri ir teātris) un kā izskatās ikdienas operacionālais ritms sūtītājam, kurš domā par piegādi. Mēs balstāmies uz infrastruktūru, ko paši uzturam AFF Lab: domēnu iesildīšana apjomā, Postfix un OpenDKIM reālā darbā un dati no reālām klientu kampaņām.

E-pasta piegāde ir varbūtība, ka jūsu nosūtīta vēstule nonāks adresāta iesūtnē — nevis viņa mēstuļu mapē, ne reklāmu cilnē, ne klusi atmesta pie vārtejas. To nosaka trīs slāņi, kas balstās viens uz otra: autentifikācija, reputācija un saturs ar iesaistes signāliem. Katrs ir nepieciešams; neviens pats par sevi nav pietiekams.

Ja jūs auksto saziņu iestatāt pirmo reizi, izejiet šo materiālu no augšas uz leju. Ja kaut kas jau ir salūzis, pārejiet uz diagnostikas sadaļu beigās — tur ir piecu minūšu izpēte soli pa solim.

„Piegādāts“ nav tas, ko jūs domājat

Pirmais sajaukums jānoskaidro uzreiz: vārdus piegādāts, nonākšana iesūtnē un piegāde nemitīgi lieto dažādās nozīmēs, un tieši spraugā starp tiem nomirst lielākā daļa auksto kampaņu.

Kad jūsu sūtīšanas rīks saka, ka vēstule ir piegādāta, parasti tas nozīmē vienu: saņemošais SMTP serveris pieņēma vēstuli pie vārtejas un atgrieza 250 OK. Tas arī viss. Serveris piekrita paņemt vēstuli. Kas notiek tālāk — vai tā nonāks iesūtnē, mēstulēs, reklāmu cilnē vai karantīnā, ko lietotājs nekad neatver — izlemj jau saņemošā sistēma, nevis sūtītājs.

Metrika, kas patiešām svarīga, ir nonākšanas iesūtnē īpatsvars: no katrām 100 pieņemtām vēstulēm cik nonāca galvenajā mapē, kur tās redzēs dzīvs cilvēks. Nozares atskaites punkti B2B aukstajām vēstulēm 2026. gadā ir diezgan plašā diapazonā:

Ko redzam savā sūtīšanas infrastruktūrā, sadalījumā pēc sūtītāja stāvokļa:

Sūtītāja stāvoklis	Tipiska nonākšana iesūtnē
Labi iestatīts domēns, iesildīts 6+ nedēļas	75–90%
Jauns domēns, autentifikācija iestatīta pareizi	50–70%
Jauns domēns bez iesildīšanas	20–40%
Domēns publiskā melnajā sarakstā	5–20%
Autentifikācija neiziet (nav SPF/DKIM)	10–30%

Jums neredzamie zudumi, ko pieminējām sākumā, ir starpība starp rīka atskaiti „95% piegādāts“ un reālo nonākšanu 60%. Nekas jūsu sūtīšanas platformā jums to nepateiks. Uzzināt to var tikai divos veidos: ar kontroltestu (sūtīšana uz kontroles pastkastu paneli dažādos providerus) vai ar trešo pušu rīkiem — GlockApps, MailGenius, Mailtrap. Iestatiet to, pirms nosūtāt pirmo kampaņu. Pretējā gadījumā lidojat akli.

Trīs piegādes slāņi

Mūsdienu pasta provideri (Gmail, Microsoft, Yahoo, Apple) izlemj, kur novietot jūsu vēstuli, balstoties uz trim neatkarīgiem slāņiem. Iziesim katru pēc kārtas, bet vispirms svarīgi saprast pašu struktūru: lielākā daļa „piegādes triku“, par ko raksta internetā, ir apsēsti ar vienu slāni un pilnībā ignorē citu.

1. Autentifikācija. Vai saņemošais serveris tic, ka sūtītājs ir tas, par ko uzdodas? Ar to nodarbojas SPF, DKIM, DMARC un ARC. Klupšana šeit ir binārā: lielākā daļa lielo provideru tagad vienkārši noraida vai nosūta karantīnā masu pastu bez autentifikācijas.
2. Reputācija. Vai saņēmējs uzticas šim domēnam un IP, balstoties uz to iepriekšējo uzvedību? Mēstuļu sūdzību īpatsvars, atlēcienu īpatsvars, iesaiste, statuss melnajos sarakstos un sūtīšanas paterna stabilitāte — viss tas savijas vienā reputācijas vērtējumā, ko saņēmējs aprēķina pie sevis, ne ar vienu nedaloties. Savu vērtējumu jūs tieši neredzat; to var tikai izsecināt.
3. Saturs un iesaiste. Vai pati vēstule izskatās pēc mēstules un vai reāli lietotāji ar to mijiedarbojas pēc piegādes? Galvenes, vēstules ķermenis, saišu paterni, attēlu un teksta attiecība, saņēmēja uzvedība (atvēršanas, atbildes, atzīmes „Mēstule“) — viss tas baro klasifikāciju katrai atsevišķai vēstulei.

Autentifikācija ir nepieciešama, bet ar to nepietiek. Reputācija nogremdēs pat ideāli autentificētu vēstuli. Saturs var glābt vai nogalināt piegādi pat ar stipru reputāciju. Slāņi reizinās — slikts rezultāts jebkurā no tiem velk lejā visu pārējo.

1. slānis: autentifikācija kā nākas

Šis ir pamats. Katrs mūsdienu pasta providers tagad prasa vismaz SPF un DKIM, un DMARC pāriet no „ieteicams“ uz „sagaidāms“: kopš 2024. gada februāra Google prasa masveida sūtītājiem (virs 5000 vēstulēm dienā uz Gmail) iestatīt SPF un DKIM un publicēt DMARC ierakstu, kaut vai ar vismaigāko politiku p=none, ar nosacījumu, ka domēns From laukā ir izlīdzināts pret SPF vai DKIM.^[1] Yahoo ieviesa tās pašas autentifikācijas un DMARC (vismaz p=none) prasības, nenosaucot apjoma slieksni.^[2]

Trīs ieraksti, kas jāpublicē:

• SPF (Sender Policy Framework) — DNS TXT ieraksts ar serveru sarakstu, kuriem atļauts sūtīt pastu no jūsu domēna. Saņemošie serveri salīdzina aploksnes sūtītāju ar šo sarakstu.
• DKIM (DomainKeys Identified Mail) — kriptogrāfisks paraksts, kas pievienots katrai izejošajai vēstulei. Saņēmējs paņem jūsu publisko atslēgu no DNS un pārbauda parakstu.
• DMARC (Domain-based Message Authentication, Reporting & Conformance) — pasaka saņēmējiem, ko darīt, kad SPF vai DKIM neiziet, un kur sūtīt kopsavilkuma atskaites.

SPF un DKIM nav alternatīvas — vajag abus. SPF autentificē sūtīšanas IP („vai šim serverim atļauts sūtīt par šo domēnu?“); DKIM autentificē pašu vēstuli („vai tā tika izmainīta ceļā?“). SPF salūzt, kad pastu pārsūta; DKIM paraksts to pārdzīvo. DMARC grib, lai vismaz viens no tiem iziet ar izlīdzināšanu, un abu turēšana ir tā pati josta ar lencēm, kas notur autentifikāciju, kad viens no tiem salūzt. Trīs sadaļas zemāk ir precīza katra ieraksta iestatīšana: vispirms SPF un DKIM, tad DMARC, kas tos sasaista.

SPF iestatīšana (soli pa solim)

SPF (Sender Policy Framework) ir viens TXT ieraksts sūtīšanas domēna saknē ar serveru sarakstu, kuriem atļauts sūtīt pastu jūsu vārdā. Kad vēstule pienāk, saņēmējs uzmeklē šo ierakstu un salīdzina sūtīšanas IP ar sarakstu — sakritība iziet, nesakritība lasās kā mēstuļu signāls. Ieraksts izskatās šādi:

v=spf1 include:_spf.google.com include:spf.smartlead.ai ~all

1. solis — uzskaitiet katru servisu, kas sūta no jūsu domēna. Pastkastes providers (Google Workspace, Microsoft 365), jūsu aukstā e-pasta rīks (Smartlead, Instantly, Lemlist, Apollo) un jebkurš transakciju vai CRM sūtītājs (SendGrid, Mailgun, HubSpot). Izlaidiet kaut vienu — un tā pasts izgāzīs SPF.

2. solis — savāciet katra servisa include: vērtību no tā dokumentācijas: Google Workspace include:_spf.google.com, Microsoft 365 include:spf.protection.outlook.com, SendGrid include:sendgrid.net. Apvienojiet tos vienā virknē, kas sākas ar v=spf1 un beidzas ar noslēdzošo direktīvu.

3. solis — publicējiet vienu TXT ierakstu sūtīšanas domēna saknē (@) ar vērtību no augšējās virknes, TTL noklusētais. Viens SPF ieraksts uz domēnu, nekad divi — vairāki v=spf1 ieraksti anulē cits citu.

4. solis — pārbaudiet pēc izplatīšanās (5–60 minūtes) ar komandu dig +short TXT yourdomain.com vai MXToolbox SPF pārbaudītāju, kas turklāt pārbauda sintaksi un uzmeklēšanu skaitu.

Vai tas strādā, izšķir divi noteikumi. Lietojiet ~all (mīkstais atteikums), nevis -all (cietais atteikums), līdz esat pārliecinājušies, ka uzskaitīts katrs legitīmais serviss — priekšlaicīgs -all noraida jūsu pašu pastu tajā brīdī, kad aizmirsāt vienu servisu; pievelciet uz -all tikai pēc mēneša tīras sūtīšanas. Un palieciet 10 DNS uzmeklēšanu limita robežās: katrs include: skaitās, arī ietvertie includes, un pārsniegšana dod permerror, ko lielākā daļa saņēmēju lasa kā tiešu SPF neizdošanos.^[3] Ja dziļas includes ķēdes (Salesforce, HubSpot) izved jūs pāri 10, izvērsiet includes uz IP adresēm vai izmetiet servisus, ko vairs nelietojat. Nekad nelietojiet +all (atļauj jebkuram) vai ?all (bez viedokļa) — abi anulē ieraksta jēgu.

DKIM iestatīšana (soli pa solim)

DKIM (DomainKeys Identified Mail) pievieno kriptogrāfisku parakstu katrai izejošajai vēstulei. Sūtīšanas serviss paraksta ar privāto atslēgu; saņēmējs paņem atbilstošo publisko atslēgu no jūsu DNS adresē <selector>._domainkey.yourdomain.com un pārbauda parakstu — tas ir pierādījums, ka vēstule nāk no jūsu domēna un nav izmainīta ceļā.^[4] Publicētajā ierakstā glabājas tikai publiskā puse:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQK...

1. solis — ģenerējiet atslēgu pāri. Gandrīz katrs serviss to izdara jūsu vietā un iedod publisko atslēgu publicēšanai (Google Workspace: Admin Console → Apps → Gmail → Authenticate email → Generate new record). Pašmitināts Postfix izmanto opendkim-genkey.

2. solis — pierakstiet selektoru, ko serviss iedeva (google, s1, smartlead, default). DNS hosts ir <selector>._domainkey, piemēram google._domainkey.

3. solis — pievienojiet TXT ierakstu pie šī hosta ar publiskās atslēgas vērtību. Lietojiet 2048 bitu atslēgas; tās pārsniedz 255 rakstzīmju limitu uz TXT rindu un tiek sadalītas vairākās pēdiņās liktās rindās — lielākā daļa DNS providēru to izdara jūsu vietā, bet ar dig pārliecinieties, ka visa atslēga nolaidās vesela. Nekad nelieciet privāto atslēgu DNS.

4. solis — pārbaudiet, ka ieraksts atrisinās: dig +short TXT <selector>._domainkey.yourdomain.com.

5. solis — pārbaudiet, ka parakstīšana tiešām notiek. Publicēta atslēga nenozīmē, ka pasts tiek parakstīts. Nosūtiet testa vēstuli un pārliecinieties, ka izejā ir DKIM-Signature galvene, bet saņēmējam — dkim=pass sadaļā Authentication-Results. Šis solis noķer visbiežāko kļūmi — pareizu ierakstu virs servisa, kuram parakstīšana tā arī netika ieslēgta.

Iedodiet aukstajai saziņai savu selektoru, atsevišķu no transakciju pasta, lai reputācijas trieciens vienā plūsmā nekad neskartu otru; bet, kad jums ir vairāki sūtīšanas servisi, iedodiet katram savu selektoru, lai to atslēgas paliek izolētas. Lielākā daļa komandu iestata DKIM vienreiz uz servisu un reizi gadā nomaina atslēgas drošības higiēnas labad.

DMARC iestatīšana un politikas izvēle

DMARC sasaista SPF un DKIM un pasaka saņēmējiem, ko darīt, kad tie neiziet. Viens TXT ieraksts adresē _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r

p= ir politika (par to zemāk); rua= ir tas, kur sūtīt kopsavilkuma atskaites — norādiet pastkasti, ko tiešām pārbaudāt; adkim/aspf uzstāda izlīdzināšanas režīmu, un mīkstais režīms (r) der gandrīz visiem. DMARC iziet tikai tad, kad SPF vai DKIM ne tikai iziet, bet arī izlīdzinās ar From-domēnu: vēstule no outreach.example.com ar From galveni [email protected] neiztur izlīdzināšanu pat ar derīgu parakstu. Un ieraksts uz example.com nesedz apakšdomēnu mail.example.com — uzstādiet sp=, ja no jūsu apakšdomēniem notiek sūtīšana.

Politika ir kāpnes, un kļūda, kas sagrauj piegādi, ir uzlēkt uzreiz to augšā.

• p=none (novērošana). Saņēmēji neko nemaina, bet sūta jums atskaites. Vienmēr sāciet no šejienes. Pabūstiet šeit 2–4 nedēļas — līdz atskaites apstiprina, ka 100% jūsu legitīmā pasta iziet SPF vai DKIM ar izlīdzināšanu.
• p=quarantine. Neizturējis pasts iet mēstulēs, nevis iesūtnē — pazemināts, bet ne pazaudēts. Izlaidiet to pakāpeniski ar pct= pogu: p=quarantine; pct=10 nosūta karantīnā 10% neizturējušā pasta^[5]; celiet līdz 25, 50, pēc tam 100 pa 2–3 nedēļām, vērojot atskaites. Tieši šeit lielākajai daļai B2B auksto vēstuļu sūtītāju vajadzētu apstāties.
• p=reject. Neizturējis pasts tiek atgriezts uzreiz — spēcīgākais signāls pret viltošanu un vismazāk piedodošais: jebkura sprauga autentifikācijā klusi pazaudē reālu pastu. Atstājiet to bankām, valsts sektoram un augsta sūtītāja viltošanas riska zīmoliem, kuriem ir operacionālā stingrība to nodrošināt.

Pareizi izdarīta, pilnā migrācija aizņem 6–12 nedēļas. To saspiest vai izlaist p=none — tā komandas nonāk situācijā, kad nedēļām atgriež savu pašu pastu, pirms saprot, kāpēc.

Vēl divi sabrukuma režīmi pārdzīvo pat pareizu ierakstu komplektu:

• Pašmitināts SMTP bez PTR ieraksta. Reversais DNS 2026. gadā joprojām ir svarīgs. Bez PTR ieraksta, kas norāda atpakaļ uz sūtītāja hostname, Gmail jūs pazemina neatkarīgi no tā, cik tīri izskatās SPF, DKIM un DMARC.
• ARC izlaišana. Ja jūsu aukstais pasts iet caur servisu, kas pārparaksta vai pārsūta (Google Groups, pasta saraksti, dažas aģentūras), ARC galvenes saglabā sākotnējo autentifikācijas ķēdi. Lielākajai daļai auksto vēstuļu sūtītāju tas nav vajadzīgs, bet, ja redzat DMARC neizdošanos uz vēstulēm, kurām uzticaties, iemesls, visticamāk, ir ARC.

Kad autentifikācija ir uzbūvēta, jūs esat nopelnījuši tiesības sūtīt — bet sūtīšana ir tikai puse no elektroinstalācijas.

MX ieraksti: kas tie ir un kā tos iestatīt

Autentifikācija ir viss par sūtīšanu. Bet aukstā kampaņa strādā tikai tad, ja atbildes atgriežas — un tas sākas ar MX.

MX (Mail eXchange) ieraksts pasaka internetam, kur piegādāt pastu, kas adresēts jūsu domēnam. Tas ir hostname plus prioritātes vērtība (zemāka = mēģina pirmo); saņemošais serveris uzmeklē jūsu MX ierakstus un piegādā uz hostu ar zemāko prioritāti, kas atbild. Nav MX ieraksta — nav atbilžu, un jūs to nepamanīsiet, jo atlēciens aiziet adresātam, ne jums; viņi vienkārši it kā apklust. Verifikācijas servisi arī lasa MX, lai izlemtu, vai domēns vispār spēj saņemt pastu, tāpēc domēns, kas sūta apjomā bez MX, izskatās aizdomīgs.

Google Workspace 2026. gadā iestatīšana ir viens ieraksts:

Type: MX   Host: @   Value: smtp.google.com   Priority: 1

Tas aizstāja veco piecu ierakstu aspmx.l.google.com komplektu (prioritāte 1 plus četri rezerves alt); vecais formāts joprojām strādā, bet jauniem domēniem vajadzētu lietot vienu ierakstu.^[6] Soļi:

1. solis — atveriet DNS domēnam pie sava providera (Cloudflare, Route53, GoDaddy, Namecheap).

2. solis — noņemiet visus novecojušos MX ierakstus, kas palikuši no iepriekšējā providera. Vecu un jaunu MX ierakstu jaukšana padara maršrutēšanu neparedzamu.

3. solis — pievienojiet MX ierakstu no augšas: host @ domēna saknei, value smtp.google.com, prioritāte 1. Norādiet prioritāti skaidri — daži provideri to pēc noklusējuma iestata uz 0 vai 10, kas nesakritīs.

4. solis — pārbaudiet pēc izplatīšanās ar dig +short MX yourdomain.com (gaidiet vienu ierakstu, smtp.google.com, prioritāte 1), tad apstipriniet Admin Console → Apps → Gmail → Verify your domain.

Divas lietas paturiet prātā. Norādiet MX uz hostname ar reālu A ierakstu, nekad uz CNAME — daļa saņēmēju noraida MX caur CNAME. Un iedodiet katram sūtīšanas apakšdomēnam, kam jāsaņem pasts, savu MX ierakstu. Bieža neskaidrība: aukstā e-pasta rīki (Smartlead, Instantly, Apollo) ir sūtīšanas platformas — tām MX nav vajadzīgi; tie ir vajadzīgi jūsu pastkastes providerim.

Pasta sūtīšana un lasīšana: SMTP un IMAP

SMTP (porti 587 STARTTLS vai 465 SSL) sūta jūsu izejošo pastu. IMAP (ports 993) lasa iesūtni un nosūtīto mapi. Aukstā e-pasta platformām vajag abus: SMTP, lai sūtītu, IMAP, lai izsekotu atbildes, apstiprinātu sūtījumus, pamanītu atlēcienus un automātiskās atbildes un uzturētu vienotu kopīgo pastkasti. Iestatīsiet tikai SMTP — platforma sūta, bet nekad neredz atbildes. Divas praktiskas piezīmes 2026. gadam: autentificējieties ar lietotnes paroli vai OAuth, nekad ne ar konta paroli — Microsoft 365 pilnībā atcēla pamata SMTP autentifikāciju, tāpēc OAuth tur ir obligāts — un lielos apjomos priekšroku dodiet sūtīšanai caur API (Gmail API, Microsoft Graph) SMTP vietā augstāku limitu un tīrākas piegādes atgriezeniskās saites dēļ. Nelietojiet POP3: tas novelk pastu no servera un salauž pastāvīgo stāvokli, uz kuru paļaujas aukstās platformas.

Kad santehnika ir savietā, reputācija izlemj, vai kāds vispār izlasīs to, ko jūs sūtāt.

2. slānis: reputācija, neredzamais rezultātu tablo

Lūk, daļa, uz kuras klūp jauni sūtītāji: pat ideāli autentificēta vēstule no pavisam jauna domēna nonāks Gmail mēstulēs. Iemesls — reputācija.

Gmail un Microsoft tur pie sevis slēgtu reputācijas vērtējumu katram sūtošajam domēnam un katram sūtošajam IP. Viņi to nekad nepublicē, nekad nepasaka, kāds tas ir, nekad nepaskaidro, kas to izmainīja. Viņi to izmanto, lai katrai vēstulei izlemtu, vai to likt iesūtnē, reklāmu cilnē, mēstuļu mapē vai nomest zemē.

Jaunam domēnam reputācijas nav. Gmail uztverē „nav reputācijas“ ir tuvāk „neuzticams“ nekā „neitrāls“. Tāpēc solis numur viens jebkuram jaunam auksto vēstuļu sūtītājam ir domēna iesildīšana — pakāpeniska sūtīšanas apjoma un iesaistes audzēšana, lai izveidotu sasniegumu vēsturi.

Tipiskas iesildīšanas mehānika:

• 1.–2. nedēļa: sūtiet 5–10 vēstules dienā uz pastkastēm, kuras jūs pats kontrolējat vai kuras piedalās iesildīšanas pūlā. Atveriet katru vēstuli, atbildiet uz aptuveni trešdaļu, jebkuru, kas nokļuva mēstulēs, atgrieziet iesūtnē.
• 3.–4. nedēļa: palieliniet līdz 25–50 vēstulēm dienā. Iesildīšanas periodā turiet atbilžu īpatsvaru no iesildīšanas korespondentiem ap 20–30% — tas ir iesildīšanas mērķis kontroles pastkastēs, nevis atskaites skaitlis aukstajām kampaņām.
• 5.–6. nedēļa: 100–200 dienā, ieskaitot dažas īstas kampaņas vēstules, iejauktas plūsmā.
• 7.+ nedēļa: uzmanīgi palieliniet līdz reālam kampaņas apjomam, katru nedēļu sekojot nonākšanai iesūtnē.

Iesildīšanas izlaišana maksā jums pirmo kampaņu mēnesi — tās aizies tieši mēstulēs. Vairāki rīki to automatizē (Mailwarm, Lemwarm, Warmup Inbox, Instantly iebūvētā iesildīšana). Visi dara aptuveni vienu un to pašu: pārvada vēstules starp dalībnieku pastkastēm un imitē iesaisti. Tas nav burvju maks — tas, ko viņi dara, ir nopelnīt jums laiku, lai izveidotu sasniegumu vēsturi, neizdedzinot reālus adresātus.

Papildus iesildīšanai pastāvīga reputācija balstās uz pieciem rādītājiem, ko saņēmēji uzrauga:

Signāls	Ko mēra	Veselīgs diapazons (aukstais B2B)
Mēstuļu sūdzību īpatsvars	% saņēmēju, kas nospieduši „Ziņot par mēstuli“	< 0.1%
Atlēcienu īpatsvars	% vēstuļu, ko noraidīja saņemošais serveris	< 2%
Atbilžu īpatsvars	% vēstuļu, uz kurām atbildējis cilvēks	> 3% (silts signāls)
Iesaiste	Atvēršanas un klikšķi (2026 sver mazāk)	atkarīgs
Sūtīšanas stabilitāte	Apjoma svārstības dienu no dienas	zemas

Mēstuļu sūdzību īpatsvars ir bez šaubām galvenais slepkava. Tiklīdz pārkāpjat 0.1% — tas ir viena sūdzība uz tūkstoti vēstuļu — Gmail ātri ierobežo jums ātrumu un pēc tam vēl vairākas nedēļas paliek piesardzīgs.^[1] Atlēcienu īpatsvars arī ir svarīgs; virs 2% norāda uz sliktu saraksta higiēnu, ko saņēmēji lasa kā zīmi, ka jūs sūtāt uz nokasītiem vai novecojušiem datiem.

Atbilžu īpatsvars ir mūsdienu reputācijas paātrinātājs. Auksto vēstuļu sūtītāji, kas konsekventi izsauc atbildes, saņem labāku reputāciju nekā legitīmi transakciju sūtītāji, kuriem atbilžu nav. Saņēmēji zina, ka atbildēja dzīvs cilvēks, tātad vēstules nav tīras mēstules. Tas ir viens no spēcīgākajiem argumentiem par labu personalizācijai apjomā: atbildes nav tikai patīkams bonuss, tās tieši uzlabo jūsu nonākšanu iesūtnē nākamajā kampaņā.

Grūtākais reputācijas pārvaldībā: to var zaudēt dažās dienās, bet atjaunot nedēļām. Viena slikta partija (novecojis saraksts, temata rinda, kas nogalina piegādi, pēkšņs pieckārtīgs apjoma lēciens) var nogāzt jūsu nonākšanu par 20–30 procentpunktiem vienā naktī. Atgūšana prasa atgriešanos pie maziem apjomiem, augstas iesaistes un pacietības. Ieplānojiet to jau iepriekš. Sūtītāji, kas izturas pret sava domēna reputāciju kā pret trauslu aktīvu — jo tā tāda ir — pārdzīvo tos, kas to nedara.

3. slānis: saturs un iesaistes signāli

Satura filtri 2026. gadā nebūt nav 2010. gadu atslēgvārdu bloķētāji. Gan Gmail, gan Microsoft darbina apmācītus modeļus, kas kombinē simtiem pazīmju: galvenes struktūru, vēstules ķermeņa valodas paterņus, saišu domēnus, attēlu un teksta attiecību, sūtīšanas paterņus, saņēmēja mijiedarbības vēsturi. Tos neapiet ar trikiem, piemēram, „FR3E“ vietā „FREE“.

Ko jūs varat izdarīt — izvairīties no paterņiem, kas noturīgi korelē ar mēstulēm apmācības datos.

Temata rindas. Izvairieties no vienlaidus LIELAJIEM BURTIEM, vairākām izsaukuma zīmēm, valūtas simboliem pirms summām, steidzamības marķieriem („ACT NOW“, „limited time“) un „Re:“ vai „Fwd:“ prefiksiem pirmajā kontaktā (pēdējais agrāk strādāja, bet tagad aktīvi izraisa karogu). Temata rindas, kas labi strādā B2B aukstajās vēstulēs, mēdz būt īsas (3–7 vārdi), konkrētas un atsaucas uz kaut ko par saņēmēju vai viņa uzņēmumu.

Vēstules ķermenis. Lielākais sarkanais karogs 2026. gadā ir šablona sajūta: ķermenis, kas lasās kā 10 000 citu identisku vēstuļu. Filtri to pamana gan caur teksta līdzības vērtējumu, gan caur personalizācijas mainīgo trūkumu renderētajā HTML. Vēstule, kas aizvieto tikai [First Name] un neko vairāk, izskatās šablonveidīga; vēstule, kas atsaucas uz konkrētu nesenu notikumu, amata detaļu vai faktu par uzņēmumu, izskatās gatavota ar roku. Filtri to atšķir.

Saites. Viena saite uz vēstuli — normāli. Divas — normāli. Piecas vai sešas — izraisa filtru nostrādāšanu. Lietojiet vienu tiešu saiti (jūsu domēns vai tikšanās rīks), nevis saišu saīsinātājus (bit.ly, tinyurl), kas tiek stipri pazemināti. Ja izmantojat savu izsekošanas domēnu — un jums vajadzētu — pārliecinieties, ka tam ir savs SPF un DKIM un ka tas pats nav nevienā melnajā sarakstā, neatkarīgi no sūtīšanas domēna.

HTML pret vienkāršu tekstu. B2B aukstajās vēstulēs uzvar vienkāršs teksts vai viegli noformēts HTML. Smagas HTML vēstules ar iegultiem attēliem, vairākiem fontiem un izsmalcinātu izkārtojumu izskatās kā mārketings un tiek klasificētas kā reklāmas. Sods par noformējumu ir reāls — mēs esam redzējuši vienu un to pašu vēstuli divos variantos (vienkāršs teksts pret noformētu HTML), kas nonāca iesūtnē 78% pret 41% vienā un tajā pašā domēnu pūlā.

Atrakstīšanās saite. Nepieciešama atbilstības dēļ, bet vēl svarīgāk — tās klātbūtne samazina mēstuļu sūdzību īpatsvaru. Saņēmējs, kurš grib iziet, izmantos saiti, nevis nospiedīs „Ziņot par mēstuli“. Šī viena starpība ir 5–10 punktu vērta nonākšanā iesūtnē. Atrakstīšanos vienā klikšķī pēc RFC 8058 (List-Unsubscribe-Post: List-Unsubscribe=One-Click) Gmail tagad sagaida no masveida sūtītājiem (virs 5000 vēstulēm dienā)^[1] un Yahoo.^[2]

Iesaiste ir puse no vērtējuma. Saņēmēji piešķir lielu svaru tam, ko jūsu reālie adresāti dara ar jūsu vēstulēm. Atvēršanas (mazāk nekā agrāk, kopš Apple Mail Privacy Protection pievienoja daudz trokšņa), klikšķi, atbildes, dzēšana bez izlasīšanas un atzīmes „Mēstule“ — viss atgriežas reputācijā pa saņēmējiem un pa domēniem. Secinājums: mērķēšana ir tikpat svarīga kā saturs. Ideāla vēstule, nosūtīta uz nepareizu sarakstu, tik un tā tiks ignorēta, un saņemošā sistēma iemācīsies, ka jūsu domēns sūta cilvēkiem, kas neiesaistās.

Savi izsekošanas domēni

Katra izsekojamā saite jūsu vēstulē — tās, kas fiksē atvēršanas un klikšķus — iet caur izsekošanas domēnu, pirms pāradresē uz reālo galamērķi. Pēc noklusējuma jūsu platforma lieto koplietotu izsekošanas domēnu — to pašu, ko katrs cits sūtītājs uz tās, ieskaitot spamerus. Kad viņu izsekošanas domēns nonāk bloķēšanas sarakstā, jūsu izsekotais pasts pārmanto kaitējumu, jo satura filtri vērtē katra ķermenī esošā saites domēna reputāciju.

Savs izsekošanas domēns to salabo: CNAME ieraksts novirza neitrālu apakšdomēnu (track., link. vai r. — nekad offers. vai promo.) uz jūsu platformas izsekošanas hostu, lai saites lasās kā jūsu domēns, bet jūsu izsekošanas reputācija ir izolēta no citu reputācijas. Iestatīšana ir 15–30 minūtes uz sūtīšanas domēnu: pievienojiet CNAME, norādiet to platformā un pārliecinieties, ka renderētās saites iet pa HTTPS (HTTP izsekošanas saite pati par sevi ir filtra karogs). Tiešais nonākšanas pieaugums ir pieticīgs — pāris punkti — bet reputācijas izolācija uzkrājas, apjomam augot, tāpēc reālās komandas ar 500+ sūtījumiem dienā to uzskata par standarta infrastruktūru, ne par neobligātu papildinājumu.

Operacionālā puse: ikdienas rutīna

Autentifikācija un saturs ir vienreizēja iestatīšana. Reputācija tiek būvēta un zaudēta nepārtraukti. Auksto vēstuļu sūtītāja ikdienas darbs, ja viņš domā par piegādi, vairāk līdzinās mazas infrastruktūras pārvaldīšanai nekā mārketingam.

Apjoma pārvaldība. Nepalieliniet no 50 līdz 500 vēstulēm dienā vienā naktī. Audzējiet apjomu ne vairāk kā par 30% nedēļā un nekavējoties atkāpieties, ja nonākšana krīt. Sūtiet saņēmēja darba stundās pēc viņa laika joslas, nevis visu vienā uzliesmojumā pusnaktī.

Saraksta higiēna. Katrs saraksts pirms sūtīšanas ir jāiztīra. Adrešu pārbaudes rīki (NeverBounce, ZeroBounce, Hunter Email Verifier, Bouncer) noķer nederīgas adreses, pirms tās rada atlēcienu — bet atlēcieni tieši bojā reputāciju. Tīrīšana parasti noņem 5–15% no jebkura saraksta; tā ir norma. Ja pārbaude atzīmē vairāk nekā 25%, jūsu avots, visticamāk, ir nokasīts vai novecojis, un tādu sarakstu labāk izmest, nevis sūtīt pa to.

Vairāki sūtīšanas domēni. Pieredzējuši aukstās saziņas operatori tur vairākus sūtīšanas domēnus rotācijā. Shēma šāda: piederiet yourbrand.com kā galveno korporatīvo domēnu (transakciju pastam un zīmolam), pēc tam reģistrējiet variantus, piemēram, yourbrand-mail.com, getyourbrand.com, tryyourbrand.com, aukstajai saziņai. Katram variantam sava iesildīšana, sava reputācija, un tas ierobežo triecienrādiusu, ja viens no tiem nodeg. Ja sūtāt vairāk nekā 1000 auksto vēstuļu nedēļā, tā vairs nav izvēle.

Melno sarakstu monitorings. Publiskie melnie saraksti (Spamhaus, SORBS, Barracuda) atzīmē domēnus un IP, ko uzskata par ļaunprātīgiem. Nokļūšana tur parasti ir simptoms, nevis cēlonis: līdz brīdim, kad esat Spamhaus, jūsu nonākšana jau ir sabrukusi. Bet iknedēļas skenēšana noķer problēmas, ko citādi palaistu garām. MXToolbox vai Multi-RBL check ļauj noskenēt 30 sekundēs.

DMARC atskaites. Kad DMARC ir uzstādīts uz p=quarantine vai p=reject, jums katru dienu pienāk kopsavilkuma XML atskaites. Lielākā daļa sūtītāju tās nekad nelasa. Neapstrādātā veidā tās ir nepatīkamas — XML, tehniskas, apjomīgas — bet tā ir vienīgā vieta, kur redzat autentifikācijas neizdošanos no trešajām pusēm, kas noķer konfigurācijas kļūdas un viltošanas mēģinājumus. Postmark DMARC, dmarcian vai EasyDMARC pārvērš XML par paneli par $20–50 mēnesī.

Kontroltesti. Palaidiet kontroltestu pirms jebkuras kampaņas virs 1000 vēstulēm. Kontroles saraksts ir 30–50 pastkastes, izkliedētas pa Gmail, Outlook, Yahoo un korporatīvajiem domēniem un izmantotas kā kontroles grupa. Sūtiet kampaņu uz kontroles sarakstu pirmo; ja nonākšana ir zem 60%, kaut ko salabojiet, pirms sūtāt pārējo.

30 dienu iestatīšana, dienu pēc dienas

Pavisam jaunai sūtīšanas operācijai reālistisks grafiks ir viens mēnesis no reģistrācijas līdz pārliecinātam kampaņas apjomam:

• 1.–3. diena. Reģistrējiet sūtīšanas domēnu, iestatiet SPF, DKIM, DMARC uz p=none. Uzstādiet pastkastes infrastruktūru (Google Workspace vai pašmitināts Postfix + Dovecot + OpenDKIM). Konfigurējiet PTR ierakstus uz sava sūtīšanas IP. Reģistrējieties Postmaster Tools un DMARC atskaišu panelī.
• 4.–7. diena. Sāciet iesildīšanu. Sāciet ar 5 vēstulēm dienā, līdz pirmās nedēļas beigām sasniedziet 25. Katru dienu sekojiet nonākšanai uz neliela kontroles saraksta.
• 8.–14. diena. Turpiniet iesildīšanu. Sasniedziet 75 vēstules dienā. Pārslēdziet DMARC uz p=quarantine, kad būsiet pārskatījuši divu nedēļu tīras atskaites.
• 15.–21. diena. Sāciet reālu saziņu mazos apjomos (50 auksto vēstuļu dienā plus turpināta iesildīšana). Pirms pirmās reālās sūtīšanas palaidiet kontroltestu.
• 22.–30. diena. Palieliniet līdz mērķa sūtīšanas apjomam. Iknedēļas kontroltesti, iknedēļas melno sarakstu skenēšana, ikdienas pārbaudes Postmaster. Pielāgojiet tekstu, mērķēšanu un apjomu pēc tā, ko rāda dati.

Ko Google tieši nepasaka: Postmaster Tools nerāda neko, kamēr domēns nesūta uz Gmail jūtamu ikdienas apjomu vairākas dienas pēc kārtas. Zem šī sliekšņa visi grafiki atbild „No data to display“ — tas nozīmē, ka neliels vai tikko iesildīts sūtītājs to diagnostikai vēl nevar izmantot. Precīzu slieksni Google nepublicē. Ja grafiki ir tukši, salauzts nav ne rīks, ne jūsu domēns: jūs vienkārši nesūtat uz Gmail pietiekami daudz, lai dati vispār rastos.

Pēc 30 dienām jums ir reāls domēns ar reālu reputāciju, piegāde ap 75–85% un strādājošs mērīšanas cikls. Tā ir bāzes līnija; no šejienes ikdienas darbs izlemj, vai piegāde pacelsies uz 85–95% nākamajās 90 dienās vai lēnām sāks kristies.

Piegādes problēmu diagnostika: piecu minūšu izpēte

Kad kampaņas pēkšņi pārstāj strādāt, izejiet šo kontrolsarakstu pēc kārtas. Lielākā daļa problēmu atrisinās vienā no pirmajiem trim soļiem.

1. solis — Autentifikācijas pārbaude (60 sekundes). Palaidiet savu sūtīšanas domēnu caur MXToolbox SuperTool vai dig. Pārliecinieties, ka SPF atrisinās bez kļūdām un paliek 10 DNS uzmeklēšanu robežās. Pārliecinieties, ka DKIM selektors atrisinās uz derīgu atslēgu. Pārliecinieties, ka DMARC ieraksts eksistē un izmanto saprātīgu politiku. Ja kaut kas no šī neiziet, vispirms labojiet autentifikāciju — nekas cits nav svarīgs, kamēr šie trīs neiziet.

2. solis — Melno sarakstu skenēšana (60 sekundes). Palaidiet savu sūtīšanas domēnu un sūtīšanas IP caur MXToolbox Multi-RBL. Trāpījumi Spamhaus, SORBS vai Barracuda bloķē 80%+ nonākšanas iesūtnē pie lielajiem provideriem. Izņemšana no saraksta aizņem 1–7 dienas un prasa pierādījumus, ka problēma ir novērsta.

3. solis — Kontroltests (5 minūtes palaišanai, 30 minūtes rezultātiem). Sūtiet kampaņu — vai vienu vēstuli no tās — uz kontroles sarakstu. Ja nonākšana ir virs 75%, ar piegādi viss ir kārtībā un problēma ir citur (mērķēšana, teksts, piedāvājums). Ja nonākšana ir zem 50%, problēma ir sūtītāja pusē.

4. solis — Nesenā apjoma un sūdzību pārbaude. Vai apjoms pēdējā laikā ir palēcies? Vai nesena kampaņa saņēma neparasti daudz mēstuļu sūdzību? Gmail un Microsoft ierobežo jums ātrumu vairākas dienas pēc vienas sliktas partijas. Samaziniet apjomu par 70% uz nedēļu, atjaunojiet iesaisti, tad lēni palieliniet.

5. solis — Postmaster Tools. Reģistrējieties Google Postmaster Tools ar savu sūtīšanas domēnu. Tas ir vienīgais publiskais logs uz to, kā Gmail redz jūsu reputāciju.^[7] Domēna reputācijas vērtējums „Bad“ vai „Low“ nozīmē — pārtrauciet sūtīt, kamēr nesalabojat. „Medium“ — labojama. „High“ — tas, ko gribat.

Dibinātājiem, kas sūta 20 vēstules dienā, viss iepriekš aprakstītais ir pārmērīgs: Google Workspace plus adekvāts teksts atrisinās uzdevumu. Pārdošanas komandām, kas sūta 200+ vēstules dienā uz katru pārdevēju vairākās kampaņās, piegāde ir pilnas slodzes darbs. Lielākā daļa komandu to nopietni nenovērtē un zaudē trīs mēnešus pārdošanas plūsmas, pirms saprot, ka viņiem ir piegādes, nevis teksta problēma. Ja redzat nonākšanu iesūtnē zem 60% uz domēna, kuram vajadzētu strādāt labāk, vai gatavojaties mērogot no 100 līdz 1000 vēstulēm dienā, aritmētika parasti ir par labu tam, ka infrastruktūras darbu nodod tiem, kuriem tā uzturēšana ir vienīgais darbs — un tieši to mēs darām AFF Lab e-pasta saziņas pakalpojumā. Ietaupījums uz vienas kampaņas, kas patiešām aizlido, to atmaksā ar uzviju.