Office 365 でのスプーフィング対策保護Anti-spoofing protection in Office 365

この記事では、Office 365 で、偽造された送信者ドメイン (スプーフィングされたドメイン) を使用するフィッシング攻撃を軽減する方法について説明します。This article describes how Office 365 mitigates against phishing attacks that use forged sender domains, that is, domains that are spoofed. これは、メッセージを分析して、標準の電子メール認証方法や、その他の送信者評価の手法を使用して認証できないメッセージをブロックすることで実現します。It accomplishes this by analyzing the messages and blocking the ones that cannot be authenticated using standard email authentication methods, nor other sender reputation techniques. 今回の変更は、Office 365 の組織が対象になるフィッシング攻撃の数を減らすために実装されました。This change was implemented to reduce the number of phishing attacks to which organizations in Office 365 are exposed.

この記事では、今回の変更が実施された理由、今回の変更に対応するように準備する方法、影響を受けるメッセージの表示方法、メッセージに関するレポートの作成方法、誤検出を減らす方法、および Microsoft への送信者が今回の変更にどのように備えるべきかについても説明します。This article also describes why this change is being made, how customers can prepare for this change, how to view messages that will be affected, how to report on messages, how to mitigate false positives, as well as how senders to Microsoft should prepare for this change.

Microsoft のスプーフィング対策テクノロジは、最初に Office 365 Enterprise E5 サブスクリプションを所有する組織、またはサブスクリプションに対応する Office 365 Advanced Threat Protection (ATP) アドオンを購入した組織に導入されました。Microsoft's anti-spoofing technology was initially deployed to its organizations that had an Office 365 Enterprise E5 subscription or had purchased the Office 365 Advanced Threat Protection (ATP) add-on for their subscription. 2018 年 10 月の時点では、Exchange Online Protection (EOP) を保有する組織にも保護の範囲を広げました。As of October, 2018 we extended the protection to organizations that have Exchange Online Protection (EOP) as well. また、すべてのフィルターが相互に学習する方法のため、Outlook.com のユーザーも影響を受ける可能性があります。Additionally, because of the way all of our filters learn from each other, Outlook.com users may also be affected.

フィッシング攻撃でスプーフィングが使用される方法How spoofing is used in phishing attacks

ユーザーの保護について、Microsoft はフィッシングの脅威を重大視しています。When it comes to protecting its users, Microsoft takes the threat of phishing seriously. 迷惑メールの送信者やフィッシャー (フィッシング詐欺師) がよく使用する手法の 1 つにスプーフィング (なりすまし) があります。スプーフィングによって、送信者が偽装されると、メッセージは実際の発信元とは異なる送信者または送信元から送られてきたように見えます。One of the techniques that spammers and phishers commonly use is spoofing, which is when the sender is forged, and a message appears to originate from someone or somewhere other than the actual source. この手法は、多くの場合、ユーザーの認証情報を詐取しようとするフィッシング活動で使用されます。This technique is often used in phishing campaigns designed to obtain user credentials. Microsoft のスプーフィング対策テクノロジでは、具体的には「From: ヘッダー」の偽装を調べます。Outlook などの電子メール クライアントには、このヘッダーが表示されます。Microsoft's Anti-spoof technology specifically examines forgery of the 'From: header' which is the one that shows up in an email client like Outlook. Microsoft は高確率で From: ヘッダーがスプーフィングされていると確信すると、そのメッセージをスプーフィングとして識別します。When Microsoft has high confidence that the From: header is spoofed, it identifies the message as a spoof.

スプーフィング メッセージは、実際のユーザーに 2 つの悪影響を及ぼします。Spoofing messages have two negative implications for real life users:

1. ユーザーがスプーフィングされたメッセージにだまされる1. Spoofed messages deceive users

1 つ目は、スプーフィングされたメッセージがユーザーにリンクをクリックするように誘導し、認証情報を提出させたり、マルウェアをダウンロードさせたり、機密コンテンツを含めてメッセージに返信させたりします (最後のものは「ビジネス メール詐欺」と呼ばれます)。First, a spoofed message may trick a user into clicking a link and giving up their credentials, downloading malware, or replying to a message with sensitive content (the latter of which is known as Business Email Compromise). たとえば、次のフィッシング メッセージにある msoutlook94@service.outlook.com は、なりすましの送信者です。For example, the following is a phishing message with a spoofed sender of msoutlook94@service.outlook.com:

service.outlook.com を偽装しているフィッシング メッセージ

上記のものは実際には service.outlook.com から発信されたものではありませんが、そう見えるようにフィッシャーがスプーフィングしています。The above did not actually come from service.outlook.com, but instead was spoofed by the phisher to make it look like it did. ここでは、ユーザーをだまして、メッセージ内のリンクをクリックさせようとしています。It is attempting to trick a user into clicking the link within the message.

次の例では、contoso.com のスプーフィングです。The next example is spoofing contoso.com:

フィッシング メッセージ: ビジネス メール詐欺

このメッセージは正当なものに見えますが、実際にはなりすましです。The message looks legitimate, but in fact is a spoof. このフィッシング メッセージは、フィッシングのサブカテゴリであるビジネス メール詐欺の一種です。This phishing message is a type of Business Email Compromise which is a subcategory of phishing.

2. ユーザーが本物と偽物のメッセージを混同する2. Users confuse real messages for fake ones

2 つ目に、スプーフィングされたメッセージために、フィッシング メッセージについての知識があっても、本物とスプーフィングされたメッセージの見分けがつかないユーザーが疑いを持つようになってしまいます。Second, spoofed messages create uncertainty for users who know about phishing messages but cannot tell the difference between a real message and spoofed one. たとえば、次のものは Microsoft Security アカウントの電子メール アドレスから送信された本物のパスワード リセットのサンプルです。For example, the following is an example of an actual password reset from the Microsoft Security account email address:

Microsoft の正当なパスワード リセット

上記のメッセージは Microsoft から発信されたものですが、その一方で、ユーザーは今までにフィッシング メッセージを何度も受け取っています。そのメッセージは、リンクをクリックするように誘導して、認証情報を提出させたり、マルウェアをダウンロードさせたり、機密コンテンツを含めてメッセージに返信させたりしようとします。The above message did come from Microsoft, but at the same time, users are used to getting phishing messages that may trick a user into clicking a link and giving up their credentials, downloading malware, or replying to a message with sensitive content. 本物と偽物のパスワード リセットを見分けることが難しいため、多くのユーザーは、こうしたメッセージを無視したり、スパムとして報告したり、間違ったフィッシング詐欺として Microsoft に不要な報告を返したりします。Because it is difficult to tell the difference between a real password reset and a fake one, many users ignore these messages, report them as spam, or unnecessarily report the messages back to Microsoft as missed phishing scams.

スプーフィングを阻止するために、電子メールのフィルター処理分野の業界は、電子メール認証のプロトコル (SPFDKIMDMARC など) を開発しました。To stop spoofing, the email filtering industry has developed email authentication protocols such as SPF, DKIM, and DMARC. DMARC は、ユーザーのメール クライアントに表示されるメッセージの送信者 (前述の例では、service.outlook.com、outlook.com、および accountprotection.microsoft.com) を SPF または DKIM をパスしたドメインで検査することでスプーフィングを防止します。DMARC prevents spoofing examining a message's sender - the one that the user sees in their email client (in the examples above, this is service.outlook.com, outlook.com, and accountprotection.microsoft.com) - with the domain that passed SPF or DKIM. つまり、ユーザーに表示されるドメインは認証されているため、スプーフィングされていないことになります。That is, the domain that the user sees has been authenticated and is therefore not spoofed. 詳細な説明については、この記事で後述するセクション「電子メール認証がスプーフィングの阻止には不十分なことがある理由」を参照してください。For a more complete discussion, see the section "Understanding why email authentication is not always enough to stop spoofing" later on in this article.

ただし、電子メール認証レコードはオプションであり、必須ではないという問題があります。However, the problem is that email authentication records are optional, not required. そのため、microsoft.com や skype.com などの強力な認証ポリシーを公開しているドメインはスプーフィングから保護されますが、公開している認証ポリシーが弱いドメインや認証ポリシーがまったく存在しないドメインはスプーフィングの対象になります。2018 年 3 月の時点で、Fortune 500 の企業のうち強力な電子メール認証ポリシーを公開しているドメインは 9% のみです。Therefore, while domains with strong authentication policies like microsoft.com and skype.com are protected from spoofing, domains that publish weaker authentication policies, or no policy at all, are targets for being spoofed.As of March 2018, only 9% of domains of companies in the Fortune 500 publish strong email authentication policies. 残りの 91% はフィッシャーによってスプーフィングされる可能性があり、その他のポリシーを使用する電子メール フィルターで検出されないと、エンド ユーザーとデバイスに配信されてしまいます。The remaining 91% may be spoofed by a phisher, and unless the email filter detects it using another policy, may be delivered to an end user and deceive them:

Fortune 500 企業の DMARC ポリシー

Fortune 500 に含まれない中小規模の企業で強力な電子メール認証ポリシーを公開している割合はさらに少なくなり、北米と西ヨーロッパ以外のドメインでは、それよりも少ない割合になります。The proportion of small-to-medium sized companies that are not in the Fortune 500 that publish strong email authentication policies is smaller, and smaller still for domains that are outside of North America and western Europe.

これは重大な問題です。企業は電子メール認証のしくみを認識していないことがありますが、フィッシャーはそのしくみを理解して利用するためです。This is a big problem because while enterprises may not be aware of how email authentication works, phishers do understand and take advantage of the lack of it.

SPF、DKIM、および DMARC のセットアップの詳細については、この記事で後述する「Office 365 のユーザー」のセクションを参照してください。For information on setting up SPF, DKIM, and DMARC, see the section "Customers of Office 365" later on in this document.

暗黙的な電子メール認証によるスプーフィングの防止Stopping spoofing with implicit email authentication

