DMARC fail: חקירת כותרות, התאמה ו-SPF

DMARC fail פירושו שאין אימות שהצליח ומתאים ל-From. p=reject מבקשת סירוב ו-p=quarantine מבקשת טיפול בהודעות כחשודות. הנמען יכול לחרוג מקומית; אין הבטחה לתיקיית ספאם מסוימת. בדקו הגדרות וגם גורמי מסירה אחרים. לסביבה הרחבה ראו דואר עסקי לעסקים קטנים.

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

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

מה משמעות DMARC fail?

לא SPF ולא DKIM מקיים הצלחת אימות והתאמה ל-From הגלוי יחד. הצלחת אימות נפרדת ללא התאמה אינה מספיקה.

הודעה עוברת רק כש-SPF או DKIM מצליח וגם מתאים לדומיין RFC5322 From. ראו RFC 7489. זה אינו מוכיח תוכן בטוח.

שלב 1: בדיקת התאמה תחילה

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

דוגמה:

Header From: support@yourdomain.com
Return-Path: bounces.vendor.net
DKIM: d=vendor.net

ייתכנו spf=pass ו-dkim=pass עם כישלון DMARC, כי vendor.net אינו מתאים ל-yourdomain.com ואין אימות אחר שהצליח ומתאים.

בדקו אימות דומיין, Return-Path או דומיין החזרות מותאם ו-DKIM מתאים במערכות שיווק, CRM, תמיכה ו-SMTP חלופי. מיתוג קישורים ודומיין מעקב אינם משנים מעצמם את דומיין המעטפת.

דוגמאות להמחשה; השתמשו בערכי הספק בפועל, הפעילו את ההגדרה ובדקו אותה:

Type: CNAME
Host: bounces
Value: yourvendor.example.net

Type: CNAME
Host: k1._domainkey
Value: dkim1.yourvendor.example.net

Type: CNAME
Host: k2._domainkey
Value: dkim2.yourvendor.example.net

TrekMail עשויה לסייע בריכוז הגדרות הדומיין. ראו הוספת דומיין ורשומות DNS נדרשות. השתמשו ב-SPF אחד לכל דומיין מעטפת רלוונטי; אל תוסיפו כל שירות אוטומטית לאותה רשומה.

שלב 2: חקירת כותרות הקבלה

פתחו את מקור ההודעה וחפשו Authentication-Results, Return-Path ודומייני DKIM d=. סמכו רק על תוצאות שהוסיפה תשתית קבלה מהימנה, לא על כותרות שרירותיות שהגיעו בהודעה.

סדר הבדיקה:

1. מצאו את From הגלוי.
2. בדקו תוצאת SPF.
3. בדקו את דומיין המעטפת שהוערך.
4. בדקו תוצאת DKIM.
5. בדקו d= של החתימה התקפה שהוערכה.
6. השוו ל-From לפי המצב שנבחר.

כותרת כישלון להמחשה:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@sendgrid.net header.s=s1;
  spf=pass smtp.mailfrom=bounces.sendgrid.net;
  dmarc=fail (p=reject) header.from=yourdomain.com

כך קוראים אותה:

SPF עבר עבור דומיין החזרות תחת sendgrid.net. header.i ב-sendgrid.net אינו מוכיח את דומיין החתימה; בדקו d=. From הוא yourdomain.com. הכישלון כאן מצביע על היעדר אימות שהצליח ומתאים.

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

שלב 3: בדיקת העברה בנפרד

העברה משנה את IP השרת המתחבר ו-SPF המקורי עלול להיכשל. DMARC יכול לעבור אם DKIM תקף ומותאם והנתונים החתומים לפי הקנוניזציה נשמרים.

כישלון SPF ב-Google Groups, Outlook או מסלולי אוניברסיטה אינו כל הסיפור. DKIM תקף ומותאם עשוי לאפשר הצלחה, ולכן צריך לבדוק את המסלול האמיתי.

RFC 7960 מסביר שימור שולח מעטפת לעומת כתיבתו מחדש. בשימור SPF עלול להיכשל; כתיבה מחדש, כולל SRS, אינה יוצרת מעצמה התאמה ל-From המקורי. ראו RFC 7960.

הוספת הרשאות SPF אקראיות אינה פתרון כללי. בחנו:

1. הגדרה ובדיקה של DKIM בזרימות נתמכות.
2. התאמה מקלה לפי דומיין ארגוני, ומצב מחמיר רק לצורך מבוסס.
3. שינויי רשימה שפוגעים בחתימה; ARC עשוי לתמוך בחריג מקומי, לא בהצלחת DMARC מובטחת.

קראו על העברת דואר ועל העברת דואר מהדומיין ל-Gmail. TrekMail עשויה להציע העברה ו-SMTP מנוהל לפי התוכנית, אך יש לבדוק כל מסלול.

שלב 4: חקירת SPF PermError

SPF PermError עשוי לנבוע ממגבלת עשרת המנגנונים והפרמטרים המשנים המחייבים DNS, כולל הערכה מקוננת, או מהגדרה לא תקפה. זו אינה מגבלה על כל חבילות DNS. DKIM תקף ומותאם יכול עדיין לאפשר הצלחת DMARC.

