Hogyan állítsa be az SPF, DKIM és DMARC rekordokat (2026-os útmutató)

Gyakorlati útmutató az SPF, DKIM és DMARC beállításához: mit csinálnak az egyes rekordok, hogyan kerülnek be a DNS-be, milyen a helyes szintaxis, és hogyan ellenőrizhető a működésük.

Ha a domainjéről SPF, DKIM és DMARC nélkül, vagy rosszul beállított rekordokkal mennek ki e-mailek, valószínűleg az alábbiak valamelyike történik: az üzenetek spambe kerülnek, a Gmail vagy az Outlook elutasíthatja őket, vagy valaki olyan e-maileket küldhet, amelyek úgy néznek ki, mintha Öntől érkeztek volna. 2024 óta a Google és a Yahoo tömeges küldésnél megköveteli ezeket a rekordokat, ezért ez már nem csak „nice to have”.

Ebben az útmutatóban megnézzük, mit csinálnak az egyes rekordok, hogyan kell őket felvenni a DNS-be, és hogyan ellenőrizhető a teljes beállítás.

Mit csinálnak az egyes rekordok?

Képzelje el az e-mailt levélként. Ebben a hasonlatban:

• SPF azoknak a szervereknek és szolgáltatásoknak a listája, amelyek az Ön feladói címével küldhetnek levelet.
• DKIM egy pecsét, amely bizonyítja, hogy a levelet útközben nem nyitották fel és nem írták át.
• DMARC utasítás a címzettnek: mit tegyen azzal a levéllel, amely nem felel meg a pecsétnek vagy az engedélyezett küldők listájának, és hová küldjön jelentést.

Mindhárom beállítás a domain DNS-ében történik. Az SPF és a DMARC TXT rekord. A DKIM rekord típusa a szolgáltatótól függ - gyakran TXT, Microsoft 365 esetén általában CNAME. A weboldalon vagy az alkalmazásban nem kell módosítani semmit.

SPF: ki küldhet a domainjéről

Az SPF (Sender Policy Framework) egy TXT rekord a gyökérdomainen. Megmondja a fogadó levelezőszervereknek, mely IP-címek és szolgáltatások küldhetnek e-mailt a domain nevében.

Egy tipikus SPF rekord Google Workspace esetén így néz ki:

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

Microsoft 365 esetén:

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

Ha egy másik szolgáltatáson keresztül is küld hírlevelet, például Mailchimp vagy Bento segítségével, annak include részét ugyanabba a rekordba tegye:

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

Mire figyeljen:

• Egy domainnek csak egy SPF rekordja lehet. Két külön TXT rekord v=spf1 kezdettel hiba, amelyet a fogadó szerverek tartós sikertelenségként értelmezhetnek. Az új szolgáltatásokat mindig a meglévő rekordba írja be.
• Legfeljebb 10 DNS lekérdezés lehet. Minden include számít. Ha sok küldőszolgáltatást használ, nézze meg, valóban szükség van-e még mindegyikre.
• ~all vagy -all a rekord végén. A softfail (~all) biztonságosabb alapbeállítás. A szigorú -all értéket csak akkor használja, ha biztos benne, hogy minden legitim küldőszolgáltatás szerepel a rekordban.

DKIM: kriptográfiai aláírás az üzeneteken

A DKIM (DomainKeys Identified Mail) aláírást ad minden e-mail fejlécéhez. Az ellenőrzéshez használt nyilvános kulcs a DNS-ben jelenik meg, például selector._domainkey.sajatdomain.hu formában.

A selectort és a DNS rekord típusát a levelezési szolgáltató határozza meg, ezért pontosan azt kövesse, amit az adminfelület mutat:

1. A szolgáltató adminfelületén (Google Workspace, Microsoft 365, tárhelyszolgáltató) generáljon DKIM kulcsot.
2. A szolgáltató megmutatja a rekord típusát, a rekord nevét (például google._domainkey vagy selector1._domainkey) és a cél értéket.
3. A rekordot pontosan ebben a formában vegye fel a DNS-be. A Google Workspace és sok tárhelyszolgáltató v=DKIM1; p=... kezdetű TXT értéket használ, a Microsoft 365 saját domainekhez két CNAME rekordot: selector1._domainkey és selector2._domainkey.
4. A szolgáltató adminfelületén kapcsolja be az aláírást.

Gyakori selector a google Google Workspace esetén, a selector1 és selector2 Microsoft 365 esetén, illetve a default. Ha nem tudja a selectort, nyisson meg egy elküldött e-mail fejlécét, és keresse a DKIM-Signature mezőben az s= értéket.