フィッシングやスピア フィッシングは大きな問題であり、強力な電子メール認証ポリシーの導入は限られているため、Microsoft はユーザーを保護するための機能に投資を続けています。Because phishing and spear phishing is such a problem, and because of the limited adoption of strong email authentication policies, Microsoft continues to invest in capabilities to protect its customers. そのため、Microsoft は暗黙的な電子メール認証を進めています。これは、ドメインが認証されていない場合、Microsoft は電子メール認証レコードが公開されているもとして、パスしない場合はそれに応じて処理します。Therefore, Microsoft is moving ahead with implicit email authentication - if a domain doesn't authenticate, Microsoft will treat it as if it had published email authentication records and treat it accordingly if it doesn't pass.

これを実現するために、Microsoft は通常の電子メール認証に対する多数の拡張機能 (送信者評価、送受信者履歴、行動分析などの高度な手法) を構築しました。To accomplish this, Microsoft has built numerous extensions to regular email authentication including sender reputation, sender/recipient history, behavioral analysis, and other advanced techniques. 電子メール認証を公開しないドメインから送信されたメッセージは、そのメッセージが正当であることを示す別のシグナルが含まれていないときには、スプーフィングのマークが付けられます。A message sent from a domain that doesn't publish email authentication will be marked as spoof unless it contains other signals to indicate that it is legitimate.

これにより、エンド ユーザーは送信されてきた電子メールがスプーフィングされていないことを確信できるようになり、送信者は自分のドメインが偽装される心配がなくなり、Office 365 のユーザーはさらに優れた偽装保護などの保護を提供できるようになります。By doing this, end users can have confidence that an email sent to them has not been spoofed, senders can be confident that nobody is impersonating their domain, and customers of Office 365 can offer even better protection such as Impersonation protection.

Microsoft の一般発表については、「大量のフィッシング詐欺: 第 2 部 - 強化された Office 365 のスプーフィング対策」を参照してください。To see Microsoft's general announcement, see A Sea of Phish Part 2 - Enhanced Anti-spoofing in Office 365.

スプーフィングとして分類されたメッセージの識別Identifying that a message is classified as spoofed

複合認証Composite authentication

SPF、DKIM、および DMARC は、いずれも単独で役立つものですが、メッセージに明示的な認証レコードが存在していないときには、認証の状態を十分に伝達しません。While SPF, DKIM, and DMARC are all useful by themselves, they don't communicate enough authentication status in the event a message has no explicit authentication records. そのため、Microsoft は、複数のシグナルを 1 つの値に結合する複合認証 (略称: compauth) というアルゴリズムを開発しました。Therefore, Microsoft has developed an algorithm that combines multiple signals into a single value called Composite Authentication, or compauth for short. Office 365 のユーザーは、メッセージのヘッダーに含まれる Authentication-Results ヘッダーに compauth の値がスタンプされます。Customers in Office 365 have compauth values stamped into the Authentication-Results header in the message headers.

Authentication-Results:
  compauth=<fail|pass|softpass|none> reason=<yyy>

CompAuth の結果CompAuth result 説明Description
failfail メッセージは明示的な認証に失敗したか (送信側ドメインが DNS で明示的にレコードを公開している場合)、暗黙的な認証に失敗した (送信側ドメインが DNS でレコードを公開していないため、そのドメインでレコードが公開されたものとして Office 365 によって結果が挿入された場合)。Message failed explicit authentication (sending domain published records explicitly in DNS) or implicit authentication (sending domain did not publish records in DNS, so Office 365 interpolated the result as if it had published records).
passpass メッセージは明示的な認証をパスした (メッセージは DMARC をパスしたか、最適な推測で DMARC をパスした)、または暗黙的な認証を高確度でパスした (送信側ドメインが電子メール認証レコードを公開していないが、Office 365 にはメッセージが正当である可能性が高いことを示す強力なバックエンドのシグナルがある)。Message passed explicit authentication (message passed DMARC, or Best Guess Passed DMARC) or implicit authentication with high confidence (sending domain does not publish email authentication records, but Office 365 has strong backend signals to indicate the message is likely legitimate).
softpasssoftpass メッセージは暗黙的な認証を信頼度「低」から「中」でパスした (送信側ドメインが電子メール認証を公開していないが、Office 365 にはメッセージが正当であることを示すバックエンドのシグナルがある。ただし、そのシグナルの強度は弱い)。Message passed implicit authentication with low-to-medium confidence (sending domain does not publish email authentication, but Office 365 has backend signals to indicate the message is legitimate but the strength of the signal is weaker).
nonenone メッセージは認証されていない (または、認証されたが一致しなかった)。ただし、送信者評価などの要因によって複合認証は適用されていない。Message did not authenticate (or it did authenticate but did not align), but composite authentication not applied due to sender reputation or other factors.
理由Reason 説明Description
0xx0xx メッセージは複合認証に失敗しました。Message failed composite authentication.
000 は、メッセージが拒否または検疫のアクションによって DMARC に失敗したことを意味します。000 means the message failed DMARC with an action of reject or quarantine.
001 は、メッセージが暗黙的な電子メール認証に失敗したことを意味します。001 means the message failed implicit email authentication. これは、送信側ドメインが電子メール認証レコードを公開していないか、公開していた場合でも弱い失敗ポリシー (SPF soft fail または neutral、p=none の DMARC ポリシー) があったことを意味します。This means that the sending domain did not have email authentication records published, or if they did, they had a weaker failure policy (SPF soft fail or neutral, DMARC policy of p=none).
002 は、組織に、スプーフィングされたメールの送信を明示的に禁止する送信者/ドメインのペアのポリシーがあることを意味します。この設定は、管理者が手動で設定します。002 means the organization has a policy for the sender/domain pair that is explicitly prohibited from sending spoofed email, this setting is manually set by an administrator.
010 は、メッセージが拒否または検疫のアクションによって DMARC に失敗して、送信側ドメインが組織の承認済みドメインに含まれていることを意味します (これは、自己完結型 (つまり組織内の) スプーフィングの一部です)。010 means the message failed DMARC with an action of reject or quarantine, and the sending domain is one of your organization's accepted-domains (this is part of self-to-self, or intra-org, spoofing).
011 は、暗黙的な電子メール認証に失敗したが、送信側ドメインが組織の承認済みドメインのいずれかであることを意味します (これは、自己完結型 (つまり組織内の) スプーフィングの一部です)。011 means the message failed implicit email authentication, and the sending domain is one of your organization's accepted domains (this is part of self-to-self, or intra-org, spoofing).
その他のすべてのコード (1xx、2xx、3xx、4xx、5xx)All other codes (1xx, 2xx, 3xx, 4xx, 5xx) メッセージが暗黙の認証にパスした理由や、認証なしでもアクションが適用されなかった理由に関する、さまざまな内部コードに対応します。Corresponds to various internal codes for why a message passed implicit authentication, or had no authentication but no action was applied.

管理者は (エンド ユーザーも) メッセージのヘッダーを調べることで、送信者がスプーフィングされている可能性があるという結論を Office 365 が導き出した過程を確認できます。By looking at the headers of a message, an administrator or even an end user can determine how Office 365 arrives at the conclusion that the sender may be spoofed.

各種のスプーフィングの区別Differentiating between different types of spoofing

Microsoft では、2 種類のスプーフィング メッセージを区別しています。Microsoft differentiates between two different types of spoofing messages:

組織内スプーフィングIntra-org spoofing

自己完結型スプーフィングとも呼ばれます。これは、From: アドレスのドメインが受信者のドメインと同じまたは一致する (受信者のドメインが組織の承認済みドメインのいずれかに含まれる) 場合、または From: アドレスのドメインが同じ組織の一部である場合に発生します。Also known as self-to-self spoofing, this occurs when the domain in the From: address is the same as, or aligns with, the recipient domain (when recipient domain is one of your organization's Accepted Domains); or, when the domain in the From: address is part of the same organization.

たとえば、次に示す送信者と受信者のドメインは同じドメイン (contoso.com) です。For example, the following has sender and recipient from the same domain (contoso.com). このページでのスパムボットの収集活動を阻止するために、電子メール アドレスにはスペースが挿入されています。Spaces are inserted into the email address to prevent spambot harvesting on this page):

From: sender @ contoso.comFrom: sender @ contoso.com

To: recipient @ contoso.comTo: recipient @ contoso.com

次に示す送信者と受信者のドメインは組織のドメイン (fabrikam.com) が一致しています。The following has the sender and recipient domains aligning with the organizational domain (fabrikam.com):

From: sender @ foo.fabrikam.comFrom: sender @ foo.fabrikam.com

To: recipient @ bar.fabrikam.comTo: recipient @ bar.fabrikam.com

