מסירת דואר ו-DNS

יצירת רשומת DMARC: בדיקת DNS, דיווח ומדיניות

מאת Alexey Bulygin
יצירת רשומת TXT של DMARC עם יעד דיווח ובדיקת DNS והתאמה

לעיתים מחליטים ליצור רשומת 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לאהתאמת SPFr כברירת מחדל, 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 שלב אחר שלב

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

  1. מפו Google Workspace, Microsoft 365, תמיכה, CRM, טפסים, חיוב וניוזלטרים.
  2. בדקו SPF תקף ו-DKIM שנבחן למקורות בפועל; DMARC אינו מחליף אותם.
  3. צרו יעד מנוהל כמו dmarc@yourdomain.com או שירות דוחות מתאים.
  4. התחילו בדרך כלל ב-p=none.
  5. חקרו דוחות שהתקבלו לצד לוגים ומיפוי המקורות.
  6. תקנו שגיאות אימות והתאמה ל-From בשירותים הרלוונטיים.
  7. בחנו p=quarantine עם ניטור ותוכנית התאוששות.
  8. בחנו 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 שגויים.

בדקו שוב:

  1. רשומת מדיניות DMARC אחת בלבד.
  2. מארח _dmarc לפי כללי ממשק ה-DNS.
  3. ערך שמתחיל ב-v=DMARC1; p=....
  4. rua מפנה ליעד מנוהל עם הרשאה ופרטיות מתאימות.
  5. SPF יחיד לכל דומיין מעטפת רלוונטי במסגרת מגבלות המנגנונים והפרמטרים המשנים המחייבים DNS, כולל הערכה מקוננת.
  6. DKIM מוגדר ונבדק במקום שנתמך.
  7. שאילתה חיצונית מציגה את המדיניות הצפויה.
  8. התחלה בדרך כלל ב-none, אלא אם המקורות והמסלולים הרלוונטיים נבדקו מספיק.

TrekMail עשויה לרכז דומיינים, תיבות IMAP, מצב DNS, בחירת SMTP והעתקת דואר. IMAP מעתיק הודעות נתמכות; מעבר MX ונתוני יישומים דורשים טיפול נפרד. בדקו אפשרויות עדכניות ב-trekmail.net והמשיכו לבדוק דואר לאחר שינויים.

שתפו מאמר זה

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

התחברות ל-TrekMail

גישה ללוח הבקרה, לתיבות הדואר ול-DNS שלכם.

או

12 תווים הסיסמאות תואמות

או

דוא״ל האיפוס נשלח

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

בהמשך אתם מסכימים ל תנאי השימוש ול מדיניות הפרטיות של TrekMail.