Domain és tárhely átvétele a régi szolgáltatótól

Scheo · 2026-11-07 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Ha a régi webes szolgáltatód nem válaszol, megszűnt, vagy egyszerűen váltani szeretnél, az átvétel több külön szálon fut. Az egyik cég tartja nyilván a domaint, egy másik kezelheti a DNS-t, és megint másik szerveren lehet a weboldal meg a levelezés. Aki ezt egyetlen feladatnak tekinti, jó eséllyel napokig nem kap levelet, vagy az oldala egy ideig biztonsági figyelmeztetéssel nyílik meg. Az alábbi lépések sorrendben végigvisznek egy átvételen. Mindenhol jelöljük, mi hivatalosan igazolt szabály, mi saját tapasztalat, és mi szakmai feltételezés.

Hogyan derítheted ki, ki a domain regisztrált tulajdonosa?

A domain tulajdonosát (a .hu domaineknél igénylőnek hívják) a nyilvános domainkeresőben vagy a regisztrátor adminfelületén látod. Magánszemélynél az adatok egy része rejtve marad, ilyenkor a regisztrátortól kérhetsz tájékoztatást.

[Hivatalosan igazolt] A .hu domainek nyilvántartását az Internet Szolgáltatók Tanácsa (ISZT) Domain Regisztrációs Szolgáltatása vezeti. A domain.hu oldal keresőjében megnézheted, melyik regisztrátornál van a domain. A .com, .eu és más végződéseknél a WHOIS vagy az újabb RDAP-lekérdezés mutatja a regisztrátort, a lejárat dátumát és a domain állapotát, például a clientTransferProhibited zárolást.

Három adatot írj fel magadnak.

• Ki az igénylő? Ha a régi fejlesztő a saját nevére vagy a saját cégére jegyeztette a domaint, jogilag az övé, és az ő közreműködése nélkül nem viheted át.
• Melyik regisztrátornál van? Ehhez a céghez fordulsz majd a regisztrátor-váltásnál.
• Mikor jár le? Ha pár héten belül lejár, előbb a hosszabbításról gondoskodj, mert egy lejárt domain az egész átvételt megakaszthatja.

[Saját tapasztalat] Az átvételek nagy része itt akad el először. Gyakori, hogy a cégvezető biztos benne, hogy a domain a cég nevén van, aztán a lekérdezésből kiderül, hogy egy korábbi alvállalkozó a bejegyzett igénylő. Ezt érdemes a legelején tisztázni, mert az igénylő módosítása időbe telik, és dokumentumokat is kérhetnek hozzá.

Hol van a tárhely, és ki kezeli a DNS-t?

A DNS-t az a szolgáltató kezeli, amelyre a domain névszerverei (NS rekordjai) mutatnak. A tárhelyet a weboldal IP-címéből tudod beazonosítani. A kettő gyakran két különböző cég.

Terminálból néhány paranccsal mindent látsz. Windowson az nslookup is jó, macOS-en és Linuxon a dig parancs a kényelmesebb.

• dig NS pelda.hu +short megmutatja a névszervereket, vagyis azt, hogy hol szerkeszthetők a DNS-rekordok.
• dig A pelda.hu +short és dig A www.pelda.hu +short megadja a weboldal IP-címét.
• whois 185.x.x.x (az IP-címre futtatva) jó eséllyel elárulja, melyik tárhelycég hálózatában fut az oldal.

[Hivatalosan igazolt] Ha az IP-cím a Cloudflare tartományába esik, az oldal egy proxy mögött van, és a valódi szerver címe rejtve marad. Ilyenkor a Cloudflare-fiókhoz is hozzáférés kell, mert ott vannak a DNS-rekordok.

[Szakmai feltételezés] Ha a névszerverek a tárhelycég nevét viselik (például ns1.tarhelyceg.hu), akkor nagy valószínűséggel a DNS és a tárhely ugyanott van, és egyetlen admin-hozzáféréssel mindkettő elérhető. Ezt mindig ellenőrizd a belépés után, mert névszerver-szolgáltatást külön is lehet vásárolni.

Miért a levelezés a leggyakrabban elfelejtett rész?

A levelezés azért marad ki, mert senki nem látja. A weboldalra mindenki rá tud nézni, a levelek útját viszont az MX rekord határozza meg, ami egészen máshova mutathat, mint az oldal.

[Saját tapasztalat] Átvételeknél azt látjuk, hogy a tulajdonos a weboldallal foglalkozik, a postafiókokra csak akkor gondol, amikor már nem jönnek a levelek. Ha az MX a régi tárhelyre mutat, és azt felmondják, a beérkező levelek visszapattannak, a régi postafiókok tartalma pedig elveszhet. Ezért a levelezést még a fájlok előtt térképezd fel.

A levelezési beállításokat ezekkel a lekérdezésekkel látod.