次に示す送信者と受信者のドメイン (microsoft.com と bing.com) は異なっていますが、どちらも同じ組織に属しています (つまり、どちらも組織の承認済みドメインの一部です)。The following sender and recipient domains are different (microsoft.com and bing.com), but they belong to the same organization (that is, both are part of the organization's Accepted Domains):

From: sender @ microsoft.comFrom: sender @ microsoft.com

To: recipient @ bing.comTo: recipient @ bing.com

組織内スプーフィングに失敗したメッセージのヘッダーには、次の値が含まれています。Messages that fail intra-org spoofing contain the following values in the headers:

X-Forefront-Antispam-Report: ...CAT:SPM/HSPM/PHSH;...SFTY:9.11X-Forefront-Antispam-Report: ...CAT:SPM/HSPM/PHSH;...SFTY:9.11

CAT はメッセージのカテゴリであり、通常は SPM (スパム) のスタンプが設定されています。ただし、メッセージ内にある別の種類のパターンによって HSPM (高確度スパム) や PHISH (フィッシング) などになっていることもあります。The CAT is the category of the message, and it is normally stamped as SPM (spam), but occasionally may be HSPM (high confidence spam) or PHISH (phishing) depending upon what other types of patterns occur in the message.

SFTY はメッセージの安全性レベルです。最初の数字 (9) はメッセージがフィッシングであることを意味します。ドットの後にある 2 番目の数字のセット (11) は組織内スプーフィングであることを意味します。The SFTY is the safety level of the message, the first digit (9) means the message is phishing, and second set of digits after the dot (11) means it is intra-org spoofing.

2018 年後半の時点では、組織内スプーフィングについてスタンプされる複合認証の特定の理由コードはありません (タイムラインは未定義です)。There is no specific reason code for Composite Authentication for intra-org spoofing, that will be stamped later in 2018 (timeline not yet defined).

クロスドメイン スプーフィングCross-domain spoofing

これは、From: アドレスの送信側ドメインが受信側組織の外部ドメインになる場合に発生します。This occurs when the sending domain in the From: address is an external domain to the receiving organization. クロスドメイン スプーフィングのために複合認証に失敗したメッセージのヘッダーには、次の値が含まれています。Messages that fail Composite Authentication due to cross-domain spoofing contain the following values in the headers:

Authentication-Results: …Authentication-Results: … compauth=fail reason=000/001compauth=fail reason=000/001

X-Forefront-Antispam-Report: ...CAT:SPOOF;...SFTY:9.22X-Forefront-Antispam-Report: ...CAT:SPOOF;...SFTY:9.22

どちらの場合も、メッセージには次に示す赤色の安全のヒントがスタンプされます (同じ内容のヒントが受信者のメールボックスの言語に応じてカスタマイズされていることもあります)。In both cases, the following red safety tip is stamped in the message, or an equivalent that is customized to the recipient mailbox's language:

赤色の安全のヒント: 不正検出

From: アドレスを調べて受信者の電子メールの内容を知るか、電子メールのヘッダーを調べることでのみ、組織内スプーフィングとクロスドメイン スプーフィングを区別できます。It's only by looking at the From: address and knowing what your recipient email is, or by inspecting the email headers, that you can differentiate between intra-org and cross-domain spoofing.

Office 365 のユーザーが自分で新しいスプーフィング対策保護の準備を整える方法How customers of Office 365 can prepare themselves for the new anti-spoofing protection

管理者向けの情報Information for administrators

Office 365 の組織の管理者には、いくつかの注意が必要になる重要な情報があります。As an administrator of an organization in Office 365, there are several key pieces of information you should be aware of.

電子メール認証がスプーフィングの阻止には不十分なことがある理由Understanding why email authentication is not always enough to stop spoofing

新しいスプーフィング対策保護は、電子メール認証 (SPF、DKIM、および DMARC) に依存してメッセージにスプーフィングのマークを付けます。The new anti-spoofing protection relies on email authentication (SPF, DKIM, and DMARC) to not mark a message as spoofing. 一般的な例として、これまでに送信側ドメインが SPF レコードを公開したことがない場合が挙げられます。A common example is when a sending domain has never published SPF records. SPF レコードが存在しない場合やレコードが不適切に設定されている場合は、Microsoft のバックエンド インテリジェンスによってメッセージが正当であると宣言されていないと、送信メッセージにスプーフィングのマークが付けられます。If there are no SPF records or they are incorrectly set up, a sent message will be marked as spoofed unless Microsoft has back-end intelligence that says the message is legitimate.

たとえば、スプーフィング対策が展開されるまで、SPF、DKIM、および DMARC のどのレコードもないメッセージは次のようなものになります。For example, prior to anti-spoofing being deployed, a message may have looked like the following with no SPF record, no DKIM record, and no DMARC record:

Authentication-Results: spf=none (sender IP is 1.2.3.4)
  smtp.mailfrom=example.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=none
  action=none header.from=example.com;
From: sender @ example.com
To: receiver @ contoso.com

スプーフィング対策後、Office 365 Enterprise E5、EOP、または ATP を使用している場合は、compauth 値がスタンプされます。After anti-spoofing, if you have Office 365 Enterprise E5, EOP, or ATP, the compauth value is stamped:

Authentication-Results: spf=none (sender IP is 1.2.3.4)
  smtp.mailfrom=example.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=none
  action=none header.from=example.com; compauth=fail reason=001
From: sender @ example.com
To: receiver @ contoso.com

これを修正するために example.com が SPF レコードを設定した場合は、DKIM レコードを設定していない場合でも、SPF にパスしたドメインと From: アドレスのドメインが一致するため、複合認証にパスするようになります。If example.com fixed this by setting up an SPF record but not a DKIM record, this would pass composite authentication because the domain that passed SPF aligned with the domain in the From: address:

Authentication-Results: spf=pass (sender IP is 1.2.3.4)
  smtp.mailfrom=example.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=bestguesspass
  action=none header.from=example.com; compauth=pass reason=109
From: sender @ example.com
To: receiver @ contoso.com

また、DKIM レコードを設定して SPF レコードを設定していない場合でも、From: アドレスのドメインとパスした DKIM-Signature のドメインが一致するため同様に複合認証にパスします。Or, if they set up a DKIM record but not an SPF record, this would also pass composite authentication because the domain in the DKIM-Signature that passed aligned with the domain in the From: address:

Authentication-Results: spf=none (sender IP is 1.2.3.4)
  smtp.mailfrom=example.com; contoso.com; dkim=pass
  (signature was verified) header.d=outbound.example.com;
  contoso.com; dmarc=bestguesspass action=none
  header.from=example.com; compauth=pass reason=109
From: sender @ example.com
To: receiver @ contoso.com

ただし、フィッシャーも SPF と DKIM を設定して自分のドメインでメッセージに署名しておいて、From: アドレスに異なるドメインを指定する可能性もあります。However, a phisher may also set up SPF and DKIM and sign the message with their own domain, but specify a different domain in the From: address. SPF と DKIM のどちらも From: アドレスのドメインと一致する必要はないため、example.com が DMARC レコードを公開していないときには、DMARC を使用してスプーフィングのマークが付けられることはありません。Neither SPF nor DKIM requires the domain to align with the domain in the From: address, so unless example.com published DMARC records, this would not be marked as a spoof using DMARC:

Authentication-Results: spf=pass (sender IP is 5.6.7.8)
  smtp.mailfrom=maliciousDomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousDomain.com;
  contoso.com; dmarc=none action=none header.from=example.com;
From: sender @ example.com
To: receiver @ contoso.com

電子メール クライアント (Outlook や Outlook on the web などのあらゆる電子メール クライアント) には、From: ドメインのみが表示され、SPF や DKIM のドメインは表示されません。そのため、ユーザーは実際には maliciousDomain.com から送信されたメッセージを example.com から送信されたものだと誤解してしまう可能性があります。In the email client (Outlook, Outlook on the web, or any other email client), only the From: domain is displayed, not the domain in the SPF or DKIM, and that can mislead the user into thinking the message came from example.com, but actually came from maliciousDomain.com.

パスした SPF または DKIM と From: ドメインが一致しないにもかかわらず認証されたメッセージ

こうした理由から、Office 365 では From: アドレスのドメインが SPF または DKIM 署名のドメインと一致することを必要とします。また、一致しない場合は、メッセージが正当であることを示す何らかの内部シグナルが含まれていることを必要とします。For that reason, Office 365 requires that the domain in the From: address aligns with the domain in the SPF or DKIM signature, and if it doesn't, contains some other internal signals that indicates that the message is legitimate. それ以外の場合、メッセージは compauth に失敗します。Otherwise, the message would be a compauth fail.

Authentication-Results: spf=none (sender IP is 5.6.7.8)
  smtp.mailfrom=maliciousDomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousDomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: sender@contoso.com
To: someone@example.com

このようにして、Office 365 のスプーフィング対策では、認証されていないドメイン、および認証が設定されていてもユーザーが確認してメッセージの送信者だと信じる From: アドレスのドメインと一致しないドメインからの保護を実施します。Thus, Office 365 anti-spoofing protects against domains with no authentication, and against domains who set up authentication but mismatch against the domain in the From: address as that is the one that the user sees and believes is the sender of the message. これは、組織外のドメインと組織内のドメインの両方に当てはまります。This is true both of domains external to your organization, as well as domains within your organization.

そのため、SPF と DKIM をパスしていても複合認証に失敗してスプーフィングのマークが付けられたメッセージを受信した場合は、From: アドレスのドメインが SPF および DKIM をパスしたドメインと一致していないことになります。Therefore, if you ever receive a message that failed composite authentication and is marked as spoofed, even though the message passed SPF and DKIM, it's because the domain that passed SPF and DKIM are not aligned with the domain in the From: address.

スプーフィングされた電子メールの処理方法の変更についてUnderstanding changes in how spoofed emails are treated

現時点では、Office 365 のすべての組織 (ATP および ATP 以外) について、拒否または検疫のポリシーで DMARC に失敗したメッセージにはスパムのマークが付けられ、そのほとんどは高確度スパムの処理が実行されますが、通常のスパム処理が実行されることもあります (別のスパム ルールが先にメッセージをスパムとして識別したかどうかに応じて異なります)。Currently, for all organizations in Office 365 - ATP and non-ATP - messages that fail DMARC with a policy of reject or quarantine are marked as spam and usually take the high confidence spam action, or sometimes the regular spam action (depending on whether other spam rules first identify it as spam). 組織内スプーフィングの検出では、通常のスパム処理が実行されます。Intra-org spoof detections take the regular spam action. この動作は、有効にする必要はありません。また、無効にすることはできません。This behavior does not need to be enabled, nor can it be disabled.

ただし、クロスドメイン スプーフィングのメッセージについては、今回の変更が実施されるまでは、通常のスパム、フィッシング、およびマルウェアのチェックが実行され、フィルターの別の部分でメッセージが疑わしいものと識別された場合に、それぞれスパム、フィッシング、またはマルウェアのマークが付けられます。However, for cross-domain spoofing messages, before this change they would go through regular spam, phish, and malware checks and if other parts of the filter identified them as suspicious, would mark them as spam, phish, or malware respectively. 新しいクロスドメイン スプーフィング対策では、認証できないメッセージには、[フィッシング対策] > [スプーフィング対策ポリシー] で定義されたアクションが既定で実行されます。With the new cross-domain spoofing protection, any message that can't be authenticated will, by default, take the action defined in the Anti-phishing > Anti-spoofing policy. これが定義されていない場合は、ユーザーの [迷惑メール] フォルダーに移動されます。If one is not defined, it will be moved to a users Junk Email folder. 場合によっては、より疑わしいメッセージには、赤色の安全のヒントもメッセージに追加されます。In some cases, more suspicious messages will also have the red safety tip added to the message.

その結果として、これまでにスパムのマークが付けられていた一部のメッセージには、引き続きスパムのマークが付けられますが、赤色の安全のヒントも付けられるようになります。また、以前は非スパムのマークが付けられていたメッセージに、赤色の安全性のヒントが追加された状態でスパムのマーク (CAT:SPOOF) が付けられることもあります。This may result in some messages that were previously marked as spam still getting marked as spam but will now also have a red safety tip; in other cases, messages that were previously marked as non-spam will start getting marked as spam (CAT:SPOOF) with a red safety tip added. さらに別のケースでは、すべてのスパムとフィッシングを検疫に移動していたユーザーは、それらが [迷惑メール] フォルダーに移動されるようになったことがわかります (この動作は変更できます。「スプーフィング対策の設定の変更」を参照してください)。In still other cases, customers that were moving all spam and phish to the quarantine would now see them going to the Junk Mail Folder (this behavior can be changed, see Changing your anti-spoofing settings).

メッセージがスプーフィングされる方法は複数ありますが (この記事で前述した「各種のスプーフィングの区別」を参照)、2018 年 3 月の時点では、そうしたメッセージを Office 365 で処理する方法は統合されていません。There are multiple different ways a message can be spoofed (see Differentiating between different types of spoofing earlier in this article) but as of March 2018 the way Office 365 treats these messages is not yet unified. 次の表は、動作が新しくなったクロスドメイン スプーフィング対策の簡単な概要です。The following table is a quick summary, with Cross-domain spoofing protection being new behavior:

スプーフィングの種類Type of spoof カテゴリCategory 安全のヒントの追加Safety tip added? 適用対象Applies to
DMARC の失敗 (検疫または拒否)DMARC fail (quarantine or reject)
HSPM (既定)、SPM または PHSH の可能性もありHSPM (default), may also be SPM or PHSH
なし (現時点)No (not yet)
すべての Office 365 ユーザー、Outlook.comAll Office 365 customers, Outlook.com
自己完結型Self-to-self
SPMSPM
ありYes
すべての Office 365 組織、Outlook.comAll Office 365 organizations, Outlook.com
クロスドメインCross-domain
SPOOFSPOOF
ありYes
Office 365 Advanced Threat Protection および E5 ユーザーOffice 365 Advanced Threat Protection and E5 customers

スプーフィング対策の設定の変更Changing your anti-spoofing settings

スプーフィング対策 (クロスドメイン) の設定を作成または更新するには、セキュリティ/コンプライアンス センターの [脅威の管理] > [ポリシー] タブにある [フィッシング対策] > [スプーフィング対策の設定] に移動します。To create or update your (cross-domain) anti-spoofing settings, navigate to the Anti-phishing > Anti-spoofing settings under the Threat Management > Policy tab in the Security & Compliance Center. これまでにフィッシング対策の設定を作成したことがない場合は、その設定を作成する必要があります。If you have never created any anti-phishing settings, you will need to create one:

フィッシング対策: 新しいポリシーの作成

既に作成したものがある場合は、それを選択して変更できます。If you've already created one, you can select it to modify it:

フィッシング対策: 既存のポリシーの変更

ここで作成したポリシーを選択して、「スプーフィング インテリジェンスの詳細情報」の手順を進めます。Select the policy you just created and proceed through the steps as described in Learn more about spoof intelligence.

スプーフィング対策の有効化または無効化

スプーフィング対策の安全のヒントの有効化または無効化

PowerShell を使用して新しいポリシーを作成するには、次のようにします。To create a new policy by using PowerShell:

$org = Get-OrganizationConfig
$name = "My first anti-phishing policy for " + $org.Name
# Note: The name should not exclude 64 characters, including spaces.
# If it does, you will need to pick a smaller name.
# Next, create a new anti-phishing policy with the default values
New-AntiphishPolicy -Name $Name
# Select the domains to scope it to
# Multiple domains are specified in a comma-separated list
$domains = "domain1.com, domain2.com, domain3.com"
# Next, create the anti-phishing rule, scope it to the anti-phishing rule
New-AntiphishRule -Name $name -AntiphishPolicy $name -RecipientDomainIs $domains

その後で、PowerShell を使用してフィッシング対策ポリシーのパラメーターを変更することもできます。Set-AntiphishPolicy のドキュメントを参照してください。You may then modify the anti-phishing policy parameters using PowerShell, following the documentation at Set-AntiphishPolicy. パラメーターとして、$name を指定できます。You may specify the $name as a parameter:

Set-AntiphishPolicy -Identity $name <fill in rest of parameters>

2018 年の後半の時点では、既定のポリシーを作成する必要はなくなりました。組織内のすべての受信者を対象とする既定のポリシーが自動的に作成されるため、手動で指定する必要はありません (上記のスクリーンショットは、最終的な実装前に変更されることがあります)。Later in 2018, rather than you having to create a default policy, one will be created for you that is scoped to all the recipients in your organization so you don't have to specify it manually (the screenshots below are subject to change before the final implementation).

フィッシング対策の既定のポリシー

ユーザーが作成したポリシーとは異なり、既定のポリシーは削除することも、優先度を変更することも、対象とするユーザー、ドメイン、またはグループを選択することもできません。Unlike a policy that you create, you cannot delete the default policy, modify its priority, or choose which users, domains, or groups to scope it to.

フィッシング対策の既定のポリシーの詳細

PowerShell を使用して既定の保護を設定するには、次のようにします。To set up your default protection by using PowerShell:

$defaultAntiphishPolicy = Get-AntiphishPolicy | ? {$_.IsDefault -eq $true}
Set-AntiphishPolicy -Identity $defaultAntiphishPolicy.Name -EnableAntispoofEnforcement <$true|$false>

スプーフィング対策保護は、Office 365 の前面に別のメール サーバーがある場合にのみ無効にします (詳細については、「スプーフィング対策の無効化が正当なシナリオ」を参照してください)。You should only disable anti-spoofing protection if you have another mail server or servers in front of Office 365 (see Legitimate scenarios to disable anti-spoofing for more details).

$defaultAntiphishPolicy = Get-AntiphishiPolicy | ? {$_.IsDefault $true}
Set-AntiphishPolicy -Identity $defaultAntiphishPolicy.Name -EnableAntispoofEnforcement $false 

重要

メール パスの最初のホップが Office 365 であり、スプーフィングのマークが付けられた正当な電子メールが多すぎる場合は、まず、スプーフィングされた電子メールの自分のドメインへの送信を許可する送信者を設定します (「認証されていない電子メールを送信する正当な送信者の管理」を参照)。If the first hop in your email path is Office 365, and you are getting too many legitimate emails marked as spoof, you should first set up your senders that are allowed to send spoofed email to your domain (see the section "Managing legitimate senders who are sending unauthenticated email" ). それでも誤検知 (正当なメッセージにスプーフィングのマークが付けられる) が多すぎる場合でも、スプーフィング対策保護を完全に無効化することはお勧めしません。If you are still getting too many false positives (that is, legitimate messages marked as spoof), we do NOT recommend disabling anti-spoofing protection altogether. その代りに、「高」ではなく「基本」の保護を選択することをお勧めします。Instead, we recommend choosing Basic instead of High protection. スプーフィングされた電子メールを放置すると長期的には組織に相当に高いコストがかかる可能性があるため、誤検知に対処するほうが良いでしょう。It is better to work through false positives than to expose your organization to spoofed email which could end up imposing significantly higher costs in the long term.

認証されていない電子メールを送信する正当な送信者の管理Managing legitimate senders who are sending unauthenticated email

Office 365 は、認証されていない電子メールを組織に送信している送信者を追跡しています。Office 365 keeps track of who is sending unauthenticated email to your organization. その送信者がサービスによって正当ではないと判断されると、compauth 失敗のマークが付けられます。If the service thinks the sender is not legitimate, it will mark it as a compauth failure. これは、SPOOF として分類されますが、そのメッセージに適用されたスプーフィング対策ポリシーによって異なります。This will be classified as SPOOF although it depends on your anti-spoofing policy that was applied to the message.

ただし、管理者は、Office 365 の決定をオーバーライドして、スプーフィングされた電子メールの送信を許可する送信者を指定できます。However, as an administrator, you can specify which senders are permitted to send spoofed email, overriding Office 365's decision.

方法 1: 組織がドメインを所有している場合は、電子メール認証を設定するMethod 1 - If your organization owns the domain, set up email authentication

この方法は、組織内スプーフィングの解決に使用できます。また、複数のテナントを所有している場合や複数のテナントとやり取りする場合のクロスドメイン スプーフィングの解決にも使用できます。This method can be used to resolve intra-org spoofing, and cross-domain spoofing in cases where you own or interact with multiple tenants. さらに、Office 365 内の別のユーザーや、別のプロバイダーでホストされているサード パーティに送信する場合のクロスドメイン スプーフィングを解決する際にも役立ちます。It also helps resolve cross-domain spoofing where you send to other customers within Office 365, and also third parties that are hosted in other providers.

詳細については、「Office 365 のユーザー」を参照してください。For more details, see Customers of Office 365.

方法 2: スプーフィング インテリジェンスを使用して、認証されていない電子メールが許可された送信者を構成するMethod 2 - Use Spoof intelligence to configure permitted senders of unauthenticated email

認証されていないメッセージを組織に送信する送信者を許可するために、スプーフィング インテリジェンスを使用することもできます。You can also use Spoof Intelligence to permit senders to transmit unauthenticated messages to your organization.

外部ドメインの場合、スプーフィングされたユーザーは From アドレスのドメインになり、送信側インフラストラクチャは送信側 IP アドレス (/24 CIDR 範囲で分割)、または PTR レコードの組織のドメインになります (次のスクリーンショットでは、送信側 IP は 131.107.18.4 で、その PTR レコードは outbound.mail.protection.outlook.com であり、送信側インフラストラクチャについては outlook.com と表示されます)。For external domains, the spoofed user is the domain in the From address, while the sending infrastructure is either the sending IP address (divided up into /24 CIDR ranges), or the organizational domain of the PTR record (in the screenshot below, the sending IP might be 131.107.18.4 whose PTR record is outbound.mail.protection.outlook.com, and this would show up as outlook.com for the sending infrastructure).

この送信者に認証されていない電子メールの送信を許可するには、[いいえ][はい] に変更します。To permit this sender to send unauthenticated email, change the No to a Yes.

スプーフィング対策の許可された送信者の設定

PowerShell を使用して、特定の送信者にドメインのスプーフィングを許可することもできます。You can also use PowerShell to allow specific sender to spoof your domain:

$file = "C:\My Documents\Summary Spoofed Internal Domains and Senders.csv"
Get-PhishFilterPolicy -Detailed -SpoofAllowBlockList -SpoofType External | Export-CSV $file

Powershell から取得したスプーフィングされた送信者

上の画像では、このスクリーンショットに収まるようにするための改行が追加されています。In the previous image, additional line breaks have been added to make this screenshot fit. 通常は、すべての値が 1 行で表示されます。Normally, all the values would appear on a single line.

ファイルを編集し、outlook.com と bing.com に対応する行を見つけて、AllowedToSpoof エントリを No から Yes に変更します。Edit the file and look for the line that corresponds to outlook.com and bing.com, and change the AllowedToSpoof entry from No to Yes:

Powershell でスプーフィングの許可を Yes に設定する

ファイルを保存して、次を実行します。Save the file, and then run:

$UpdateSpoofedSenders = Get-Content -Raw "C:\My Documents\Spoofed Senders.csv"
Set-PhishFilterPolicy -Identity Default -SpoofAllowBlockList $UpdateSpoofedSenders

これにより、bing.com は認証されていない電子メールを *.outlook.com から送信できるようになります。This will now allow bing.com to send unauthenticated email from *.outlook.com.

方法 3: 送信者/受信者ペアの許可エントリを作成するMethod 3 - Create an allow entry for the sender/recipient pair

特定の送信者に対するすべてのスパム フィルター処理をバイパスすることもできます。You can also choose to bypass all spam filtering for a particular sender. 詳細については、「Office 365 の許可リストに安全に送信者を追加する方法」を参照してください。For more details, see How to securely add a sender to an allow list in Office 365.

この方法を使用すると、スパム フィルター処理と一部のフィッシング フィルター処理がスキップされます。ただし、マルウェア フィルター処理はスキップされません。If you use this method, it will skip spam and some of the phish filtering, but not malware filtering.

方法 4: 送信者に問い合わせて、電子メール認証を設定するように依頼するMethod 4 - Contact the sender and ask them to set up email authentication

スパムとフィッシングの問題があるため、Microsoft は、すべての送信者が電子メール認証を設定することをお勧めします。Because of the problem of spam and phishing, Microsoft recommends all senders set up email authentication. 送信側ドメインの管理者がわかっている場合は、その管理者に問い合わせて、電子メール認証レコードを設定するように要求し、一切のオーバーライドが不要になるようにします。If you know an administrator of the sending domain, contact them and request that they set up email authentication records so you do not have to add any overrides. 詳細については、この記事で後述する「Office 365 ユーザーではないドメインの管理者」を参照してください。For more information, see Administrators of domains that are not Office 365 customers" later in this article.

送信側ドメインで認証することは最初は難しい場合もありますが、そのドメインからの電子メールを迷惑メールとして処理したり拒否したりする電子メール フィルターが時間の経過と共に増え続け、適切に配信されるようにするために適切なレコードを設定することになります。While it may be difficult at first to get sending domains to authenticate, over time, as more and more email filters start junking or even rejecting their email, it will cause them to set up the proper records to ensure better delivery.

スプーフィングのマークが付けられたメッセージの数量に関するレポートの表示Viewing reports of how many messages were marked as spoofed

スプーフィング対策ポリシーを有効にすると、脅威の調査と対応の機能を使用して、フィッシングのマークが付けられたメッセージの量に関する数値を取得できます。Once your anti-spoofing policy is enabled, you can use threat investigation and response capabilities to get numbers around how many messages are marked as phish. このためには、セキュリティ/コンプライアンス センター (SCC) の [脅威の管理] > [エクスプローラー] に移動して、[表示] を [フィッシング] に設定し、[送信者のドメイン] または [保護の状態] でグループ化します。To do this, go into the Security & Compliance Center (SCC) under Threat Management > Explorer, set the View to Phish, and group by Sender Domain or Protection Status:

フィッシングのマークが付けられたメッセージ数の表示

各種のレポートを操作して、SPOOF のマークが付けられたメッセージも含めて、フィッシングのマークが付けられた数を確認できます。You can interact with the various reports to see how many were marked as phishing, including messages marked as SPOOF. 詳細については、「Office 365 の脅威の調査と対応についての作業を開始する」を参照してください。To learn more, see Get started with Office 365 Threat investigation and response.

現在のところ、どのメッセージにスプーフィングのマークが付けられたかを分類することはできません。その他の種類のフィッシングは分類できます (全般的なフィッシング、ドメインまたはユーザーの偽装など)。You can't yet split out which messages were marked due to spoofing as opposed to other types of phishing (general phishing, domain or user impersonation, and so on). 将来、これはセキュリティ/コンプライアンス センターから実行できるようになる予定です。However, later, you will be able to do this through the Security & Compliance Center. そのときには、このレポートを起点として使用して、認証に失敗したためにスプーフィングのマークが付けられている正当な送信側ドメインを特定できるようになります。Once you do, you can use this report as a starting place to identify sending domains that may be legitimate that are being marked as spoof due to failing authentication.

次のスクリーンショットは、このデータの表示形式を提案するためのものですが、リリース時には変更されている可能性があります。The following screenshot is a proposal for how this data will look, but may change when released:

検出の種類別に表示されたフィッシング レポート

ATP なしのユーザーと E5 ユーザーの場合、こうしたレポートは、将来、脅威に対する保護の状態 (TPS) レポートで利用できるようになりますが、少なくとも 24 時間の遅れがあると見込まれます。For non-ATP and E5 customers, these reports will be available later under the Threat Protection Status (TPS) reports, but will be delayed by at least 24 hours. このページは、それらの機能をセキュリティ/コンプライアンス センターに統合したときに更新される予定です。This page will be updated as they are integrated into the Security & Compliance Center.

スプーフィングのマークが付けられるメッセージの数量の予測Predicting how many messages will be marked as spoof

Office 365 の設定が更新されて、スプーフィング対策の適用をオフにしたり、「基本」または「高」の適用でオンにしたりできるようになると、さまざまな設定でメッセージの処理がどのように変化するかを確認できるようになります。Once Office 365 updates its settings to let you turn the anti-spoofing enforcement Off, or on with Basic or High enforcement, you will be given the ability to see how message disposition will change at the various settings. つまり、スプーフィング対策がオフのときに、「基本」にするとスプーフィングとして検出されるメッセージの数を確認できるようになり、「基本」になっているときに、「高」にするとスプーフィングとして検出されるメッセージ数の増加量を確認できるようになるということです。That is, if anti-spoofing is Off, you will be able to see how many messages will be detected as Spoof if you turn to Basic; or, if it's Basic, you will be able to see how many more messages will be detected as Spoof if you turn it to High.

この機能は、現在開発中です。This feature is currently under development. 詳細が明らかになり次第、このページはセキュリティ/コンプライアンス センターのスクリーンショットと、PowerShell の例の両方で更新される予定です。As more details are defined, this page will be updated both with screenshots of the Security and Compliance Center, and with PowerShell examples.

スプーフィング対策を有効にした場合の「What-If」レポート

スプーフィングされた送信者を許可する際の予定される UX

スプーフィング対策の無効化が正当なシナリオLegitimate scenarios to disable anti-spoofing

スプーフィング対策はフィッシング攻撃からのユーザーの保護を向上するためのものです。そのため、スプーフィング対策保護を無効にすることはお勧めできません。Anti-spoofing better protects customers from phishing attacks, and therefore disabling anti-spoofing protection is strongly discouraged. 無効にすることで、ある程度の誤検知を短期的に解決することはできますが、長期的には、より大きなリスクにさらされることになります。By disabling it, you may resolve some short-term false positives, but long term you will be exposed to more risk. 送信者側で認証を設定するコストや、フィッシング ポリシーの調整のためのコストは、通常、1 回限りのイベントであり、要求されるメンテナンスは最小限の定期的なもののみです。The cost for setting up authentication on the sender side, or making adjustments in the phishing policies, are usually one-time events or require only minimal, periodic maintenance. その一方、フィッシング攻撃によってデータが公開されてしまったり、資産が侵害されてしまうと、その回復にかかるコストは非常に高くなります。However, the cost to recover from a phishing attack where data has been exposed, or assets have been compromised is much higher.

このため、スプーフィング対策保護を無効にするよりも、スプーフィング対策の誤検知に対処するほうが好結果が得られます。For this reason, it is better to work through anti-spoofing false positives than to disable anti-spoof protection.

ただし、スプーフィング対策の無効化が必要になる正当なシナリオもあります。そのシナリオとは、メッセージ ルーティングに別のメールのフィルター処理製品があり、メール パスの最初のホップが Office 365 ではない場合です。However, there is a legitimate scenario where anti-spoofing should be disabled, and that is when there are additional mail-filtering products in the message routing, and Office 365 is not the first hop in the email path:

ユーザーの MX レコードは Office 365 を指していません

その他のサーバーは、オンプレミスの Exchange メール サーバー、Ironport などのメール フィルター処理デバイス、または別のクラウドでホストされているサービスです。The other server may be an Exchange on-premises mail server, a mail filtering device such as Ironport, or another cloud hosted service.

受信者ドメインの MX レコードが Office 365 を指していない場合は、スプーフィング対策を無効にする必要はありません。Office 365 は受信側ドメインの MX レコードを検索して、そのレコードが別のサービスを指しているときには、スプーフィング対策を抑止します。If the MX record of the recipient domain does not point to Office 365, then there is no need to disable anti-spoofing because Office 365 looks up your receiving domain's MX record and suppresses anti-spoofing if it points to another service. ドメインの前面に別のサーバーがあるかどうかがわからない場合は、MX Toolbox などの Web サイトを使用すると MX レコードを参照できます。If you don't know if your domain has another server in front, you can use a website like MX Toolbox to look up the MX record. これにより、次のような表示が得られます。It might say something like the following:

MX レコードはドメインが Office 365 を指していないことを示しています

このドメインの MX レコードは Office 365 を指していないため、Office 365 はスプーフィング対策の実施を適用しません。This domain has an MX record that does not point to Office 365, so Office 365 would not apply anti-spoofing enforcement.

ただし、受信者のドメインが Office 365 を指している場合は、Office 365 の前面に別のサービスが存在していても、スプーフィング対策を無効にする必要があります。However, if the MX record of the recipient domain does point to Office 365, even though there is another service in front of Office 365, then you should disable anti-spoofing. 最も一般的な例は、受信者の書き換えによるものです。The most common example is through the use of a recipient rewrite:

受信者の書き換えのルーティング図

ドメイン contoso.com の MX レコードはオンプレミスのサーバーを指していますが、ドメイン @office365.contoso.net の MX レコードは Office 365 を指しています。これは、MX レコードに *.protection.outlook.com、または *.eo.outlook.com が含まれているためです。The domain contoso.com's MX record points to the on-premises server, while the domain @office365.contoso.net's MX record points to Office 365 because it contains *.protection.outlook.com, or *.eo.outlook.com in the MX record:

MX レコードは Office 365 を指しているため、受信者が書き換えられている可能性があります

受信者のドメインの MX レコードが Office 365 指していない場合と、受信者の書き換えが実施された場合を区別するようにしてください。Be sure to differentiate when a recipient domain's MX record does not point to Office 365, and when it has undergone a recipient rewrite. この 2 つのケースを見分けることが重要です。It is important to tell the difference between these two cases.

受信側ドメインの受信者が書き換えられたかどうか不明な場合は、メッセージのヘッダーを調べることで判断できます。If you are unsure whether or not your receiving domain has undergone a recipient-rewrite, sometimes you can tell by looking at the message headers.

a) まず、メッセージのヘッダーで、Authentication-Results ヘッダーにある受信者ドメインを調べます。a) First, look at the headers in the message for the recipient domain in the Authentication-Results header:

