Greșeli frecvente

Modulul 8: Mutarea și organizarea domeniului dvs. · Timp de citire: 13 minute

Obiectivul lecției: După această lecție veți putea recunoaște cele douăsprezece greșeli frecvente cu e-mailul după simptomele lor, veți putea explica de ce apar și le veți putea rezolva.

Noțiuni-cheie: înregistrare SPF dublă, prea multe căutări SPF, DMARC prea devreme pe reject, DKIM neactivat la un serviciu de trimitere, redirecționare către Gmail, catch-all, vizitatorul ca expeditor, server de ieșire fără autentificare, nume de server mail. fără certificat, căsuță poștală plină, MX uitat la o mutare, POP3 pe mai multe dispozitive

Cum folosiți această lecție

Fiecare greșeală are aceeași structură: ce vedeți (simptomul, așa cum îl raportează un client), de ce apare și cum o rezolvați. Adesea simptomele seamănă între ele ("e-mailul meu nu ajunge"), în timp ce cauza este cu totul diferită. De aceea, la fiecare greșeală se precizează și cum o confirmați: ce dovadă căutați înainte de a schimba ceva. Nu ghiciți, măsurați întâi (lecția 6.3).

Numerele le veți folosi în exercițiu.

Greșeli în DNS

Greșeala 1: două înregistrări SPF.
Vedeți: e-mailurile către Gmail și Outlook.com ajung brusc în spam, de când ați conectat un serviciu nou (Microsoft 365, un newsletter, un pachet de contabilitate). În antete apare spf=permerror.
De ce: serviciul v-a spus "adăugați această înregistrare SPF", iar acum există două înregistrări TXT care încep cu v=spf1. Conform RFC 7208, aceasta este o eroare permanentă: SPF nu mai contează deloc.
Confirmați: căutați înregistrările TXT ale domeniului dumneavoastră și numărați înregistrările v=spf1.
Soluție: combinați totul într-o singură înregistrare (lecția 4.2).

Greșeala 2: mai mult de zece căutări SPF.
Vedeți: același lucru, spf=permerror, dar există o singură înregistrare. Adesea după adăugarea celui de-al câta-lea include.
De ce: fiecare include, a, mx, exists și redirect costă o căutare DNS, inclusiv în interiorul includerilor. Peste zece, SPF devine invalid.
Confirmați: lăsați un verificator SPF să numere recursiv (exercițiul Z4.2).
Soluție: eliminați serviciile pe care nu le mai folosiți, înlocuiți a și mx cu ip4/ip6 dacă acestea sunt fixe, sau lăsați un serviciu să trimită printr-un subdomeniu propriu pentru bounce (lecția 7.1).

Greșeala 3: DMARC pus imediat pe p=reject.
Vedeți: de când a fost setată o înregistrare DMARC, facturile din pachetul de contabilitate sau e-mailurile de pe site nu mai ajung. Destinatarii returnează 550 5.7.1 cu o referință la DMARC.
De ce: nu toți expeditorii au fost identificați. Tot ce nu trece prin SPF sau DKIM aliniat este acum respins.
Confirmați: înregistrarea DMARC și rapoartele (lecția 4.5): ce surse eșuează?
Soluție: reveniți la p=none cu o adresă de raportare, reparați toți expeditorii, apoi treceți pas cu pas la quarantine și reject (lecția 4.4). Aceasta este și linia de recomandare a acestui curs.

Greșeala 4: DKIM neconfigurat la serviciul de trimitere.
Vedeți: newsletterele nu mai ajung în Inbox la tot mai mulți destinatari. În antete: dkim=pass header.d= domeniul serviciului, dmarc=fail.
De ce: serviciul semnează cu propriul domeniu, deci DMARC nu poate reuși prin DKIM, iar SPF nu este nici el aliniat.
Confirmați: antetele unui newsletter de test (exercițiul Z7.1).
Soluție: autentificați-vă domeniul la serviciu (DKIM prin CNAME, lecția 7.1).

