Ha a legutóbbi posztokból már megértettük, mit is azok a DNS rekordok, lehetséges, hogy szeretnénk ezeket magunk beállítani. Nincs is izgalmasabb, mint a kisvállalkozók egészséges magabiztossága, akik mindent megtanulnak azért, hogy alacsonyan tartsák a költségeket, és minél többet megtudjanak a világ ügyes-bajos dolgairól. Amíg nem nő nagyra a cég, ez az úttörő szakasz tényleg sok kalandot rejt. Mi segítünk ebben, de ha nem megy, inkább írjatok a ZTS support email címére.

Í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-ok azok, amiknek megadjuk a jogot, hogy a nevünkben emailt küldjenek. Nem vészesen bonyolult egy ilyen kód, ám azért el lehet ezt is rontani. Lássuk, hogy milyen gyakori hibákat követnek el a topdeliverability.com cikke alapján.

1. Túl sok DNS lekérdezés

Az SPF maximum 10 DNS lookupot engedélyez (pl. egymásba ágyazott include-ok, A rekord feloldás, MX rekord feloldás, PTR rekord feloldás stb. összesen nem lehet több 10-nél).

A legtöbb ellenőrző rendszer, ha még a 10-es limit elérése előtt sikeresen tudja hitelesíteni a küldőt, akkor PASS eredményt ad. Ha viszont túlléped a 10 lekérdezést, az PermError hibát eredményez.

2. Több SPF rekord szerepel a DNS-ben

Ez akkor fordul elő, amikor valaki további IP-címeket vagy harmadik fél szolgáltatókat szeretne hozzáadni az SPF rekordhoz, de nem az eredeti rekordot bővíti, hanem létrehoz egy második TXT rekordot.

Például:

pelda.hu IN TXT "v=spf1 include:spf.protection.outlook.com -all"
pelda.hu IN TXT "v=spf1 ip4:1.2.3.4 -all"

Helyesen így kellene kinéznie:

pelda.hu IN TXT "v=spf1 include:spf.protection.outlook.com ip4:1.2.3.4 -all"

Ha több SPF rekord van, az SPF szabvány szerint PermError hibát kellene adni.

Az Office 365 elnézőbb, és a két SPF rekordot egyként próbálja értelmezni (feltételezve a valós szándékot), de a legtöbb fogadó szerver nem ilyen megengedő.

3. Felesleges include-ok

Az Office 365 működéséhez például elegendő az alábbi:

include:spf.protection.outlook.com

Nincs szükség az alábbiakra:

include:outlook.com
include:spf.messaging.microsoft.com
include:spf.frontbridge.com

Bár ezekkel is működik az SPF, feleslegesen közelebb visznek a 10 DNS lookup limithez, ami megnehezíti további külső szolgáltatók hozzáadását.

Ha ezek közül bármelyik szerepel az SPF rekordban, célszerű lecserélni erre:

include:spf.protection.outlook.com

4. ip4: helyett ip: használata

Például:

pelda.hu IN TXT "v=spf1 ip4:1.2.3.4 ip4:5.6.7.8 ip:9.10.11.12 -all"

Bizonyos szolgáltatók PermError hibát adhatnak az „ip:”-re.

5. Hibás idézőjel-formázás

Több idézőjel használható SPF rekordban, ha megfelelően vannak elválasztva szóközzel:

pelda.hu IN TXT "v=spf1" "include:spf.protection.outlook.com" "ip4:1.2.3.4" "include:_spf.google.com" "-all"

Azonban sokan hibásan próbálnak így külső szolgáltatókat hozzáadni, és a rekord szóköz nélkül összefűződik:

"v=spf1include:spf.protection.outlook.comip4:1.2.3.4include:_spf.google.com-all"

Ebben az esetben a fogadó szerverek úgy kezelik, mintha nem is lenne SPF rekord.

Helyesen:

"v=spf1 " "include:spf.protection.outlook.com " "ip4:1.2.3.4 " "include:_spf.google.com " "-all"

Jobb azonban egyetlen rekordként, felesleges idézőjelek nélkül megadni, mert az SPF rekord teljes hossza korlátozott.

6. 255 karakter túllépése

Ha az SPF rekord meghaladja a 255 karaktert, akkor több részre kell bontani, szóközzel elválasztva, maximum két komponensre:

pelda.hu IN TXT "v=spf1 include:spf.protection.outlook.com <további elemek> ip4:1.2.3.4 " "ip4:5.6.7.8 -all"

Ha túlléped a 255 karaktert, sok fogadó PermError hibát adhat, de ez implementációfüggő.

7. Az SPF azonosító részek hiánya

Az alábbiak mind hibásak:

"include:spf.protection.outlook.com ip4:1.2.3.4 -all"

"v=spf1 include:spf.protection.outlook.com ip4:1.2.3.4"

"include:spf.protection.outlook.com ip4:1.2.3.4"

Az elsőből hiányzik a v=spf1, a másodikból hiányzik a lezáró policy (-all, ~all stb.), a harmadikból mindkettő hiányzik.

Ilyenkor a fogadó szerverek PermError hibát adhatnak vagy úgy kezelik, mintha nem lenne SPF rekord.

8. +all használata

Elfogadható policy-k:

• -all
• ~all
• ?all

Ne használj +all-t:

pelda.hu IN TXT "v=spf1 ip4:1.2.3.4 +all"

Ez gyakorlatilag lehetővé teszi, hogy bárki a világon a te domained nevében küldjön levelet.

Több nagy fogadó rendszerrel is egyeztetve felmerült, hogy a jövőben az ilyen rekorddal rendelkező domainek esetén már SMTP szinten elutasítás történhet.

9. Túl nagy IP-tartományok

A /16-nál szélesebb IP tartomány általában indokolatlanul széles:

pelda.hu IN TXT "v=spf1 ip4:1.0.0.0/2 -all"

Itt az ip4:1.0.0.0/2 azt jelenti, hogy az első 2 bit fix, a többi szabadon változhat, a rendszer el fogja fogadni. Ez brutálisan sok IP címet jelent. A ip4:1.0.0.0/32 jelent 1 db IP-címet, a ip4:1.0.0.0/16 már 65 536 IP-re ad engedélyt.

10. PTR használata SPF-ben

Például:

pelda.hu IN TXT "v=spf1 ptr ptr:pelda.hu -all"

Ez azt jelenti, engedélyezett minden olyan IP, amelynek a reverse DNS (PTR rekordja) a pelda.hu domainre mutat.

Nincs ezzel óriási gond, csak annyi, hogy az SPF specifikáció szerint a PTR használata deprecated (nem ajánlott). Bár érthető az indok a használatára, általánosságban nem javasolt, mert lassú (reverse DNS lekérdezés kell), megbízhatatlan. A reverse DNS nem erős hitelesítési módszer.