Authentication-Results: spf=fail (sender IP is 1.2.3.4)
  smtp.mailfrom=example.com; office365.contoso.net; dkim=fail
  (body hash did not verify) header.d=simple.example.com;
  office365.contoso.net; dmarc=none action=none
  header.from=example.com; compauth=fail reason=001

受信者のドメインは、上記の赤色で示された太字のテキストでわかります (この例では、office365.contoso.net)。The recipient domain is found in the bold red text above, in this case office365.contoso.net. これは、To: ヘッダーの受信者と異なる場合があります。This may be different that the recipient in the To: header:

To: Example Recipient <recipient @ contoso.com>To: Example Recipient <recipient @ contoso.com>

実際の受信者のドメインの MX レコード検索を実行します。Perform an MX-record lookup of the actual recipient domain. MX に *.protection.outlook.com、mail.messaging.microsoft.com、*.eo.outlook.com、または mail.global.frontbridge.com が含まれている場合、その MX は Office 365 を指していることを意味します。If it contains *.protection.outlook.com, mail.messaging.microsoft.com, *.eo.outlook.com, or mail.global.frontbridge.com, that means that the MX points to Office 365.

これらの値が含まれていない場合、その MX は Office 365 を指していないことを意味します。If it does not contain those values, then it means that the MX does not point to Office 365. これを確認するには、MX Toolbox などを使用できます。One tool you can use to verify this is MX Toolbox.

