חיפשתם "activetrail spf dkim הגדרה" כי משהו לא עובד — או כי אתם רוצים לעשות את זה נכון מההתחלה. ActiveTrail מאפשרת לשלוח בשם הדומיין שלכם (למשל newsletter@העסק-שלכם.co.il), אבל מבחינת ספקי דואר כמו Gmail, Outlook ו-iCloud, זו עדיין שליחה מתשתית זרה — של ActiveTrail — בשם דומיין שלא בבעלותה. בלי אימות DNS מפורש, הספקים האלה פשוט לא סומכים על ההצהרה הזו, וזה מתבטא בנחיתה בספאם, בשיעורי פתיחה נמוכים ובקושי לצאת מ"טאב הפרסומות" בג׳ימייל. המדריך הזה עובר על כל שלב: מה זה SPF ו-DKIM בפועל, איך מגדירים אותם בלוח הבקרה של ActiveTrail, ולמה הרוב הגדול של הכשלים נובע מטעות DNS אחת קטנה וספציפית.
למה אימות דומיין קריטי לפני שליחה דרך ActiveTrail
מאז שגוגל ויאהו הידקו את הדרישות למשווקים בהיקף גדול, SPF ו-DKIM תקינים, יחד עם DMARC ברמת מדיניות בסיסית לפחות, הפכו לתנאי סף — לא "נחמד שיהיה". גם אם רוב הרשימה שלכם היא ישראלית, חלק ניכר מהתיבות עדיין רץ על Gmail (כעסקי וכאישי) או על Outlook/Microsoft 365, כך שהדרישות האלה נוגעות לכם ישירות. בנוסף, אצל ספקים כמו Walla! Mail ו-iCloud חוסר אימות מתורגם לרוב פשוט לספאם, בלי שום התראה מסודרת.
הגדרת SPF: איך לא לשבור שליחות דואר קיימות
SPF היא רשומת TXT אחת בדומיין שמפרטת אילו שרתים מורשים לשלוח דואר בשמו. הטעות הכי שכיחה היא הוספת רשומת SPF שנייה במקום מיזוג הרשומה הקיימת. לדומיין מותר להיות רק רשומת SPF אחת — אם יש שתיים, ספקי דואר עלולים להתעלם משתיהן או לבחור שרירותית, וזה בדיוק המצב שגורם למיילים תקינים מ-Google Workspace או מהאתר לקרוס ביחד עם השליחות מ-ActiveTrail.
בפועל: קודם בודקים איזו רשומת SPF כבר קיימת לדומיין (למשל דרך כל כלי בדיקת DNS), ואז מוסיפים לתוכה את ה-include שהמערכת של ActiveTrail מספקת לכם באזור האישי, בלי למחוק include-ים קיימים. שומרים, ומחכים להתפשטות DNS — בדרך כלל דקות עד כמה שעות.
הגדרת DKIM ב-ActiveTrail שלב אחר שלב
- נכנסים לאזור ניהול הדומיינים בלוח הבקרה של ActiveTrail ובוחרים בדומיין השליחה.
- המערכת מציגה רשומת CNAME ייעודית לאימות DKIM — לא רשומת TXT כמו ב-SPF.
- מעתיקים את שם המארח (host) ואת הערך (value) בדיוק כפי שהם מופיעים, ומוסיפים אותם כרשומת CNAME בממשק ה-DNS של הדומיין.
- חוזרים ללוח הבקרה של ActiveTrail ומפעילים בדיקת אימות — היא בודקת שהרשומה אכן מוחזרת כשצריך.
חשוב לוודא שהמארח שמעתיקים לא כולל את שם הדומיין פעמיים — טעות הקלדה נפוצה כשמעתיקים מלוח בקרה לממשק DNS אחר, וזו סיבה שכיחה לכך שהאימות "תקוע בהמתנה" ימים שלמים.
DMARC: השלב שרוב משתמשי ActiveTrail מדלגים עליו
ActiveTrail לא תמיד דורשת DMARC כתנאי טכני להתחלת שליחה, אבל בלעדיו הדומיין שלכם חשוף לזיוף — מישהו יכול לשלוח מייל שנראה כאילו הגיע מכם בלי לעבור דרך ActiveTrail בכלל. מדיניות DMARC בסיסית ברמת p=none כבר נותנת לכם דוחות (aggregate reports) שמראים מי שולח בשם הדומיין שלכם ומאיפה, בלי לחסום כלום. זו נקודת התחלה בטוחה לפני מעבר הדרגתי ל-p=quarantine ואז ל-p=reject ברגע שבטוחים שכל מקורות השליחה הלגיטימיים — כולל ActiveTrail וכל שירות נוסף כמו סליקה או חשבוניות — עוברים אימות.
טעויות נפוצות שהופכות אימות תקין ל"לא עובד"
- שינוי רשומת ה-CNAME של DKIM אחרי שכבר סומן כמאומת בלוח הבקרה, בלי לרענן את הבדיקה.
- שליחה מתת-דומיין (למשל mail.העסק.co.il) בזמן שהאימות הוגדר רק לדומיין הראשי.
- שימוש מקביל בעוד פלטפורמה — למשל Shopify, WooCommerce או מערכת חשבוניות — שדורשת include משלה ב-SPF, ולא רק ActiveTrail.
- אי-התאמה בין דומיין ה-From לדומיין שמופיע ב-DKIM signing domain — גורם ל-DMARC alignment להיכשל גם כשה-SPF וה-DKIM עצמם תקינים.
איך לבדוק שההגדרה באמת עובדת
סטטוס "מאומת" בלוח הבקרה של ActiveTrail מראה שהרשומות קיימות ב-DNS — הוא לא מראה איך ספקי הדואר בפועל מתייחסים למייל שלכם. הדרך היחידה לדעת בוודאות היא לשלוח מייל אמיתי ולבדוק את התוצאה בפועל: לאן הוא נחת אצל Gmail, Outlook, Walla! ו-iCloud, מה הכותרות (headers) מראות לגבי SPF/DKIM/DMARC, ואיך המייל בעצם נראה בתיבה — כולל תמיכה ב-RTL כשהתוכן בעברית מעורב עם מספרים או טקסט בלועזית.
כלי כמו בדיקת מסירות חינמית ללא הרשמה עושה בדיוק את זה: שולחים מייל לכתובות seed שהכלי נותן אצל מגוון ספקים, ומקבלים תוצאה ברורה — Inbox, Spam או Promotions — יחד עם דוח SPF/DKIM/DMARC וצילום מסך של איך המייל נראה בתיבה עצמה, גם במצב כהה. זו הדרך המהירה ביותר לוודא שהעבודה שעשיתם בלוח הבקרה של ActiveTrail באמת מתורגמת לנחיתה ב-Inbox.