SPF a gyakorlatban: minden küldő feltérképezése

Modul 4: Kézbesíthetőség: SPF, DKIM és DMARC a gyakorlatban · Olvasási idő: 12 perc

Tanulási cél: E lecke után képes lesz felderíteni az összes olyan szolgáltatást, amely az Ön domainje nevében küld levelet, egyetlen SPF-rekordba foglalni őket, a kereséseket rekurzívan megszámolni a tízes határig, és tudatosan választani a ~all és a -all között.

Kulcsfogalmak: küldők leltára, boríték feladó (envelope sender, Return-Path), egyetlen SPF-rekord, include, redirect, a 10 DNS-keresés korlátja (RFC 7208, 4.6.4. szakasz), üres keresések (void lookups, legfeljebb 2), rekurzív számolás, permerror, flattening (laposítás), SPF aldomainekhez, SPF olyan domainen, amely nem küld levelet, ~all és -all

Gyors ismétlés

Az SPF-rekord egy TXT-rekord az Ön domainjén, amely v=spf1 kezdéssel felsorolja, mely szerverek küldhetnek levelet a domain nevében. A felépítés, a + - ~ ? jelek és a három leggyakoribb hiba (két rekord, +all, tíznél több keresés) a DNS-tanfolyam 4.3. leckéjében szerepel. Ha az SPF újdonság Önnek, azt olvassa el előbb. Ez a lecke a nehezebb részről szól: a gyakorlatban szinte senki nem tudja pontosan, kik is küldenek levelet a domainje nevében.

1. lépés: a leltár

Az SPF csak akkor működik, ha minden küldő szerepel benne. Ha egyet elfelejt, az a levél spambe kerül, vagy elutasításra kerül, amint szigorítja a DMARC-ot. Ezért nézze végig ezt a listát. Egy átlagos kisvállalkozásnál gyorsan összejön öt-hat is:

Két jó módszer a megtalálásukra:

1. Fejlécek olvasása. Küldjön magának levelet minden rendszerből (egy számlát, egy jelszó-visszaállítást, egy teszt hírlevelet), és nézze meg a fejlécekben a Return-Path és az Authentication-Results mezőket (1.5. lecke). Ott láthatja, melyik domainen és szerveren keresztül érkezett.
2. DMARC-jelentések. Állítsa a DMARC-ot p=none értékre, jelentési címmel (4.4. lecke). Néhány hét múlva a jelentésekben (4.5. lecke) láthatja az összes szervert, amely a domainje nevében küldött levelet, azokat is, amelyekről megfeledkezett. Ez a legmegbízhatóbb leltár.

Nem minden szolgáltatás tartozik az SPF-be

Itt szokott a dolog gyakran félresiklani. Az SPF a boríték feladóját (a Return-Path-et) vizsgálja, nem a Feladó (From) mezőt. Sok hírlevél- és küldőszolgáltatás saját domainjén lévő Return-Path-tel küld, például bounce-123@mail.mailer.example címmel. A fogadó ilyenkor a mailer.example SPF-rekordját ellenőrzi, nem az Önét. Az adott szolgáltatás include-ja az Ön rekordjában ilyenkor semmit nem ér, csak egy keresésbe kerül.

Amire a szolgáltatásnak valóban szüksége van ahhoz, hogy átmenjen a DMARC-on, az egy az Ön domainjéhez tartozó DKIM-aláírás (4.3. lecke), vagy egy saját Return-Path aldomain Öntől (például bounce.example.com CNAME-ként a szolgáltatásra mutatva). Olvassa el tehát a szolgáltatás útmutatójában, mit kér. Ha azt írja, hogy "tegyen include: bejegyzést az SPF-jébe", akkor tegye meg. Ha csak azt írja, hogy "hozza létre ezeket a CNAME-rekordokat a DKIM-hez és a bounce-domainhez", akkor a főrekordban semmit nem kell módosítani. A 7. modul ezzel részletesebben foglalkozik.

2. lépés: egy rekord, és pontos számolás

Minden küldő egyetlen rekordba kerül. Tegyük fel, hogy a leltára ezt eredményezi: a tárhelyszolgáltatója levelezőszervere, Microsoft 365 néhány munkatárshoz, a könyvelőprogramja és egy ügyfélszolgálati rendszer. Ekkor a rekord például így néz ki:

example.com.  3600  IN  TXT  "v=spf1 a mx include:spf.hosting.example include:spf.protection.outlook.com include:_spf.boekhoud.example include:mail.helpdesk.example ~all"

Hány keresés ez? Számolja meg minden a, mx, include, exists, ptr és redirect elemet, majd számolja hozzá mindazt is, ami az egyes include-ok mögötti rekordokban található:

11-nél a fogadó permerror hibát ad: ekkor a teljes SPF-rekord érvénytelenné válik, egyetlen küldő esetében sem számít. A saját levelezőszerveréről küldött levelét tehát rosszabbul ítélik meg, mert az ügyfélszolgálati rendszer három keresésbe kerül. A dolog alattomos oldala: a rekordja ma lehet 9, holnap pedig 11, anélkül, hogy Ön bármit módosítana, mert egy szolgáltatás kibővíti a saját rekordját.

Emellett: legfeljebb két üres keresés

Az RFC 7208 az úgynevezett void lookups (üres keresések) fogalmát is ismeri: olyan kereséseket, amelyek semmit nem adnak eredményül (a név nem létezik, vagy nincs SPF- vagy címrekordja). Ha kettőnél több ilyen van, az szintén permerror hibát okoz. Ez leginkább régi include bejegyzésekkel fordul elő, olyan szolgáltatásoktól, amelyeket már nem használ, és amelyek eltávolították a rekordjukat, vagy egy a: bejegyzéssel, amely már nem létező szerverre mutat. Érdemes tehát rendet tenni.

3. lépés: vissza a tíz alá

Ha a tíz fölött van, négy megoldás létezik, a legjobbtól a legkevésbé jóig:

1. Távolítsa el, ami felesleges. Szolgáltatások, amelyeket már nem használ. Szolgáltatások, amelyek saját Return-Path-tel küldenek (lásd fent), és így nem tartoznak az SPF-jébe. Az a, ha a weboldala maga nem küld levelet. Az mx, ha az MX-je olyan szolgáltatásra mutat, amely már szerepel egy include-ban a rekordjában.
2. Használjon aldomaint. Egy szolgáltatás küldjön a nieuws.example.com vagy factuur.example.com aldomainről. Ez az aldomain saját SPF-rekordot kap, csak azzal a szolgáltatással, és nem számít bele a főbb domain tíz keresésébe. A DMARC-illeszkedés (alignment, 4.4. lecke) alapértelmezetten az aldomainekre is érvényes.
3. Használjon ip4: és ip6: bejegyzéseket a saját, fix szervereihez. Ezek nem kerülnek keresésbe. Ezt csak olyan címeknél tegye, amelyeket Ön kezel, és amelyek nem változnak.
4. Flattening (laposítás) (az összes include lecserélése az azok mögött éppen álló IP-címekre). Ez nullára csökkenti a számot, de a rekord már nem lesz pontos, amint egy szolgáltatás megváltoztatja a címeit, a nagy szolgáltatások pedig ezt rendszeresen megteszik. Csak olyan eszközzel tegye ezt, amely automatikusan frissíti, és inkább egyáltalán ne tegye.

redirect vagy include?

A redirect= azt jelenti: használja a másik domain SPF-rekordját e rekord helyett. Egy keresésbe kerül, akárcsak egy include. Hasznos, ha sok domainje van, amelyeknek pontosan ugyanazt a szabályzatot kell kapniuk: v=spf1 redirect=_spf.example.com minden domainen, a tényleges rekord pedig egyetlen helyen. Egy redirect=-et tartalmazó rekordnak nem lehet all bejegyzése, mert akkor a redirect figyelmen kívül marad. A Gmail is ezt használja: a gmail.com rekordja v=spf1 redirect=_spf.google.com.

4. lépés: ~all vagy -all?

E tanfolyam ajánlása, megegyezően a DNS-tanfolyaméval:

• Kezdje ~all-lal (softfail). Az olyan szervertől érkező levél, amely nem szerepel a rekordjában, gyanúsnak minősül, de általában nem kerül azonnal elutasításra. Ha megfeledkezik egy küldőről, a kár korlátozott.
• Térjen át -all-ra (fail), ha biztos benne, hogy minden küldő szerepel a rekordban, például miután néhány hétig figyelte a DMARC-jelentéseket, és nincs több ismeretlen forrás.