この例では、contoso.com (To: ヘッダーにあるため受信者のように見えるドメイン) の MX レコードは、次に示すようにオンプレミスのサーバーを指しています。For this particular example, the following says that contoso.com, the domain that looks like the recipient since it was the To: header, has MX record points to an on-prem server:

オンプレミスのサーバーを指している MX レコード

ただし、実際の受信者は office365.contoso.net であり、その MX レコードは Office 365 を指しています。However, the actual recipient is office365.contoso.net whose MX record does point to Office 365:

MX は Office 365 を指しています (受信者が書き換えられている可能性が高い)

そのため、このメッセージは受信者が書き換えられている可能性があります。Therefore, this message has likely undergone a recipient-rewrite.

b) その次に、受信者の書き換えの一般的なユースケースを区別するようにします。b) Second, be sure to distinguish between common use cases of recipient rewrites. 受信者のドメインを *.onmicrosoft.com に書き換えようとしている場合は、そのドメインを *.mail.onmicrosoft.com に書き換えます。If you are going to rewrite the recipient domain to *.onmicrosoft.com, instead rewrite it to *.mail.onmicrosoft.com.

別のサーバーの背後にルーティングされる最終的な受信者のドメインを特定し、その受信者のドメインの MX レコードが実際には Office 365 を指していることを特定したら、スプーフィング対策を無効にする作業を進めることができます。Once you have identified the final recipient domain that is routed behind another server and the recipient domain's MX record actually points to Office 365 (as published in its DNS records), you may proceed to disable anti-spoofing.

