Cloudflare Email Service: a két DKIM-rekord nem duplikáció

Ha ugyanazon a domainen használod a Cloudflare Email Sending és Email Routing funkcióját, tartsd meg mindkét DKIM-rekordot: a Cloudflare hitelesítési útmutatója a küldéshez a cf-bounce._domainkey, a továbbításhoz a cf2024-1._domainkey szelektort rendeli. A külön névhez külön nyilvános kulcs tartozik, így az egyik rekord nem helyettesíti a másikat.

Az SPF-nél a teljes DNS-nevet nézd: a gyökérdomainen már meglévő szabályba kell beilleszteni a Cloudflare elemét, ha más szolgáltató is jogosult levelet küldeni. A cf-bounce aldomain saját SPF- és MX-rekordjai külön maradnak. Az Email Routing a gyökérdomain MX-rekordjait használja a bejövő levelek fogadására.

Melyik rekord melyik funkcióhoz tartozik?

A Cloudflare domainkonfigurációs leírása a küldés visszapattanó leveleihez tartozó rekordokat a cf-bounce aldomainhez, a bejövő levelek továbbításához szükséges MX- és SPF-rekordokat pedig a gyökérdomainhez rendeli. Az alábbi példákban a yourdomain.com helyére a saját domained kerül; a DNS-szerkesztő a gyökérdomaint gyakran @ jellel jelöli.

• Email Sending, cf-bounce.yourdomain.com: az MX-rekordok a visszapattanó leveleket vezetik a Cloudflare-hez. Ugyanezen a néven az SPF TXT-rekord mintája v=spf1 include:_spf.mx.cloudflare.net ~all.
• Email Sending, cf-bounce._domainkey.yourdomain.com: a DKIM TXT-rekord a küldéshez létrehozott nyilvános kulcsot tartalmazza. A pontos értéket a vezérlőpultból kell átvenni.
• Email Routing, yourdomain.com: az MX-rekordok a domainre érkező leveleket a Cloudflare kiszolgálóira irányítják. A gyökérdomain SPF TXT-rekordjának Cloudflare-eleme az include:_spf.mx.cloudflare.net.
• Email Routing, cf2024-1._domainkey.yourdomain.com: ez a továbbításhoz tartozó, külön DKIM TXT-rekord neve és nyilvános kulcsa.

A két SPF-rekord mintaértéke azonos lehet, de eltérő DNS-néven szerepelnek. Ezért azonos szövegük önmagában nem ok a cf-bounce rekord törlésére. A _dmarc.yourdomain.com néven található DMARC-szabályzatot is érdemes megőrizni és átnézni, különösen ha már szigorú elutasítási szabályt alkalmazol.

Mikor kell összevonni az SPF-rekordokat?

Azonos DNS-néven egyetlen v=spf1 kezdetű szabály maradjon. Ha a gyökérdomainen egy másik levelezőszolgáltató SPF-rekordja már létezik, annak szükséges elemeit és az include:_spf.mx.cloudflare.net elemet ugyanabba a TXT-értékbe kell rendezni. A Cloudflare SPF-hibaelhárítási útmutatója a többszörös rekordok összevonását írja elő, és az SPF-ellenőrzés összesen legfeljebb tíz DNS-kereséses korlátjára is figyelmeztet.

Feltételes példa, ha a Google Workspace valóban küld levelet a gyökérdomain nevében: v=spf1 include:_spf.mx.cloudflare.net include:_spf.google.com ~all. Ez egyetlen szabály, egyetlen v=spf1 kezdettel és egyetlen lezáró all mechanizmussal. A szolgáltatók elemeit a tényleges küldési beállításaid alapján válaszd ki; a példa bemásolása fölöslegesen engedélyezhet egy nem használt szolgáltatót.

Az összevonás előtt számold át az include és más DNS-keresést kiváltó mechanizmusok teljes költségét, a hivatkozott SPF-rekordokban végzett keresésekkel együtt. A megengedett szám túllépése SPF-hibát okozhat akkor is, ha maga a TXT-érték helyesnek látszik. Ha a gyökérdomain rekordja zárolt, az Email Routing Settings oldalán oldható fel szerkesztéshez; az Email Sending cf-bounce rekordjait a szolgáltatás kezeli.

Miért marad külön a DKIM és az MX?

A DKIM-nél a teljes rekordnév számít, nem az, hogy mindkét érték v=DKIM1 szöveggel kezdődik. A cf-bounce._domainkey és a cf2024-1._domainkey külön szelektor: a fogadó rendszer a levél aláírásában megadott szelektor alapján keresi meg a megfelelő nyilvános kulcsot. Ha az egyik kulcsot a másik név alá másolod, az nem pótolja a hiányzó rekordot. Egy további levélküldő szolgáltató saját szelektora szintén külön néven maradhat.

Az MX-rekordoknál hasonlóan a rekord DNS-neve dönti el a feladatot. A gyökérdomain MX-rekordjai a felhasználóknak címzett bejövő levelek útvonalát adják meg, a cf-bounce aldomain MX-rekordjai pedig a küldött levelek visszapattanó válaszait kezelik. Az Email Routing használatához a gyökérdomainen a Cloudflare által megadott MX-beállítás kell; ugyanott egy korábbi külső postafiókszolgáltató MX-rekordjai ütközést okoznak. Az MX-célokat és prioritásokat a saját domain vezérlőpultban látható értékeihez igazítsd.

Ellenőrzés DNS-lekérdezéssel és a vezérlőpultban

A parancsokban cseréld le a yourdomain.com nevet a saját domainedre. A válaszokat DNS-névenként értelmezd: az üres találat hiányzó rekordra vagy még nem látható módosításra utalhat, míg az SPF esetében az azonos néven megjelenő több v=spf1 érték ütközést jelez.

1. dig TXT yourdomain.com +short — keresd a gyökérdomain SPF-szabályát, és nézd meg, szerepel-e benne minden tényleges küldő szükséges eleme.
2. dig TXT cf-bounce.yourdomain.com +short — ellenőrizd a küldéshez tartozó, külön SPF-rekordot.
3. dig TXT cf-bounce._domainkey.yourdomain.com +short és dig TXT cf2024-1._domainkey.yourdomain.com +short — mindkét néven a megfelelő DKIM-kulcsnak kell megjelennie.
4. dig MX yourdomain.com +short és dig MX cf-bounce.yourdomain.com +short — külön ellenőrizd a bejövő levelek és a visszapattanó levelek útvonalát.

Ezután nyisd meg külön a Compute > Email Service > Email Sending > Settings és a Compute > Email Service > Email Routing > Settings oldalt. Mindkettő a saját rekordjainak állapotát mutatja. A Locked és az Unlocked is jelenthet helyesen beállított rekordot: a különbség az, hogy a szolgáltatás zárolva kezeli-e. A Not Found jelzésnél vesd össze a DNS-válaszban látható teljes nevet és értéket a megfelelő Settings oldallal, majd a DNS-változás terjedése után ismételd meg a lekérdezést.

Olvassa el ezt is:

• DMARC beállítása: a p=reject nem lehet az első lépés
• Cloudflare Workers vagy AWS Lambda: a várakozási idő írhatja át a számlát
• Vercel vagy Cloudflare Pages: a gyorsaság helyett a számla dönthet