A DMARC bevezetésével a különbség kisebb, mint sokan gondolnák. A DMARC azon az elven dönt, hogy "az SPF vagy a DKIM sikeres és illeszkedik-e". A softfail a DMARC szempontjából egyszerűen "nem sikeres". A valódi védelem tehát egy szigorú DMARC-szabályzatból fakad, nem a -all-ból. Egyes fogadók a -all esetén már a DMARC-elbírálás előtt elutasítják a levelet; ez egy ok arra, hogy csak akkor válassza a -all-t, ha a rekordja valóban teljes.

Egy domain, amely sosem küld levelet

Vannak olyan domainjei, amelyek sosem küldenek levelet (egy régi márkanév, egy elgépelés-domain)? Védje meg őket a visszaélésektől a következővel:

example.org.         IN  TXT  "v=spf1 -all"
_dmarc.example.org.  IN  TXT  "v=DMARC1; p=reject"
example.org.         IN  MX   0 .

Itt a -all rögtön helyes: senki nem jogosult levelet küldeni. Az utolsó sor egy null MX (RFC 7505): "ez a domain nem fogad e-mailt". Az example.com maga is pontosan így van beállítva.

A gyakorlatban: így néz ki egy kezelőpanelen

A WebOké tárhelycsomagjainál alapértelmezetten a v=spf1 a mx include:webawere.nl ~all érték szerepel. Ha szolgáltatást ad hozzá, ezt a rekordot módosítja (a DirectAdminben: DNS Management, a ceruza ikon az SPF-rekord mögött, Beleértve a domaineket mező; a Fiókomban: az SPF-segéd a DNS fülön). Hagyja meg az include:webawere.nl bejegyzést, amíg a levelezése vagy a weboldala ezeken a szervereken keresztül fut. Más szolgáltatóknál az alapértelmezett include másképp hangzik, de az elv ugyanaz: egészítse ki, ne hozzon létre egy második rekordot.

Összefoglalás

• Először készítsen leltárt az összes küldőről; a DMARC-jelentések és a fejlécek segítenek ebben.
• Egy saját Return-Path-tel rendelkező szolgáltatás nem tartozik az SPF-jébe; ahhoz az Ön domainjéhez tartozó DKIM szükséges.
• Számoljon rekurzívan: minden include, a, mx, exists, ptr és redirect, az include-okon belül is. Tíz fölött, vagy kettőnél több üres keresésnél, permerror lesz az eredmény.
• Térjen vissza a tíz alá rendrakással és aldomainek használatával; a flattening csak automatikus karbantartással.
• Kezdje ~all-lal, térjen át -all-ra, ha biztos a dolgában. A sosem küldő domainek esetén: -all, DMARC reject és null MX.

Kvíz

Feladat

Z4.2 feladat: A domén SPF-jének rekurzív megszámoltatása. Adja meg a saját domainjét (vagy a sidn.nl-t, ha nincs saját domainje). Először saját maga számolja meg, hány DNS-keresésbe kerül az SPF-rekord, beleértve az include-okon belüli mindent, és adja meg a számot, a rekord végével együtt (~all, -all, ?all vagy +all). A program élőben újraszámolja, beleértve az üres kereséseket is, és megmutatja a fastruktúrát.

O4.2 feladat: A feladó rendszerek leltára. A leckében szereplő táblázat segítségével készítsen listát az összes olyan rendszerről, amely az Ön domainje nevében küld levelet. Mindegyiknél jegyezze fel: melyik szerveren vagy szolgáltatáson keresztül megy, tartozik-e az SPF-be (saját Return-Path-szel rendelkezik-e vagy sem), és aláírja-e DKIM-mel az Ön domainjét. Küldjön legalább két rendszerből tesztlevelet saját magának, és jegyezze fel a fejlécekből a Return-Path domainjét és a DKIM domainjét (d=).

Bővebben

Az e cikkekben leírt lépések a WebOké kezelőpaneleire vonatkoznak; más szolgáltatóknál hasonlóan működik.

• Ingyenes DNS-tanfolyam 4.3: SPF: ki küldhet levelet a domainje nevében?
• DirectAdmin útmutató 5.7: SPF beállítása és kiegészítése
• Hogyan működik az SPF-rekord a DNS-ben?
• SPF-rekord hozzáadása vagy módosítása a DirectAdminban
• WebOké útmutató 5.5: DNS-segédeszközök: MX, SPF, DMARC, CAA és SRV
• RFC 7208 (SPF), 4.6.4. szakasz (korlátok) és 6.1. szakasz (redirect); RFC 7505 (null MX)