רשומות TXT: SPF, DKIM, ואימות דומיין

רשומות TXT הן מגירת הזבל של DNS — שדה שמאחסן טקסט חופשי, שנועד במקור להערות קריאות לאדם כמו "שרת זה מתוחזק על ידי בוב." אז מישהו הבין: אם אפשר לפרסם טקסט שכל מחשב בעולם יכול לקרוא ולאמת, אפשר לפרסם הצהרות פומביות על הדומיין שלך. מי מורשה לשלוח את המיילים שלך. האם אתה הבעלים של הדומיין הזה. אילו מדיניות אבטחה אתה אוכף.

הטריק הזה הפך לתשתית קריטית. רשומות TXT מאמתות כיום מיליארדי מיילים מדי יום, מוכיחות בעלות על דומיין לגוגל ולמיקרוסופט, ומפרסמות מדיניות אבטחה שמגינות על משתמשים מפישינג. שדה שנועד לפתקי דבק הפך לבסיס של אמון במייל.

מה הן רשומות TXT

רשומות TXT מאחסנות טקסט חופשי ב-DNS. בשונה מרשומות A (שמחזיקות כתובות IP) או רשומות MX (שמפנות לשרתי דואר), רשומות TXT יכולות להכיל כל מחרוזת עד 255 תווים. הגמישות הזו הפכה אותן לאפשרות המועדפת כשרוצים להוסיף יכולות חדשות ל-DNS מבלי לשנות את הפרוטוקול.

example.com.  IN  TXT  "v=spf1 include:_spf.google.com ~all"

המשמעות: "כל מי שמבקש רשומות TXT עבור example.com יקבל את המחרוזת הזו." מה שהמחרוזת אומרת תלוי לחלוטין באפליקציה שקוראת אותה. DNS רק מאחסן ומגיש את הטקסט — הוא לא מפרש אותו.

הנה התובנה המרכזית: רשומות TXT פותרות בעיה יסודית. כיצד עושים הצהרה פומבית, שניתנת לאימות, על הדומיין שלך שכל מחשב בעולם יכול לבדוק? מפרסמים אותה ב-DNS.

SPF: הצהרה על מי מורשה לשלוח את המייל שלך

Sender Policy Framework (SPF) משתמש ברשומות TXT כדי לענות על שאלה פשוטה: "האם שרת זה מורשה לשלוח מייל מהדומיין הזה?"

ללא SPF, כל אחד יכול לזייף את כתובת "מאת" במייל. הפרוטוקול לא מתעניין בכך. תוקף שולח מייל שמתיימר להגיע מ-your-bank.com, ואין שום דבר במערכת המייל שאומר אחרת.

SPF משנה זאת. אתה מפרסם רשומת TXT שמפרטת את כל השרתים המורשים לשלוח מייל בשמך:

v=spf1 ip4:192.0.2.0/24 include:_spf.google.com -all

הפירוט:

• v=spf1 — זוהי רשומת SPF
• ip4:192.0.2.0/24 — טווח IP זה מורשה לשלוח את המייל שלנו
• include:_spf.google.com — שרתי גוגל מורשים לשלוח את המייל שלנו (למשתמשי Workspace)
• -all — דחה מייל מכל שרת אחר

כאשר שרת דואר מקבל הודעה שמתיימרת להגיע מהדומיין שלך, הוא בודק את רשומת SPF שלך. אם שרת השליחה אינו ברשימה, ההודעה נכשלת באימות.

הדירקטיבה האחרונה שולטת באכיפה:

• -all (כשל חמור): דחה מייל לא מורשה
• ~all (כשל קל): סמן כחשוד אך בצע מסירה
• ?all (ניטרלי): ללא אכיפה

SPF לא מאמת את תוכן ההודעה ולא מוכיח שהשולח הוא מי שהוא טוען להיות. הוא רק מאשר שהשרת השולח מורשה. אבל הוא מבטל את צורת הזיוף הקלה ביותר: המצאת כתובת "מאת".

DKIM: הוכחה שההודעה לא שובשה