Greșeli legate de redirecționare și adrese

Greșeala 5: redirecționarea totală către Gmail.
Vedeți: e-mailurile de la anumiți expeditori nu ajung la adresa Gmail către care trimiteți e-mailul dumneavoastră de afaceri, sau ajung în spam. Uneori expeditorii primesc un bounce de la Gmail.
De ce: la redirecționare, e-mailul ajunge la Gmail de pe serverul dumneavoastră, care nu figurează în SPF-ul expeditorului original. Fără DKIM sau cu un expeditor cu p=reject, DMARC eșuează. În plus, spamul redirecționat pare pentru Gmail spam trimis chiar de dumneavoastră, ceea ce vă afectează reputația.
Confirmați: bounce-ul sau antetele la Gmail (spf=fail sau softfail cu serverul dumneavoastră ca sursă).
Soluție: nu redirecționați, ci adăugați căsuța poștală în aplicația Gmail de pe telefon prin IMAP (lecțiile 2.4 și 3.3).

Greșeala 6: un catch-all.
Vedeți: mult spam pe adrese care nu au existat niciodată (xyz123@example.com), și o căsuță poștală plină.
De ce: un catch-all acceptă e-mailuri pentru orice adresă imaginabilă. Spammerii încearcă adrese aleatorii, iar acestea ajung toate. Dacă mai și redirecționați catch-all-ul în exterior, devine greșeala 5 în mare.
Confirmați: verificați în căsuța poștală către ce adrese de destinatar mergea spamul.
Soluție: dezactivați catch-all-ul și creați un alias sau o căsuță poștală pentru fiecare adresă folosită efectiv (lecția 3.3).

Greșeala 7: adresa vizitatorului ca expeditor într-un formular.
Vedeți: mesajele prin formularul de contact ajung uneori, alteori nu, mai ales nu de la vizitatori cu o adresă la un furnizor mare.
De ce: site-ul dumneavoastră trimite "în numele" domeniului vizitatorului. Dacă acel domeniu are p=reject sau p=quarantine, destinatarul respinge sau filtrează e-mailul (lecția 7.3).
Confirmați: verificați ce From folosește formularul.
Soluție: adresa dumneavoastră proprie în From, vizitatorul în Reply-To.

Greșeli la configurare

Greșeala 8: server de ieșire fără autentificare.
Vedeți: primirea funcționează, trimiterea nu. Mesaje precum "relay access denied", "authentication required" sau 550 5.7.1. Pe iPhone, frecvent: câmpurile de la serverul de ieșire lăsate goale ("opțional").
De ce: un server de ieșire trimite mai departe e-mailuri doar pentru cine se autentifică. Altfel oricine l-ar putea folosi drept tun de spam.
Confirmați: setările serverului de ieșire din programul de e-mail.
Soluție: activați autentificarea, cu adresa de e-mail completă și parola, port 587 cu STARTTLS sau 465 cu SSL/TLS (lecțiile 1.4 și 2.3).

Greșeala 9: mail.<domeniu> ca nume de server fără certificatul potrivit.
Vedeți: un mesaj despre un certificat nevalid sau "nu se poate verifica identitatea serverului", sau conexiunea nu reușește deloc.
De ce: programul verifică dacă numele serverului figurează în certificat. mail.example.com ar putea să indice către server, dar nu figurează în certificat. Sau numele mai indică, după o mutare, încă spre vechiul furnizor.
Confirmați: verificați porturile de e-mail cu numele serverului (exercițiile Z2.1 și Z8.4).
Soluție: folosiți numele de server indicat de furnizor și nu faceți clic pur și simplu pe "continuă oricum" (lecția 2.1).

Greșeala 10: o căsuță poștală plină.
Vedeți: expeditorii primesc un bounce cu 452 4.2.2 sau 552 5.2.2 (mailbox vol, căsuță plină). Dumneavoastră nu observați nimic, sau doar că nu mai sosesc e-mailuri noi.
De ce: căsuța poștală și-a atins cota. Adesea din cauza anilor de atașamente acumulate, sau a unui folder Sent și Trash care nu se golesc niciodată.
Confirmați: utilizarea căsuței poștale din panou sau din webmail.
Soluție: faceți curățenie, arhivați sau măriți cota (lecția 3.2).

