MX-rekordok és prioritás

4. modul: Rekordok az e-mailhez · Olvasási idő: 8 perc

Tanulási cél: E lecke után Ön képes lesz az MX-rekordok olvasására és beállítására, a megfelelő prioritás kiválasztására, valamint annak elmagyarázására, mi történik, ha egy domainnek nincs MX-rekordja.

Kulcsfogalmak: MX-rekord, prioritás (preference), tartalék MX, mailszerver (hosztnév), implicit MX, null MX, helyi kézbesítés

Hová kell mennie a levélnek?

Ha valaki levelet küld az info@example.com címre, a feladó mailszerverének ki kell derítenie, melyik szerverhez kell kézbesítenie azt a levelet. Ezt a DNS-ben nézi meg, az example.com MX-rekordjára (Mail eXchanger) kérdezve rá.

A válasz nem egy IP-cím, hanem egy lista mailszerverekről, mindegyik előtt egy számmal:

example.com.   3600  IN  MX  10 mail.example.com.
example.com.   3600  IN  MX  20 backup.example.net.

Ezután a küldő szerver lekérdezi a mail.example.com A- vagy AAAA-rekordját, és csak ekkor tudja, melyik IP-címet kell hívnia. Egy MX-rekord tehát mindig egy névre mutat, amelynek saját A- vagy AAAA-rekordja van.

Az MX-rekord szinte mindig magán a domainnéven (@) található, mivel az e-mail cím @ jel utáni részéről van szó. Ha szeretne levelet fogadni az info@nieuws.example.com címen, akkor a nieuws.example.com domainnek saját MX-rekordra van szüksége.

Prioritás: az alacsonyabb megy először

A mailszerver előtti számot prioritásnak nevezzük (a szabványban, az RFC 5321-ben, preference néven szerepel). A szabály egyszerű:

• Minél alacsonyabb a szám, annál előbb kerül sorra az adott szerver.
• Ha az a szerver nem érhető el, a feladó a következőt próbálja.
• Ha két szervernek ugyanaz a száma, a feladó véletlenszerűen osztja el a levelet a kettő között. Így oszthatja el a terhelést.

Maga a szám semmit nem jelent. 0, 1, 5, 10 vagy 100: csak a sorrend számít. Egy 10-es és egy 20-as prioritású rekord pontosan ugyanúgy működik, mint egy 1-es és 2-es. Ha az e-mail szolgáltatója megad egy számot, azt vegye át. Ha csak egy szervert ad meg, a szám nem számít.

A magasabb számú szervert gyakran tartalék MX-nek nevezzük. Régen ez bevett gyakorlat volt: ha a saját szerver kiesett, a tartalék megőrizte a levelet. Manapság a küldő szerver maga is megőrzi a levelet néhány napig, és újra próbálkozik. Egy rosszul beállított tartalék MX (például spamszűrő nélkül) inkább spamet vonz magához. Csak akkor használjon ilyet, ha szolgáltatója kifejezetten ezt kéri.

Szabályok a jó MX-rekordhoz

1. Név, nem IP-cím. Az MX 10 192.0.2.25 érvénytelen. Hozzon létre egy mail A-rekordot 192.0.2.25 értékkel, és az MX mutasson a mail.example.com. névre.
2. Ne CNAME-re. Az MX-rekordban szereplő névnek saját A- vagy AAAA-rekordja kell legyen, nem CNAME (RFC 2181, 10.3. szakasz). Sok szerver így is feloldja, de nem mindegyik.
3. A pont a végén. Sok vezérlőpultban a mail.example.com. pontot is beírja. Pont nélkül a vezérlőpult még egyszer hozzáfűzi a domainnevet: mail.example.com.example.com. Ez a név nem létezik, és a levele nem érkezik meg.
4. A mailszervernek léteznie kell. Ha az MX egy olyan névre mutat, amelynek nincs A- vagy AAAA-rekordja, semmi sem érkezik meg. A gyakorlatban ezt gyakran akkor látjuk, amikor valaki a domainje névszervereit egy weboldalszerkesztőhöz költözteti: az MX-rekord átkerül, de a mail A-rekordja nem.
5. A régi rekordokat távolítsa el. Ha másik e-mail szolgáltatóra vált, távolítsa el a régi szolgáltató MX-rekordjait. Ha bent hagyja őket, a levelei egy része továbbra is a régi szolgáltatóhoz fog beérkezni.

Nincs MX-rekord: implicit MX és null MX

Mi történik, ha egy domainnek egyáltalán nincs MX-rekordja? Az RFC 5321 szerint a küldő szerver ekkor magának a domainnévnek az A- vagy AAAA-rekordját próbálja meg. Ezt implicit MX-nek nevezzük. Ha a weboldala egy mail nélküli szerveren van, akkor a világ a webszerverénél próbálja kézbesíteni a levelét. Ez késleltetést és hibaüzeneteket okoz a feladónál.

