אימות דוא״ל עם SPF, DKIM ו-DMARC מוסבר

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

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

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

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

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

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

SPF: מי רשאי לשלוח בשם הדומיין?

SPF הוא השכבה הראשונה. השרת המקבל משתמש בדומיין MAIL FROM או envelope בפועל, קורא את רשומת SPF TXT ובודק את כתובת ה-IP המתחברת. העברה ושרשראות include ארוכות עלולות לשבש אותו.

SPF מפורסם כרשומת TXT ב-DNS. דוגמה רגילה:

v=spf1 include:_spf.google.com include:spf.trekmail.net -all

משמעות השורה:

1. v=spf1 מצהיר על סוג הרשומה.
2. include: מפנה לתשתית שליחה שדומיין אחר פרסם.
3. -all מבקש fail לכל מקור אחר.

מגבלה חשובה היא 10 שאילתות DNS לפי RFC 7208. כל include נספר, וכן מנגנונים ו-modifiers מקוננים שמבצעים שאילתה. חריגה עלולה להחזיר PermError, שאינו מעבר SPF תקף.

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

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

בשימוש ב-TrekMail, התיעוד הנוכחי מפרט את ה-include הדרוש ואת השילוב ללא כפילות: רשומות DNS נדרשות.

DKIM: מי חתם והאם הנתונים נשמרו?

DKIM חותם במפתח פרטי והנמען מאמת באמצעות מפתח ציבורי ב-DNS. הוא עשוי לשרוד העברה אם חתימה תקפה ומיושרת והנתונים החתומים לאחר canonicalization נשארים תקינים. שינוי body או כותרות חתומות עלול להכשיל אותו.

רשומות DKIM נמצאות תחת selector כגון selector1._domainkey.example.com או dkim._domainkey.example.com. השולח חותם עם ה-selector והנמען מביא את המפתח מ-DNS.

ערך DNS טיפוסי:

Host: dkim._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G...

כשלים תפעוליים נפוצים:

1. לאחר סבב מפתחות השרת עדיין משתמש ב-selector הישן.
2. אחרי מעבר ספק המפתח הציבורי החדש לא פורסם.
3. מארח DNS מעבד לא נכון את ערך TXT הארוך.
4. רשימת דיוור משנה את body ושוברת את החתימה.

בסביבה תואמת, השתמשו במפתחות 2048 סיביות כברירת מחדל מומלצת, אלא אם הספק או DNS מחייבים חלופה שנבדקה. מערכות ישנות עשויות להשתמש ב-1024 סיביות; בדקו תאימות לפני מעבר ב-2026.

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

DMARC: מדיניות מבוקשת לנמענים

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

מפרסמים ב-_dmarc.example.com. אפשר להתחיל כך:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

מחמירים לאחר מלאי ובדיקות חיות:

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

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

p=none אינו מבקש הגבלת DMARC, p=quarantine מבקש יחס חשוד ו-p=reject מבקש דחייה. לנמענים יש מדיניות מקומית, ולכן אין disposition אחידה מובטחת.

יישור הוא מלכודת מרכזית. לדוגמה:

From גלוי: newsletter@yourcompany.com
Return-Path: bounce.vendor.com
דומיין DKIM: vendor.com

SPF ו-DKIM עשויים לעבור טכנית, אך DMARC נכשל כי אף אחד אינו מיושר עם yourcompany.com.

זה קורה ב-Mailchimp, HubSpot, Zendesk ובמערכות CRM כאשר אימות דומיין הלקוח אינו מופעל בפועל. השאלות הנפוצות הנוכחיות של Google דורשות משולחי תפוצה רלוונטיים לחשבונות Gmail אישיים SPF ו-DKIM, ולפחות אחד מיושר עם From בדואר ישיר, וכן DMARC מינימלי, גם p=none: שאלות נפוצות על הנחיות השולחים של Google.

SPF לעומת DKIM לעומת DMARC: מה חשוב יותר?

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

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

מדוע העברה ורשימות דיוור גורמות לכשלים חריגים?

העברה עלולה לשבור SPF משום שהמעביר שולח הלאה. DKIM עשוי לעזור אם החתימה התקפה והמיושרת נשמרת, אך שינוי body או subject עלול לשבור גם אותו.

ההגדרה עשויה להיראות נכונה בעוד מסלול עקיף נכשל: כתובת IP משתנה, הרשימה מוסיפה footer ושני אותות היישור נעלמים. הדבר מסביר כשל DMARC אך אינו מוכיח את תוצאת המסירה.

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

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

רשומות תקינות אינן מבטיחות תיבת דואר נכנס. נמענים בודקים גם reverse DNS, TLS, תלונות, מוניטין והסרה. SPF, DKIM ו-DMARC הם הבסיס, לא כל המודל.

1. Forward-confirmed reverse DNS: כתובת IP שולחת צריכה PTR ששמו נפתר חזרה לאותה כתובת. Google מונה DNS קדמי ואחורי תקינים בדרישות הרלוונטיות.
2. TLS: ספקים גדולים מצפים ל-TLS, והשאלות הנפוצות של Google מציינות דואר ללא TLS כסיבה אפשרית לכשל זמני או קבוע.
3. תלונות ספאם: ההנחיה הרלוונטית הנוכחית של Google מציינת פחות מ-0.1% ומזהירה מפני 0.3%. זו אינה הבטחת מסירה כללית.
4. הסרה בלחיצה אחת: בדואר שיווקי רלוונטי נדרשות כותרות בסגנון RFC 8058, לא רק קישור footer חבוי.

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

הגדרה בלי לפגוע בסביבת הייצור

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

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

רשומות בסיס לדומיין TrekMail עם שליחה מנוהלת עשויות להיראות כך, בהתאם להגדרת החשבון הנוכחית:

MX  @                mail.trekmail.net.            priority 10
TXT @                v=spf1 include:spf.trekmail.net -all
TXT dkim._domainkey  v=DKIM1; k=rsa; p=...unique key from dashboard...
TXT _dmarc           v=DMARC1; p=quarantine; rua=mailto:dmarc@trekmail.net

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

השיטה הישנה לעומת החדשה

באופן מסורתי שילמו לפי משתמש על חבילה גדולה או ניהלו לבד DNS, TLS, selectors ומוניטין. סביבה מודולרית יכולה להפריד אירוח תיבות משליחה ולרכז אימות והגירה.

לפי ההצעה הנוכחית, Nano עשויה לכלול עד 10 דומיינים, 5 ג׳יגה-בייט של אחסון משותף ו-BYO SMTP. חבילות בתשלום מתחילות כעת ב-$3.50 לחודש ועשויות לכלול SMTP מנוהל. דומיינים מותאמים, IMAP, catch-all, העברה, הגירת IMAP וגישה ל-API תלויים בחבילה. לחבילות בתשלום עשוי להיות ניסיון חינם של 14 ימים המחייב כרטיס אשראי; Nano עשויה להיות חינמית ללא כרטיס לפי התנאים הנוכחיים. בדקו מחירים, תכונות ומגבלות.

בדומיינים רבים, לוח אחד, אחסון משותף, ערכי DNS לחשבון והגירה בצד השרת יכולים לרכז עבודה בלי להבטיח חיסכון. השוו אירוח דוא"ל לריבוי דומיינים ו-מחירי TrekMail.

סיכום: SPF, DKIM ו-DMARC הם קו הבסיס

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

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