繰り返しになりますが、ルーティング パスでドメインの最初のホップが Office 365 の場合はスプーフィング対策を無効にしないでください (その前に 1 つ以上のサービスがある場合にのみ実行してください)。Remember, you don't want to disable anti-spoofing if the domain's first hop in the routing path is Office 365, only when it's behind one or more services.

スプーフィング対策を無効にする方法How to disable anti-spoofing

フィッシング対策ポリシーが作成済みの場合は、EnableAntispoofEnforcement パラメーターを $false に設定します。If you already have an Anti-phishing policy created, set the EnableAntispoofEnforcement parameter to $false:

$name = "<name of policy>"
Set-AntiphishPolicy -Identity $name -EnableAntiSpoofEnforcement $false

無効にするポリシーの名前がわからない場合は、次のようにして表示できます。If you don't know the name of the policy (or policies) to disable, you can display them:

Get-AntiphishPolicy | fl Name

既存のフィッシング対策ポリシーがない場合は、そのポリシーを作成してから無効にしてください (ポリシーがない場合でも、スプーフィング対策は適用されています。2018 年後半の時点で、既定のポリシーが自動で作成されるようになったため、既定のポリシーを作成することなく無効にできます)。If you don't have any existing anti-phishing policies, you can create one and then disable it (even if you don't have a policy, anti-spoofing is still applied; later on in 2018, a default policy will be created for you and you can then disable that instead of creating one). これは、複数の手順で実行する必要があります。You will have to do this in multiple steps:

$org = Get-OrganizationConfig
$name = "My first anti-phishing policy for " + $org.Name
# Note: If the name is more than 64 characters, you will need to choose a smaller one
# Next, create a new anti-phishing policy with the default values
New-AntiphishPolicy -Name $Name
# Select the domains to scope it to
# Multiple domains are specified in a comma-separated list
$domains = "domain1.com, domain2.com, domain3.com"
# Next, create the anti-phishing rule, scope it to the anti-phishing rule
New-AntiphishRule -Name $name -AntiphishPolicy -RecipientDomainIs $domains
# Finally, scope the anti-phishing policy to the domains
Set-AntiphishPolicy -Identity $name -EnableAntispoofEnforcement $false

スプーフィング対策は、コマンドレットでのみ無効化できます (将来は、セキュリティ/コンプライアンス センターでも可能になります)。Disabling anti-spoofing is only available via cmdlet (later it will be available in the Security & Compliance Center). PowerShell にアクセスできない場合は、サポート チケットを作成してください。If you do not have access to PowerShell, create a support ticket.

繰り返しになりますが、この操作は、Office 365 への送信時に間接的にルーティングされるドメインにのみ適用してください。Remember, this should only be applied to domains that undergo indirect routing when sent to Office 365. ある程度の誤検出を理由にスプーフィング対策を無効にする誘惑には負けないようにしてください。長期的には、誤検出に対処するほうが好結果が得られます。Resist the temptation to disable anti-spoofing because of some false positives, it will be better in the long run to work through them.

個々のユーザーに関する情報Information for individual users

個々のユーザーは、スプーフィング対策の安全のヒントに対する操作内容が制限されています。Individual users are limited in how they can interact with the anti-spoofing safety tip. ただし、一般的なシナリオを解決するために、いくつかのことを実行できます。However, there are several things you can do to resolve common scenarios.

一般的なシナリオ #1 - ディスカッション リストCommon scenario #1 - Discussion lists

ディスカッション リストには、スプーフィング対策に関する既知の問題があります。このリストは、メッセージを転送して、その内容を変更するにもかかわらず元の From: アドレスが保持されるという方法に問題の原因があります。Discussion lists are known to have problems with anti-spoofing due to the way they forward the message and modify its contents yet retain the original From: address.

たとえば、自分の電子メール アドレスが user @ contoso.com で、バード ウォッチングに興味があり、ディスカッション リスト birdwatchers @ example.com に参加するとします。For example, suppose your email address is user @ contoso.com, and you are interested in Bird Watching and join the discussion list birdwatchers @ example.com. このディスカッション リストにメッセージを送信するときには、次の方法で送信することになります。When you send a message to the discussion list, you might send it this way:

From: John Doe <user @ contoso.com>From: John Doe <user @ contoso.com>

宛先: Birdwatcher のディスカッション リスト <birdwatchers @ example.com>To: Birdwatcher's Discussion List <birdwatchers @ example.com>

件名: 今週、レーニア山からアオカケスSubject: Great viewing of blue jays at the top of Mt. を見ることができますRainier this week

今週、レーニア山からの風景をAnyone want to check out the viewing this week from Mt. 眺めてみませんか?Rainier?

電子メール リストはメッセージを受信すると、そのメッセージの書式を設定し、内容を変更して、ディスカッション リストの残りのメンバーに向けてメッセージをリプレイします。このメンバーは、多様な電子メール レシーバーから構成されています。When the email list receives the message, they format the message, modify its contents, and replay it to the rest of the members on the discussion list which is made up of participants from many different email receivers.

From: John Doe <user @ contoso.com>From: John Doe <user @ contoso.com>

