Dažniausiai daromos klaidos

8 modulis: Perkėlimas ir domeno tvarkymas · Skaitymo trukmė: 13 min.

Mokymosi tikslas: Po šios pamokos galėsite atpažinti dvylika dažniausiai daromų e. pašto klaidų iš jų požymių, paaiškinti, kodėl jos atsiranda, ir jas ištaisyti.

Pagrindinės sąvokos: dvigubas SPF įrašas, per daug SPF paieškų, DMARC per anksti nustatytas į reject, DKIM neįjungtas siuntimo paslaugoje, peradresavimas į Gmail, catch-all, lankytojo adresas kaip siuntėjas, išsiunčiamasis serveris be autentifikavimo, mail. serverio pavadinimas be tinkamo sertifikato, pilna pašto dėžutė, pamirštas MX perkeliant, POP3 keliuose įrenginiuose

Kaip naudotis šia pamoka

Kiekviena klaida turi tą pačią struktūrą: ką matote (požymį, kaip jį praneša klientas), kodėl tai atsitinka ir kaip tai išspręsti. Dažnai požymiai panašūs ("mano laiškai nepasiekia adresato"), tačiau priežastis gali būti visai kitokia. Todėl prie kiekvienos klaidos nurodyta, kaip ją patvirtinti: kokių įrodymų ieškoti prieš ką nors keičiant. Nespėliokite, pirmiausia išmatuokite (pamoka 6.3).

Numerius naudosite užduotyje.

DNS klaidos

1 klaida: du SPF įrašai.
Matote: laiškai į Gmail ir Outlook.com ima patekti į šlamštą nuo tada, kai prijungėte naują paslaugą (Microsoft 365, naujienlaiškį, buhalterinę programą). Kopregeliuose yra spf=permerror.
Kodėl: paslauga nurodė "pridėkite šį SPF įrašą", ir dabar yra du TXT įrašai, prasidedantys v=spf1. Pagal RFC 7208 tai yra nuolatinė klaida: SPF tada visai nebeskaičiuojamas.
Patvirtinkite: peržiūrėkite domeno TXT įrašus ir suskaičiuokite v=spf1 įrašus.
Sprendimas: sujunkite viską į vieną įrašą (pamoka 4.2).

2 klaida: daugiau nei dešimt SPF paieškų.
Matote: tą patį spf=permerror, tačiau yra tik vienas įrašas. Dažnai tai nutinka pridėjus dar vieną include.
Kodėl: kiekvienas include, a, mx, exists ir redirect kainuoja po vieną DNS paiešką, taip pat ir pačių include'ų viduje. Viršijus dešimt, SPF tampa negaliojantis.
Patvirtinkite: paleiskite SPF tikrinimą, kuris skaičiuoja rekursyviai (užduotis Z4.2).
Sprendimas: pašalinkite nebenaudojamas paslaugas, pakeiskite a ir mx į ip4/ip6, jei adresai fiksuoti, arba leiskite paslaugai siųsti per atskirą bounce subdomeną (pamoka 7.1).

3 klaida: DMARC iš karto nustatytas į p=reject.
Matote: nuo tada, kai buvo nustatytas DMARC įrašas, nebepasiekia sąskaitos iš buhalterinės programos arba laiškai iš svetainės. Gavėjai grąžina 550 5.7.1 su nuoroda į DMARC.
Kodėl: ne visi siuntėjai buvo įvertinti. Tai, kas neatitinka suderinto (aligned) SPF ar DKIM, dabar atmetama.
Patvirtinkite: DMARC įrašą ir ataskaitas (pamoka 4.5): kurie šaltiniai neatitinka reikalavimų?
Sprendimas: grįžkite prie p=none su ataskaitų adresu, sutvarkykite visus siuntėjus, tada žingsnis po žingsnio pereikite prie quarantine ir reject (pamoka 4.4). Tai taip pat šio kurso rekomenduojama eiga.

4 klaida: DKIM nenustatytas siuntimo paslaugoje.
Matote: naujienlaiškiai vis dažniau nepasiekia gavėjų pašto dėžutės. Kopregeliuose: dkim=pass header.d= paslaugos domenas, dmarc=fail.
Kodėl: paslauga pasirašo savo pačios domenu, todėl DMARC negali būti sėkmingas per DKIM, o SPF taip pat nesuderintas.
Patvirtinkite: testinio naujienlaiškio kopregelius (užduotis Z7.1).
Sprendimas: autentifikuokite savo domeną paslaugoje (DKIM per CNAME, pamoka 7.1).

