סדר זהיר להגדרת SPF, DKIM ו-DMARC לדוא״ל

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

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

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

בשימוש ב-TrekMail, בדקו בתיעוד ובתנאים העדכניים את יכולות בדיקת DNS, דומיינים מותאמים, תיבות IMAP, ניתוב catch-all, העברה, הגירה ואפשרויות SMTP בתוכנית שלכם. התחילו במדריך הגדרת הדומיין, או קראו על יצירת דוא"ל עם דומיין.

מה SPF, DKIM ו-DMARC עושים בפועל

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

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

סדר הגדרה זהיר

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

1. מפו כל מערכת ששולחת בשם הדומיין.
2. פרסמו רשומת SPF אחת הכוללת שולחים לגיטימיים.
3. הפעילו DKIM אצל כל שולח שתומך בו.
4. פרסמו DMARC עם p=none ואספו דוחות.
5. תקנו כשלי התאמה.
6. עברו ל-p=quarantine ולאחר מכן ל-p=reject אם הראיות תומכות בכך.

זו התוכנית. הקושי אינו אורך הרשומות אלא מורכבות מערך השליחה בפועל.

שלב 1: מיפוי ו-SPF

SPF מתאים כשינוי ראשון כי הוא מבהיר אילו כתובות IP מורשות בנתיב MAIL FROM. הוא אינו פותר הכול, אך מספק נקודת התחלה וחושף ספקים ישנים.

לפני DNS, רשמו כל שולח: דואר ארגוני, חיוב, CRM, תמיכה, שיווק, טפסים ומדפסות. כל מה ששולח באמצעות @yourdomain.com דורש בדיקת נתיב האימות בפועל.

פרסמו רשומת SPF אחת, לא אחת ל-Google ואחרת לשיווק. כמה רשומות SPF TXT לאותו דומיין גורמות למצב שגיאה, כפי שמסבירות דוגמאות DNS של TrekMail.

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net include:amazonses.com ~all

~all עשוי להתאים למדיניות בזמן אימות התעבורה. השתמשו ב--all רק לאחר שבדקתם את כל נתיבי השליחה ושהמדיניות שלמה ומתאימה.

המלכודת העיקרית היא מגבלת החיפושים. לפי RFC 7208, הערכת SPF מוגבלת ל-10 חיפושים הנובעים ממנגנונים ומשנים רלוונטיים. הצטברות include:,‏ a או mx מקוננים עלולה להחזיר permerror.

אפשר להוסיף Google, HubSpot, Zendesk, QuickBooks, Mailchimp ומערכת כרטיסים ישנה. SPF נראה שלם, אך המקבל מגיע למגבלה ומקבל שגיאה.

בדומיינים רבים זה הופך לתהליך תפעולי. הסירו include רק לאחר אימות שאינם בשימוש, ופצלו תעבורה לתת-דומיינים רק עבור נתיב envelope פעיל שנבדק. הדבר חשוב במיוחד באירוח דוא"ל למספר דומיינים עם בדיקות DNS מרכזיות.

שלב 2: DKIM והתאמה

DKIM שני משום ש-SPF רגיש לנתיב. העברה עשויה לשבור SPF, אך DKIM עשוי להישאר תקף אם הנתונים החתומים לאחר canonicalization לא השתנו.

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

רשומת DNS טיפוסית:

Type: TXT
Host: trek._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqh...

ספקים מסוימים משתמשים ב-CNAME במקום מפתח TXT. פעלו לפי התיעוד הנוכחי והערכים הפעילים של הספק; השיטה משתנה, הדרישה לא.

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

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

אם Mailchimp חותמת בדומיין שלה ומשתמשת ב-return-path משלה, בדיקות לדומיינים אחרים עשויות לעבור בעוד DMARC נכשל לכתובת הגלויה שלכם. הגדירו אימות דומיין מותאם אצל הספק אם הוא נתמך.

העברה היא מקרה מוכר. קראו על הגדרה ותיקון של העברת דוא"ל אם הצוות נשען עליה.

שלב 3: התחלת DMARC עם p=none

נהוג להתחיל בבקשת p=none כדי לאסוף נתונים לפני בקשת בידוד או דחייה. מסננים מקומיים של המקבלים ממשיכים לפעול.

התחילו ברשומה בסיסית:

Type: TXT
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s

התאמה רגועה עשויה להתאים למבנה שלכם; מחמירה אינה תמיד טובה יותר. אל תעברו לדחייה לפני אימות השולחים וההתאמה.

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

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

שלב 4: תיקון לפי הדוחות

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

רוב הכשלים שייכים לכמה קבוצות:

• שולח לגיטימי חסר ב-SPF.
• ספק חותם DKIM, אך לא בדומיין שלכם.
• מערכת שיווק משתמשת בדומיין החזרה ברירת מחדל.
• מכשיר שולח ישירות במקום דרך SMTP מאומת.
• מקור לא מורשה עשוי להתחזות ל-From מכתובות IP אקראיות.

מדפסות וסורקים מועדים לבעיה. נתבו אותם דרך ממסר SMTP מאומת כשאפשר. בדקו בתנאי TrekMail העדכניים זמינות SMTP מנוהל או פרטי. מדריך IMAP ו-SMTP מתעד מארחים ויציאות נוכחיים ומציין IMAP ולא POP3.

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

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

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

אימות הרשומות משורת הפקודה

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

בדיקת SPF:

dig txt example.com +short

בדיקת DKIM לבורר:

dig txt trek._domainkey.example.com +short

בדיקת DMARC:

dig txt _dmarc.example.com +short

חפשו רשומת SPF אחת, מפתח DKIM תקף והמדיניות שהתכוונתם לפרסם. לאחר שינוי, הביאו בחשבון TTL ומטמון והשוו מול resolver חיצוני.

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

הדרך הישנה והחדשה

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

זה חשוב למספר מותגים, לקוחות או תיבות משותפות. אמתו בדף TrekMail הנוכחי את Starter שמתחילה ב-$3.50 לחודש, את Nano ב-$0 עם BYO SMTP, SMTP מנוהל בתוכניות בתשלום, וכן דומיינים, IMAP,‏ catch-all, העברה, הגירת IMAP בצד השרת ו-API בתוכניות מתאימות. הכדאיות תלויה בשימוש ובתכונות.

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

סיכום

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

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