• dig MX pelda.hu +short megmutatja, melyik szerver fogadja a leveleket. Ha google.com vagy outlook.com végű címet látsz, a levelezés Google Workspace-en vagy Microsoft 365-ön fut, és a tárhelyváltás nem érinti.
• dig TXT pelda.hu +short kiadja az SPF rekordot, például v=spf1 include:_spf.tarhelyceg.hu ~all.
• dig TXT _dmarc.pelda.hu +short megmutatja a DMARC szabályt.
• A DKIM kulcs egy szelektor alatt van (például default._domainkey.pelda.hu), a szelektor nevét a régi adminfelületen vagy egy kiküldött levél fejlécében találod.

Az MX-en túl ezeket is írd össze.

• az összes postafiók nevét és a tárhelyméretét,
• az aliasokat, átirányításokat és automatikus válaszokat,
• hogy ki milyen levelezőprogramot használ, és IMAP vagy POP3 kapcsolattal,
• a weboldal űrlapjainak levélküldését (SMTP-beállítás, feladó cím),
• a külső rendszereket, amelyek a domain nevében küldenek levelet (hírlevélküldő, számlázó, webshop).

[Szakmai feltételezés] Ha valaki POP3-mal tölti le a leveleit, a régi levelek jó eséllyel csak az ő gépén vannak meg, a szerveren már nem. Náluk a migráció előtt a helyi levelezőprogram adatfájlját is érdemes elmenteni.

Milyen sorrendben vedd át a domaint, a levelezést és a fájlokat?

Először mentesz és felépíted az új környezetet, utána állítod át a DNS-t, és a domain regisztrátor-váltása a legvégére marad, amikor minden már az új helyen működik. Így a régi rendszer végig tartalékként fut.

1. Hozzáférések összegyűjtése. Regisztrátor, DNS-kezelő, tárhely-adminfelület, FTP vagy SFTP, adatbázis, WordPress-admin, postafiókok.
2. Teljes mentés a fájlokról, az adatbázisról és a postafiókokról (lásd lent).
3. DNS-rekordok lementése. Az összes rekordot írd ki egy fájlba, az aldomaineket és a TXT rekordokat is.
4. TTL csökkentése. Legalább egy nappal a váltás előtt vedd le a fontos rekordok TTL-értékét például 300 másodpercre, így a módosítás gyorsabban terjed.
5. Az új tárhely felépítése. Fájlok és adatbázis feltöltése, a postafiókok létrehozása ugyanazokkal a nevekkel.
6. Tesztelés a hosts fájllal, még a DNS-váltás előtt.
7. Levelek első szinkronja a régi postafiókokból az újakba.
8. DNS-váltás. Az A rekordok, majd az MX, az SPF és a DKIM átírása.
9. SSL-tanúsítvány kiállítása az új szerveren.
10. Második levélszinkron, ami átemeli a váltás alatt még a régi szerverre érkezett leveleket.
11. Regisztrátor-váltás, ha szükséges.
12. A régi szolgáltatás felmondása, csak az ellenőrzések után.

[Hivatalosan igazolt] A generikus végződéseknél (.com, .net, .org) az ICANN átviteli szabályzata szerint a regisztrátor-váltáshoz egy átviteli kód (auth code vagy EPP-kód) kell, és a domain a regisztrációt vagy egy korábbi átvitelt követő 60 napban általában nem vihető át. A .hu domaineknél a regisztrátor-váltás menetét az ISZT Domainregisztrációs Szabályzata írja le, ehhez az igénylő hozzájárulása kell.

Hogyan teszteld az új oldalt a DNS-váltás előtt?

A saját gépeden a hosts fájlban a domaint ideiglenesen az új szerver IP-címére irányíthatod. Ekkor csak te látod az új oldalt, a látogatók továbbra is a régit érik el. Egy sor kell hozzá, például 203.0.113.10 pelda.hu www.pelda.hu. Macen és Linuxon a fájl helye /etc/hosts, Windowson C:\Windows\System32\drivers\etc\hosts. Nézd végig az aloldalakat, az űrlapokat, a képeket és a belépést, aztán töröld ki a sort.

Hogyan vidd át a leveleket kiesés nélkül?

Az IMAP-postafiókokat a legtöbb tárhely-adminfelület importálóval tudja átvenni, de a nyílt forrású imapsync is ismert eszköz erre. Egy egyszerű hívás így néz ki.

imapsync --host1 mail.regi.hu --user1 info@pelda.hu --password1 '...' --host2 mail.uj.hu --user2 info@pelda.hu --password2 '...'

[Saját tapasztalat] Az első szinkront a DNS-váltás előtt futtatjuk, ez viszi át a régi leveleket. A másodikat egy-két nappal a váltás után, mert a DNS terjedése alatt egyes küldők még a régi szerverre kézbesítenek. Kétlépcsős átvitellel jó eséllyel egyetlen levél sem marad le.

Mire figyelj a mentésnél?

A mentés akkor ér valamit, ha le is tudod tölteni, és vissza is tudod állítani. A régi szolgáltató szerverén tárolt mentés nem számít, mert a felmondással az is eltűnik.