Greșeli la mutare

Greșeala 11: MX uitat la o mutare.
Vedeți: după mutarea site-ului sau a domeniului, nu mai sosesc e-mailuri, sau acestea ajung într-un loc pe care nimeni nu-l verifică. Sau invers: ați mutat e-mailul la un furnizor nou, dar MX încă indică spre cel vechi.
De ce: la o schimbare de nameserver, întreaga zonă se mută odată cu acestea. Dacă înregistrările MX ale furnizorului de e-mail nu se află în noua zonă, e-mailul dumneavoastră indică spre noul server web. Sau MX nu a fost niciodată actualizat.
Confirmați: interogați MX la nameserverul autoritativ (exercițiul Z8.2).
Soluție: introduceți înregistrările MX corecte în zona care este cu adevărat activă, apoi copiați e-mailul încă o dată (lecția 8.2).

Greșeala 12: POP3 pe mai multe dispozitive.
Vedeți: e-mailul se află pe laptop, dar nu pe telefon, sau invers. După înlocuirea laptopului, ani de e-mailuri au dispărut.
De ce: POP3 preia e-mailul de pe server pe un singur dispozitiv și adesea îl șterge de acolo (lecția 1.3).
Confirmați: tipul de cont din programul de e-mail.
Soluție: treceți la IMAP; mutați mai întâi, prin tragere, e-mailul care se află doar local, în căsuța poștală IMAP.

Ce au în comun aceste greșeli

Parcurgeți din nou lista. Aproape fiecare greșeală apare pentru că cineva a urmat o instrucțiune izolată ("adăugați această înregistrare", "activați redirecționarea") fără a vedea ansamblul. Firul roșu al acestui curs:

• aflați cine trimite e-mailuri în numele domeniului dumneavoastră (inventar, lecțiile 4.2 și 8.1);
• schimbați un singur lucru odată și verificați apoi;
• citiți dovada: bounce-ul (lecția 6.1), antetele (lecția 1.5), raportul DMARC (lecția 4.5) și DNS-ul de la serverul autoritativ.

Rezumat

• Greșeli DNS: două înregistrări SPF, prea multe căutări, DMARC prea devreme pe reject, DKIM neactivat la un serviciu de trimitere.
• Greșeli de adresă: redirecționare către Gmail, catch-all, adresa vizitatorului ca From.
• Greșeli de configurare: fără autentificare la ieșire, un nume de server care nu figurează în certificat, o căsuță poștală plină.
• Greșeli de mutare: MX uitat, POP3 pe mai multe dispozitive.
• Confirmați întotdeauna cauza cu dovezi înainte de a schimba ceva.

Quiz

Exercițiu

Exercițiu Z8.3: Care este greșeala? Primiți opt scurte cazuri, fiecare cu un simptom și o bucată de dovadă (un antet, un bounce, un răspuns DNS sau o setare). Alegeți pentru fiecare caz numărul greșelii (1 până la 12). Programul verifică folosind o cheie fixă și, în cazul unui răspuns greșit, vă arată ce dovadă ați trecut cu vederea.

Lectură suplimentară

Pașii din aceste articole sunt valabili pentru panourile WebOké; la alți furnizori funcționează similar.

• Manual DirectAdmin 18.9: Nu mai primesc e-mailuri
• Manual DirectAdmin 18.10: Nu pot trimite e-mailuri
• Nu mai primiți e-mailuri: iată cum identificați cauza
• Nu pot trimite e-mailuri (primirea funcționează)
• Redirecționarea e-mailurilor către o altă adresă (redirecționări, adresa catch-all nu este recomandată)
• Curs gratuit de DNS 8.4: Greșeli frecvente