Peradresavimo ir adresų klaidos

5 klaida: visko peradresavimas į Gmail.
Matote: kai kurių siuntėjų laiškai nepasiekia Gmail adreso, į kurį persiunčiate verslo paštą, arba patenka į šlamštą. Kartais siuntėjai gauna grąžintą laišką (bounce) iš Gmail.
Kodėl: peradresavimo atveju laiškas į Gmail atkeliauja iš Jūsų serverio, kurio nėra originalaus siuntėjo SPF įraše. Be DKIM arba kai siuntėjas turi p=reject, DMARC patikrinimas nepavyksta. Be to, peradresuotas šlamštas Gmail atrodo kaip šlamštas, kurį siunčiate Jūs, o tai kenkia Jūsų reputacijai.
Patvirtinkite: grąžintą laišką arba kopregelius Gmail (spf=fail arba softfail, kai šaltinis yra Jūsų serveris).
Sprendimas: nepersiųsti, o pridėti pašto dėžutę Gmail programėlėje telefone per IMAP (pamokos 2.4 ir 3.3).

6 klaida: catch-all.
Matote: daug šlamšto adresais, kurie niekada neegzistavo (xyz123@example.com), ir pilna pašto dėžutė.
Kodėl: catch-all priima paštą bet kokiam įmanomam adresui. Šlamšto siuntėjai bando atsitiktinius adresus, ir visi jie pasiekia dėžutę. Jei dar ir peradresuojate catch-all į išorę, gaunasi 5 klaida, tik didesniu mastu.
Patvirtinkite: pažiūrėkite pašto dėžutėje, kokiems gavėjų adresams buvo siunčiamas šlamštas.
Sprendimas: išjunkite catch-all ir kiekvienam realiai naudojamam adresui sukurkite alias arba pašto dėžutę (pamoka 3.3).

7 klaida: lankytojo adresas kaip siuntėjas formoje.
Matote: pranešimai per kontaktų formą kartais pasiekia, kartais ne, ypač jei lankytojas naudoja didelio paslaugų teikėjo adresą.
Kodėl: Jūsų svetainė siunčia laišką "lankytojo domeno vardu". Jei tas domenas turi p=reject arba p=quarantine, gavėjas laišką atmeta arba filtruoja (pamoka 7.3).
Patvirtinkite: pažiūrėkite, kokį From laukelį naudoja forma.
Sprendimas: savo adresą naudokite From lauke, lankytojo adresą perkelkite į Reply-To.

Nustatymo klaidos

8 klaida: išsiunčiamasis serveris be autentifikavimo.
Matote: gaunamasis paštas veikia, siunčiamasis ne. Pranešimas, pavyzdžiui, "relay access denied", "authentication required" arba 550 5.7.1. „iPhone“ įrenginyje dažnai: laukai prie išsiunčiamojo serverio palikti tušti ("neprivaloma").
Kodėl: išsiunčiamasis serveris persiunčia paštą tik tiems, kurie prisijungia. Kitaip bet kas galėtų juo naudotis kaip šlamšto siuntimo kanalu.
Patvirtinkite: išsiunčiamojo serverio nustatymus pašto programoje.
Sprendimas: įjunkite autentifikavimą, naudojant visą e. pašto adresą ir slaptažodį, prievadas 587 su STARTTLS arba 465 su SSL/TLS (pamokos 1.4 ir 2.3).

9 klaida: mail.<domenas> kaip serverio pavadinimas be atitinkamo sertifikato.
Matote: pranešimą apie negaliojantį sertifikatą arba "nepavyko patikrinti serverio tapatybės", arba ryšys visai nepavyksta.
Kodėl: programa tikrina, ar serverio pavadinimas nurodytas sertifikate. mail.example.com galbūt nukreipia į serverį, bet nėra įtraukta į sertifikatą. Arba pavadinimas po perkėlimo vis dar nukreipia į senąjį paslaugų teikėją.
Patvirtinkite: patikrinkite pašto prievadus su serverio pavadinimu (užduotys Z2.1 ir Z8.4).
Sprendimas: naudokite tą serverio pavadinimą, kurį nurodo paslaugų teikėjas, ir niekada tiesiog nespauskite "vis tiek tęsti" (pamoka 2.1).