DomainKeys Identified Mail (DKIM) הולך צעד קדימה. הוא חותם קריפטוגרפית על מיילים יוצאים כך ששרתי קבלה יכולים לאמת שההודעה לא שובשה בדרך.

1. שרת הדואר שלך חותם על כל הודעה יוצאת עם מפתח פרטי
2. החתימה מתווספת לכותרות המייל
3. שרת הקבלה מאחזר את המפתח הציבורי שלך מרשומת TXT
4. הוא משתמש במפתח הציבורי לאימות שהחתימה תואמת את ההודעה

מפתחות ציבוריים של DKIM מאוחסנים בתת-דומיין הנקרא "selector", המאפשר לך לסובב מפתחות מבלי להשפיע על כל המיילים שלך:

default._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA..."

המבנה:

• v=DKIM1 — זוהי רשומת DKIM
• k=rsa — סוג המפתח (הצפנת RSA)
• p= — המפתח הציבורי מקודד ב-Base64

מפתחות ציבוריים ארוכים — לעיתים כמה מאות תווים. מכיוון שמחרוזות TXT בודדות מוגבלות ל-255 תווים, DNS מפצל אותן למספר קטעים מצוטטים:

"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC" "3yBhP6aF7x9E2NvLmR8qT5uWz1jK4pQ6sD8cF9nV2hL" "remainder-of-key-here"

DNS משרשר אותם בעת החזרת הערך. רוב ספקי המייל מייצרים את המפתחות ומוסרים לך את רשומת TXT המדויקת להוספה — אין צורך להבין את הקריפטוגרפיה.

DKIM משלים את SPF. SPF מאמת את שרת השליחה. DKIM מוכיח שתוכן ההודעה שלם. יחד עם DMARC (מדיניות נוספת מבוססת רשומות TXT), הם מהווים אימות מייל מודרני.

אימות דומיין: הוכחת בעלות

כשנרשמים ל-Google Workspace, Microsoft 365, או רוב פלטפורמות SaaS, הן צריכות לאמת שאתה שולט בדומיין לפני מתן גישה.

המנגנון אלגנטי:

1. השירות מייצר אסימון אקראי ייחודי
2. אתה מוסיף את האסימון כרשומת TXT על הדומיין שלך
3. השירות מבצע שאילתת DNS לאסימון
4. אם הוא נמצא, הוכחת שיש לך שליטה

רשומות האימות של גוגל נראות כך:

example.com.  IN  TXT  "google-site-verification=rXOxyZounnZasA8Z7oaD3c14JdjS9aKSWvsR1EbUSIQ"

מיקרוסופט משתמשת ב:

example.com.  IN  TXT  "MS=ms12345678"

זה עובד כי רק מי שיש לו שליטה ב-DNS יכול להוסיף רשומות. פרסום אסימון האימות מוכיח בעלות.

כדאי לחשוב על זה — למה זה כל כך חכם. אימות מייל יכול להיות מיורט. אימות אתר דורש אתר קיים. אבל אימות DNS עובד לכל דומיין — אפילו אחד שרשמת לפני חמש דקות ללא הגדרות. אתה מוכיח שאתה הבעלים של משהו על ידי הדגמה שאתה יכול לדבר בשמו.

טיפול ברשומות ארוכות

מגבלת 255 התווים נובעת ממבנה חבילות DNS: כל מחרוזת TXT מקדימה לה בית אורך, ובית יכול להחזיק ערכים 0-255.

לנתונים ארוכים יותר, יש שתי אפשרויות:

שרשור מחרוזות (רשומה אחת, מספר מחרוזות):

example.com.  IN  TXT  "first-255-characters" "next-portion" "final-portion"

רשומות TXT נפרדות מרובות:

example.com.  IN  TXT  "v=spf1 include:_spf.google.com ~all"
example.com.  IN  TXT  "google-site-verification=rXOxyZounnZasA8Z..."
example.com.  IN  TXT  "MS=ms12345678"

