Domeno konfigūravimas – kaip prijungti el. paštą prie savo domeno (MX įrašai)

Turite savo domeną – puiku. Turite hostingo paslaugą – dar geriau. Bet kai bandote prisijungti el. paštą prie savo domeno ir gaunate klaidą „nieko nerasta”, jausmas yra ne pats maloniausias. O dar blogiau – viskas atrodo sukonfigūruota teisingai, bet laiškai paprasčiausiai nepasiekia gavėjo. Jie neišsiunčiami, negrįžta atgal, tiesiog dingsta tarp serverių kaip į juodąją skylę.

Geros naujienos: tai nėra magija. Domeno konfigūravimas el. paštui yra logiškas, nors ir keliais žingsniais sudėtingesnis procesas, nei daugelis mano. Supratus, kaip veikia MX įrašai ir kokie dar DNS įrašai yra būtini, viskas tampa aišku. Šiame straipsnyje einame nuo paprasto prie sudėtingo – nuo to, kas yra MX įrašas, iki pilnos SPF, DKIM ir DMARC konfigūracijos, klaidų šalinimo ir praktinių patarimų. Nepriklausomai nuo to, ar naudojate Google Workspace, Microsoft 365, Zoho Mail ar savo hostingo teikėjo el. pašto paslaugą – principai tie patys.

---

Kas yra MX įrašas ir kodėl jis toks svarbus?

MX (Mail Exchange) įrašas yra DNS sistemos dalis, kuri nurodo, kuris el. pašto serveris yra atsakingas už jūsų domeno pašto pristatymą. Kai kas nors siunčia laišką adresu info@jusudomenas.lt, jo el. pašto serveris patikrina MX įrašus jūsų domeno DNS zonoje. Jei MX įrašas rodo į Google serverius – laiškas keliauja ten. Jei rodo į Microsoft – keliauja ten. Jei MX įrašo iš viso nėra – laiškas grįžta siuntėjui su klaida „domenas neturi pašto服务器”.

MX įrašai turi du esminius parametrus: prioritetą ir serverio adresą. Pavyzdžiui:

Prioritetas	Serveris
1	ASPMX.L.GOOGLE.COM
5	ALT1.ASMX.L.GOOGLE.COM
5	ALT2.ASMX.L.GOOGLE.COM
10	ALT3.ASMX.L.GOOGLE.COM
10	ALT4.ASMX.L.GOOGLE.COM

Prioritetas nurodo eilės tvarką, kurioje serveriai yra bandomi. Mažesnis skaičius reiškia aukštesnį prioritetą. Tai reiškia, kad siuntėjo serveris pirmiausia bando prisijungti prie serverio su prioritetu 1. Jei jis nepasiekiamas, bandomas kitas – prioritetu 5, ir taip toliau. Tai yra panašu į skambučių centrą su keliais numeriais – jei pirmasis užimtas, bandote antrą.

Kodėl reikia kelių MX įrašų su skirtingais prioritetų? Patikimumumui. Jei pagrindinis serveris sugestų ar būtų perkrautas, paštas būtų pristatytas į atsarginį serverį, kuris vėliau sinchronizuoja su pagrindiniu. Didieji tiekėjai, tokie kaip Google ir Microsoft, turi kelis serverius skirtingose geografinėse lokacijose, kad užtikrintų, jog paštas visuomet pasiekia gavėją.

---

Kaip veikia DNS sistema el. paštui?

Kai kas nors siunčia laišką jums, procesas vyksta maždaug taip:

1. Siuntėjas parašo laišką ir paspaudžia „Siųsti”.
2. Siuntėjo el. pašto serveris priima laišką ir patikrina, kur jį nukreipti.
3. DNS užklausa: siuntėjo serveris atlieka MX įrašo užklausą domenui jusudomenas.lt.
4. DNS serveris atsako su MX įrašų sąrašu – pvz., ASPMX.L.GOOGLE.COM.
5. Siuntėjo serveris prisijungia prie nurodyto serverio per SMTP protokolą (paprastai prievadu 25 arba 587).
6. Gavėjo serveris priima laišką, patikrina jį pagal saugumo taisykles (SPF, DKIM, DMARC) ir padeda į gavėjo pašto dėžutę.

Visas šis procesas vyksta per kelias sekundes, dažniausiai netgi greičiau. Tačiau jei bet kuriame etape kažkas negerai – neteisingas MX įrašas, klaida SPF konfigūracijoje, serveris nepasiekiamas – laiškas gali būti atmestas, uždelstas arba nukreiptas į spam.

