AFF Lab
E-pasta piegāde

Kas ir MX ieraksti: cold email sūtītāja ceļvedis 2026

Ko MX ieraksti dara, kāpēc tie ir svarīgi cold email sūtītājiem 2026, kā tos pārbaudīt un verificēt, un izplatītās kļūdas, kas salauž sūtīšanu.

Autors Mark Barkan

MX ieraksti (Mail eXchange records) ir DNS ieraksti, kas pasaka internetam, kur piegādāt mail dotajam domēnam. Tie ir pamati — bez pareiziem MX ierakstiem nekādu e-pastu nevar piegādāt jūsu domēnam vispār — bet lielākā daļa cold email komandu izturas pret tiem kā pret kaut ko, ko IT iestatīja vienreiz un nekad nepaskatās atkal. Tas parasti ir labi, līdz dienai, kad MX ieraksti kļūst par iemeslu, kāpēc jūsu kampaņas klusi neizdodas. Šis raksts — ko MX ieraksti dara, kāpēc tie ir svarīgi cold email sūtītājiem konkrēti, kā tos pārbaudīt un kļūdas, kas salauž sūtīšanu. Pāris ar e-pasta piegādes ceļvedi un Google Workspace MX iestatīšanas ceļvedi.

MX ieraksts ir DNS ieraksts, kas uzskaita mail serverus, kas atbildīgi par e-pasta saņemšanu domēna vārdā. Katram MX ierakstam ir prioritātes vērtība (zemāka = priekšroka) un servera hostname. Kad kāds sūta mail uz you@yourdomain.com, viņu serveris vaicā DNS pēc jūsu domēna MX ierakstiem un piegādā uz augstākās-prioritātes serveri, kas atbild.

Ko MX ieraksti dara praksē

Katram domēnam, kas saņem e-pastu, jābūt vismaz vienam MX ierakstam. Ieraksta formāts izskatās šādi:

yourdomain.com.  IN  MX  10  smtp.google.com.
yourdomain.com.  IN  MX  20  smtp2.google.com.

Tas saka: “Mail yourdomain.com jāiet uz smtp.google.com pirmo (prioritāte 10), un, ja tas nav sasniedzams, mēģiniet smtp2.google.com (prioritāte 20)”.

Prioritātes skaitļi rada fallback ķēdi. Zemāki skaitļi tiek mēģināti pirmie. Vairāki MX ieraksti ar to pašu prioritāti sadala slodzi cauri serveriem — sūtīšanas sistēmas izvēlas vienu nejauši.

Cold email sūtītājiem konkrēti MX ieraksti svarīgi trīs veidos:

Atbilžu saņemšana. Jūsu prospektu atbildēm jānokļūst jūsu iesūtnē. Ja jūsu MX ieraksti ir nepareizi konfigurēti, atbildes bouncē. Jūs to uzreiz nepamanīsiet, jo bounce iet pie prospekta, ne pie jums — viņi vienkārši pārstāj jums atbildēt, un jūs domājat, ka viņi ignorēja atbildi.

E-pasta verifikācija. Verifikācijas servisi pārbauda MX ierakstus, lai noteiktu, vai domēns vispār var saņemt mail. Domēni bez MX ierakstiem vai ar salauztiem MX ierakstiem tiek flagoti kā nepiegādājami, neatkarīgi no konkrētās adreses.

Reputācijas signāls. Saņemošās sistēmas izmanto MX konfigurāciju kā vienu signālu domēna leģitimitātes novērtējumā. Domēns bez MX ierakstiem, bet ar augstu izejošo apjomu, izskatās aizdomīgs — leģitīmiem domēniem ir pareiza saņemšanas infrastruktūra.

Kā pārbaudīt MX ierakstus

Vienkāršākais veids pārbaudīt MX ierakstus ir dig komanda:

dig +short MX yourdomain.com

Tas atgriež domēna MX ierakstus. Online rīki kā MXToolbox, DNSChecker vai What’s My DNS sniedz to pašu informāciju pārlūka saskarnē, plus papildu diagnostiku.