Ha világossá szeretné tenni, hogy egy domain soha nem fogad levelet, használjon null MX-et (RFC 7505):

example.net.  3600  IN  MX  0 .

Prioritás 0, és mailszerverként csak egy pont. A küldő ekkor azonnal látja, hogy nem kell próbálkoznia, és rögtön rendes hibaüzenetet küld a feladónak. Kombinálja ezt egy v=spf1 -all SPF-rekorddal (4.3. lecke), ha a domain levelet sem küld.

Helyi kézbesítés: a csapda a mailszolgáltatást is tartalmazó tárhelynél

Sok tárhelycsomagnak egyetlen gépen van webszervere és mailszervere. Ez a szerver alapértelmezés szerint úgy gondolkodik: "a levelet ehhez a domainhez magam kézbesítem". Ha átköltözteti a levelezését egy másik szolgáltatóhoz, módosítja az MX-rekordokat, de a szerver ezt nem jegyzi meg magától. Ennek következménye: a saját kapcsolatfelvételi űrlapjáról, és az ugyanazon a szerveren lévő más weboldalakról érkező levelek a régi szerveren rekednek, és soha nem érkeznek meg az új szolgáltatóhoz. A feladó néha 550 Unknown user hibát kap vissza.

Ezt a kérdést a tárhelyszolgáltatók nagyon gyakran kapják. A legtöbb vezérlőpultban ezért van egy kapcsoló, amelynek neve valami ilyesmi: "Ezt a szervert használom az e-mailjeim kezelésére" vagy "Helyi levélkézbesítés". Más szolgáltatónál van a levelezése? Módosítsa az MX-et, ÉS kapcsolja ki ezt a kapcsolót. Ha csak az egyiket teszi meg, hiba lesz belőle.

A gyakorlatban: így néz ki egy vezérlőpulton

Ebben a példában a DirectAdmin felületet használjuk. Az E-mail kezelés, MX rekordok alatt láthatja a domainje MX-rekordjait. Minden rekordnál a prioritást egy mezőbe írja be, utána a mailszervert, a végén ponttal. Alatta található a Ezt a szervert használom az e-mailjeim kezelésére jelölőnégyzet. Az MX sablon alatt előre elkészített beállításokat választhat, például Microsoft 365-höz vagy Google Workspace-hez.

A Fiókom felületen ugyanez a domain DNS fülén található; a kapcsoló neve ott Kézbesítés.

A cPanel, Plesk, Cloudflare vagy a regisztrátora felületén másként néz ki a képernyő, de mindig ugyanazt a három dolgot adja meg: a nevet (@ vagy üresen), a prioritást és a mailszervert.

Összefoglalás

• Az MX-rekord megmondja, hová kell mennie a domainjéhez tartozó levélnek. Névre mutat, soha nem IP-címre vagy CNAME-re.
• A legalacsonyabb prioritás megy először; egyenlő számok esetén a levelek megoszlanak; maga a szám semmit nem jelent.
• MX nélkül a világ az A-rekordját próbálja (implicit MX). Ha soha nem fogad levelet, használjon MX 0 . (null MX) rekordot.
• Ha átköltözteti a levelezését, távolítsa el a régi MX-rekordokat, és kapcsolja ki a helyi kézbesítést a tárhelyszerverén.

Kvíz

Feladat

Z4.1 feladat: MX kikeresése. Keresse ki a wikipedia.org MX-rekordjait (vagy a saját domainjéét). Töltse ki, melyik mailszervernek van a legalacsonyabb prioritási száma, és mennyi az a szám.

O4.1 feladat: Önálló beállítás a gyakorlózónájában. Hozzon létre a <code>.dnspractice.eu gyakorlózónájában két MX-rekordot: 10-es prioritással a mail.<code>.dnspractice.eu névre, és 20-as prioritással a backup.<code>.dnspractice.eu névre. Mindkét névhez hozzon létre egy A-rekordot: a mail nevet a 192.0.2.25 címre, a backup nevet pedig a 192.0.2.26 címre. Ezután kattintson az Ellenőrzés gombra.

További olvasnivaló

Az ezekben a cikkekben leírt lépések a WebOké vezérlőpultjaira vonatkoznak; más vezérlőpultokon hasonlóan működik.

• DirectAdmin útmutató 5.5: MX rekordok: hová érkezik az e-mail?
• Az Ön e-mailje máshol: Microsoft 365, Google Workspace vagy saját levelezőszerver
• PHP-ből nem sikerül levelet küldeni, az MX-rekordok máshová mutatnak
• DirectAdmin útmutató 18.9: Nem érkezik több e-mailem
• RFC 5321 5.1. szakasz (levéltovábbítás útvonala), RFC 7505 (null MX)