כך כותבים רשומות SPF, DKIM ו-DMARC ב-DNS בלי לטעות בתחביר
כתיבת רשומות spf dkim dmarc records נראית טכנית פשוטה, אבל טעות תחבירית אחת - רשומת SPF כפולה, selector שלא תואם, או p=reject שהופעל מוקדם מדי - מספיקה כדי שקמפיין cold email B2B ממוקד ייפול לספאם עוד לפני שאיש קשר יראה אותו. המדריך הזה מפרק את התחביר של כל אחת משלוש הרשומות, מראה איך check spf dkim dmarc records ו-verify spf dkim dmarc records בפועל, ומסמן את הטעויות שחוזרות הכי הרבה אצל דומיינים חדשים.
- spf dkim dmarc records הן שלוש רשומות DNS נפרדות שפועלות יחד, לא תחליף זו לזו
- שתי רשומות SPF על אותו דומיין תמיד לא תקינות - חייבים רשומת TXT אחת מאוחדת בלבד
- SPF מוגבל ל-10 DNS lookups מצטברים; חריגה מבטלת את כל הרשומה עם permerror
- DMARC כדאי להתחיל ב-p=none ולעלות בהדרגה רק אחרי ניטור דוחות rua
- אימות DNS תקין מפחית תלונות ספאם ומשלים, לא מחליף, את חובות תיקון 40 לחוק התקשורת
למה תחביר DNS שגוי הופך cold email B2B לספאם
כשמדובר בקמפיין cold email ממוקד ל-B2B, כל טעות קטנה ברשומות DNS מספיקה כדי שספק כמו Gmail או Outlook יסמן את הדומיין כלא אמין. spf dkim dmarc records הן שלוש שכבות שמאמתות שהמייל אכן נשלח מטעם הדומיין שמופיע בכתובת השולח, ולא מזויף. בלי אימות תקין, אפילו הודעה אישית לאיש קשר בודד בחברה יעדית עלולה לנחות בתיקיית הספאם או להיחסם לגמרי.
הבעיה מחריפה כי חלק גדול מהתחביר אינו אינטואיטיבי - רשומת TXT עודפת, include שמצביע לשירות שכבר לא בשימוש, או selector של DKIM שלא תואם את פלטפורמת השליחה, מספיקים כדי לשבור את כל השרשרת. בישראל יש גם ממד רגולטורי: תיקון 40 לחוק התקשורת מחייב הסכמה או קשר עסקי קיים ואפשרות הסרה ברורה בכל פנייה שיווקית בדוא"ל, אבל גם דומיין שעומד בדרישות החוק ייתקל בחסימות אם ה-DNS שלו לא בנוי נכון - שתי השכבות משלימות זו את זו ולא מחליפות אחת את השנייה.
SPF: איך בונים רשומת TXT תקינה
רשומת SPF מתפרסמת כ-TXT יחיד על הדומיין השורש (לא על תת-דומיין), ומתחילה תמיד ב-v=spf1. אחריה מגיעה רשימת המקורות המורשים לשלוח בשם הדומיין - כתובות IP עם ip4: או ip6:, ומנגנוני include: להאצלת בדיקה לספק חיצוני כמו שירות תיבות דואר, ESP או פלטפורמת cold email.
לדוגמה, לחברת גליל ייצוא בע"מ שמשתמשת ב-Google Workspace לתיבות אנשי המכירות וב-LDM לשליחת קמפיינים ממוקדים, הרשומה תיראה כך.
הביטוי בסוף הרשומה קובע מה קורה למייל ממקור שלא ברשימה: ~all הוא softfail (מסומן אך לרוב לא נחסם), -all הוא hardfail (דחייה), ו-?all הוא neutral שלא אומר כלום ולכן חסר תועלת. מגבלה קריטית שמפילה המון דומיינים: תקן ה-SPF (RFC 7208) מתיר עד 10 בדיקות DNS מצטברות - כל include, redirect או exists נספר - וחריגה ממנה גורמת ל-permerror שמבטל את כל הרשומה, גם אם התחביר עצמו נראה תקין.
רשומת TXT על galil-export.co.il: "v=spf1 include:_spf.google.com include:_spf.live-direct-marketing.online ~all"
DKIM: selector, מפתח ציבורי וחתימה
DKIM לא מוגדר ברשומת TXT אחת גלובלית אלא בתת-דומיין ייעודי בשם selector, בפורמט [selector]._domainkey.[domain]. ה-selector הוא מזהה שרירותי (למשל s1 או ldm1) שקובעת פלטפורמת השליחה, וצריך להתאים בדיוק בין כותרת ה-DKIM-Signature שהשרת השולח מוסיף לכל מייל לבין רשומת ה-TXT שמפורסמת ב-DNS.
אורך מפתח נפוץ הוא 1024 או 2048 סיביות; 2048 מומלץ כברירת מחדל היום, אבל צריך לוודא שספק ה-DNS תומך ברשומת TXT ארוכה מ-255 תווים - חלקם דורשים פיצול לכמה מחרוזות מצוטטות בתוך אותה רשומה. שגיאה שכיחה במיוחד היא רווחים או שבירות שורה שנוספים בהעתקה-הדבקה מהפאנל של ספק ה-DNS, מה שהופך את המפתח לפגום גם כשהוא נראה תקין לעין.
רשומת TXT על ldm1._domainkey.galil-export.co.il: "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..." (המפתח הציבורי מסופק על ידי פלטפורמת השליחה)
DMARC: מדיניות, יישור (alignment) ודיווחים
רשומת DMARC יושבת ב-_dmarc.[domain] ומגדירה מה קורה כשמייל נכשל גם ב-SPF וגם ב-DKIM, או כשאין יישור עם דומיין ה-From. התחביר המינימלי הוא v=DMARC1; p=none; rua=mailto:כתובת-לדוחות.
p=none רק צופה ואוסף דוחות, p=quarantine שולח כשלונות לספאם, ו-p=reject חוסם לגמרי. adkim ו-aspf קובעים אם היישור בין דומיין ה-From לדומיינים שנבדקו ב-SPF/DKIM צריך להיות מדויק (s, strict) או מקל (r, relaxed) - ברירת המחדל היא relaxed. rua מגדיר לאן נשלחים דוחות אגרגטיביים יומיים, וזה הכלי המעשי היחיד לגלות בעיות לפני שהן פוגעות ב-deliverability בפועל.
הנתונים אינדיקטיביים, מבוססים על ניסיון קמפיינים ממוקדים ב-B2B ואינם מחקר פורמלי
רשומת TXT על _dmarc.galil-export.co.il: "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@galil-export.co.il; pct=100; adkim=s; aspf=s"
טעויות נפוצות שאפשר לתפוס לפני שהן עולות כסף
רוב הכישלונות ב-spf dkim dmarc dns records לא נובעים מבורות טכנית אלא מהעתקה חלקית של הוראות ספק אחד על גבי רשומה קיימת שכבר שירתה ספק אחר.
- שתי רשומות SPF TXT נפרדות על אותו דומיין - חייבים לאחד לרשומה אחת; שני records נחשבים לא תקינים גם אם כל אחד לחוד תקין
- חריגה מ-10 DNS lookups ב-SPF בגלל include מקונן (include שמפנה לעוד include) - גורמת ל-permerror שמפיל את כל ה-SPF
- selector של DKIM שהוגדר בפלטפורמת השליחה אבל לא פורסם ב-DNS, או להפך
- הפעלת p=reject ביום הראשון בלי תקופת ניטור ב-p=none - חוסמת גם מיילים לגיטימיים שעדיין לא מיושרים כראוי, כמו תפוצות דרך שירותי צד ג'
- שכחת aspf/adkim relaxed כשה-From משתמש בתת-דומיין (למשל mail.galil-export.co.il) שלא תואם בדיוק לדומיין שחתום עליו DKIM
- אי בדיקה מחדש אחרי מעבר ספק שליחה - include ישן שנשאר ברשומת SPF מצביע לספק שכבר לא בשימוש, ומרחיב את משטח החשיפה לזיוף
איך לבדוק ולאמת את הרשומות + checklist לפני קמפיין
לפני כל קמפיין cold email B2B חדש כדאי check spf dkim dmarc records ו-verify spf dkim dmarc records בכלים ייעודיים - למשל dig או nslookup ישירות מהטרמינל, או כלי בדיקה אונליין שמנתחים syntax - ולא להסתפק בהעתקה מהמדריך של הספק בלי לוודא שהערכים תואמים בפועל את הדומיין השולח.
ב-LDM כל דומיין שולח עובר את הבדיקה הזו לפני שהוא מחובר לקמפיין ממוקד - כי גם reply שירדוף אחריו SDR שווה אפס אם המייל בכלל לא הגיע לתיבה.
- dig TXT [domain] מציג רשומת SPF אחת בלבד, מתחילה ב-v=spf1 ומסתיימת ב-~all או -all
- dig TXT [selector]._domainkey.[domain] מחזיר מפתח DKIM תקין ללא רווחים שבורים
- dig TXT _dmarc.[domain] מציג p ברמה שתואמת את שלב הפרויקט - none בהתחלה, quarantine/reject רק אחרי ניטור
- מייל בדיקה עצמי לחשבון Gmail וקריאת כותרות Authentication-Results - צריך לראות spf=pass, dkim=pass, dmarc=pass
- דוחות ה-rua נקראים בפועל לפחות פעם בשבוע בתחילת קמפיין
שאלות נפוצות
מה ההבדל בין SPF, DKIM ל-DMARC?
SPF מגדיר אילו שרתים מורשים לשלוח בשם הדומיין, DKIM מוסיף חתימה קריפטוגרפית שמוכיחה שהתוכן לא שונה בדרך, ו-DMARC קובע מה לעשות כששני הבדיקות נכשלות ומספק דוחות. שלושתם ביחד, לא כל אחד לחוד, נותנים לספקי הדואר אימות אמין.
כמה זמן לוקח לרשומות DNS להתעדכן?
זה תלוי ב-TTL שהוגדר לרשומה, בדרך כלל בין 5 דקות לשעה אצל רוב ספקי ה-DNS, אבל תפוצה מלאה בכל העולם יכולה לקחת עד 24-48 שעות. מומלץ להוריד את ה-TTL זמנית לפני שינוי גדול ולחכות יום שלם לפני תחילת קמפיין.
אפשר להתחיל היישר עם p=reject ב-DMARC?
לא מומלץ. עדיף להתחיל ב-p=none ולנטר את דוחות ה-rua שבועיים-שלושה, לוודא שכל מקורות השליחה הלגיטימיים - כולל שירותי צד ג' כמו CRM או חתימת מייל - עוברים יישור, ורק אז לעלות בהדרגה ל-quarantine ואז ל-reject.
איך בודקים שהרשומות תקינות בלי לחכות למייל שנופל לספאם?
הדרך המהירה ביותר היא dig TXT ישירות מול הדומיין והסלקטור, לצד כלי בדיקה ייעודיים שמנתחים syntax ומתריעים על lookups עודפים ב-SPF. שליחת מייל בדיקה לחשבון Gmail ובדיקת כותרות Authentication-Results נותנת אישור סופי שהמייל מזוהה כ-pass בשלושת המנגנונים.
מה עושים כשיש כמה כלי שליחה וחורגים מ-10 lookups ב-SPF?
צריך לאחד include-ים כפולים, להסיר ספקים שכבר לא בשימוש, ובמקרים מורכבים לעבור למנגנון flattening שממיר include ל-IP-ים ישירים - בזהירות, כי זה דורש עדכון ידני בכל פעם שהספק משנה את טווח ה-IP שלו.
האם תיקון 40 לחוק התקשורת דורש גם הגדרות DNS ספציפיות?
לא - תיקון 40 עוסק בהסכמה, זיהוי השולח ואפשרות הסרה בתוכן ההודעה עצמה, ולא בתחביר DNS. אבל שני התחומים משלימים זה את זה: פנייה שעומדת בדרישות החוק ומגיעה מדומיין עם SPF/DKIM/DMARC תקינים סובלת מפחות תלונות ספאם, מה שמגן גם על המוניטין הטכני של הדומיין וגם על הציות המשפטי.
רוצים ליישם את זה באאוטריץ׳ שלכם?
נראה לכם איך זה עובד על הסגמנט והמוצר שלכם — לפני שמתחילים.
דברו איתנו