宛先: Birdwatcher のディスカッション リスト <birdwatchers @ example.com>To: Birdwatcher's Discussion List <birdwatchers @ example.com>

件名: [BIRDWATCHERS] 今週、レーニア山からアオカケスSubject: [BIRDWATCHERS] Great viewing of blue jays at the top of Mt. を見ることができますRainier this week

今週、レーニア山からの風景をAnyone want to check out the viewing this week from Mt. 眺めてみませんか?Rainier?


このメッセージは、Birdwatchers ディスカッション リストに送信されました。This message was sent to the Birdwatchers Discussion List. いつでも購読を解除できます。You can unsubscribe at any time.

上記のリプレイされたメッセージには、同じ From: アドレス (user @ contoso.com) がありますが、元のメッセージは件名にタグを追加して、メッセージの下側にフッターを追加することで変更されています。In the above, the replayed message has the same From: address (user @ contoso.com) but the original message has been modified by adding a tag to the Subject line, and a footer to the bottom of the message. この種のメッセージの変更は、メーリング リストでは一般的なものですが、誤検出の原因になることがあります。This type of message modification is common in mailing lists, and may result in false positives.

組織内のいずれかのユーザーがメーリング リストの管理者になっている場合は、そのメーリング リストがスプーフィング対策をパスするように構成できます。If you or someone in your organization is an administrator of the mailing list, you may be able to configure it to pass anti-spoofing checks.

メーリング リストの所有者でない場合は、次のようにします。If you do not have ownership of the mailing list:

  • メーリング リストの管理者に、上記のいずれかのオプションを実装するように要求してください (この管理者は、メーリング リストを中継するドメインにも電子メール認証を設定する必要があります)。You can request the maintainer of the mailing list to implement one of the options above (they should also have email authentication set up for the domain the mailing list is relaying from)

  • 電子メール クライアントで、メッセージを受信トレイに移動するメールボックス ルールを作成してください。You can create mailbox rules in your email client to move messages to the Inbox. また、組織の管理者に許可ルールを設定するように要求するか、「認証されていない電子メールを送信する正当な送信者の管理」のセクションで説明するようにオーバーライドするように要求してください。You can also request your organization's administrators to set up allow rules, or overrides as discussed in the section Managing legitimate senders who are sending unauthenticated email

  • Office 365 でサポート チケットを作成して、メーリング リストを正当なものとして扱うためのオーバーライドを作成してください。You can create a support ticket with Office 365 to create an override for the mailing list to treat it as legitimate

その他のシナリオOther scenarios

  1. 上記の一般的なシナリオのいずれにも当てはまらない場合は、そのメッセージを誤検出として Microsoft に報告してください。If neither of the above common scenarios applies to your situation, report the message as a false positive back to Microsoft. 詳細については、この記事で後述する「スパムまたは非スパムのメッセージについて、どのように Microsoft に報告すればよいですか」のセクションを参照してください。For more information, see the section How can I report spam or non-spam messages back to Microsoft? later in this article.

  2. また、サポート チケットとして Microsoft にこの件を提出できる電子メール管理者に問い合わせることもできます。You may also contact your email administrator who can raise it as a support ticket with Microsoft. Microsoft のエンジニアリング チームは、メッセージにスプーフィングのマークが付けられた理由を調査します。The Microsoft engineering team will investigate why the message was marked as a spoof.

  3. さらに、送信者がわかっていて、悪意のあるスプーフィングでないと確信している場合は、送信者に、認証されていないメール サーバーからメッセージを送信していることを返信で知らせてください。Additionally, if you know who the sender is and are confident they are not being maliciously spoofed, you may reply back to the sender indicating that they are sending messages from a mail server that does not authenticate. これにより、元の送信者は要求された電子メール認証レコードを設定する IT 管理者に問い合わせることもあります。This sometimes results in the original sender contacting their IT administrator who will set up the required email authentication records.

ドメインの所有者に対して相当数の送信者が電子メール認証レコードの設定が必要なことを返信することで、ドメインの所有者の行動を促します。When enough senders reply back to domain owners that they should set up email authentication records, it spurs them into taking action. Microsoft は必要なレコードを公開するためにドメインの所有者と協力しますが、個々のユーザーの要求が大きな支援になります。While Microsoft also works with domain owners to publish the required records, it helps even more when individual users request it.

  1. 必要に応じて、送信者を [差出人セーフ リスト] に追加します。Optionally, add the sender to your Safe Senders list. ただし、そのアカウントをフィッシャーがスプーフィングすると、それが自分のメールボックスに配信される点に注意してください。However, be aware that if a phisher spoofs that account, it will be delivered to your mailbox. そのため、このオプションは慎重に使用してください。Therefore, this option should be used sparingly.

スプーフィング対策保護に対して Microsoft への送信者が必要になる準備How senders to Microsoft should prepare for anti-spoofing protection

現在、Microsoft (Office 365 または Outlook.com) にメッセージを送信する管理者は、電子メールが適切に認証されていることを確認する必要があります。そうしていないと、そのメールにはスパムまたはフィッシングのマークが付けられる可能性があります。If you are an administrator who currently sends messages to Microsoft, either Office 365 or Outlook.com, you should ensure that your email is properly authenticated otherwise it may be marked as spam or phish.

Office 365 のユーザーCustomers of Office 365

Office 365 のユーザーが Office 365 を使用して送信メールを送信する場合は、次のようにします。If you are an Office 365 customer and you use Office 365 to send outbound email:

Microsoft は、SPF、DKIM、および DMARC のそれぞれに関する詳細な実装ガイドラインを提供しません。Microsoft does not provide detailed implementation guidelines for each of SPF, DKIM, and DMARC. ただし、オンラインで公開されている大量の情報があります。However, there is a lot of information published online. また、組織が電子メール認証レコードを設定する際の支援を専門としているサード パーティ企業もあります。There are also 3rd party companies dedicated to helping your organization set up email authentication records.

Office 365 のユーザーではないドメインの管理者Administrators of domains that are not Office 365 customers

Office 365 のユーザーではないドメインの管理者は、次のようにします。If you are a domain administrator but are not an Office 365 customer:

  • SPF を設定してドメインの送信側 IP アドレスを公開する必要があります。また、DKIM (使用可能な場合) を設定してメッセージにデジタル署名する必要があります。You should set up SPF to publish your domain's sending IP addresses, and also set up DKIM (if available) to digitally sign messages. さらに、DMARC レコードを設定することも検討してください。You may also consider setting up DMARC records.

  • 自分の代りに電子メールを転送するバルク送信者がいる場合は、その送信者と協力して、From: アドレスの送信側ドメインが SPF または DMARC をパスするドメインと一致するような方法で電子メールを送信する必要があります (送信側ドメインを所有している場合)。If you have bulk senders who are transmitting email on your behalf, you should work with them to send email in a way such that the sending domain in the From: address (if it belongs to you) aligns with the domain that passes SPF or DMARC.

  • オンプレミスのメール サーバーがある場合、またはサービスとしてのソフトウェア プロバイダーや、クラウド ホスティング サービス (Microsoft Azure、GoDaddy、Rackspace、アマゾン ウェブ サービスなど) からメールを送信する場合は、それらを SPF レコードに追加する必要があります。If you have on-premises mail servers, or send from a Software-as-a-service provider, or from a cloud-hosting service like Microsoft Azure, GoDaddy, Rackspace, Amazon Web Services, or similar, you should ensure that they are added to your SPF record.

  • ISP でホストされている小規模ドメインの場合は、その ISP が用意した手順に従って SPF レコードを設定する必要があります。If you are a small domain that is hosted by an ISP, you should set up your SPF record according to the instructions that is provided to you by your ISP. ほとんどの ISP は、この種の手順を用意していて、その会社のサポート ページに掲載しています。Most ISPs provide these types of instructions and can be found on the company's support pages.

  • これまでは電子メール認証レコードを公開する必要がなく、問題なく機能していたとしても、Microsoft に電子メールを送信するには電子メール認証レコードの公開が必要になります。Even if you have not had to publish email authentication records before, and it worked fine, you must still publish email authentication records to send to Microsoft. そうすることが、フィッシング詐欺の撲滅に協力することになり、自分やメール送信先の組織がフィッシング詐欺の被害を受ける可能性を減らすことになります。By doing so, you are helping in the fight against phishing, and reducing the possibility that either you, or organizations you send to, will get phished.

自分のドメインとして電子メールを送信した送信者がわからない場合What if you don't know who sends email as your domain?

多くのドメインは、すべての送信者を把握しているわけではないため、SPF レコードを公開していません。Many domains do not publish SPF records because they do not know who all their senders are. そのことは問題になりません。すべての送信者がわかっている必要はありません。That's okay, you do not need to know who all of them are. その代りに、自分が知っているもの、特に会社のトラフィックがある場所の SPF レコードを公開することから始めて、次のニュートラル SPF ポリシー (?all) を公開します。Instead, you should get started by publishing an SPF record for the ones you do know of, especially where your corporate traffic is located, and publish a neutral SPF policy, ?all:

example.com IN TXT "v=spf1 include:spf.example.com ?all"example.com IN TXT "v=spf1 include:spf.example.com ?all"

ニュートラル ポリシーとは、会社のインフラストラクチャから送信されるすべての電子メールが、その他すべての電子メール レシーバーの場所で電子メール認証にパスするという意味です。The neutral SPF policy means that any email that comes out of your corporate infrastructure will pass email authentication at all other email receivers. 不明な送信者から送られた電子メールは、ニュートラルにフォールバックします。これは、SPF レコードをまったく公開していないこととほとんど同じです。Email that comes from senders you don't know about will fall back to neutral, which is almost the same as publishing no SPF record at all.

Office 365 への送信時、会社のトラフィックから送信された電子メールには認証済みのマークが付けられますが、不明な送信元から送信された電子メールには引き続きスプーフィングのマークが付けられることがあります (Office 365 によって暗黙的に認証できるかどうかによって異なります)。When sending to Office 365, email that comes from your corporate traffic will be marked as authenticated, but the email that comes from sources you don't know about may still be marked as spoof (depending upon whether or not Office 365 can implicitly authenticate it). ただし、これは Office 365 によってすべての電子メールにスプーフィングのマークが付けられることからの改善に過ぎません。However, this is still an improvement from all email being marked as spoof by Office 365.