• A weboldal összes fájlja, a rejtett fájlokkal együtt (például .htaccess).
• Az adatbázis exportja (WordPressnél wp db export vagy phpMyAdmin), és a konfigurációs fájl, amelyben a kapcsolódási adatok vannak.
• A postafiókok tartalma, ha lehet, IMAP-on keresztül vagy a tárhely saját exportjával.
• A DNS-zóna teljes listája szövegfájlban.
• A cron-feladatok, az átirányítások és a PHP-verzió, mert ezek nélkül az oldal másképp viselkedhet az új helyen.

[Saját tapasztalat] A mentést mindig próbáld visszaállítani az új helyen, mielőtt bármit átállítasz. Egy félbeszakadt adatbázis-export csak a visszaállításnál derül ki.

Mi a teendő az SSL-tanúsítvánnyal?

Az SSL-tanúsítványt az új szerveren újra ki kell állítani, mert a régi szerverhez kötött tanúsítvány általában nem vihető át. Az ingyenes Let's Encrypt tanúsítvány csak akkor állítható ki, amikor a domain már az új szerverre mutat.

[Hivatalosan igazolt] A Let's Encrypt HTTP-01 ellenőrzése azt vizsgálja, hogy a domain alatt elérhető-e egy megadott fájl, ezért a DNS-váltás után működik. A DNS-01 ellenőrzés egy TXT rekorddal igazol, így a tanúsítvány a váltás előtt is kiállítható, ha a DNS-kezelő ezt támogatja. A Let's Encrypt tanúsítványai rövid érvényességűek, az automatikus megújítás ezért kötelező.

[Szakmai feltételezés] Ha a régi oldal HSTS-fejlécet használt, a látogatók böngészője csak HTTPS-en engedi megnyitni az oldalt. Ilyenkor a váltás és a tanúsítvány kiállítása között eltelt idő alatt hibaüzenetet láthatnak, ezért ezt a két lépést érdemes közvetlenül egymás után elvégezni, kis forgalmú időszakban.

Mi legyen az átvételi ellenőrzőlistán?

Az ellenőrzőlista négy részből áll, a feltérképezésből, a mentésből, a levelezésből és az átállás utáni ellenőrzésből. Minden pontot egyenként pipálj ki.

Feltérképezés

• Ki a domain igénylője, melyik regisztrátornál van, és mikor jár le?
• Hova mutatnak a névszerverek, és van-e hozzáférésed a DNS-hez?
• Melyik tárhelyen fut az oldal, és van-e előtte proxy?
• Hova mutat az MX, és mi az SPF, a DKIM és a DMARC beállítás?

Mentés

• A fájlok, az adatbázis és a postafiókok saját gépre vagy felhőbe letöltve.
• A DNS-zóna szövegfájlban.
• A visszaállítás kipróbálva az új helyen.

Levelezés

• Minden postafiók, alias és átirányítás létrehozva az új helyen.
• Első levélszinkron lefutott.
• Az új SPF és DKIM rekord élesítve, a régi küldők közül a még használtak benne maradtak.
• A felhasználók levelezőprogramjában átírva a szerver neve.
• A második szinkron lefutott a váltás után.

Átállás után

• Az oldal HTTPS-en, figyelmeztetés nélkül nyílik meg, a www és a www nélküli cím is.
• Az űrlapok levelei megérkeznek, és nem a spam mappában landolnak.
• Egy próbalevél külső címről beérkezik, és kifelé is kimegy.
• A Google Search Console és az analitika továbbra is adatot kap.
• A TTL visszaállítva a szokásos értékre.
• A régi tárhely felmondása csak ezek után.

Mikor érdemes segítséget kérni az átvételhez?

Akkor érdemes segítséget kérni, ha a domain nem a te nevеden van, ha nem éred el a DNS-t, vagy ha több postafiókot kell átvinni úgy, hogy közben senki ne maradjon le levelekről. Ezek a pontok viszik el a legtöbb időt, és itt okoz a legnagyobb kárt egy rossz sorrend.

Ha nem szeretnéd egyedül végigcsinálni, a Scheónál segítünk az átvételben. Feltérképezzük, hol van a domain, a DNS, a tárhely és a levelezés, elkészítjük a mentést, és a fenti sorrendben átállítjuk a rendszert, hogy közben az oldal és a levelezés is működjön. Minden átvétel más, ezért kiesésmentességet előre nem ígérünk, de a feltérképezés után pontosan elmondjuk, mire számíthatsz.

Források és további olvasnivalók

• ISZT Domainregisztrációs Szabályzat és Eljárásrend (domain.hu)
• ICANN Transfer Policy
• IETF RFC 7208 (Sender Policy Framework, SPF)
• IETF RFC 6376 (DomainKeys Identified Mail, DKIM)
• IETF RFC 7489 (DMARC)
• Let's Encrypt dokumentáció, Challenge Types
• Google Search Central, Webhely áthelyezése
• Google Workspace Admin súgó, MX rekordok beállítása