SPF,‏ DKIM ו-DMARC תקינים, והדואר עדיין בספאם

אימות דוא״ל: למה הגדרת SPF,‏ DKIM ו-DMARC עדיין אינה מספיקה

עשיתם את כל העבודה. ביליתם שעות במסכי DNS והעתקתם מחרוזות לא ברורות מספקי הדוא״ל. הרצתם כלי בדיקה וקיבלתם סימון ירוק בכל סעיף. אז למה שיעורי הפתיחה יורדים? מדוע הודעות תפעוליות, כמו איפוס סיסמה, חשבוניות והתראות, מגיעות לתיקיית הספאם או נעלמות לגמרי?

זו האמת החשובה לגבי אימות דוא״ל באמצעות SPF,‏ DKIM ו-DMARC: הגדרה תקינה אינה זהה למוניטין טוב. גם תעודה מזהה תקפה אינה מבטיחה לבדה כניסה למועדון. מאז פברואר 2024 ספקים כמו Google ו-Yahoo החמירו את הדרישות משולחי תפוצה, ואילו Microsoft מפעילה אותות ומדיניות משלה. אם לוח הבקרה מציג סימונים ירוקים אבל התוצאות העסקיות מידרדרות, סביר שנתקלתם באחת הבדיקות הפחות גלויות שמעבר לפרוטוקולי האימות הבסיסיים.

המלכודת של שולחי תפוצה: הרף נמוך מכפי שנדמה

אחת הטעויות המסוכנות היא: "אני שולח פחות מ-5,000 הודעות ביום, לכן כללי התפוצה אינם חלים עליי".

הטענה שגויה משתי סיבות, וגם אימות SPF,‏ DKIM ו-DMARC תקין לא יגן מפני המלכודת הזו. ראשית, Google סופרת את הנפח ברמת הדומיין הראשי. אם שולחים 2,000 הודעות שיווק מ-news.example.com,‏ 2,000 הודעות תפעוליות מ-app.example.com ועוד 1,500 התראות פנימיות מ-corp.example.com, נחשבים לשולחי תפוצה. הנפח מכל תתי הדומיינים מצטבר תחת דומיין הבסיס.

שנית, הרף המרבי שהושג ממשיך לקבוע. אם הדומיין הראשי חוצה פעם אחת את סף 5,000 ההודעות, למשל במבצע Black Friday או בעדכון חד פעמי למסד הנתונים, Google ממשיכה להתייחס אליו כשולח תפוצה. הדרישות המחמירות נשארות בתוקף גם אם הנפח יורד אחר כך ל-50 הודעות ביום.

Microsoft מעריכה שולחים בעזרת שילוב אחר של אותות. רשומות SPF,‏ DKIM ו-DMARC יכולות להיות ללא דופי, אך גם הגיל והמוניטין של כתובת ה-IP עשויים להשפיע. אם מפעילים דומיין וכתובת IP חדשים ומיד שולחים 2,000 הודעות, ייתכן שיוחלו הגבלות עם שגיאות 4xx בלי קשר לתוצאת SPF. לשולח חדש עדיין אין מוניטין מצטבר.

נקודות הכשל של SPF,‏ DKIM ו-DMARC: משולש הברזל

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

SPF: השטח המת של העברת הודעות

SPF דומה לרשימת כתובות IP מורשות. הרשומה אומרת למשל: "כתובת IP 1.2.3.4 רשאית לשלוח בשם example.com". הכול עובד היטב עד שאדם מגדיר העברה אוטומטית.

נניח ששלחתם חשבונית אל client@smallbiz.com. הלקוח מעביר את כל הדואר אל client@gmail.com. מבחינת Gmail, החיבור מגיע מכתובת ה-IP של smallbiz.com ולא מהכתובת שלכם. Gmail בודקת את רשומת SPF שלכם, אינה מוצאת בה את smallbiz.com, ולכן SPF עלול להיכשל. אם מסתמכים על SPF בלבד, דואר שהועבר עלול להגיע לספאם או להידחות. נדרשת חתימת DKIM תקפה ותואמת כדי שההודעה תעבור את שלב ההעברה. להסבר מלא עיינו במדריך להגדרת רשומת SPF.

DKIM: בעיית התאמת הדומיינים