フォールバック ポリシーが ?all の SPF レコードを出発点として、段階的に送信側インフラストラクチャを増強して、より厳密なポリシーを公開してください。Once you've gotten started with an SPF record with a fallback policy of ?all, you can gradually include more and more sending infrastructure and then publish a stricter policy.

メーリング リストの所有者の場合What if you are the owner of a mailing list?

セクション「一般的なシナリオ #1 - ディスカッション リスト」を参照してください。See the section Common scenario #1 - Discussion lists.

インターネット サービス プロバイダー (ISP)、電子メール サービス プロバイダー (ESP)、クラウド ホスティング サービスなどのインフラストラクチャ プロバイダーの場合What if you are an infrastructure provider such as an Internet Service Provider (ISP), Email Service Provider (ESP), or cloud hosting service?

ドメインの電子メールをホストしていて、そのドメインで電子メールを送信する場合、または電子メールを送信できるホスティング インフラストラクチャを提供している場合は、次のようにします。If you host a domain's email, and it sends email, or provide hosting infrastructure that can send email, you should do the following:

  • 顧客に SPF レコードで公開する内容の詳細についてのドキュメントを提供します。Ensure your customers have documentation detailing what to publish in their SPF records

  • 顧客が明示的に設定していない場合でも、送信電子メールの DKIM 署名に署名することを検討します (既定のドメインで署名)。Consider signing DKIM-signatures on outbound email even if the customer doesn't explicitly set it up (sign with a default domain). DKIM 署名では電子メールに二重署名することもできます (顧客のドメインで設定されている場合に 1 つ目の署名、会社の DKIM 署名で 2 つ目の署名)。You can even double-sign the email with DKIM signatures (once with the customer's domain if they have set it up, and a second time with your company's DKIM signature)

プラットフォームから送信された電子メールを認証していても Microsoft への配信が可能であることが保証されるわけではありませんが、少なくとも、認証されていないという理由で Microsoft がそのメールを迷惑メールとして処理することはなくなります。Deliverability to Microsoft is not guaranteed even if you authenticate email originating from your platform, but at least it ensures that Microsoft does not junk your email because it is not authenticated. Outlook.com での電子メールのフィルター処理に関する詳細については、Outlook.com Postmaster ページを参照してください。For more details around how Outlook.com filters email, see the Outlook.com Postmaster page.

サービス プロバイダーのベスト プラクティスの詳細については、「M3AAWG Mobile Messaging Best Practices for Service Providers」を参照してください。For more details on service providers best practices, see M3AAWG Mobile Messaging Best Practices for Service Providers.

よく寄せられる質問Frequently Asked Questions

Microsoft が今回の変更を行う理由Why is Microsoft making this change?

フィッシング攻撃の影響により、15 年以上前から電子メール認証が実施されているため、Microsoft は認証されていない電子メールを許可し続けるリスクのほうが、正当な電子メールを失うリスクよりも高いと判断しています。Because of the impact of phishing attacks, and because email authentication has been around for over 15 years, Microsoft believes that the risk of continue to allow unauthenticated email is higher than the risk of losing legitimate email.

今回の変更により正当なメールにスパムのマークが付けられることがありますかWill this change cause legitimate email to be marked as spam?

当初は、一部のメッセージにスパムのマークが付けられるようになります。At first, there will be some messages that are marked as spam. ただし、時間の経過と共に、送信者が適応するようになり、ほとんどのメール パスでスプーフィングとして間違ったラベルが付けられるメッセージの量は無視できる程度になります。However, over time, senders will adjust and then the amount of messages mislabeled as spoofed will be negligible for most email paths.

Microsoft は、この機能をお客様に展開する数週間前に率先して導入しました。Microsoft itself first adopted this feature several weeks before deploying it to the rest of its customers. 最初のうちは混乱もありましたが、それも次第に収まりました。While there was disruption at first, it gradually declined.

Microsoft は、この機能を Outlook.com と Advanced Threat Protection のない Office 365 ユーザーに導入しますかWill Microsoft bring this feature to Outlook.com and non-Advanced Threat Protection customers of Office 365?

Microsoft のスプーフィング対策テクノロジは、最初に Office 365 Enterprise E5 サブスクリプションを所有する組織、またはサブスクリプションに対応する Office 365 Advanced Threat Protection (ATP) アドオンを購入した組織に導入されました。Microsoft's anti-spoofing technology was initially deployed to its organizations that had an Office 365 Enterprise E5 subscription or had purchased the Office 365 Advanced Threat Protection (ATP) add-on for their subscription. 2018 年 10 月の時点では、Exchange Online Protection (EOP) の所有組織にも保護の範囲を広げました。As of October, 2018 we've extended the protection to organizations that have Exchange Online Protection (EOP) as well. 今後は、Outlook.com にもリリースする予定です。In the future, we may release it for Outlook.com. ただし、その場合は、レポートやカスタム オーバーライドなどの一部の機能が適用されない可能性があります。However, if we do, there may be some capabilities that are not applied such as reporting and custom overrides.

スパムまたは非スパムのメッセージについて、どのように Microsoft に報告すればよいですかHow can I report spam or non-spam messages back to Microsoft?

Outlook 用の迷惑メール報告アドインを使用できます。このアドインをインストールしていない場合は、スパム、非スパム、およびフィッシング詐欺メッセージを分析のために Microsoft に送信することもできます。You can either use the Report Message Add-in for Outlook, or if it isn't installed, Submit spam, non-spam, and phishing scam messages to Microsoft for analysis.

ドメイン管理者ですが、把握できていない送信者がいますI'm a domain administrator who doesn't know who all my senders are!

Office 365 のユーザーではないドメインの管理者」を参照してください。Please see Administrators of domains that are not Office 365 customers.

Office 365 がプライマリ フィルターだとしても、自分の組織のスプーフィング対策保護を無効にすると問題が発生しますかWhat happens if I disable anti-spoofing protection for my organization, even though Office 365 is my primary filter?

これについては、お勧めできません。より多くの見逃されたフィッシング メッセージやスパム メッセージにさらされるようになります。We do not recommend this because you will be exposed to more missed phishing and spam messages. すべてのフィッシングがスプーフィングであるわけでなく、すべてのスプーフィングが見逃されるわけでもありません。Not all phishing is spoofing, and not all spoofs will be missed. ただし、スプーフィング対策を有効にしているお客様よりもリスクは高くなります。However, your risk will be higher than a customer who enables anti-spoofing.

スプーフィング対策保護を有効にすることで、すべてのフィッシングから保護されるようになりますかDoes enabling anti-spoofing protection mean I will be protected from all phishing?

残念ながら、そうはなりません。フィッシャーは侵害されたアカウントやフリー サービスのアカウントを設定するなど、別の手法を採用するようになるためです。Unfortunately, no, because phishers will adapt to use other techniques such as compromised accounts, or setting up accounts of free services. ただし、Office 365 の各保護層は連携するように設計されていて、相互をベースとして構築されているため、フィッシング対策保護は、そのような別の種類のフィッシング方法の検出にも優れています。However, anti-phishing protection works much better to detect these other types of phishing methods because Office 365's protection layers are designed work together and build on top of each other.

他の大規模な電子メール レシーバーが認証されていない電子メールをブロックすることはありますかDo other large email receivers block unauthenticated email?

ほとんどすべての大規模電子メール レシーバーが、従来型の SPF、DKIM、および DMARC を実装してます。Nearly all large email receivers implement traditional SPF, DKIM, and DMARC. 一部のレシーバーは、そうした標準のものよりも厳密な別のチェックを実施していますが、認証されていない電子メールをブロックしてスプーフィングとして扱う Office 365 に匹敵するものはわずかしかありません。Some receivers have other checks that are more strict than just those standards, but few go as far as Office 365 to block unauthenticated email and treat them as a spoof. ただし、この業界のほとんどが、特にフィッシング詐欺の問題を理由に、この種の電子メールに対する厳しさを増しています。However, most of the industry is becoming more and more strict about this particular type of email, particularly because of the problem of phishing.

スプーフィング対策を有効にしていても、"SPF Hard Fail" に対して高度な迷惑メール フィルターのオプションを有効にする必要がありますかDo I still need the Advanced Spam Filtering option enabled for "SPF Hard Fail" if I enable anti-spoofing?

いいえ。このオプションは不要になりました。スプーフィング対策機能では、SPF hard fail だけでなく、それよりも広範な条件のセットが考慮されます。No, this option is no longer required because the anti-spoofing feature not only considers SPF hard fails, but a much wider set of criteria. スプーフィング対策を有効にしているときに、SPF Hard Fail オプションも有効にすると、誤検出が多くなく可能性があります。If you have anti-spoofing enabled and the SPF Hard Fail option enabled, you will probably get more false positives. この機能は無効にすることをお勧めします。この機能によって、追加で捕捉されるスパムやフィッシングはほとんどなく、多くの場合に誤検出が発生します。We recommend disabling this feature as it would provide almost no additional catch for spam or phish, and instead generate mostly false positives.

センダー リライティング スキーム (SRS) は転送された電子メールの問題修正に役立ちますかDoes Sender Rewriting Scheme (SRS) help fix forwarded email?

SRS は転送された電子メールの問題を部分的にしか解決しません。SRS only partially fixes the problem of forwarded email. SMTP MAIL FROM を書き換えることで、SRS では転送されたメッセージが次の宛先で確実に SPF をパスするようになります。By rewriting the SMTP MAIL FROM, SRS can ensure that the forwarded message passes SPF at the next destination. ただし、スプーフィング対策は MAIL FROM または DKIM 署名のドメイン (またはその他のシグナル) と組み合わせた From: アドレスに基づいているため、転送された電子メールにスプーフィングのマークが付けられることを回避するには不十分です。However, because anti-spoofing is based upon the From: address in combination with either the MAIL FROM or DKIM-signing domain (or other signals), it is not enough to prevent forwarded email from being marked as spoofed.