Хорошая идея? Отказаться от входящих писем с окончанием нашего собственного домена? (потому что они должны быть поддельными)

יש כבר תקן לעשות זאת. קוראים לזה DMARC . אתה מיישם את זה עם חתימה על DKIM (וזה רעיון טוב ליישם בכל מקרה).

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

המשמעות היא שאתה עדיין יכול לקבל שירותים חיצוניים למסור דוא"ל לדומיין שלך (כמו דסק עזרה מתארח תוכנה וכו '), אך יכול לחסום ניסיונות דיוג של חנית.

הדבר הנהדר הנוסף ב- DMARC הוא שתקבל דוחות כשל, כך שתוכל לנהל את הטיפול בחריגים כנדרש.

הצד התחתון הוא שאתה צריך להיות בטוח שהכל הסתדר ביסודיות מראש או שתתחיל להפיל דוא"ל לגיטימי.

Да, если вы знаете, что электронная почта для вашего домена должна поступать только с вашего собственного сервера, тогда вам следует заблокировать любую электронную почту для этого домена, исходящую с другого сервера. Даже если почтовый клиент отправителя находится на другом хосте, они должны войти на ваш сервер (или любой другой почтовый сервер, который вы используете) для отправки электронной почты.

Сделав еще один шаг, вы можете настроить свой сервер для проверки записей SPF. Вот сколько хостов предотвращают подобную активность электронной почты. Записи SPF - это запись DNS, запись TXT, которая дает правила о том, каким серверам разрешено отправлять электронную почту для вашего домена. Как включить проверку записей SPF, будет зависеть от вашей почтовой службы, и это выходит за рамки того, о чем мы будем говорить здесь. К счастью, в большинстве сред хостинга и программного обеспечения есть документация по работе с записями SPF. Возможно, вы захотите узнать больше о SPF в целом. Вот статья в Википедии: https://en.wikipedia.org/wiki/Sender_Policy_Framework

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

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

Возможно, но есть некоторые случаи, которые вам необходимо рассмотреть, прежде чем вносить такое изменение.

1) Использует ли кто-либо в вашей компании какие-либо внешние услуги (например, Survey Monkey, Постоянный контакт и т. Д.), Чтобы отправлять электронные письма, которые кажутся "из" вашего домена? Даже если они не делают этого сегодня, могут ли они сделать это в будущем?

2) Есть ли какие-нибудь внешние адреса, которые пересылаются вашим пользователям? Например, предположим, что учетная запись gmail (скрытая) пересылает на (скрытый), а ваш пользователь (скрытый) отправляет на (скрытый). В этом случае сообщение будет приходить извне, но с (скрытым) адресом От:

3) Подписаны ли какие-либо из ваших пользователей на внешние списки рассылки, которые сохраняют исходный адрес «От:» в сообщениях в этот список? Например, если Боб подписывается на (скрыто) и отправляет сообщение, он получит входящее сообщение примерно следующего вида: От: (скрыто) Кому: (скрыто) Отправитель:

Если ваш сервер наивно смотрит на заголовок «От:» (вместо «Отправитель:»), он может отклонить это сообщение, потому что вы получаете его извне.

Из-за всего вышесказанного, имея Общая политика «... от настоящего отправителя в нашей компании, электронное письмо никогда не будет приходить извне» не всегда осуществима.

Вы можете сделать это в PowerShell, обновив разрешения коннектора получения, чтобы исключить анонимных пользователей из отправки в качестве полномочного отправителя домена:

Get-ReceiveConnector <identity> | Remove-AdPermission -User "NT AUTHORITY\Anonymous Logon" -ExtendedRights ms-Exch-SMTP-Accept-Authoritative-DomainSender

Однако проблема возникает, когда у вас есть удаленные серверы приложений, которым необходимо отправлять вам сообщения о статусе, так как они обычно используют ваше доменное имя в своем адресе От. Можно создать дополнительный коннектор получения для их конкретных IP-адресов, чтобы случайно не исключить их.

В GMail есть параметр, позволяющий отправлять электронные письма с доменом, отличным от GMail, при условии, что адрес электронной почты будет сначала проверен. Ваше решение заблокирует эти электронные письма.

Наличие у вас пользователей, которые могут использовать эту функцию GMail, и целесообразность их обслуживания во многом зависит от поведения внутри вашей компании.

SPF не вылечит это, так как конверт вполне может иметь правильный проход SPF (т. Е. Спамеры, использующие скомпрометированный сервер), в то время как они будут подделывать электронную почту внутри конверта. Что вам нужно, так это блокировать сообщение электронной почты вашего собственного домена, в конверте которого указан исходный почтовый сервер, который вам не подходит.

Я настоятельно рекомендую вам внедрить DMARC для вашего домена. DMARC поможет вам защитить свой бренд и предотвратить спуфинг или фишинговые атаки на ваш домен. Чтобы использовать DMARC, вы также должны настроить SPF и DKIM для своего домена.

Еще одно преимущество внедрения DMARC заключается в том, что вы можете использовать новый уровень проверки подлинности электронной почты, который называется BIMI. BIMI— это дополнительный уровень проверки подлинности электронной почты, который отображает ваш логотип в почтовых ящиках ваших клиентов. BIMI позволяет вашей электронной почте выделиться среди остальных.

Если вы хотите узнать больше об отчетности DMARC и о том, как ее настроить, мы только что закончили Полное руководство по отчетности DMARC в 2022 году.

Кроме того, вы можете использовать наш анализатор DMARCдля бесплатного мониторинга и просмотра 10 000 сообщений в месяц.