Satura rādītājs
„Klientas sako, kad atsiuntė el. laišką, bet mes jo negavome.” „Mūsų pasiūlymai patenka į gavėjo šlamšto aplanką.” Tai du dažniausi Google Workspace naudotojų klausimai apie el. paštą, ir abiem atvejais kaltininkas paprastai ne Gmail, o DNS įrašai, kurie taip ir liko nesutvarkyti iki galo.
Trys įrašai, kurie lemia viską
Kad jūsų domeno laiškai būtų laikomi tikrais, gavėjo serveris turi galėti patikrinti tris dalykus:
- SPF nustato, kurie serveriai gali siųsti laiškus jūsų domeno vardu. Tai vienas TXT įrašas, kuriame turi būti
include:_spf.google.comir visi kiti siuntėjai, naudojantys jūsų domeną: CRM, sąskaitų sistema, naujienlaiškių siuntimo paslauga, svetainės formos. Svarbu: domenas gali turėti tik vieną SPF įrašą. Du SPF įrašai yra taip pat blogai, kaip nė vieno. - DKIM yra kriptografinis parašas, įrodantis, kad laiškas nebuvo pakeistas kelyje. Jei savo rakto nėra, Google pasirašo numatytuoju raktu, kuris nesusietas su jūsų domenu ir DMARC patikroje nieko neduoda. Administratoriaus pulte (Admin console) patikrinkite (Apps → Google Workspace → Gmail → Authenticate email), ar jūsų domenas turi būseną Authenticating email; jei ne, sugeneruokite raktą ir pridėkite jį į DNS. Šis žingsnis praleidžiamas labai dažnai.
- DMARC nurodo, ką daryti su laiškais, kurie neišlaiko patikros. Pradėkite nuo
p=noneir ataskaitų adreso (rua=), kad matytumėte, kas siunčia jūsų vardu, ir tik tada pereikite priequarantinearbareject.
Kaip DMARC iš tikrųjų sprendžia: susiejimas su From adresu
DMARC patikra išlaikoma, jei bent viena iš patikrų, SPF arba DKIM, yra sėkminga ir jos domenas sutampa su domenu lauke From, kurį mato gavėjas. Tai vadinama susiejimu (alignment): SPF tikrina grąžinimo adresą (Return-Path), DKIM – parašo domeną (d=).
Pavyzdys. Naujienlaiškių paslauga siunčia iš info@imone.lt, bet grąžinimo adresas yra bounce@paslauga.com. SPF patikra išlaikoma, tačiau su imone.lt nesusieta, ir DMARC jos neįskaito. Laiškas išlaikys patikrą tik tada, jei paslauga jį pasirašys DKIM raktu, kuriame d=imone.lt. Todėl kiekvienam išoriniam siuntėjui reikia atskiro DKIM rakto jūsų domenui. Persiuntimas yra priešingas atvejis: SPF patikra neišlaikoma, nes laišką pristato svetimas serveris, bet DKIM parašas išlieka ir DMARC patikra išlaikoma.
Netikrinkite rezultato vien diagnostikos įrankiais
Google Admin Toolbox ir panašūs įrankiai kartais rodo įspėjimus ir tada, kai viskas tvarkoje, ir atvirkščiai. Patikimesnis testas: išsiųskite laišką iš savo domeno į paskyrą kitoje paslaugoje ir pažiūrėkite jo šaltinį (Gmail: Show original). Eilutėje Authentication-Results lemiamas yra dmarc=pass: jei SPF rodo fail, bet DKIM patikra išlaikyta ir susieta, laiškas tvarkoje. Jei DMARC rodo fail, žiūrėkite, kuri patikra neišlaikoma ir kodėl: nesutampa domenas, SPF įraše trūksta siuntėjo arba neįjungtas DKIM.
Vienas testas parodo vieną sistemą vienu momentu: pakartokite jį iš kiekvienos sistemos, kuri siunčia jūsų vardu. Be to, autentifikavimas yra būtina sąlyga, o ne pristatymo garantija: gavėjas vertina ir domeno reputaciją, siuntimo apimtį, turinį ir savo politiką.
Gaunamas paštas, kuris niekada neateina
Jei konkretaus siuntėjo laiškai dingsta visiškai ir nepatenka net į šlamšto aplanką, jūsų pačių SPF ir DKIM su tuo nesusiję: jie taikomi jūsų siunčiamiems laiškams. Pradėkite nuo Administratoriaus pulto skilties Email Log Search: ten matyti, ar laiškas apskritai pasiekė Google ir kas su juo nutiko. Jei nepasiekė, paprašykite siuntėjo viso grąžinto laiško pranešimo: jame nurodyta, kuris serveris laišką atmetė ir kodėl. Dažniausios priežastys:
- Kontaktų formos jūsų svetainėje, kurios siunčia laiškus su kliento adresu kaip siuntėju. Google tai laiko klastojimu. Sprendimas: forma turi siųsti iš jūsų domeno adreso, o kliento adresas turi būti įrašytas lauke Reply-To.
- Paties siuntėjo SPF arba DKIM neišlaiko patikros. Problema yra jo pusėje, ir ją parodo grąžinto laiško pranešimas.
- Per griežtos Compliance arba Content taisyklės Administratoriaus pulte, kurios kadaise buvo nustatytos ir pamirštos.
- Senas MX įrašas, kuris vis dar nukreipia į ankstesnį pašto serverį. Laiškai nukeliauja ten ir toliau nebepatenka.
Ir ne, Outlook nėra sprendimas
Kai paštas pradeda elgtis keistai, dažnai bandoma pereiti prie Outlook arba Apple Mail. Google Workspace sukurtas kaip žiniatinklio programa; per IMAP veikia mažiau funkcijų ir atsiranda naujų sinchronizavimo problemų. Jei pagrindinė priežastis yra DNS, pašto programos pakeitimas nieko neišspręs.
Susijusios paslaugos: DNS ir el. pašto autentifikavimas yra Google Workspace diegimo dalis. Jei pereinate iš Microsoft 365 ar kito serverio, žr. migraciją be prastovų.
Susiję straipsniai: Migracija iš Microsoft 365 į Google Workspace · Bendrinama pašto dėžutė Google Workspace
El. laiškai vis dar dingsta arba patenka į šlamštą? Peržiūrime paveiktą pašto srautą, visas sistemas, siunčiančias jūsų domeno vardu, ir SPF, DKIM bei DMARC įrašus, tada testuojame realius siuntimus. Registruotis nemokamam 30 minučių auditui arba skambinkite +371 22 30 50 90.
