לעיתים מחליטים ליצור רשומת DMARC בעקבות התחזות, אזהרות Gmail או בקשת DNS מספק. תוצאות SPF ו-DKIM שונות בין הודעות מצריכות בדיקה. אם הסביבה עדיין בהקמה, ראו את מדריך הדואר העסקי כדי לתאם בין הדומיין, התיבות וה-DNS.
קיום רשומה אינו מבטיח שימוש תקין. מארח שגוי, מדיניות לא מתאימה, יעד דוחות לא פעיל או התאמה חסרה יכולים לפגוע בהגדרה. DMARC גם אינו מבטיח הגעה לדואר הנכנס או מניעת כל התחזות.
המדריך מסביר יצירת רשומה, תגיות חשובות, פרסום ב-_dmarc.yourdomain.com ובחינת מעבר מניטור לאכיפה.
מה מפרסמים ברשומת DMARC?
מפרסמים TXT ב-_dmarc.yourdomain.com, המתחילה ב-v=DMARC1 וכוללת מדיניות תקפה כמו p=none, p=quarantine או p=reject. DMARC מבקש טיפול בדואר שבו אף אחת מהבדיקות, SPF או DKIM, אינה מצליחה עם ההתאמה הנדרשת ל-From.
דוגמה תקפה מינימלית:
Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none;היא מפרסמת מדיניות ללא בקשת הגבלה מכוח DMARC, אך אינה מבקשת דוחות מצטברים. סינון מקומי עדיין אפשרי. זו אינה הגדרת דיווח מלאה.
דוגמה הכוללת דיווח:
Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100לאחר בדיקה מספקת אפשר להחליף את המדיניות הקיימת, למשל כך:
Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100לפי RFC 7489, התגית v חייבת להיות ראשונה ו-p חייבת להופיע. רשומה לא תקפה עשויה לא לשמש כמתוכנן. לפרטים ראו RFC 7489.
היכן יוצרים את הרשומה ב-DNS?
לא מפרסמים בשורש הדומיין אלא ב-_dmarc. עבור example.com, יעד החיפוש הוא _dmarc.example.com. שם אחר לא מספק את המדיניות הרצויה.
אל תפרסמו את הערך ב-@. הזנת _dmarc.example.com במלואו או רק _dmarc תלויה בממשק ה-DNS ובשאלה אם הוא מוסיף את שם האזור. בדקו את השם המלא שנוצר.
לאחר הפרסום בדקו גם מחוץ ללוח:
dig txt _dmarc.example.com +short
nslookup -q=txt _dmarc.example.comצריכה להיות רשומת מדיניות DMARC אחת שמתחילה ב-v=DMARC1. רשומות TXT אחרות אינן בהכרח סתירה, וכמה מקטעי טקסט בתוך רשומה אחת מצטרפים לערך יחיד.
ב-TrekMail בדקו את הערכים המתאימים להגדרה בפועל. ראו הוספת דומיין, רשומות DNS נדרשות ובדיקת מצב DNS. בדיקת לוח אינה מחליפה ניסוי של כל מסלולי השליחה.
תגיות ברשומת DMARC
התחילו ב-v, ב-p וב-rua כשנדרש דיווח. תגיות התאמה מספקות בקרה נוספת. השתמשו באפשרויות נוספות אחרי הבנת השפעתן.
| תגית | חובה? | תפקיד | עצה מעשית |
|---|---|---|---|
v | כן | גרסה | DMARC1 וחייבת להופיע ראשונה |
p | כן | מדיניות מבוקשת בכישלון | בדרך כלל none, ובהמשך בחינת quarantine ו-reject |
rua | לא | יעד דוחות מצטברים | יעד מנוהל לצד לוגים עצמאיים |
ruf | לא | יעד דוחות כישלון | לבחירה, בתמיכה מוגבלת ועם רגישות לפרטיות |
adkim | לא | התאמת DKIM | ברירת המחדל r; בדקו את מבנה הדומיינים |
aspf | לא | התאמת SPF | r כברירת מחדל, s לצורך מבוסס |
pct | לא | שיעור החלת מדיניות מבוקש בדואר שנכשל | 100 אינו מבטיח טיפול בכל הדואר או אצל כל נמען |
sp | לא | מדיניות נורשת לדומייני משנה | בעת חזרה למדיניות הדומיין הארגוני כשאין רשומת מדיניות ייעודית בתוקף לדומיין המשנה |
רשומה עם p=none וללא rua יכולה להיות תקפה, אך אינה מבקשת דוחות מצטברים. לוגים ובדיקות עצמאיות עדיין אפשריים. הדיווח דורש ניהול פרטיות וגישה, ויעד חיצוני עשוי לדרוש הרשאת DNS.
בחירת המדיניות המתאימה
התחילו בדרך כלל ב-p=none אם לא נבדקו כל הזרימות. בחנו p=quarantine לאחר תיקון ובדיקות. שקלו p=reject אחרי בדיקת מקורות מספקת, הכוללת תעבורה לא מוכרת וזרימות לגיטימיות נדירות.
| מדיניות | טיפול מבוקש | מועד לבחינה | סיכון |
|---|---|---|---|
p=none | ללא בקשת הגבלת DMARC | בדיקה ראשונית | אין בקשת הגבלה לדואר שנכשל; מסננים מקומיים ממשיכים לפעול |
p=quarantine | התייחסות להודעות כחשודות | לאחר בדיקה, כשמתאים | דואר לגיטימי חריג עלול להיפגע; אין הבטחת תיקייה או שחזור |
p=reject | בקשת סירוב | סביבה שנבדקה מספיק | דואר לגיטימי שהוגדר לא נכון עלול להידחות; חריגים מקומיים אפשריים |
Google מחילה דרישות SPF, DKIM והתאמת From רלוונטית על שולחים בכמויות גדולות. ל-DMARC מספיק אימות אחד שהצליח ומתאים. בדקו את הדרישות לקטגוריית השליחה בשאלות נפוצות על הנחיות שולחי Google בלי להניח דרישות עתידיות.
DMARC אינו רק סימון ברשימה. אם CRM משתמש בדומיין שלכם ב-From ובדומיין הספק לחתימה ולהחזרות, האימות יכול לעבור בלי הצלחה מותאמת ל-DMARC.
יצירת רשומת DMARC שלב אחר שלב
מפו מקורות ופרסמו מדיניות ניטור, ואז בחנו אכיפה באמצעות דוחות, לוגים וניסויים אמיתיים. תקופת דוחות שקטה אינה מוכיחה שכל הזרימות נבדקו.
- מפו Google Workspace, Microsoft 365, תמיכה, CRM, טפסים, חיוב וניוזלטרים.
- בדקו SPF תקף ו-DKIM שנבחן למקורות בפועל; DMARC אינו מחליף אותם.
- צרו יעד מנוהל כמו
dmarc@yourdomain.comאו שירות דוחות מתאים. - התחילו בדרך כלל ב-
p=none. - חקרו דוחות שהתקבלו לצד לוגים ומיפוי המקורות.
- תקנו שגיאות אימות והתאמה ל-From בשירותים הרלוונטיים.
- בחנו
p=quarantineעם ניטור ותוכנית התאוששות. - בחנו
p=rejectלאחר בדיקות מספקות, כולל זרימות נדירות חיוניות.
דוגמת ניטור להמחשה בסביבה בשנת 2026:
Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100למסלולי העברה ראו העברת דואר מהדומיין ל-Gmail. SPF המקורי עלול להיכשל; DKIM מסייע רק עם חתימה תקפה ומותאמת ונתונים חתומים שנשמרו לפי הקנוניזציה. ARC עשוי לסייע בהחלטה מקומית, אך אינו הופך כישלון DMARC להצלחת אימות.
טעויות נפוצות ביצירת הרשומה
בדקו שמות מארח, מדיניות כפולה, כתובות דיווח ואימות בסיסי. בדקו את הרשומה גם מחוץ לסביבת הניהול.
שימו לב לטעויות הבאות:
1. פרסום בשורש במקום ב-_dmarc.
ב-@ לא תימצא מדיניות DMARC הרצויה.
2. שימוש ביותר מרשומת מדיניות DMARC אחת.
RFC 7489 מסביר שרשומות מדיניות מרובות עוצרות את העיבוד. מקטעי טקסט באותה רשומה הם דבר אחר.
3. החלת p=reject מיד.
דואר איפוס, חשבוניות או תשובות תמיכה משירות שנשכח עלול להידחות.
4. הפניית rua ליעד לא פעיל.
הדבר עלול למנוע קבלה; היעדר דוחות אינו מוכיח שנמענים אכן שלחו אותם.
5. ציפייה ש-DMARC יתקן העברה.
נדרשת הצלחת SPF או DKIM עם התאמה. בדקו אם DKIM תקף ומותאם נשמר במסלול האמיתי.
אישורי הזמנה, תמיכה ושיווק משתמשים בשלושה ספקי SMTP. אתם מפרסמים
p=rejectבלי לבדוק: מסלול אחד עובר ושניים נכשלים. דואר לקוחות עשוי להידחות בהחלת המדיניות; גם החלטת הנמען משפיעה.
להקמה חדשה, המדריך יצירת דואר עם הדומיין שלכם מסביר את עבודת ה-DNS והתיבות סביב האימות.
ניהול DMARC בדומיינים רבים
גיליונות וערכים מפניות ישנות עלולים לבלבל. לוח משותף ורשומות מותאמות לכל דומיין עשויים לארגן את הבדיקה, אך עדיין צריך לאמת DNS ושליחה בפועל.
| ניהול מפוצל | אפשרויות TrekMail |
|---|---|
| כניסה לכל רשם לבדיקת ערכים עדכניים | ניהול מספר דומיינים בסביבה משותפת |
| השוואת TXT ידנית | בדיקות להערכת הבדלי DNS, ללא הבטחת השלמת הפצה |
| פיצול אימות בין כלים | סיוע בהגדרת SPF, DKIM ו-DMARC באותו מקום |
| חיוב למשתמש בחלק מהשירותים | מספר דומיינים במסגרת התוכנית, במחיר פתיחה מוזכר של $3.50 לחודש |
TrekMail עשויה להציע מספר דומיינים, אחסון משותף, תיבות IMAP, העתקת דואר, catch-all, העברה ו-SMTP משלכם או מנוהל לפי התנאים. Nano מתוארת כחינמית עד 10 דומיינים עם SMTP משלכם; מחיר הפתיחה בתשלום המוזכר הוא $3.50 לחודש. בדקו תכונות ותנאים עדכניים במחירי TrekMail.
סביבה משותפת עשויה לארגן בדיקה שהתפזרה בין חמישה ספקים ועשרים כרטיסיות. היא אינה מוכיחה לבדה את אימות כל הזרימות או חיסכון מסוים.
בדיקה אחרונה לפני אכיפה
בדקו הצלחת אימות עם התאמה למקורות לגיטימיים, יעד דיווח פעיל ורשומת מדיניות DMARC תקפה אחת ב-_dmarc. DMARC אינו מתקן SPF או DKIM שגויים.
בדקו שוב:
- רשומת מדיניות DMARC אחת בלבד.
- מארח
_dmarcלפי כללי ממשק ה-DNS. - ערך שמתחיל ב-
v=DMARC1; p=.... ruaמפנה ליעד מנוהל עם הרשאה ופרטיות מתאימות.- SPF יחיד לכל דומיין מעטפת רלוונטי במסגרת מגבלות המנגנונים והפרמטרים המשנים המחייבים DNS, כולל הערכה מקוננת.
- DKIM מוגדר ונבדק במקום שנתמך.
- שאילתה חיצונית מציגה את המדיניות הצפויה.
- התחלה בדרך כלל ב-
none, אלא אם המקורות והמסלולים הרלוונטיים נבדקו מספיק.
TrekMail עשויה לרכז דומיינים, תיבות IMAP, מצב DNS, בחירת SMTP והעתקת דואר. IMAP מעתיק הודעות נתמכות; מעבר MX ונתוני יישומים דורשים טיפול נפרד. בדקו אפשרויות עדכניות ב-trekmail.net והמשיכו לבדוק דואר לאחר שינויים.