למה הדוא"ל שהעברת לעצמך נחת בספאם

הגדר העברה אוטומטית מחשבון הישן שלך לחדש, וחלק מהדוא"ל הזה יעלם בשקט לספאם — לא כי הספק שלך שבור, אלא כי העברה שכתבת מחדש את מי ששולח את ההודעה מבלי לשכתב מחדש את ההוכחה ההצפנה. SPF בודק את השרת הלא נכון, הפסק ה-DMARC הופך לכישלון, והדוא"ל לגיטימי ששלחת לעצמך נחנק. לתיקון שם: ARC, שהוגדר ב-RFC 8617 חזרה ב-2019.

למה העברה גורמת לדוא"ל שלי להיכשל ב-SPF?

כי SPF בודק את השרת האחרון שהעביר את ההודעה, והעברה משנה את השרת הזה. SPF — Sender Policy Framework — הוא רשומת DNS המפרטת אילו כתובות IP מורשות לשלוח דוא"ל לתחום. כשׁ-bank.com שולח לך קבלה, השרת המקבל בודק: האם זה הגיע מכתובת IP שׁ-bank.com אישר? כן. עבר.

עכשיו העבר את הקבלה הזו מ-Gmail שלך לכתובת החדשה שלך. שרתים של Google משדרים אותה הלאה. השרת המקבל הסופי מפעיל בדיקת SPF ושואל: האם Google מורשה לשלוח עבור bank.com? לא, זה לא. SPF נכשל. התיעוד של Workspace של Google עצמו של Google מפרט זאת בבירור — הודעות שהועברו נכשלות SPF כי שרת ההעברה אינו ברשומת ה-SPF של התחום המקורי. שום דבר לא זוייף. הבדיקה פשוט מסתכלת על הקפיצה הלא נכונה.

אז למה זה שולח את זה לספאם?

DMARC. SPF שנכשל לבדו היה שרדה פעם; DMARC הפכה את זה לפסק דין. DMARC קושרת SPF ו-DKIM ואומרת למקבלים מה לעשות כשׁ-שְׁנֵיהֶם נכשלו: כלום, בידוד, או דחיה. עד 2024, לשולחים גדולים לא היה בחירה — Google ו-Yahoo החלו דורשים DMARC על כל מי ששולח יותר מ-5,000 הודעות ביום למשתמשים שלהם.

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

מהו ARC והאם זה באמת תוקן את זה?

ARC — Authenticated Received Chain, RFC 8617 — מאפשרת להעברה כנה להיות ערב שהדוא"ל עבר אימות לפני שנגעה בו. שרת ההעברה חותם את ההודעה עם רשומה אטומה שאומרת "כשזה הגיע אליי, SPF ו-DKIM היו תקפים — תאמין לדברי שלי עבור הרגל שלא יכול להוודא." המקבל הסופי, אם הוא מאמין לאותו מעביר, יכול לעקוף את הכישלון של DMARC ולהעביר.

הלכידה היא ב"אם זה מאמין." ARC אינה סיסמה; זו מערכת מוניטין. מקבל משקלל אם הARC sealer היא מפעיל ידוע וטוב. Google גם חותמת ARC headers וגם מכבדת אותם משולחים שהוא מאמין, וזו הסיבה שהעברה Gmail-to-Gmail בדרך כלל שורדת בעוד העברה דרך כמה ממסר אוניברסיטה עתיק לא.

אם אתה מנהל את ההעברה בעצמך, שתי צעדים קונקרטיים עוזרים. השתמש ב-Server-Side Redirect / SRS-style rewriting אם המארח שלך מציע זאת, שכותב מחדש את משלח המעטפה כדי שבדיקות SPF כנגד המעביר שלך במקום התחום המקורי. והעדיפו העברה בין ספקים שׁשְׁנֵיהֶם תומכים ב-ARC. אם אתה מאחד חשבונות ורוצה שהיעד פשוט יטפל בעבורך בעבודת אימות, זה בדיוק סוג ה-plumbing שפלטפורמת דוא"ל עם בינה מלאכותית בנויה כדי ליטול.

מתי אני צריך להפסיק להאשים את הספק שלי?

כשהדפוס הוא "רק דוא"ל שהועבר נכשל," הספק עושה את עבודתו בצורה נכונה — הפרוטוקול הוא הבעיה. הנה הסימן: פתח את כותרי ההודעה החסרה וחפש את שורת Authentication-Results. אם אתה רואה spf=fail לצד כתובת IP שולח השייכת למעביר ולא לשולח המקורי, זה SPF בדיקה בקפיצה הלא נכונה. אם dkim=fail מופיע בדוא"ל שעבר דרך רשימה או משדר שעורך הודעות, זו חתימה מעוותת, לא זיוף.

האמת הלא נוחה היא שאימות דוא"ל הוצמד, שכבה אחר שכבה, למשך שתי עשרויות למערכת שלא חשבה מעולם שמישהו יתכחש. SPF הגיע ב-2006, DKIM ב-2007, DMARC ב-2015, ARC ב-2019 — כל אחד תיקון חור שהאחרון פתח. העברה היא התפר שבו כל ארבעתם משפשפים זה בזה, ותיבת הדוא"ל שלך היא המקום שבו אתה מרגיש את החיכוך.