התאמת DMARC: בדיקת SPF, DKIM ו-From

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

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

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

מהי התאמת DMARC?

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

זהו הכלל של RFC 7489. DMARC אינו מחליף אימות, אלא קושר הצלחה לדומיין שהנמען רואה ב-From.

הבדיקות:

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

DMARC pass = (SPF pass + SPF aligned) OR (DKIM pass + DKIM aligned)

SPF מצליח אך ההתאמה נכשלת

Return-Path של הספק עשוי לאפשר הצלחת SPF ללא התאמה ל-From שלכם. זה אפשרי בהגדרות SendGrid, Mailchimp, HubSpot או Shopify. DKIM שהצליח ומתאים יכול עדיין לאפשר הצלחת DMARC.

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

From גלוי: billing@example.com
Return-Path: bounces+123@sendgrid.net

SPF יכול לעבור בזכות הרשאת IP ל-sendgrid.net. זה אינו מספק התאמת SPF, משום ש-sendgrid.net אינו מתאים ל-example.com.

להתאמת SPF הגדירו דומיין החזרות או Return-Path מותאם שנתמך אצל הספק. מיתוג קישורים ודומיין מעקב אינם בהכרח אותה תכונה; בדקו את שולח המעטפת בפועל.

bounces.example.com.   CNAME   u1234.wl.sendgrid.net.

לאחר הפעלת הספק ובדיקות, אפשר להשתמש ב-bounces.example.com במעטפת. הוא מתאים ל-example.com במצב מקל. CNAME לבדו אינו מוכיח שההגדרה פעילה.

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

מדוע התאמת DKIM חשובה?

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

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

From גלוי: newsletter@example.com
חתימת DKIM: d=mailchimpapp.net

DKIM יכול לעבור ללא התאמה. DMARC נכשל רק כשגם אין SPF שהצליח ומתאים.

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

s1._domainkey.example.com.   CNAME   s1.domainkey.u1234.vendor.net.
s2._domainkey.example.com.   CNAME   s2.domainkey.u1234.vendor.net.

הגדרה פעילה עשויה לחתום עם d=example.com או דומיין משנה מתאים כמו d=mail.example.com. זה תומך ב-DMARC כש-SPF נכשל רק אם החתימה תקפה ועומדת במצב ההתאמה שנבחר.

Google דורשת משולחים בכמויות גדולות התאמת From דרך SPF או DKIM לצד דרישות האימות הרלוונטיות. בדקו את הקטגוריה וההודעות בפועל; שגיאת התאמה אינה מנבאת לבדה כל סינון או הגבלה.

התאמה מקלה ומחמירה

מצב מקל משווה דומיינים ארגוניים; מצב מחמיר דורש דומיין זהה בדיוק. מקל הוא ברירת המחדל, אך הבחירה תלויה במקורות ובצורכי הניהול.

aspf שולטת בהתאמת SPF ו-adkim בהתאמת DKIM.

דוגמה:

_dmarc.example.com. TXT "v=DMARC1; p=none; aspf=r; adkim=r; rua=mailto:dmarc@example.com"

במצב מחמיר חתימה של mail.example.com אינה מתאימה ל-From ב-example.com. זהו תנאי המצב, לא הוכחה לניצול לרעה.

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

חקירת התאמת DMARC

בדקו Authentication-Results שהתקבלו, DKIM d=, SPF smtp.mailfrom ותוצאת dmarc עבור header.from. סמכו רק על תוצאות שהוסיפה תשתית קבלה מהימנה, לא על כותרות שרירותיות שהגיעו עם ההודעה.

התוצאות מסייעות למצוא שגיאות. header.i בדוגמה הבאה אינו מוכיח את דומיין חתימת DKIM; ל-DMARC קובע d= בחתימה שהוערכה.

Authentication-Results: mx.google.com;
  dkim=pass header.i=@sendgrid.net header.s=s1;
  spf=pass smtp.mailfrom=bounces+123@sendgrid.net;
  dmarc=fail header.from=example.com