DMARC בודק שני דברים: האם SPF או DKIM לפי RFC 6376 הצליחו, והאם הדומיינים תואמים. התאמה פירושה שדומיין הכותרת From מתאים לדומיינים שבכותרות הטכניות, כלומר Return-Path עבור SPF והערך d= עבור DKIM.

זהו תרחיש מוכר לצוותי תמיכה: משתמשים במערכת CRM כמו Zendesk או HubSpot כדי לשלוח בשם support@yourcompany.com. המערכת מטפלת בהחזרות, ולכן Return-Path הוא bounces.zendesk.com והתאמת SPF נכשלת. אם לא הגדרתם CNAME מותאם, DKIM חותם באמצעות d=zendesk.com וגם התאמת DKIM נכשלת. ההודעה אומתה טכנית כהודעה של Zendesk, אבל DMARC אינו רואה שיטת אימות מוצלחת שתואמת לדומיין שלכם. אם המדיניות היא p=reject, ההודעה עלולה להידחות.

מגבלת 10 השאילתות

לפי RFC 7208, ל-SPF יש תקרה קשיחה של 10 שאילתות DNS בכל בדיקה. סוכנויות שמנהלות לקוחות המשתמשים בכלי SaaS רבים נתקלות בכך במהירות. Google Workspace לבדה עשויה לצרוך 4 שאילתות. הוסיפו את Mailchimp,‏ HubSpot, מערכת כרטיסי תמיכה וכלי משאבי אנוש:

v=spf1 include:_spf.google.com include:servers.mcsv.net include:mail.zendesk.com ~all

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

בדיקות נסתרות מעבר ל-SPF,‏ DKIM ו-DMARC

מעבר לשלושת הפרוטוקולים המוכרים קיימות דרישות טכניות נטולות שם שיווקי נוצץ, וגם הן יכולות לעצור את המסירה.

FCrDNS (אימות קדמי של DNS הפוך)

לכל כתובת IP שולחת צריכה להיות רשומת PTR שמפנה לשם מארח, ולשם המארח צריכה להיות רשומת A שמחזירה אל כתובת ה-IP המקורית. הבדיקה המעגלית עוזרת לזהות את התשתית באופן עקבי. אם מקימים מכונה וירטואלית בענן, מתקינים Postfix ושולחים ללא רשומת PTR,‏ Gmail עשויה לראות בתעבורה חשודה ולהחזיר למשל 550 5.7.1.

RFC 8058: הסרה מרשימה בלחיצה אחת

מאז יוני 2024, קישור בתחתית ההודעה אינו מספיק עבור דואר שיווקי של קבוצות מסוימות של שולחי תפוצה. ההודעות הרלוונטיות צריכות לכלול שתי כותרות מסוימות:

List-Unsubscribe: <https://example.com/unsub>, <mailto:unsub@example.com>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

נקודת הקצה ב-HTTPS צריכה לקבל בקשת POST ולא להסתמך על GET. בוטים נגד ספאם בודקים לפעמים הודעות באמצעות פתיחת קישורים. אם בקשת GET מבטלת הרשמה מיד, הבוט עלול להסיר משתמשים אמיתיים בטעות. אם המשתמשים אינם מוצאים דרך קלה לצאת, הם עשויים לבחור במקום זאת ב"דיווח על ספאם" ולקרב את שיעור התלונות לסף 0.3%.

סף 0.3%: הכלכלה של מוניטין השולח

תוצאות מושלמות ב-SPF,‏ DKIM ו-DMARC,‏ FCrDNS תקין וכותרות מדויקות אינם מספיקים אם הנמענים אינם רוצים את התוכן.

שיעור התלונות על ספאם הוא מדד מרכזי. Google ממליצה לשמור עליו מתחת ל-0.3%, כלומר פחות מ-3 תלונות לכל 1,000 הודעות שנמסרו, ועדיף הרבה מתחת לכך. חריגה חוזרת עלולה להוביל להגבלת הדומיין או לחסימתו.

מלכודת המכנה בדוחות של Yahoo

שיעור התלונות המוצג עשוי להשתנות לפי ההודעות שהספק כולל במכנה. נניח ששלחתם 1,000 הודעות. מוניטין הדומיין כבר חלש, ולכן 900 מגיעות לספאם ורק 100 לתיבת הדואר הנכנס. אדם אחד מתלונן. בקבוצת תיבת הדואר שבדוגמה החישוב הוא 1/100 = 1.0%, כלומר 3x מסף האכיפה. לכן יש לבדוק את הגדרת המדד בלוח הספק ולא להסתמך רק על נפח השליחה הכולל.

