Ékezetes domainek a gyakorlatban – amit a levelezésről mindenképpen tudni kell

Mi az az IDN-domain, és hogyan működik?

A DNS-rendszer eredetileg kizárólag az ASCII-karakterkészletet (a–z, 0–9, kötőjel) támogatja. Az ékezetes és más nem angol karaktereket tartalmazó domainneveket ezért egy Punycode nevű kódolási eljárással alakítják át a háttérben.Példa:

A böngészők és a legtöbb modern alkalmazás automatikusan elvégzi ezt az átalakítást, így a felhasználó számára az ékezetes forma jelenik meg. A háttérben azonban minden lekérdezés Punycode formában fut.Magyar vonatkozásban a .hu zónában a NIC.HU (SZTNH által felügyelt registry) 2014 óta teszi lehetővé az ékezetes domainek regisztrációját. A támogatott karakterek: á, é, í, ó, ö, ő, ú, ü, ű, valamint a kötőjel és a számjegyek.

Az ékezetes domainek előnyei

• Márkahűség és megjegyezhetőség. A „HajósÉlmény.hu" természetesebb, mint a „HajosElmeny.hu".
• SEO-előny a magyar keresésekben. A felhasználók ékezetekkel gépelnek; a találati listában vizuálisan is kiemelkedik az ékezetes domain.
• Bizalomépítés. A helyesírásilag korrekt domain professzionálisabb benyomást kelt.
• Rövidebb, tisztább URL-ek a marketinganyagokban, névjegykártyákon.

A levelezés: ahol a legtöbb probléma lakozik

Az EAI-szabvány (Email Address Internationalization)

Az ékezetes e-mail-címek – például info@kávézó.hu – technikai alapját az RFC 6530–6533 szabványcsomag (EAI – Email Address Internationalization) adja, amely:

• lehetővé teszi nem ASCII karakterek használatát a helyi részben (infó@…) és a domainrészben (…@kávézó.hu) egyaránt,
• az SMTP-t az UTF8SMTP kiterjesztéssel egészíti ki,
• a fejlécek kódolását az RFC 2047 helyett natív UTF-8-ra váltja.

A valóság 2026-ban

Bár az RFC-k több mint egy évtizede léteznek, a gyakorlati támogatottság egyenlőtlen:

Tipikus hibajelenségek

1. Visszapattanó üzenetek (bounce): a fogadó MTA nem ismeri az UTF8SMTP kiterjesztést, és 550-es hibával elutasítja a kézbesítést.
2. Mojibake a fejlécekben: a „From:" vagy „Subject:" mező ékezetes karakterei kérdőjelekké vagy „é" szerű szekvenciákká torzulnak.
3. Spamszűrő téves riasztás: a Punycode-forma gyanúsnak tűnhet a heurisztikus szűrők számára (adathalász-gyanú).
4. Nemzetközi partnerkommunikáció: ha a címzett szervere nem EAI-képes, az üzenet egyszerűen nem érkezik meg – és a küldő nem feltétlenül kap hibaüzenetet.

Gyakorlati javaslatok az ITCsapat olvasóinak

1. Regisztráció és DNS

• Az ékezetes domaint mindig párosítsuk az ékezetmentes (transzliterált) változattal (kavezo.hu + kávézó.hu). Mindkettőt ugyanarra a zónára, ugyanazokra a rekordokra mutassuk.
• Az MX-rekordoknál ne az IDN-formát, hanem a Punycode-ot (xn--…) adjuk meg, mert egyes DNS-adminisztrációs felületek nem fogadják el a nyers ékezetes nevet.
• Állítsunk be SPF-, DKIM- és DMARC-rekordot mindkét domainváltozatra. A DKIM-aláírás d= mezőjében a Punycode-forma szerepeljen.

2. Levelezőszerver-konfiguráció