דוגמת SPF מורחבת:

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

הרשימה הגלויה אינה מוכיחה הערכה תקינה. בדקו includes מקוננים ו-redirects במסלול ההערכה האמיתי.

בצעו שאילתה לקבלת הערכים שפורסמו:

dig +short txt yourdomain.com
nslookup -type=txt yourdomain.com

השאילתה לבדה אינה מוכיחה PermError. גם ספק שלא השתמשתם בו שישה חודשים יש להסיר רק אחרי אישור שאין זרימה שעדיין זקוקה לו. ייתכן שפיצול מתאים:

marketing.yourdomain.com
support.yourdomain.com
billing.yourdomain.com

תקציב SPF נפרד חל על דומיין מעטפת המשמש בפועל עם הגדרת ספק פעילה. פרסום DNS לדומיין משנה לבדו אינו משנה מסלול. בדקו הרשאה והתאמה ל-From לאחר השינוי.

TrekMail מתארת SPF כפול ובדיקת ערכים בבדיקת מצב DNS.

שלב 5: חקירת אפשרות לניצול לרעה

לא כל כישלון מחייב תיקון DNS. ייתכן מקור לא מורשה או מסלול לגיטימי שגוי; כישלון אינו סיווג אוטומטי כהתחזות.

IP לא מוכר עם כישלון SPF ו-DKIM מצריך חקירה, לא היתר או חסימה עיוורים. בדקו מקורות, ממסרים והעברה. p=quarantine ו-p=reject מבקשות טיפול בכישלון, בכפוף לשיקול דעת מקומי.

החליטו לפי ראיות:

1. חקרו IP וספק לא מוכרים בעזרת מיפוי, לוגים ובדיקות.
2. אשרו את השולח בפועל ואת אימות הדומיין בדואר לגיטימי.
3. הפעילו ובדקו DKIM שנתמך אך חסר.
4. חקרו מגבלות לפני מעבר לדומיין משנה או החלפת כלי; בדקו את המעטפת בפועל וההתאמה.

אכיפה רלוונטית יכולה להשפיע גם על שגיאות שלכם, ללא קשר לכוונה. חריגים מקומיים אפשריים. ראו הנחיות Google לאימות שולחים.

דפוסים לפי סוג שולח

סוג המערכת עוזר לכוון חקירה, אך אינו מוכיח את הסיבה.

ניהול כישלונות במספר דומיינים

Google Workspace, cPanel, SendGrid והעברת Gmail אצל לקוחות שונים דורשים הגדרות עדכניות לכל מקרה. DNS לא ברור מקשה על חקירה חוזרת.

סביבה משותפת עשויה לסייע במעקב אחרי מצב דומיין, העברה, SMTP ואימות. לוח אינו הוכחה לתוצאות כל ההודעות בפועל.

מחיר הפתיחה בתשלום המוזכר ל-TrekMail הוא $3.50 לחודש, עם תקופת ניסיון חינמית של 14 ימים לפי ההצעה המתוארת ואפשרות חינמית עם SMTP משלכם. דומיינים, תיבות IMAP, catch-all, העברה, העתקת IMAP, API וסיוע בהגדרה כפופים לתנאי התוכנית העדכניים. IMAP מעתיק הודעות נתמכות; MX ונתוני יישומים דורשים טיפול נפרד.

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

רשימת חקירה קצרה

התחילו בהודעה מסוימת, בדקו תוצאות מהימנות והשוו דומייני אימות ל-From, ואז תקנו את החריגה שהוכחה.

1. בדקו Authentication-Results מהימנים בהודעה.
2. בדקו תוצאת SPF ודומיין מעטפת.
3. בדקו DKIM ודומיין d= תקף.
4. השוו ל-Header From.
5. תקנו התאמה אם אין מנגנון שהצליח ומתאים.
6. בדקו DKIM תקף ומותאם ושימור נתונים חתומים בהעברה.
7. חקרו הערכת SPF ופיצול מעטפת בפועל לפי הצורך.
8. חקרו מקורות לא מוכרים בלוגים ובניסויים, בלי לסווג לפי כישלון בלבד.

סדר ברור מסייע לבחור שינויים מבוססי ראיות.

סיכום: תיקון הסיבה שהוכחה

DMARC fail יכול לנבוע מהתאמה שגויה, DKIM שלא נשמר בהעברה, SPF PermError או שליחה לא מורשית. הכישלון לבדו אינו מוכיח ניצול לרעה ואינו מנבא מסירה.

תקנו את השכבה שנבדקה במקום להוסיף רשומות אקראיות. TrekMail עשויה להציע אחסון משותף, מספר דומיינים, SMTP משלכם ב-Nano, SMTP מנוהל והעתקת IMAP לפי התוכנית. בדקו אפשרויות עדכניות ב-TrekMail או השוו תוכניות ב-https://trekmail.net/pricing, והמשיכו לבדוק גם זרימות לגיטימיות נדירות.