10 klaida: pilna pašto dėžutė.
Matote: siuntėjai gauna grąžintą laišką (bounce) su 452 4.2.2 arba 552 5.2.2 (mailbox full). Jūs nieko nepastebite, arba pastebite tik tai, kad nauji laiškai nebegaunami.
Kodėl: pašto dėžutė pasiekė savo kvotos ribą. Dažnai dėl metų metais kaupiamų priedų, arba dėl to, kad aplankai Išsiųsta ir Šiukšliadėžė niekada netuštinami.
Patvirtinkite: pašto dėžutės naudojimą valdymo skydelyje arba internetiniame pašte.
Sprendimas: susitvarkykite, archyvuokite arba padidinkite kvotą (pamoka 3.2).

Perkėlimo klaidos

11 klaida: pamirštas MX perkeliant.
Matote: perkėlus svetainę ar domeną, paštas nebegaunamas arba atkeliauja į vietą, kurios niekas netikrina. Arba atvirkščiai: perkėlėte paštą pas naują paslaugų teikėją, tačiau MX vis dar rodo į senąjį.
Kodėl: keičiant vardų serverius, perkeliama visa zona. Jei naujoje zonoje nėra pašto paslaugų teikėjo MX įrašų, Jūsų paštas nukreipiamas į naująjį žiniatinklio serverį. Arba MX niekada nebuvo pakeistas.
Patvirtinkite: užklauskite MX iš autoritetingo vardų serverio (užduotis Z8.2).
Sprendimas: nustatykite teisingus MX įrašus toje zonoje, kuri realiai aktyvi, ir tada dar kartą nukopijuokite paštą (pamoka 8.2).

12 klaida: POP3 keliuose įrenginiuose.
Matote: paštas yra nešiojamajame kompiuteryje, bet ne telefone, arba atvirkščiai. Pakeitus nešiojamąjį kompiuterį, dingsta metų metais kauptas paštas.
Kodėl: POP3 paimą paštą iš serverio į vieną įrenginį ir dažnai jį ten pašalina (pamoka 1.3).
Patvirtinkite: paskyros tipą pašto programoje.
Sprendimas: pereikite prie IMAP; paštą, kuris yra tik vietoje, pirmiausia nuvilkite į IMAP pašto dėžutę.

Kas bendra tarp šių klaidų

Dar kartą peržvelkite sąrašą. Beveik kiekviena klaida atsiranda dėl to, kad kažkas vykdė pavienę instrukciją ("pridėkite šį įrašą", "įjunkite peradresavimą"), nematydamas viso vaizdo. Šio kurso pagrindinė mintis:

• žinokite, kas siunčia paštą Jūsų domeno vardu (inventorius, pamokos 4.2 ir 8.1);
• keiskite po vieną dalyką ir po to patikrinkite;
• skaitykite įrodymus: grąžintą laišką (pamoka 6.1), kopregeles (pamoka 1.5), DMARC ataskaitą (pamoka 4.5) ir DNS iš autoritetingo serverio.

Santrauka

• DNS klaidos: du SPF įrašai, per daug paieškų, DMARC per anksti nustatytas į reject, DKIM neįjungtas siuntimo paslaugoje.
• Adresų klaidos: peradresavimas į Gmail, catch-all, lankytojo adresas kaip From.
• Nustatymo klaidos: neįjungtas išsiunčiamojo serverio autentifikavimas, serverio pavadinimas, kurio nėra sertifikate, pilna pašto dėžutė.
• Perkėlimo klaidos: pamirštas MX, POP3 keliuose įrenginiuose.
• Prieš ką nors keisdami, visada patvirtinkite priežastį įrodymais.

Testas

Užduotis

Užduotis Z8.3: Kokia tai klaida? Gausite aštuonis trumpus atvejus, kiekvienas su požymiu ir įrodymo fragmentu (kopregele, grąžintu laišku, DNS atsakymu ar nustatymu). Kiekvienam atvejui pasirinkite klaidos numerį (nuo 1 iki 12). Programa tikrina pagal fiksuotą raktą ir, jei atsakymas neteisingas, parodo, kokį įrodymą praleidote.

Skaitykite daugiau

Šiuose straipsniuose aprašyti žingsniai galioja WebOké valdymo skydeliams; pas kitus paslaugų teikėjus veikimo principas panašus.

• DirectAdmin vadovas 18.9: Negaunu daugiau el. laiškų
• DirectAdmin vadovas 18.10: Negaliu išsiųsti el. laiško
• Negaunate el. laiškų: kaip rasti priežastį
• Negaliu išsiųsti el. laiško (gavimas veikia)
• El. laiškų persiuntimas į kitą adresą (persiuntimo adresai, catch-all nerekomenduojama)
• Nemokamas DNS kursas 8.4: Dažniausiai pasitaikančios klaidos