בדקו לפי הסדר:

1. בדקו header.from לזיהוי הדומיין הגלוי.
2. בדקו smtp.mailfrom; דומיין ספק שאינו מתאים לא מספק התאמת SPF.
3. header.i אינו הקריטריון ל-DMARC; בדקו את d= של החתימה התקפה.
4. אם אין אימות שהצליח ומתאים, DMARC נכשל גם אם SPF ו-DKIM עברו בנפרד.

בדקו גם DNS:

dig +short TXT _dmarc.example.com
dig +short TXT example.com
dig +short CNAME s1._domainkey.example.com

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

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

דפוסי כישלון נפוצים

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

מצבים חוזרים:

1. דומיין החזרות של ספק: SPF עובר ללא התאמה; DKIM יכול עדיין לתמוך ב-DMARC.
2. חתימת ספק: DKIM עובר ללא התאמה; SPF יכול עדיין לתמוך ב-DMARC.
3. העברה: SPF עלול להיכשל; DKIM עוזר אם נשאר תקף ומותאם.
4. מצב מחמיר לא מכוון: דומייני משנה שונים אינם מתאימים.
5. רשומות ישנות: בדקו מסלולים וחתימות בפועל; DNS אינו מפעיל מעצמו גורם חתימה שגוי.

בתגובה כגון 4.7.32 מ-Gmail בנוגע להתאמת From, בדקו תוצאות אימות ודרישות רלוונטיות. ראו הנחיות שולחי הדואר של Google.

ניהול התאמה עם TrekMail

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

השוואה תפעולית:

ניהול מפוצל לעומת משולב

SMTP מנוהל עשוי להיות זמין במסגרת תנאי תוכנית בתשלום. עם SMTP משלכם מחברים ספק אמיתי כמו SES, SendGrid או Mailgun ובודקים את דרישותיו. בכל אפשרות נדרשים DNS מתאים והצלחת אימות עם התאמה בפועל, ולא רק מצב ירוק.

מדריכים שימושיים:

הדואר שלי מגיע לספאם מסביר תוצאות העברה. הגדרות IMAP & SMTP מתאר הגדרת לקוחות. כניסה מוצלחת של לקוח אינה הצלחת DMARC בדואר יוצא.

מחיר הפתיחה המוזכר ל-Starter הוא $3.50 לחודש. הניסיון החינמי המתואר לתוכניות בתשלום נמשך 14 ימים ודורש כרטיס אשראי להתחלה. Nano מתוארת כחינמית עם SMTP משלכם, עד 10 דומיינים ו-5 GB אחסון משותף. בדקו מחירים, תכונות ותנאים עדכניים במחירי TrekMail. העברת IMAP מעתיקה הודעות נתמכות, לא MX או את כל נתוני היישומים אוטומטית.

רשימת בדיקה סופית להתאמה

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

1. מפו דואר, CRM, חיוב, תמיכה, חנות, טפסים ושיווק.
2. בדקו From גלוי לכל מקור.
3. בדקו הרשאת SPF והתאמת Return-Path.
4. הגדירו ובדקו חתימת DKIM מתאימה.
5. השתמשו ב-aspf=r וב-adkim=r אלא אם צורך שנבדק דורש מצב אחר.
6. בדקו Gmail ונמענים רלוונטיים ונתחו Authentication-Results מהימנים.
7. השאירו בדרך כלל p=none עד בדיקה מספקת של מקורות ומסלולים חשובים; סינון מקומי אפשרי.
8. בחנו אכיפה בעזרת דוחות חלקיים, לוגים, ניסויים ותוכנית התאוששות. כישלון אינו סיווג אוטומטי כהתחזות; בדקו גם זרימות נדירות.

התאמה קושרת אימות לדומיין הגלוי, לא לבטיחות תוכן או ללגיטימיות מובטחת. השוו אפשרויות ועלויות עדכניות לניהול דומיינים ב-TrekMail.