---

Pirmas žingsnis: domeno paruošimas

Prieš pradedant konfigūruoti MX įrašus, reikia įsitikinti, kad turite viską, ko reikia:

1. Registruotas domenas. Jūs turite turėti domeną (pvz., jusudomenas.lt), užregistruotą pas domenų registrarą. Jei dar neturite domeno, pirmiausia jį užregistruokite.

2. Prieiga prie DNS valdymo. Jums reikia prieigos prie DNS zonos, kurioje galite pridėti, redaguoti ir trinti įrašus. Šią prieigą paprastai suteikia domenų registraras, hostingo teikėjas arba specializuota DNS paslaugų įmonė (Cloudflare, Amazon Route 53).

3. Pasirinktas el. pašto teikėjas. Prieš konfigūruojant MX įrašus, jūs turite žinoti, kurie MX įrašai turi būti nukreipti. Kiekvienas teikėjas turi savo specifinius serverius:

• Google Workspace: ASPMX.L.GOOGLE.COM (prioritetas 1) + keli atsarginiai
• Microsoft 365: jusudomenas-lt.mail.protection.outlook.com (prioritetas 0)
• Zoho Mail: mx.zoho.eu (prioritetas 10) + mx2.zoho.eu (prioritetas 20)
• Proton Mail: mail.protonmail.ch (prioritetas 10) + mailsec.protonmail.ch (prioritetas 20)
• Savo serverio paštas: jūsų serverio IP adresas arba domeną (pvz., mail.jusudomenas.lt)

4. Patvirtinta domeno nuosavybė. Dauguma el. pašto teikėjų reikalauja, kad prieš pradedant naudotis paslaugą, patvirtintumėte, jog domenas tikrai priklauso jums. Tai daroma pridedant TXT įrašą su unikaliu kodu, kurį sugeneruoja teikėjas.

---

MX įrašų konfigūracija: žingsnis po žingsnio

Dabar pereiname prie praktinės dalies. Process gali šiek tiek skirtis priklausomai nuo to, kur valdote DNS, tačiau principai yra tie patys.

1. Prisijunkite prie DNS valdymo sąsajos

Tai gali būti jūsų domenų registraros sąsaja (GoDaddy, Namecheap, OVH, Hostinger), hostingo valdymo skydelis (cPanel, Plesk, DirectAdmin) arba specializuota DNS paslauga (Cloudflare, Route 53). Ieškokite skyriaus, kuris vadinasi „DNS Management”, „DNS Settings”, „Zone Editor” ar panašiai.

2. Sukurkite naują MX įrašą

Pasirinkite įrašo tipą MX. Užpildykite laukus:

• Name / Host: @ arba palikite tuščią – tai reiškia, kad įrašas taikomas pagrindiniam domenui (jusudomenas.lt). Jei konfigūruojate subdomeną, įveskite subdomeno vardą (pvz., info).
• Mail Server / Points to: serverio adresas, kurį pateikė jūsų el. pašto teikėjas (pvz., ASPMX.L.GOOGLE.COM).
• Priority: skaičius, nurodantis prioritetą (mažesnis = aukštesnis prioritetas).
• TTL: laikas sekundėmis, per kurį įrašas yra cache’uojamas. Naudokite numatytąją reikšmę (paprastai 3600 = 1 valanda). Jei planuojate greitai keisti, galite sumažinti iki 300.

3. Pridėkite visus reikiamus MX įrašus

Jei jūsų teikėjas pateikia kelis MX įrašus (kaip Google pateikia penkis), pridėkite juos visus. Kiekvienam sukurkite atskirą įrašą su atitinkamu prioritetu.

4. Pašalinkite senus MX įrašus

Jei anksčiau naudojote kitą el. pašto teikėją, senieji MX įrašai turi būti pašalinti. Du skirtingi MX įrašai skirtingiems serveriams gali sukelti situaciją, kai viena laiškų dalis keliauja į vieną serverį, kita – į kitą. Tai vadinama „split delivery” ir dažniausiai yra nesąmoninga klaida, ne tyčinis nustatymas.

5. Išsaugokite ir palaukite propagacijos

DNS pakeitimai neįsigalioja akimirksniu. Pasaulio DNS resolveriai turi atnaujinti savo cache. Paprastai tai trunka nuo kelias valandas iki 48 valandų, nors kai kurie pasikeitimai gali būti matomi per kelias minutes.