Ko verificēt, pārbaudot:

  • Eksistē vismaz viens MX ieraksts. Nav MX ierakstu = nav e-pasta saņemšanas.
  • MX hostname atrisina uz faktiskiem mail serveriem. Katram hostname jābūt A vai AAAA ierakstam, kas norāda uz reālu IP.
  • Prioritātes ir saprātīgas. Produkcijas setup tipiski ir primary (zems prioritātes skaitlis) plus 1–3 backups (augstākas prioritātes).
  • Mail serveri faktiski pieņem savienojumus uz porta 25. Savienošanās caur telnet mailserver.com 25 vai izmantojot rīku kā Email Tester apstiprina, ka serveris atbild.
  • PTR ieraksti eksistē mail servera IP. Saņemošās sistēmas pārbauda, vai MX hostname ir atbilstošs reverse DNS ieraksts.

Tipiskas MX ieraksta kļūdas

Nav MX ierakstu vispār. Domēni bez MX ierakstiem nevar saņemt e-pastu. Dažas komandas iestata sūtīšanu, nekonfigurējot saņemšanu, pieņemot “mums nav vajadzīga saņemšana”. Bet cold email vajag saņemšanu — atbildēm jāatrod kāda vieta.

MX ieraksti, kas norāda uz neeksistējošiem serveriem. Atstāts MX ieraksts, kas norāda uz vecu mail piegādātāju (pēc migrācijas), rada piegādes mēģinājumu neveiksmes. Produkcijas komandas audit MX ierakstus pēc katras infrastruktūras izmaiņas.

Prioritātes kārtība nepareizi konfigurēta. Kad primary MX ir augsta prioritāte (augsts skaitlis) un backup ir zema prioritāte, sūtīšanas sistēmas dod priekšroku nepareizajam serverim. Tas parasti nesalauž piegādi, bet ražo neparastu maršrutēšanu.

Dublētie MX ieraksti tajā pašā prioritātē. Dažas DNS konfigurācijas beidzas ar dublētiem ierakstiem — dublēts neizraisa kļūdu, bet var mulsināt slodzes sadali.

Subdomain MX ieraksti trūkst. Ja sūtāt no outreach.yourdomain.com, subdomain vajag savus MX ierakstus (vai mantot no parent — verificējiet pēc jūsu DNS piegādātāja uzvedības). Aizmiršana par subdomain MX ierakstiem nozīmē, ka atbildes uz subdomain adresēm neizdodas.

MX ieraksti ar CNAME aliases. RFC saka, ka MX ierakstiem jānorāda uz A/AAAA ierakstiem, ne CNAMEs. Daži DNS piegādātāji to atļauj, bet saņemošās sistēmas var noraidīt konfigurāciju. Vienmēr norādiet MX ierakstus uz hostname ar tiešiem A ierakstiem.

Kad atjaunināt MX ierakstus

Atjaunot MX ierakstus, kad:

  • Migrējat e-pasta piegādātājus (piem., no Gmail uz Office 365 vai pretēji). Migrācijas piegādātājs dos jums jaunās MX vērtības; atjauniniet DNS un gaidiet izplatīšanos.
  • Pievienojat jaunu subdomain sūtīšanai. Jaunajiem subdomains vajag savus MX ierakstus, ja tie saņems mail.
  • Pievienojat trešās puses mail filtrēšanas servisu (Mimecast, Proofpoint, Barracuda) — tie kļūst par primary MX ar apakšā esošo mail piegādātāju kā backup.
  • Pārslēdzaties uz jaunu transakcionālu e-pasta piegādātāju — parasti neprasa MX izmaiņas (transakcionālie piegādātāji ir tikai sūtīšana), bet verificējiet pret piegādātāja dokumentāciju.

Neatjaunot MX ierakstus:

  • Cold email rīkiem kā Smartlead, Lemlist, Apollo — tie ir sūtīšanas platformas, ne saņemšanas. Tām nav vajadzīgi MX ieraksti.
  • Lai “uzlabotu piegādi” bez konkrēta iemesla — MX ieraksti ietekmē saņemšanu, ne sūtīšanas placement.

Paterns: MX ieraksti ir pamati, vienkārši un bieži tiek aizmirsti. To pareiza iestatīšana ir 5 minūšu uzdevums; to nepareiza konfigurēšana ražo klusas neveiksmes, kas var darboties nedēļas, pirms kāds pamana. Produkcijas komandas verificē MX konfigurāciju kā daļu no katra domēna audita un jebkuras infrastruktūras izmaiņas.

Saistītie raksti