• Postfix: smtpd_utf8 = yes, smtputf8_enable = yes paraméterek ellenőrzése; a mydestination és virtual_mailbox_domains listába a Punycode-forma is kerüljön be.
• Dovecot: a mail_max_userip_connections és a karakterkódolási beállítások mellett győződjünk meg róla, hogy a mailbox-nevek UTF-8-kompatibilisek.
• Exchange / Microsoft 365: az ékezetes domain felvétele az Accepted Domains közé lehetséges, de az EAI-támogatás béta/preview státuszú lehet – tesztelés nélkül ne élesítsük.

3. Tesztelés

• Használjuk a verisign.com/tools vagy a idn.icann.org ellenőrzőit a Punycode-konverzió helyességéhez.
• Küldjünk tesztmailt különböző célállomásokra (Gmail, Outlook.com, saját szerver, külföldi ISP) az info@kávézó.hu címről, és figyeljük a fejléceket.
• Ellenőrizzük a Return-Path és DKIM-Signature mezőket: ne szerepeljen bennük kódolási hiba.

4. Fokozatos bevezetés

• Az ékezetes e-mail-címet aliasként vezessük be egy meglévő, ékezetmentes cím mellé. Így ha az EAI-útvonal megszakad, a hagyományos cím akkor is fogadja a leveleket.
• A névjegykártyán és a weboldalon az ékezetes forma jelenjen meg, de a láblécben vagy az impresszumban tüntessük fel a „biztonsági" ékezetmentes címet is.
• Ügyfélszerződésekben, számlázási rendszerekben egyelőre az ASCII-forma használata javasolt, mert számos ERP/CRM szoftver még mindig nem kezeli megfelelően az IDN-címeket.

5. Biztonság

• Az IDN-domainek klasszikus támadási felületet jelentenek a homográf-támadások számára (pl. a cirill „а" és a latin „a" összetéveszthetősége). A magyar ékezetes karaktereknél ez kisebb kockázat, de a felhasználók tudatosítása szükséges.
• A DMARC p=quarantine vagy p=reject szintű beállítása ékezetes domain esetén különösen fontos, mert a szűrők bizonytalanabbul kezelik.

Jogi és adminisztratív tudnivalók (magyar kontextus)

• A .hu IDN-domainekre ugyanazok a regisztrációs szabályok vonatkoznak, mint az ékezetmentesekre: a NIC.HU-nál bejelentett, magyarországi vagy EU-s kapcsolattartó szükséges.
• Védjegyügyi szempontból az ékezetes és az ékezetmentes változat külön domainnévnek minősül. Ha a márkanevet védjük, mindkét formát érdemes regisztrálni.
• Az elektronikus ügyintézésben (Ügyfélkapu, cégeljárás) a hivatalos rendszerek jellemzően nem fogadnak el ékezetes e-mail-címet – erre ügyeljünk az ügyfél-tájékoztatásban.

Összefoglalás

Az ékezetes domainek 2026-ra elérték azt a szintet, ahol webes jelenlétre már bátran ajánlhatók: a böngészők, a keresőmotorok és a közösségi média platformjai megbízhatóan kezelik őket. A levelezés terén azonban még mindig átmeneti időszakban vagyunk: az EAI-szabvány ugyan létezik, de az ökoszisztéma nem egységes.Az ITCsapat javaslat:

Regisztráljuk az ékezetes domaint, használjuk bátran a webcímben és a marketingben, de az e-mail-infrastruktúrát csak alapos tesztelés és fallback-mechanizmus mellett állítsuk át.

A kettős (ékezetes + ékezetmentes) stratégia még évekig a legbiztonságosabb út marad.

Ha kérdése van az IDN-domainek bevezetésével vagy az EAI-konfigurációval kapcsolatban, keresse az ITCsapat.hu ügyfélszolgálatát a support@itcsapat.hu címen.

Kulcsszavak: ékezetes domain, IDN, Punycode, EAI, UTF8SMTP, levelezés, RFC 6530, NIC.HU, DMARC, DKIM, magyar domain