---

MX įrašai populiariems el. pašto teikėjams

Kiekvienas teikėjas turi savo specifinius MX įrašus. Štai jie:

Google Workspace

Tipas	Prioritetas	Reikšmė
MX	1	ASPMX.L.GOOGLE.COM
MX	5	ALT1.ASMX.L.GOOGLE.COM
MX	5	ALT2.ASMX.L.GOOGLE.COM
MX	10	ALT3.ASMX.L.GOOGLE.COM
MX	10	ALT4.ASMX.L.GOOGLE.COM

Google taip pat reikalauja SPF įrašo: v=spf1 include:_spf.google.com ~all

Microsoft 365

Tipas	Prioritetas	Reikšmė
MX	0	jusudomenas-lt.mail.protection.outlook.com

Microsoft 365 naudoja tik vieną MX įrašą. Dėmesio: domeno vardas formuojamas automatiškai – jūsų domeno vardas su brūkšneliais ir -lt.mail.protection.outlook.com priesaga.

SPF įrašas: v=spf1 include:spf.protection.outlook.com ~all

Zoho Mail

Tipas	Prioritetas	Reikšmė
MX	10	mx.zoho.eu
MX	20	mx2.zoho.eu
MX	50	mx3.zoho.eu

SPF įrašas: v=spf1 include:zoho.eu ~all

Proton Mail

Tipas	Prioritetas	Reikšmė
MX	10	mail.protonmail.ch
MX	20	mailsec.protonmail.ch

SPF įrašas: v=spf1 include:_spf.protonmail.ch ~all

Hostingo teikėjo el. paštas

Kiekvienas hostingo teikėjas turi savo MX įrašus. Paprastai tai yra kažkas panašaus į mail.jusudomenas.lt su prioritetu 0. Patikrinkite savo hostingo dokumentaciją arba valdymo skydelį.

---

SPF įrašas: kodėl be jo laiškai keliauja į spam?

MX įrašas nurodo, kur gauti laiškus, bet ne pasako, kas gali juos siųsti. Šiam tikslui yra SPF (Sender Policy Framework) įrašas. Tai TXT tipo DNS įrašas, kuris publikai pareiškia, kurie serveriai turi teisę siųsti el. laiškus jūsų domenui.

Kodėl tai svarbu? Įsivaizduokite, kad sukčius nusprendžia siųsti suklastotą laišką jūsų vardu – pvz., info@jusudomenas.lt – iš savo paties serverio. Kai gavėjo serveris gauna tokį laišką, jis patikrina SPF įrašą. Jei sukčiaus serveris nėra įtrauktas į jūsų SPF sąrašą, laiškas bus pažymėtas kaip nesaugus arba atmestas. Be SPF įrašo, sukčiaus laiškas galėtų būti pristatytas be jokių įspėjimų.

SPF įrašo sintaksė yra paprasta, bet gali būti sudėtinga, jei naudojate kelias siuntimo paslaugas. Štai pavyzdžiai:

Google Workspace:

v=spf1 include:_spf.google.com ~all

Microsoft 365:

v=spf1 include:spf.protection.outlook.com ~all

Zoho Mail:

v=spf1 include:zoho.eu ~all

Kelios paslaigos kartu (Google + Mailchimp):

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

Pasibaigimas -all reiškia „hard fail” – visi serveriai, kurie nėra sąraše, bus atmesti. ~all reiškia „soft fail” – laiškai bus pažymėti, bet ne atmesti. Pradedant rekomenduojama naudoti ~all, o vėliau pereiti prie -all, kai įsitikinate, kad visi teisėti serveriai yra įtraukti.

---

DKIM: skaitmeninis parašas jūsų laiškams

DKIM (DomainKeys Identified Mail) yra kriptografinis metodas, kuris prideda skaitmeninį parašą prie kiekvieno išsiskiriančio laiško. Skirtingai nei SPF, kuris veikia DNS lygiu, DKIM veikia laiško lygyje – kiekvienas laiškas yra pasirašomas privatu raktu, o gavėjas gali patikrinti parašą naudodamas viešąjį raktą, kuris yra publikuojamas DNS TXT įraše.

DKIM veikimo principas:

1. Rakto generavimas: el. pašto teikėjas sugeneruoja privatų ir viešą raktų porą.
2. Privatus raktas lieka serveryje ir naudojamas kiekvieno laiško pasirašymui.
3. Viešasis raktas publikuojamas DNS TXT įraše, kurio pavadinimas yra kažkas panašaus į selector._domainkey.jusudomenas.lt.
4. Gavėjo serveris, gavęs laišką, atlieka DNS užklausą, gauna viešąjį raktą ir patikrina parašą.
5. Jeigu parašas atitinka, laiškas yra autentifikuotas – jis tikrai išėjo iš jūsų serverio ir nebuvo modifikuotas kelioneje.

DKIM konfigūracija kiekvienam teikėjui yra skirtinga. Google Workspace siūlo automatinį DKIM įjungimą per administravimo konsolę. Microsoft 365 taip pat turi automatizuotą procesą. Zoho Mail pateikia instrukcijas su konkrečiu raktu. Svarbu žinoti, kad DKIM įrašas yra specifinis kiekvienam teikėjui ir negali būti bendras.

Pavyzdys, kaip atrodo DKIM TXT įrašas:

selector1._domainkey.jusudomenas.lt → "v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDY..."

Šis įrašas yra gana ilgas – jame yra viešasis raktas base64 formatu. Svarbu jį nukopijuoti tiksliai, be jokių pakitimų, kitaip DKIM neveiks.

---

DMARC: saugumo politika, kuri sujungia viską

DMARC (Domain-based Message Authentication, Reporting & Conformance) yra trečiasis saugumo sluoksnis, kuris remiasi SPF ir DKIM. Jo paskirtis – nurodyti gavėjo serveriams, ką daryti su laiškais, kurie nepraėjo SPF ar DKIM patikrinimo.

DMARC TXT įrašas paprastai atrodo taip:

_dmarc.jusudomenas.lt → "v=DMARC1; p=none; rua=mailto:dmarc@jusudomenas.lt"

Parametrai:

• p=none: Stebėjimo režimas. Laiškai, kurie nepraėjo patikrinimo, yra praleidžiami, bet jūs gaunate ataskaitas.
• p=quarantine: Laiškai, kurie nepraėjo patikrinimo, yra siunčiami į spam.
• p=reject: Laiškai, kurie nepraėjo patikrinimo, yra visiškai atmetami.

Be politikos parametro, DMARC taip pat leidžia nurodyti:

• rua=mailto:… Adresas, kuriuo siunčiamos agreguotos ataskaitos (XML formatu) apie laiškus, siunčiamus jūsų vardu.
• ruf=mailto:… Adresas, kuriuo siunčiamos teisinės ataskaitos apie konkretus nepatikrinusius laiškus.
• pct=… Procentas laiškų, kuriems taikoma politika (pvz., pct=50 taiko politiką tik 50% laiškų – naudinga laipsniškam perėjimui).
• aspf=a / adkim=s Strategijos suderinamumo lygis – ar SPF/DKIM turi atitikti tiksliai, ar leidžiama dalinis atitikimas.

Rekomenduojama DMARC įgyvendinimo strategija:

1. Savaitė 1–2: p=none – Stebėkite ataskaitas. Pamatysite, kurie serveriai siunčia laiškus jūsu vardu, ar visi legitimi serveriai yra įtraukti į SPF/DKIM.
2. Savaitė 3–4: p=quarantine – Nepatikrinti laiškai siunčiami į spam. Patikrinkite, ar nėra skundų dėl dingusių laiškų.
3. Po mėnesio: p=reject – Visiškas nepatikrintų laiškų atmetimas. Jūsų domenas dabar yra pilnai apsaugotas nuo spoofing.

DMARC ataskaitos gali būti sudėtingos skaityti – jos yra XML formatu. Egzistuoja nemokamos ir mokamos paslaugos (pvz., Dmarcian, Postmark DMARC Digest), kurios analizuoja ataskaitas ir pateikia skaitomą santrauką.

---

TTL reikšmės svarba planuojant migraciją

TTL (Time to Live) yra DNS įrašo parametras, nurodantis, kiek laiko įrašas yra saugomas cache atmintyje prieš atnaujinant. Tai yra ypač svarbu planuojant el. pašto migraciją iš vieno teikėjo į kitą.

Įsivaizduokite: jūs naudojate Google Workspace, bet nusprendžiate persikelti į Microsoft 365. Pakeitus MX įrašus, srautas turi būti nukreiptas į Microsoft serverius. Tačiau jei jūsų TTL yra 86400 (24 valandos), pasaulio DNS resolveriai dar 24 valandas siųs paštą į Google. Tai reiškia, kad perėjimo metu viena laiškų dalis bus pristatyta į seną sistemą, kita – į naują.

