Kāpēc tavs e-pasts nonāk mēstulēs?

Īsā atbilde

Kad likumīgs e-pasts nonāk mēstulēs, tas gandrīz nekad nav nejaušība. Saņēmēju serveri, piemēram, Gmail, Outlook un uzņēmumu filtri, katru vēstuli vērtē pēc trim jautājumiem: vai sūtītājs pierāda, kas viņš ir, vai sūtošajai IP ir tīra reputācija, un vai vēstule izskatās pēc pasta, ko cilvēki tiešām grib saņemt? Sakārto šos trīs, un problēma parasti pazūd. Tālāk ir aprakstīts, kā pārbaudīt katru no tiem, sākot ar biežāko cēloni.

1. E-pasta autentifikācija: SPF, DKIM un DMARC

Šis ir visbiežākais cēlonis. Kopš 2024. gada Gmail un Yahoo pieprasa autentifikāciju visiem, kas sūta lielos apjomos, un neautentificēts pasts tiek klusi pazemināts vai noraidīts. Tavam sūtīšanas domēnam vajag trīs DNS ierakstus.

SPF uzskaita serverus, kuriem atļauts sūtīt tava domēna vārdā. DKIM pievieno kriptogrāfisku parakstu, lai saņēmējs varētu pārliecināties, ka vēstule nav mainīta. DMARC savieno abus un pasaka saņēmējam, ko darīt, ja pārbaude neizdodas.

Pārbaudi, ko tu pašlaik publicē:

dig +short TXT example.com
dig +short TXT default._domainkey.example.com
dig +short TXT _dmarc.example.com

Veselīgi ieraksti parasti izskatās šādi:

SPF:   v=spf1 mx include:_spf.tavsserviss.com -all
DMARC: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=s; aspf=s

Sāc DMARC ar p=none, lai savāktu atskaites, tad pārej uz quarantine un beigās reject, kad SPF un DKIM stabili iztur pārbaudi. Ja DKIM neko neatgriež, selektora nosaukums ir nepareizs vai tavs pasta serveris vispār neparakstās; pārbaudi, kādu selektoru izmanto tavs pakalpojumu sniedzējs.

2. Reversais DNS (PTR) un HELO nosaukums

Ja tu darbini savu pasta serveri, sūtošajai IP vajag derīgu PTR ierakstu, kas atved atpakaļ pie reāla resursdatora nosaukuma, un šim nosaukumam jāsakrīt ar to, ko serveris paziņo savā HELO/EHLO sveicienā. Nesakritība vai iztrūkstošs PTR ir tūlītējs trieciens reputācijai.

dig -x 203.0.113.10 +short

Rezultātam jābūt kaut kam līdzīgam mail.example.com, un šī nosaukuma tiešā uzmeklēšana atgriež to pašu IP. PTR ierakstus iestata IP bloka īpašnieks, tāpēc, ja tas ir tukšs, palūdz savam hostinga sniedzējam to pievienot.

3. IP un domēna reputācija, un melnie saraksti

Pavisam jaunam domēnam vai IP nav vēstures, tāpēc filtri pret to izturas aizdomīgi. Nekad nesūti masveida pastu no svaigas IP jau pirmajā dienā; palielini apjomu pakāpeniski dažu nedēļu laikā. Pārliecinies arī, ka neesi kādā melnajā sarakstā, piemēram, Spamhaus. Sūtīšana no mājas vai dinamiskas IP adreses gandrīz vienmēr tiks bloķēta, tāpēc pastam jāiet caur pienācīgu serveri ar statisku IP un tīru rDNS.

Ātra reputācijas pārbaude: nosūti vēstuli testa rīkam, piemēram, mail-tester.com, lai saņemtu novērtējumu, un pieteic savu domēnu Google Postmaster Tools, lai laika gaitā sekotu mēstuļu līmenim un autentifikācijai. Uzturi sūdzību līmeni zem 0,3 procentiem.

4. Saturs un sūtīšanas ieradumi

• Sūti pa šifrētu savienojumu (STARTTLS/TLS). Nešifrēts pasts tiek sodīts.
• Jaunumu vēstulēm un paziņojumiem pievieno strādājošu List-Unsubscribe galveni ar viena klikšķa atteikšanos.
• Izvairies no vēstulēm, kas sastāv tikai no attēliem, no saišu saīsinātājiem, maldinošiem tematiem un TEKSTA VISIEM LIELAJIEM BURTIEM.
• From adresei jāsakrīt ar sūtīšanas domēnu, un tīri saraksti, izņemot atlēkušos un neaktīvos adresātus.
• Izmanto vienu konsekventu sūtīšanas domēnu, nevis lēkā starp daudziem.

Ātrs diagnostikas saraksts

1. Palaid trīs dig komandas augšā. SPF, DKIM un DMARC jābūt klāt un jāiztur pārbaude.
2. Pārbaudi PTR ar dig -x un apstiprini, ka HELO sakrīt.
3. Nosūti vienu vēstuli mail-tester.com un izlabo visu, kas novērtēts zem 10.
4. Pārliecinies, ka IP nav melnajā sarakstā.
5. Apstiprini, ka TLS ir aktīvs un masveida pastam ir atteikšanās galvene.

Secinājums

Deviņdesmit procenti mēstuļu mapes problēmu ir autentifikācija un reputācija, nevis saturs. Publicē pareizus SPF, DKIM un DMARC ierakstus, dod sūtošajai IP atbilstošu PTR un tīru vēsturi, sūti pa TLS un seko savam mēstuļu līmenim. Sakārto šo, un tavs e-pasts nonāks iesūtnē, kur tam jābūt.