8 modulis · 8.3
Dažniausiai pasitaikančios klaidos
8 modulis: Perkėlimas ir Jūsų domeno sutvarkymas · Skaitymo trukmė: 13 min.
Mokymosi tikslas: Po šios pamokos galėsite atpažinti dvylika dažniausiai pasitaikančių el. pašto klaidų pagal jų požymius, 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, perpildyta pašto dėžutė, pamirštas MX perkėlimo metu, POP3 keliuose įrenginiuose
Kaip naudotis šia pamoka
Kiekviena klaida aprašyta pagal tą pačią struktūrą: ką matote (požymis, kaip jį nurodo klientas), kodėl taip atsitinka ir kaip tai išspręsti. Dažnai požymiai panašūs ("mano laiškai nepasiekia adresato"), nors priežastis visai kitokia. Todėl prie kiekvienos klaidos taip pat nurodyta, kaip ją patvirtinti: kokių įrodymų ieškoti prieš ką nors keičiant. Nespėliokite, pirmiausia išmatuokite (3.6 pamoka, neteisingas numeris pataisytas į 6.3 pamoka).
Šiuos numerius naudosite užduotyje.
Klaidos DNS įrašuose
1 klaida: du SPF įrašai.
Matote: laiškai į Gmail ir Outlook.com staiga patenka į šlamštą nuo tada, kai prijungėte naują paslaugą (Microsoft 365, naujienlaiškį, buhalterinę programą). Antraštėse 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 visiškai nebegalioja.
Patvirtinkite: peržiūrėkite savo domeno TXT įrašus ir suskaičiuokite v=spf1 įrašus.
Sprendimas: sujunkite viską į vieną įrašą (4.2 pamoka).
2 klaida: daugiau nei dešimt SPF paieškų.
Matote: tą patį, spf=permerror, bet 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 viduje pačių include'ų. Viršijus dešimt, SPF tampa negaliojantis.
Patvirtinkite: paleiskite SPF patikrą, kuri 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 savo atskirą bounce poddomeną (7.1 pamoka).
3 klaida: DMARC iš karto nustatytas į p=reject.
Matote: nuo tada, kai nustatytas DMARC įrašas, sąskaitos iš buhalterinės programos ar laiškai iš svetainės nebepasiekia adresato. Gavėjai grąžina 550 5.7.1 su nuoroda į DMARC.
Kodėl: ne visi siuntėjai buvo įvertinti iš anksto. Viskas, kas neatitinka suderinto (aligned) SPF ar DKIM, dabar atmetama.
Patvirtinkite: DMARC įrašą ir ataskaitas (4.5 pamoka): kurie šaltiniai neatitinka reikalavimų?
Sprendimas: grįžkite prie p=none su ataskaitų adresu, ištaisykite visus siuntėjus, tada žingsnis po žingsnio pereikite prie quarantine ir reject (4.4 pamoka). Tai ir yra šio kurso rekomenduojama tvarka.
4 klaida: DKIM nenustatytas siuntimo paslaugoje.
Matote: naujienlaiškiai vis dažniau nepasiekia gavėjų pašto dėžutės. Antraštėse: dkim=pass header.d= paslaugos domenas, dmarc=fail.
Kodėl: paslauga pasirašo savo pačios domenu, todėl DMARC negali būti patvirtintas per DKIM, o SPF taip pat nėra suderintas.
Patvirtinkite: testinio naujienlaiškio antraštes (užduotis Z7.1).
Sprendimas: autentifikuokite savo domeną paslaugoje (DKIM per CNAME, 7.1 pamoka).
Klaidos, susijusios su peradresavimu ir adresais
5 klaida: visko peradresavimas į Gmail.
Matote: laiškai nuo kai kurių siuntėjų nepasiekia Gmail adreso, į kurį nukreipiate verslo paštą, arba patenka į šlamštą. Kartais siuntėjai gauna atmestą laišką (bounce) iš Gmail.
Kodėl: peradresuojant, laiškas į Gmail atkeliauja iš Jūsų serverio, kurio nėra originalaus siuntėjo SPF įraše. Be DKIM arba jei siuntėjas turi p=reject, DMARC neatitinka reikalavimų. Be to, Gmail peradresuotą šlamštą laiko šlamštu, kurį siunčiate Jūs, o tai kenkia Jūsų reputacijai.
Patvirtinkite: atmestą laišką (bounce) arba antraštes Gmail sistemoje (spf=fail arba softfail, kai šaltinis yra Jūsų serveris).
Sprendimas: nenaudokite peradresavimo, o pridėkite pašto dėžutę telefono Gmail programėlėje per IMAP (2.4 ir 3.3 pamokos).
6 klaida: catch-all.
Matote: daug šlamšto adresais, kurie niekada neegzistavo (xyz123@example.com), ir perpildytą pašto dėžutę.
Kodėl: catch-all priima laiškus bet kokiam įsivaizduojamam adresui. Šlamšto siuntėjai bando atsitiktinius adresus, ir jie visi pasiekia dėžutę. Jei dar peradresuojate catch-all į išorę, gaunasi 5 klaida padidintu mastu.
Patvirtinkite: pašto dėžutėje patikrinkite, kuriais gavėjų adresais buvo siunčiamas šlamštas.
Sprendimas: išjunkite catch-all ir kiekvienam realiai naudojamam adresui sukurkite aliasą arba pašto dėžutę (3.3 pamoka).
7 klaida: lankytojo adresas kaip siuntėjas formoje.
Matote: pranešimai per kontaktų formą kartais pasiekia adresatą, kartais ne, ypač nuo lankytojų, kurių adresas yra pas didelį paslaugų teikėją.
Kodėl: Jūsų svetainė siunčia laišką "vardu" lankytojo domeno. Jei tas domenas turi p=reject arba p=quarantine, gavėjas atmeta arba filtruoja laišką (7.3 pamoka).
Patvirtinkite: patikrinkite, kokį From adresą naudoja forma.
Sprendimas: From lauke naudokite savo adresą, o lankytojo adresą įrašykite Reply-To lauke.
Klaidos nustatant paskyrą
8 klaida: išsiunčiamasis serveris be autentifikavimo.
Matote: gauti laiškus pavyksta, siųsti ne. Pranešimas skelbia "relay access denied", "authentication required" arba 550 5.7.1. iPhone įrenginyje dažnai: laukai prie išsiunčiamojo serverio palikti tušti ("neprivalomi").
Kodėl: išsiunčiamasis serveris persiunčia laiškus tik tiems, kurie prisijungia. Kitaip bet kas galėtų jį naudoti kaip šlamšto siuntimo kanalą.
Patvirtinkite: išsiunčiamojo serverio nustatymus pašto programoje.
Sprendimas: įjunkite autentifikavimą, naudodami visą el. pašto adresą ir slaptažodį, 587 prievadą su STARTTLS arba 465 prievadą su SSL/TLS (1.4 ir 2.3 pamokos).
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 ir nukreipia į serverį, bet sertifikate jo nėra. 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 serverio pavadinimą, kurį nurodo paslaugų teikėjas, ir niekada tiesiog nespauskite "vis tiek tęsti" (2.1 pamoka).
10 klaida: perpildyta pašto dėžutė.
Matote: siuntėjai gauna atmestą laišką (bounce) su 452 4.2.2 arba 552 5.2.2 (pašto dėžutė pilna). Jūs nieko nepastebite, arba tik tai, kad nebeateina nauji laiškai.
Kodėl: pašto dėžutė pasiekė savo kvotą. Dažnai dėl metų metais kaupiamų priedų, arba dėl aplankų Išsiųsta ir Šiukšliadėžė, kurie niekada neištuštinami.
Patvirtinkite: pašto dėžutės naudojimą valdymo skydelyje arba žiniatinklio pašte.
Sprendimas: susitvarkykite, archyvuokite arba padidinkite kvotą (3.2 pamoka).
Klaidos perkeliant
11 klaida: pamirštas MX perkeliant.
Matote: perkėlus svetainę arba domeną, laiškai nebepasiekia adresato, arba jie pasiekia vietą, kurios niekas netikrina. Arba atvirkščiai: perkėlėte paštą pas naują paslaugų teikėją, bet MX vis dar nukreipia į senąjį.
Kodėl: keičiant vardų serverius, visa zona keliaujama kartu. Jei pašto paslaugų teikėjo MX įrašų nėra naujoje zonoje, Jūsų laiškai nukreipiami į 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 yra aktyvi, o tada dar kartą nukopijuokite paštą (8.2 pamoka).
12 klaida: POP3 keliuose įrenginiuose.
Matote: laiškai yra nešiojamajame kompiuteryje, bet ne telefone, arba atvirkščiai. Pakeitus nešiojamąjį kompiuterį, dingsta metų metais kaupti laiškai.
Kodėl: POP3 atsisiunčia laiškus iš serverio į vieną įrenginį ir dažnai juos ten ištrina (1.3 pamoka).
Patvirtinkite: paskyros tipą pašto programoje.
Sprendimas: pereikite prie IMAP; laiškus, kurie yra tik vietinėje saugykloje, pirmiausia nutempkite į IMAP pašto dėžutę.
Kas bendro tarp šių klaidų
Dar kartą peržvelkite sąrašą. Beveik kiekviena klaida atsiranda, kai kažkas vykdo atskirą nurodymą ("pridėkite šį įrašą", "įjunkite peradresavimą"), nematydamas viso vaizdo. Pagrindinė šio kurso mintis:
- žinokite, kas siunčia laiškus Jūsų domeno vardu (inventorizacija, 4.2 ir 8.1 pamokos);
- keiskite po vieną dalyką ir po to patikrinkite;
- skaitykite įrodymus: atmestą laišką (bounce, 6.1 pamoka), antraštes (1.5 pamoka), DMARC ataskaitą (4.5 pamoka) ir DNS įrašus autoritetingame serveryje.
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.
- Nustatymų klaidos: nėra autentifikavimo išsiuntimui, serverio pavadinimas, kurio nėra sertifikate, perpildyta pašto dėžutė.
- Perkėlimo klaidos: pamirštas MX, POP3 keliuose įrenginiuose.
- Prieš ką nors keičiant, visada patvirtinkite priežastį įrodymais.
Testas
Užduotis
Užduotis Z8.3: Kokia tai klaida? Gausite aštuonis trumpus atvejus, kiekvieną su požymiu ir įrodymo fragmentu (antrašte, atmestu laišku (bounce), DNS atsakymu arba nustatymu). Kiekvienam atvejui pasirinkite klaidos numerį (nuo 1 iki 12). Programa patikrina pagal fiksuotą raktą ir, jei atsakymas neteisingas, parodo, kokį įrodymą praleidote.
Skaitykite daugiau
Šiuose straipsniuose aprašyti žingsniai galioja WebOké valdymo skydeliuose; kitų paslaugų teikėjų atveju 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škų (gavimas veikia)
- El. laiškų persiuntimas į kitą adresą (persiuntimo adresai, catch-all nerekomenduojama)
- Nemokamas DNS kursas 8.4: Dažniausiai pasitaikančios klaidos
- Outlook su Jūsų el. pašto adresu 5.2: Outlook nuolat prašo slaptažodžio arba nepavyksta išsiųsti laiškų