Kaip to išvengti:

1. Mažinkite TTL 24–48 valandas prieš migraciją iki 300 sekundžių (5 minutės).
2. Atlikite MX įrašų keitimą planuotu metu, idealiai – savaitgalį ar naktį, kai srautas yra mažiausias.
3. Palaukite propagacijos – po 30–60 minučių dauguma DNS serverių turėtų atsinaujinti.
4. Grąžinkite TTL į numatytąją reikšmę (3600 arba ilgesnę), kad sumažintumėte DNS apkrovą.

---

Klaidos ir trikčių šalinimas

Net jei viskas atrodo sukonfigūruota teisingai, problemų gali kilti. Štai dažniausios klaidos ir jų sprendimai:

Klaida 1: Laiškai nepasiekia gavėjo

Galimos priežastys:

• MX įrašas nurodo į neteisingą serverį
• SPF įrašas neapima siuntimo serverio
• DKIM parašas yra neteisingas arba trūksta
• Gavėjo serveris blokuoja jūsų IP adresą

Sprendimas:

1. Patikrinkite MX įrašus naudodami įrankį dig MX jusudomenas.lt arba online įrankius (pvz., MXToolbox, DNS Checker).
2. Patikrinkite, ar SPF įrašas apima visus serverius, kurie siunčia laiškus.
3. Siųskite testinį laišką į mail-tester.com – nemokama paslauga, kuri patikrina jūsų laiško pristatymo kokybę.
4. Patikrinkite, ar jūsų serverio IP adresas nėra įtrauktas į juoduosius sąrašus (blacklists).

Klaida 2: Laiškai keliauja į spam

Galimos priežastys:

• Trūksta SPF, DKIM ar DMARC įrašo
• Laiško turinys sukelia spam filtrus (per daug nuorodų, spam žodžių, vaizdų)
• IP reputacija yra bloga
• Domenas yra naujas ir neturi reputacijos

Sprendimas:

1. Įsitikinkite, kad visi trys saugumo įrašai (SPF, DKIM, DMARC) yra sukonfigūruoti teisingai.
2. Patikrinkite laiško turinį naudodami mail-tester.com.
3. Patikrinkite IP reputaciją per Talos Intelligence (Cisco) arba Sender Score.
4. Jei domenas yra naujas, duokite laiko – reputacija kaupiasi per savaites ir mėnesius.

Klaida 3: Gali gauti laiškus, bet negalite siųsti

Galimos priežastys:

• SMTP serveris neteisingai sukonfigūruotas el. pašto programoje
• ISP blokuoja prievadą 25 (įprasta praktika namų interneto ryšiuose)
• SPF įrašas neapima siuntimo serverio

Sprendimas:

1. Patikrinkite, ar el. pašto programoje nurodytas teisingas SMTP serveris, prievadas (dažniausiai 587 su TLS arba 465 su SSL) ir autentifikacija.
2. Jei prievadas 25 yra užblokuotas, naudokite prievadą 587 arba 465.
3. Patikrinkite, ar SPF įrašas apima siuntimo serverius.

Klaida 4: DNS propagacija užtrunka per ilgai

Galimos priežastys:

• TTL reikšmė per didelė
• Vietinis DNS resolveris cache’uoja seną informaciją
• Nameserveriai nėra sinchronizuoti

Sprendimas:

1. Patikrinkite DNS įrašus per kelias skirtingas paslaugas (DNS Checker, WhatsMyDNS) – ar visi rodo tą patį.
2. Atnaujinkite savo kompiuterio DNS cache: Windows – ipconfig /flushdns, macOS – sudo dscacheutil -flushcache.
3. Pakeiskite savo kompiuterio DNS serverius į Google (8.8.8.8) ar Cloudflare (1.1.1.1) ir bandykite dar kartą.

Klaida 5: Konfliktuojantys MX įrašai

Galimos priežastys:

• Likę seno teikėjo MX įrašai po migracijos
• Subdomeno MX įrašai konfliktuoja su pagrindinio domeno įrašais

Sprendimas:

1. Patikrinkite visą DNS zoną ir pašalinkite visus MX įrašus, kurie nėra susiję su dabartiniu el. pašto teikėju.
2. Jei naudojate subdomeną el. paštui (pvz., mail.jusudomenas.lt), įsitikinkite, kad jo MX įrašai nesusikerta su pagrindinio domeno įrašais.

