החשבוניות האוטומטיות נוחתות בספאם? סדר הפעולות בפועל: קריאת Authentication-Results, תיקון SPF ו-DKIM, פרסום DMARC, ואיך מוודאים שכל שלב עבד.
עיקרי הדברים
- הראיה נמצאת בכותרות המייל, לא בתחושה. `Authentication-Results` אומרת מה עבר ומה נכשל.
- SPF מאשר שרתים שולחים, DKIM חותם על המסר, ו-DMARC קובע מה עושים כשאחד מהם נכשל.
- התאמה (alignment) היא מה שרוב האנשים מפספסים: SPF יכול לעבור ו-DMARC בכל זאת ייכשל.
- שולח בנפח גבוה נמדד גם על שיעור תלונות הספאם, לא רק על רשומות DNS.
- מתחילים תמיד ב-`p=none` עם דוחות, ורק אחרי שקוראים אותם מהדקים ל-`quarantine`.
כשחשבוניות אוטומטיות נוחתות בתיקיית הספאם, הצעד הראשון אינו לשנות את הטקסט אלא לפתוח מייל אחד שנחת שם ולקרוא את כותרת Authentication-Results. היא מציגה שלוש תוצאות: spf, dkim ו-dmarc. מה שנכשל שם הוא מה שמתקנים, בסדר הזה בדיוק.
הצעד הראשון: לקרוא את כותרת Authentication-Results
בכל לקוח מייל אפשר להציג את המקור המלא של ההודעה. בתוכו יש שורה בסגנון Authentication-Results: mx.google.com; spf=pass ...; dkim=pass ...; dmarc=fail .... השורה הזו היא האבחון.
spf=passו-dkim=passאבלdmarc=failפירושם בעיית התאמה, לא בעיית רשומות.spf=failפירושו שהשרת ששלח בפועל אינו מורשה ברשומת ה-SPF של הדומיין.dkim=noneפירושו שההודעה כלל לא נחתמה. זו הבעיה הכי נפוצה במערכות אוטומטיות שהוגדרו פעם ונשכחו.spf=permerrorפירושו שהרשומה עצמה שבורה, ולרוב בגלל חריגה ממגבלת החיפושים.
בלי הכותרת הזו אתם משנים נוסח בתקווה. איתה אתם יודעים איזו משלוש הרשומות מטפלים.
מה כל אחת משלוש הרשומות עושה בפועל
| רשומה | היכן היא יושבת ב-DNS | מה היא אומרת | מה קורה בלעדיה |
|---|---|---|---|
| SPF | רשומת TXT בדומיין עצמו | אילו שרתים רשאים לשלוח בשם הדומיין | הנמען לא יכול לפסול שולח מזויף לפי כתובת IP |
| DKIM | רשומת TXT ב-selector._domainkey.example.com | המפתח הציבורי שמאמת את החתימה על ההודעה | אין הוכחה שההודעה לא שונתה בדרך |
| DMARC | רשומת TXT ב-_dmarc.example.com | מה לעשות כששני הקודמים נכשלים, ולאן לשלוח דוחות | לנמען אין מדיניות ללכת לפיה |
הערכים בפועל נראים כך: v=spf1 include:_spf.example.net ~all ל-SPF, v=DKIM1; k=rsa; p=<מפתח בבסיס 64> ל-DKIM, ו-v=DMARC1; p=none; rua=mailto:dmarc@example.com ל-DMARC. שלוש הערות שחוסכות סיבוב: רשומת SPF אחת בלבד לדומיין, מגבלת חיפושי ה-DNS בהערכת SPF היא 10 ומעליה מוחזר permerror, וה-selector של DKIM נקבע על ידי ספק השליחה שלכם.
מה זו התאמה, ולמה SPF שעובר עדיין נכשל ב-DMARC?
התאמה (alignment) היא הדרישה שהדומיין שעבר אימות יהיה אותו דומיין שהנמען רואה בשדה From. זה החלק שנופל אצל רוב העסקים, והוא גם ההסבר למצב המבלבל שבו הכול "ירוק" ו-DMARC עדיין נכשל.
- SPF מאמת את הדומיין שבמעטפה, כלומר
5321.MailFrom. הנמען רואה את5322.From. אם ספק הדיוור מגדיר מעטפה בדומיין שלו, SPF עובר אך אינו מותאם. - DKIM נחשב מותאם כשהדומיין שחתם על ההודעה תואם לדומיין שב-From.
- DMARC עובר אם לפחות אחד מהשניים מותאם. לכן די בהתאמת DKIM גם כשה-SPF שייך לספק.
- מצב ההתאמה נקבע בתגיות
aspfו-adkim. הערךrהוא מרוכך והוא ברירת המחדל, והערךsמחייב התאמה מדויקת של הדומיין המלא.
תרגום מעשי: אם אתם שולחים דרך ספק חיצוני, בקשו ממנו לחתום ב-DKIM עם הדומיין שלכם. זו הפעולה שמייצרת התאמה בלי לגעת ב-SPF.
סדר הטיפול
- רשמו את כל מי ששולח בשמכם: שרת האתר, מערכת החשבוניות, מערכת הדיוור, CRM, כלי אוטומציה. רשומה שמפספסת מקור אחד תפיל אותו.
- פרסמו רשומת SPF אחת שכוללת את כולם, וסיימו ב-
~allבשלב הראשון. - הפעילו DKIM אצל כל ספק, ופרסמו את רשומת ה-selector שהוא נותן לכם.
- פרסמו DMARC ב-
p=noneעםrua, וחכו.noneלא חוסם דבר; הוא רק גורם לדוחות לזרום. - קראו את הדוחות שבוע עד שבועיים, ואתרו מקורות ששולחים בשמכם ולא ידעתם עליהם.
- תקנו את מה שהדוחות חשפו, ורק אז עברו ל-
p=quarantine. - עברו ל-
p=rejectבסוף התהליך, לא בתחילתו.rejectעל תשתית לא שלמה חוסם את החשבוניות שלכם עצמכם.
מול אילו ספים אתם נמדדים?
ספקי הדואר הגדולים פרסמו דרישות מפורשות לשולחים בנפח גבוה. הן חלות על כל מי ששולח מעל 5,000 הודעות ביום לאותו שירות.
| נמדד | Gmail | Outlook.com, Hotmail ו-Live |
|---|---|---|
| סף נפח | מעל 5,000 הודעות ביום | מעל 5,000 הודעות ביום |
| אימות נדרש | SPF, DKIM ו-DMARC | SPF, DKIM ו-DMARC |
| מדיניות DMARC מינימלית | p=none מספיקה | p=none מספיקה |
| התאמה | ה-From חייב להיות מותאם ל-SPF או ל-DKIM | זהה, מול 5321.MailFrom או הדומיין החותם |
| שיעור ספאם | להישאר מתחת ל-0.10%, ולא להגיע ל-0.30% | לא פורסם כמספר |
| דחייה | פגיעה במסירות | 550 5.7.515 Access denied |
שתי נקודות שכדאי לשים לב אליהן: Google דורשת גם רשומת PTR תקינה לכתובת ה-IP השולחת וגם חיבור TLS, וכן כותרות List-Unsubscribe ו-List-Unsubscribe-Post: List-Unsubscribe=One-Click בהודעות שיווקיות, עם טיפול בבקשת ההסרה בתוך יומיים. Microsoft מציינת שדומיין שחצה פעם את הסף ממשיך להיות כפוף לדרישות גם אם הנפח היומי ירד מאז.
איך מוודאים שכל שלב באמת עבד
- שלחו הודעת בדיקה לכתובת Gmail וקראו שוב את
Authentication-Results. זו הבדיקה היחידה שמשקפת את המציאות. - ודאו שיש רשומת TXT אחת בלבד שמתחילה ב-
v=spf1. שתי רשומות SPF שוברות את הבדיקה. - ספרו את מנגנוני ה-
includeבשרשרת. חריגה מעשרה חיפושי DNS מחזירהpermerrorוהתוצאה שקולה לכישלון. - שלחו הודעה מכל מערכת בנפרד: אתר, מערכת חשבוניות, מערכת דיוור. הן לרוב חתומות אחרת זו מזו.
- בדקו שדוחות ה-
ruaמגיעים בפועל לתיבה שהגדרתם. תיבה שלא נבדקת שווה לאין דוחות. - אחרי מעבר ל-
quarantine, עקבו שבוע אחרי הודעות תפעוליות קריטיות לפני שמהדקים הלאה.
מה עדיין נכנס לספאם כשהאימות מושלם
אימות הוא תנאי הכרחי ולא מספיק. הוא מוכיח שאתם מי שאתם טוענים, לא שההודעה רצויה. אחרי שהכול עובר, מה שנשאר משפיע הוא התנהגות:
- כתובות שלא קיימות. שיעור החזרות גבוה פוגע במוניטין השולח מהר יותר מכל דבר אחר.
- שליחת מסה מדומיין חדש בלי הדרגתיות.
- ערבוב דיוור שיווקי עם מיילים תפעוליים על אותו דומיין. הפרדה לתת-דומיינים שומרת על החשבוניות כשקמפיין נכשל.
- היעדר דרך הסרה ברורה, שמובילה לדיווחי ספאם במקום להסרה שקטה.
קשור: מייל חשבונית שלא התקבל - צ'ק ליסט, אוטומציית מייל לעסק קטן, מה זה DNS.
מקורות
שאלות נפוצות
מה ההבדל בין ~all לבין -all ברשומת SPF?
`~all` הוא כישלון רך: שרת שאינו ברשימה מסומן כחשוד אך ההודעה בדרך כלל נמסרת. `-all` הוא כישלון קשה ומנחה את הנמען לדחות. מתחילים ב-`~all` עד שוודאתם שכל מערכות השליחה שלכם מופיעות ברשומה.
האם `p=none` שווה משהו אם היא לא חוסמת?
כן. `p=none` הוא מצב תצפית: הוא לא משנה מסירות אך מפעיל את זרימת הדוחות ל-`rua`, וכך מגלה מקורות שליחה שלא ידעתם עליהם. הוא גם מספיק כדי לעמוד בדרישת ה-DMARC של Gmail ושל Outlook לשולחים בנפח גבוה.
למה DKIM נכשל רק בחלק מההודעות?
כמעט תמיד מפני שהן נשלחות ממערכת אחרת שאינה חותמת, או שהן עוברות דרך רשימת תפוצה או שירות העברה שמשנה את גוף ההודעה. חתימה שנשברה בדרך שקולה לחתימה שלא הייתה. בדקו את ה-selector שבכותרת של כל הודעה נכשלת.
כמה זמן לוקח עד שרואים שיפור?
שינויי DNS נכנסים לתוקף בתוך שעות לפי ה-TTL, אך מוניטין השולח נבנה על פני שבועות. הפרדת דיוור שיווקי מהודעות תפעוליות לתת-דומיינים היא הדרך המהירה ביותר להגן על החשבוניות בזמן שהמוניטין מתייצב.
להמשך קריאה
שירות רלוונטי
אוטומציה לעסקים
אני בונה אוטומציות מותאמות שמורידות עבודה חוזרת מקצה לקצה.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.