DMARC: szabályzat és jelentések

A DMARC (Domain-based Message Authentication, Reporting and Conformance) egy szabályzatba kapcsolja össze az SPF-et és a DKIM-et. Nem elég azonban, hogy az SPF vagy a DKIM technikailag sikeres legyen - legalább az egyiknek igazodnia is kell ahhoz a domainhez, amelyet a címzett a From mezőben lát. Ez különösen fontos hírleveleknél és külső küldőszolgáltatásoknál.

A DMARC TXT rekordként kerül a _dmarc aldomainre:

_dmarc.sajatdomain.hu  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

A paraméterek jelentése:

• p=none - csak monitorozás, a címzettek nem blokkolnak semmit. Az első hetekre ideális.
• p=quarantine - a gyanús üzenetek kerüljenek spambe.
• p=reject - a gyanús üzeneteket utasítsák el. Céges domaineknél ez a célállapot.
• rua= - az a cím, ahová a címzettek összesített jelentéseket küldenek.

Az ajánlott folyamat az, hogy p=none értékkel kezd, néhány hétig figyeli a jelentéseket, majd ha biztos abban, hogy a legitim levelek átmennek, átvált quarantine, később pedig reject értékre. Hosszú távon a p=none nem védelem - lényegében azt mondja a címzetteknek, hogy ne avatkozzanak be a kézbesítésbe.

Hogyan ellenőrizze a beállítást?

A DNS módosítások a TTL szerint fokozatosan jelennek meg, általában néhány órán belül. Ezután ellenőrizze a beállítást:

1. Nyissa meg a domain DNS ellenőrzőt, és adja meg a domaint. Az eszköz ellenőrzi az MX, SPF, DMARC, DNSSEC és nameserver beállításokat, DKIM esetén pedig automatikusan megpróbálhat gyakori selectorokat.
2. Küldjön teszt e-mailt Gmailre, és az Eredeti megjelenítése nézetben ellenőrizze, hogy az SPF, DKIM és DMARC eredménye PASS.
3. Figyelje a DMARC jelentéseket - ezek megmutatják azokat a szolgáltatásokat is, amelyeket kihagyott az SPF-ből.

Gyakori hibák

A legtöbb gond nem az első DNS bejegyzésnél keletkezik, hanem később, amikor új szolgáltatás kerül be, és senki nem ellenőrzi újra a beállítást. Tipikus helyzetek:

• Új hírlevélküldő vagy CRM kerül be, és létrejön egy második SPF rekord. A domainnek csak egy v=spf1 kezdetű rekordja legyen. Az új szolgáltatást ne új TXT rekordként vegye fel, hanem adja hozzá az include részét a meglévő SPF-hez.
• A DKIM bent van a DNS-ben, de a szolgáltató mégsem írja alá az üzeneteket. A kulcs vagy CNAME felvétele önmagában nem elég. A DNS mentése után a levelezési szolgáltató adminfelületén általában külön be kell kapcsolni az aláírást, és a szolgáltatónak ellenőriznie kell a rekordot.
• A DMARC hibát mutat, pedig az SPF vagy a DKIM sikeres. Ellenőrizze az igazodást a From mezőben látható domainhez. Külső küldőszolgáltatásoknál gyakran saját küldődomaint kell beállítani, nem elég csak a fiókot hitelesíteni.
• A jelentések sehová sem érkeznek. rua nélkül a szabályzat működhet, de nem fogja látni, mely legitim szolgáltatások hibáznak. Használjon olyan címet vagy eszközt, ahol az első hetekben figyelni tudja a DMARC jelentéseket.
• Az aldomainek kimaradnak. Ha newsletter.sajatdomain.hu vagy mail.sajatdomain.hu alól küld levelet, ezeket a neveket is ellenőrizze. Nem elég csak a fődomaint megnézni.
• Túl korán teszteli a változást. A DNS nem frissül azonnal. Ha az ellenőrző még a régi állapotot mutatja, várja meg a TTL lejártát, és teszteljen újra.

A helyesen beállított SPF, DKIM és DMARC ma már alapvető domainhigiénia - hasonlóan a weboldalak HTTPS-éhez. Egy DNS rekordokra szánt óra javíthatja a kézbesíthetőséget, és sokkal nehezebbé teszi a domain hamisítását. Ha több domaint kezel, futtassa végig mindet a DNS ellenőrzőn - a leggyengébb domain általában az, amelyikről valaki megfeledkezett.