Miért fontosak a DNS rekordok az üzleti levelezésben? – SPF, DKIM

A rövidítéseket senki sem szereti. De azt sem szeretik, ha a nevükben más küld ki tömegesen emaileket, amikkel felhasználók százait verik át, és emiatt rajtuk csattan az ostor. Pedig ha jól van beállítva a levelezés, akkor erről leggyorsabban az a cég szerez tudomást, akinek a nevében a spoofingot elkövetik a támadók.

Az SPF, DKIM és DMARC az a három DNS rekord, ami eldönti, hogy a kimenő leveled megérkezik-e a címzetthez, vagy spambe megy, esetleg elutasításra kerül.

Ehhez egy pillanatra képzeljük magunkat a fogadó szerver helyébe (Gmail, Outlook, Yahoo stb.). Kapunk egy levelet, amire így reagálunk: „Jön egy levél a pelda.hu nevében. Honnan tudjam, hogy ez tényleg a cég szervere, és nem egy csaló?”

Kell nekünk valamiféle hitelesítés, hogy tudjuk, ezt a levelet kézbesíthetjük-e a postafiókba, vagy el kell utasítanunk. De vajon hol találunk ilyen hitelesítést?

Ekkor jön a képbe az SPF (Sender Policy Framework) rekord, ami azt mutatja:

„A ceg.hu nevében EZEK az IP-k / szolgáltatók küldhetnek levelet.”

A fogadó szerver tehát ellenőrzi, erről az IP-címről jött-e a levél. Ha a levelet nem ezen IP-k valamelyikéről küldték, az gyanús. És persze, mondhatjuk, hogy miért ilyen bonyolult ez, hiszen ha az én SMTP szerverem IP-jéről megy a levél, és ez nyilván szerepel az SPF rekordban, akkor miért aggódnék? Ám ha a cégünk használ még pl. számlázót, hírlevél rendszert, CRM-et, amik küldhetnek levelet a cég nevében (fizetési felszólítás, hírlevél vagy promóciós ajánlat), és ezen szofverek mail szerverének IP-je nem szerepel az SPF rekordban, akkor jönnek a problémák.

A fogadó oldal joggal fogja hinni, hogy spoofing történik, vagyis valaki az adott cég nevében küld rosszindulatú levelet. Így néz ki egy SPF rekord:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:spf.mailgun.org ip4:192.0.2.10 -all

az include: után lehet írni azokat az SPF include sorokat, amiket az adott szolgáltató (aki a nevünkben küldene emaileket) megad. Fontos technikai korlát azonban, hogy 10 DNS lookup a limit, vagyis ennél több külső szervernek nem engedélyezhetjük, hogy a nevünkben emaileket küldjön.

A DKIM (DomainKeys Identified Mail) egy egy újabb eszköz arra, hogy biztosak lehessünk egy levél hitelességét illetően. A szerver ugyanis minden kimenő levelet digitálisan aláír, a fogadó fél pedig a DNS-ben lévő publikus kulccsal ellenőrzi.

Ez bizonyítja, hogy:

• a levél nem módosult útközben
• tényleg az küldte, aki a domainhez tartozik

Amikor tehát arra panaszkodnak, hogy „Néha nem kapják meg a leveleimet”, „a Gmailes partneremnél mindig spambe megy a levél” vagy „a számlázó rendszerből küldött levelek nem érnek célba”, az szinte biztos, hogy SPF/DKIM/DMARC hiba.

Ez a hiba pedig független attól, hogy a domainünkhöz tartozó levelezést hol oldjuk meg. Ezeket a beállításokat mindig ott kell megtennünk, ahol a domainhez tartozó szerverek vannak, tehát ebben mindig a hoszting szolgáltató segítségét kérhetjük.

Nálunk levelezel? Hasonló gondod van? Írj nekünk, természetesen megkeressük neked a hibát.

2026.04.02.

Kérdése van? Hivjon minket bizalommal!

A nap 24 órájában elérhetőek vagyunk, hogy válaszoljunk kérdéseire és tanácsot adjunk szolgáltatásainkhoz.

+36 20 340 3333

Elérhetőségeink

ZeroTime Services
1037 Budapest, Montevideo utca 9.
[email protected]
Adószám: 23386031-2-41
Bankszámlák:
BinX 30400001-00000000-22057952
KH Bank HU66 1040 3057 5052 7075 7757 1006
Wise Bankszámla: HU62 12600016 17529307 13111412
EU Adószám: HU23386031
Cégjegyzék szám: 01-09-454083
Európai Egyedi Azonosító: EUID: HUOCCSZ.01-09-454083

Hibabejelentés

E-mail: [email protected]
Web: Hibajegy nyitása
Telefon: +36 20 340 3333

Adatközpont

Szervereink a Drávanet adatközpontjaiban kerültek elhelyezésre.
Adatkezelés adatvédelmi nyilvántartásba vételhez használható címek:
Budapest 1132, Victor Hugo utca 18-22.
Budapest 1138, Váci út 188.