שתיהן עובדות. בשאילתת רשומות TXT, מקבלים את כל הרשומות התואמות ומעבדים כל אחת בנפרד. דומיין יכול לפרסם מדיניות SPF, מפתחות DKIM ואסימוני אימות בו-זמנית ללא התנגשות.

מדוע ארכיטקטורה זו חשובה

רשומות TXT הפכו לבסיס לאבטחת האינטרנט משום ש-DNS פותר את הבעיה הקשה: פרסום מדיניות קריאת-מכונה במערכת מבוזרת, נגישה גלובלית.

DNS מספק:

• גישה אוניברסלית — כל שרת יכול לבצע שאילתה ללא אישורים
• סמכות — רק בעל הדומיין שולט ברשומות
• שמירה במטמון — ביצועים מבלי לפגוע באבטחה
• גמישות — פורמט טקסט מאפשר מנגנונים חדשים ללא שינוי פרוטוקול

לפני SPF ו-DKIM, לא היה אימות שולח במייל. כל אחד יכול היה לטעון ששולח מכל דומיין. בעזרת רשומות TXT, מערכת המייל הוסיפה אימות מבלי לעצב מחדש את SMTP. התשתית כבר קיימת — פשוט השתמשו בה.

הדפוס הזה חוזר על עצמו בכל רחבי תשתית האינטרנט. צריך להוכיח בעלות על דומיין? רשומת TXT. רוצה לפרסם מדיניות CAA השולטת באילו רשויות אישורים יכולות להנפיק אישורים לדומיין שלך? רשומת TXT. בונה מערכת אימות חדשה? כנראה רשומות TXT.

ללא צורך בתכונות DNS חדשות. ללא פרוטוקולים מורכבים. פשוט מחרוזות טקסט שכל ארגון יכול לפרסם וכל שרת יכול לקרוא.

שאלות נפוצות על רשומות TXT

האם אפשר לקבל רשומות TXT מרובות באותו דומיין?

כן. ניתן לפרסם כמה רשומות TXT שצריך על דומיין אחד. כל אחת משרתת מטרה שונה — אחת ל-SPF, אחת לאימות גוגל, אחת למיקרוסופט. כאשר שרת מבצע שאילתה לרשומות TXT שלך, הוא מקבל את כולן ומעבד את אלו שרלוונטיות לו.

מה קורה אם רשומת SPF חסרה או שגויה?

ללא SPF, לשרתי הקבלה אין דרך לאמת שהמייל שלך לגיטימי. ההודעות שלך נוטות יותר להגיע לתיקיות דואר זבל או להידחות לחלוטין. רשומת SPF שגויה — כמו אי-הכללת שרתי ספק המייל שלך — עלולה לגרום לכך שהמייל הלגיטימי שלך ייכשל באימות.

כמה זמן לוקח לשינויים ברשומות TXT להתפשט?

התפשטות DNS לוקחת בדרך כלל מדקות ועד שעות, בהתאם לערכי TTL (time-to-live) של הרשומות הקיימות שלך ולשמירה במטמון על ידי פותרי DNS. רוב שירותי האימות ממליצים לחכות עד 48 שעות, אם כי שינויים מופיעים לרוב הרבה יותר מהר. ניתן לבדוק את ההתפשטות באמצעות כלים כמו dig או בודקי DNS מקוונים.

האם צריך להבין קריפטוגרפיה כדי להגדיר DKIM?

לא. ספק המייל שלך מייצר את המפתחות ומוסר לך את רשומת TXT המדויקת להוספה. אתה מעתיק ומדביק אותה בתצורת DNS שלך. הספק מטפל בחתימה ובניהול המפתחות.

מדוע חלק מהשירותים מבקשים רשומות TXT בתת-דומיינים?

מערכות אימות שונות משתמשות במוסכמות שונות. DKIM משתמש בתת-דומייני selector (כמו default._domainkey.example.com) כדי לאפשר סיבוב מפתחות. חלק מהשירותים משתמשים בתת-דומיינים כדי להימנע מעומס על רשומות TXT של הדומיין השורשי שלך. המנגנון זהה — רק המיקום ב-DNS משתנה.