בעיית השכן הרועש

גם כאשר SPF,‏ DKIM ו-DMARC מוגדרים נכון, באחסון משותף רגיל או בפלטפורמת דוא״ל זולה ו"ללא הגבלה" ההודעות שלכם עשויות לצאת מאותה כתובת IP המשמשת אלפי לקוחות אחרים. אם אחד מהם מפיץ הונאה ו-Spamhaus מכניסה את ה-IP לרשימת חסימה, גם המסירה שלכם עלולה להיפגע. לא עשיתם דבר רע, אך אתם חולקים את מוניטין התשתית. רמת הסיכון תלויה בפיקוח ובבידוד שמפעיל הספק.

אופן השליחה	מי שולט במוניטין	מתאים במיוחד עבור
IP משותף (רוב ספקי ESP)	הספק, ולכן מושפעים גם משולחים אחרים	שולחים בנפח נמוך שסומכים על אכיפת הספק
SMTP מנוהל (TrekMail Starter/Pro)	TrekMail, שאוכפת מדיניות מחמירה נגד ספאם ומטפלת בשולחים פוגעניים	עסקים שמעוניינים במסירה מנוהלת
SMTP לבחירתכם (TrekMail Free + בתשלום)	אתם, באמצעות חיבור Amazon SES,‏ SendGrid או כתובות IP ייעודיות של Mailgun	סוכנויות ושולחים בנפח גבוה שרוצים בידוד רב יותר

רשימת הבדיקה של יום שישי ל-SPF,‏ DKIM ו-DMARC

1. בדקו כותרות: שלחו הודעה לחשבון Gmail אישי. פתחו אותה, לחצו על שלוש הנקודות ובחרו "הצגת המקור". חפשו את Authentication-Results. האם SPF הצליח? האם DKIM הצליח? האם הדומיין של dkim= מתאים לדומיין של header.from? אם לא, בדקו את הגדרת ההתאמה.

2. אמתו FCrDNS: הריצו dig -x <your-sending-ip>. האם מתקבל שם מארח? הריצו dig <that-hostname>. האם מתקבלת כתובת ה-IP? אם המעגל אינו נסגר, תקנו את ה-DNS לפני הגדלת נפח השליחה.

3. הפרידו תעבורה: עדיף שלא לשלוח שיווק מהדומיין הארגוני הראשי. השתמשו ב-team@company.com להתכתבות אנושית וב-newsletter@marketing.company.com לקמפיינים. אם השיווק מגיע לסף 0.3%, ההפרדה מסייעת להגן על מוניטין הדומיין הראשי, אך אינה מבטיחה זאת באופן מוחלט.

4. קראו עוד: לצעדים מעשיים לשיקום מוניטין עיינו במדריך למוניטין של שולח דוא״ל ובהסבר המקיף על מוניטין של דומיין דוא״ל.

תוכניות TrekMail

תוכנית	מחיר	תכונת אימות
Free	$0	SMTP לבחירתכם ושליטה מלאה ב-IP (ללא כרטיס)
Starter	$3.50/לחודש	SMTP מנוהל ויצירת DKIM אוטומטית
Pro	$10/לחודש	כמה דומיינים ולוח אימות DNS
Agency	.25/לחודש	אחסון משותף, הגדרת DNS בכמות גדולה וניהול מוניטין

התוכניות בתשלום המתוארות כוללות תקופת ניסיון של 14 יום המחייבת כרטיס. תוכנית Free אינה מחייבת כרטיס. בדקו את המחירים והתנאים העדכניים לפני ההצטרפות.

סיכום

אימות דוא״ל באמצעות SPF,‏ DKIM ו-DMARC אינו משימה שמגדירים ושוכחים, אלא דרישה תפעולית מתמשכת. מעבר הבדיקות הוא רק תנאי בסיסי. כדי לשפר את הסיכוי להגיע לתיבת הדואר הנכנס נחוצים התאמת דומיינים מדויקת, תחזוקת רשת תקינה הכוללת FCrDNS, כותרות להסרה בלחיצה אחת ואסטרטגיה לניהול המוניטין. שום הגדרה יחידה אינה מבטיחה מיקום בתיבת הדואר. עקבו אחר התוצאות ושמרו על שליטה בתשתית.