---

Subdomenų el. pašto konfigūravimas

Kartais jums gali prireikti sukurti el. paštą subdomenui – pavyzdžiui, info@padalinys.jusudomenas.lt. Subdomeno el. pašto konfigūravimas yra panašus į pagrindinio domeno konfigūravimą, tačiau yra kelios svarbios detalės:

1. Subdomeno MX įrašas turi būti sukurtas subdomeno DNS zonoje. Jei subdomenas neturi savo DNS zonos, įrašas kuriamas pagrindinio domeno zonoje su Name lauku padalinys.
2. SPF įrašas taip pat turi būti sukurtas subdomenui – jis nėra automatiškai paveldimas iš pagrindinio domeno.
3. DKIM įrašas turi būti sukurtas subdomenui su atskiru selectoriumi.
4. DMARC įrašas gali būti sukurtas subdomenui atskirai (_dmarc.padalinys.jusudomenas.lt), arba, jei jo nėra, bus naudojamas pagrindinio domeno DMARC.

Subdomenų el. paštas naudojamas retai, bet gali būti naudingas didelėms organizacijoms, turinčioms kelias verslo linijas ar geografinius padalinius.

---

Kaip patikrinti, ar viskas veikia?

Po konfigūracijos svarbu patikrinti, ar viskas veikia. Štai įrankiai, kurie padės:

MXToolbox (mxtoolbox.com) – vienas populiariausių įrankių DNS ir el. pašto diagnostikai. Leidžia patikrinti MX įrašus, SPF, DKIM, DMARC, blacklists ir dar daugiau. Įveskite savo domeną ir per kelias sekundes gausite išsamią ataskaitą.

Google Admin Toolbox (toolbox.googleapps.com) – Google siūlomas nemokamas įrankis, kuris patikrina DNS įrašus, MX konfigūraciją ir el. pašto pristatymą. Naudingas net jei nenaudojate Google Workspace.

Mail-Tester.com – siųskite testinį laišką į unikalų adresą ir gaukite 10 balų įvertinimą su detalia analize: ar SPF, DKIM, DMARC veikia, ar turinys nesukelia spam filtrų, ar laiškas yra HTML formatu teisingai.

DNS Checker (dnschecker.org) – patikrinkite, kaip DNS įrašai yra išplatinti visame pasaulyje. Įveskite domeną, pasirinkite įrašo tipą (MX, TXT, A) ir matysite, ką rodo DNS serveriai skirtingose šalyse.

Dmarcian (dmarcian.com) – DMARC ataskaitų analizės įrankis. Pirmos 100 000 pranešimų per metus yra nemokamos. Padeda suprasti, kas siunčia laiškus jūsų vardu ir ar yra nesankcijinguotų siuntėjų.

---

DUK – Dažniausiai užduodami klausimai

---

Išvados

Domeno konfigūravimas el. paštui nėra rocket science, tačiau reikalauja dėmesio detalėms. MX įrašai nurodo, kur laiškai turi būti pristatyti. SPF įrašas pasako, kas turi teisę siųsti. DKIM prideda skaitmeninį parašą. DMARC nurodo, ką daryti su nepatikrintais laiškais. Kartu šie keturi DNS įrašų tipai sudaro pilną el. pašto infrastruktūros pagrindą.

Klausimas nėra, ar verta juos konfigūruoti – verta. Be tinkamų įrašų, jūsų laiškai gali būti prarasti, atmetami arba nukreipiami į spam. O sukčių laiškai, siunčiami jūsų vardu, gali pakenkti jūsų reputacijai ir klientų pasitikėjimui.

Praktiniai žingsniai:

✅ Patikrinkite savo MX įrašus per MXToolbox ✅ Sukonfigūruokite SPF įrašą ✅ Sukonfigūruokite DKIM įrašą ✅ Pridėkite DMARC įrašą su p=none ir stebėkite ataskaitas ✅ Laipsniškai perjunkite DMARC politiką į quarantine, tada reject ✅ Reguliariai tikrinkite ir testuokite

Domeno konfigūravimas yra vienkartinis darbas, kurio nauda jaučiama kiekvieną dieną – kai laiškai pasiekia gavėjus be problemų, kai spam filtrai nebeblokuoja jūsų komunikacijos, ir kai jūsų domenas yra apsaugotas nuo piktnaudžiavimo. Investuokite laiko dabar, kad vėliau nereikėtų spręsti problemų.