DMARCというキーワードは、皆さんにはかなりお馴染みになったのではないでしょうか。この記事では、DMARC導入直後のお客様から少なからずお尋ねいただく「SPF/DKIM が Pass なのに DMARC が Pass にならないのは何故なのか？」というご質問についてご説明したいと思います。メールエンジニアの方々にとっては分かりきっている内容かもしれませんが、ご容赦ください。
DMARC は、送信ドメイン認証の一つで、なりすましメールかどうかをメールサーバで認証して、その処理方法を指定する仕組みです。
弊社では DMARCレポートの分析サービス「DMARC/25 analyze」をご提供し、DMARCレポートの分析や、DMARCポリシー強化をお手伝いしていますが、今年 2 月、総務省などからの DMARC 導入要請の影響もあり、サービスへの問い合わせが急増し、日本国内でも注目度が高まっていることを実感しています。そんな中、実際に導入してみると、冒頭のような問題に遭遇することもありますので、この記事が、DMARC を理解する一助になれば幸いです。
●DMARCに関連する4つの差出人情報
「SPF/DKIM が Pass なのに、DMARC が Pass にならないのは何故か？」という質問にご回答する前に、DMARC に関係するメールの差出人情報についてご説明します。
DMARC、ならびに SPF/DKIM には、以下 4 つの差出人情報が関係しています。
（1）ヘッダFrom（RFC5322.from などと呼ばれることもあります）
皆さんがメールを受信した際にメールソフト上に表示されるので、一般的に受信者が差出人であると認識する情報で、以下のように記載されています。
From: 桐原健一 <xxxx@example.com>
皆さんが受信したメールに返信すると、特別な設定がされていない限り、基本的にはこのヘッダFrom のメールアドレスに返信メールが送られます。
DMARC は、ヘッダFrom のドメイン部分（上記の「@example.com」）が正しいかどうかを確認するための技術です。
（2）エンベロープFrom（mfrom、RFC5321.from と呼ばれることもあります）
皆さんがメールを受信した際に、メールソフト上では基本的に表示されませんが、メールヘッダ情報を確認すると以下のように表示されています。
Return-Path: <xxxx@example.com>
メールサーバ間の配送時に使われるのは、このエンベロープFrom です。
エンベロープFrom は、実際にメール送信した差出人（送信元）の情報であり、配送が問題なく完了した場合は参照されることはありませんが、何らかの原因でメールが宛先に届かなかった場合に、エンベロープFrom のアドレス宛に、配送できなかったことを知らせる MAILER-DAEMON@example.com のようなリターンメールが戻ります。
SPF はエンベロープFrom のドメイン部分（上記の「@example.com」）が正しいかどうかを確認するための技術です。
（3）DKIM署名ドメイン
皆さんがメールを受信した際に、メールソフト上では基本的に表示されません。メールヘッダ情報を確認すると以下のように表示されています。
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=selector;
(以下略)
DKIM は、メールヘッダ情報が改竄されていないことを確認する技術で、メールが改竄されていないかを認証するために電子署名を使用します。
電子署名の確認ができた場合は、dタグ部分（上記のd=example.com）の管理者が電子署名を施した後にメールが改竄されていないことが確認できます。
（4）helo/ehloホスト
皆さんがメールを受信した際に、メールソフト上では基本的に表示されません。メールヘッダ情報を確認すると以下のように表示されています。
Received: from mx01.example.com (xxx.xxx.xxx.xxx) by
(以下略)
helo/ehloホストはメールサーバ間の配送時に、送信側のサーバが、受信側のサーバに名乗ったホスト名です（上記の場合は mx01.example.com）。
あまり認知されていないのですが、helo/ehloホストは SPF で使われることがあります。前述のとおり、エンベロープFrom はリターンメールの宛先として使われます。もし、リターンメールの宛先が更に不明の場合、エンベロープFrom が設定されていると、更にリターンメールが発生し・・・といった永遠にピンポンとなる、好ましくない状況が発生します。このようにリターンメールを受け取りたくない送信の場合、エンベロープFrom を null(<>)に指定することになっています。
SPF では、エンベロープFrom が null(<>)になっていた場合は、helo/ehloホストの SPFレコードをチェックすることになっています。そのため、インターネットを通して外部に配送するメールサーバの helo/ehloホストは、SPFレコードの設定が必要です。
また、インターネットから名前解決ができるホスト名でなければなりません。忘れがちなところですので、メールサーバを管理されている方は一度確認してみてください。
その他、メールサーバの IPアドレスの逆引きホストと少なくともドメインが一致していないと迷惑メール判定されやすくなるなど、helo/ehloホストに関するバッドノウハウはいくつかあるのですが、DMARC とは関係なく、長くなるので本記事では省略します。
●DMARCの仕様について
SPF と DKIM は、ヘッダFrom を保護するものではありません。攻撃者は、SPF/DKIM を Pass するよう設定し、受信者が差出人と認識するヘッダFrom に有名企業名などを表示させることで、なりすましメールを送ることができてしまいます。
そこで、SPF と DKIM を補完する技術として登場した DMARC は、SPF/DKIM の認証結果を使って、ヘッダFrom が正しいかどうかを確認するために、以下のような仕様としています。
・SPF が Pass している場合で、ヘッダFromドメインとエンベロープFromドメインが一致していればDMARC でも SPF は Pass とする
※エンベロープFrom が null(<>)になっていた場合は、helo/ehloホストの SPFレコードを確認
・DKIM が Pass している場合で、ヘッダFromドメインと DKIM-Signature の dタグ部分が一致していればDMARC でも DKIM は Pass とする
・上記の DMARC での SPF、DMARC での DKIM のどちらかが Pass であれば、DMARC は Pass とする
●正当なサーバでDMARC認証失敗するケース
皆さんが通常メールソフトなどで送信するメールは、ヘッダFromドメイン＝エンベロープFromドメインとなっているため、冒頭のような問題が発生することはあまりありません。しかし、SaaSサービスの送信機能やメールマガジン送信のために外部のメール配信サービスなどを利用している際に発生することが多いです。
例えば、Salesforce などの CRMツールなどです。Salesforce では、登録されている見込み顧客などにメールを送信することができます。また、Salesforce には、送ったメールが宛先不明などで届いていないバウンスメールとなっていないか確認する機能があり、それを有効にした場合、ヘッダFrom、エンベロープFrom、DKIM-Signature の dタグは以下のようになっています。
この状態ですと、SPF は Pass となりますが、ヘッダFromドメイン＝エンベロープFromドメインではないため、DMARC としての SPF は Fail します。DKIM署名もされていないので、DMARC としては DKIM も Fail となります。つまり、DMARC は Pass になりません。
DMARC のレポートを受信して分析すると、使用された認証方法と結果、DMARC の合否などを見える化することができます。
DMARC が Pass になるためには、Salesforce の設定変更が必要です。Salesforce では、エンベロープFrom の変更はできませんが、自社ドメインで DKIM署名を設定することが可能です。
Salesforce のオンラインマニュアルを参考に DKIM の設定をすると以下のようになります。
この設定変更により、DKIM が Pass した上で、ヘッダFromドメイン＝DKIM-Signature の dタグ部分が一致しているので、DMARC は Pass となります。
DMARC のポリシーを強制力のあるもの（quarantine以上）にするためには、DMARCレポートを分析した後に、こういったメールシステムごとの対応方法の確認と設定変更が必要となります。
もし、ご自身で上記のような DMARCレポートを分析し、対応するのは難しいというお客様に対しては、弊社はコンサルティングサービスもご提供しておりますので、お気軽にお問い合わせください。
最後に、今回はなるべく長くなりすぎないように、あえて、端折って書いたため、技術仕様について詳しく知りたいという方には物足りない内容かもしれません。そのような方は弊社も運用に関わっていますなりすまし対策ポータル「ナリタイ」をご参照ください。
著者プロフィール
株式会社TwoFive 技術部 シニアコンサルタント 桐原 健一（きりはら けんいち）。29 歳の時に一念発起して UNIX の世界へ。その後、メール配信事業者、メーカ系 ISP、メール ASP で長年インフラ及びシステムの構築・運用・サポートに従事。株式会社TwoFive 入社後は、主にプリセールス、コンサルティングを担当。プライベートでは FCバルセロナと横浜DeNAベイスターズをこよなく愛している。
株式会社TwoFive
国内大手 ISP / ASP、携帯事業者、数百万～数千万ユーザー規模の大手企業のメッセージングシステムの構築・サポートに長年携わってきた日本最高水準のメールのスペシャリスト集団。メールシステムの構築、メールセキュリティ、スレットインテリジェンスを事業の柱とし、メールシステムに関するどんな課題にもきめ細かに対応し必ず顧客が求める結果を出す。
