4
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

はじめに

  • 数年前のことも含んでいますが、
    記録を取っていたわけではないので記憶だよりです。
  • 製造業の中小企業
  • メールドメインは1つ

DMARCとは?

詳細は割愛しますが、
自ドメインアドレスと名乗っている送信メールが
SPF,DKIMのチェックに引っかかった時の対処方法を指定するので
p=reject;とは「SPF,DKIMのチェックに引っかかったら破棄しちゃって」と宣言することです。

DMARCを設定するには

DMARCはその設定をDNSのレコードに登録します。
前項の通りSPF,DKIMのチェック結果に対する処置に関することなので
SPF,DKIMも設定する必要があります。

実施の流れ

社会の流れや取引先要望などから会社のサイバーセキュリティの見直しをすることとなりました。
その中で会社メールについて対応することになりました。

現状把握

数年前、私が今の会社に入ったとき
SPFは一応設定されていましたが、それ以外は何もありませんでした。
そのSPFも「~all」=SoftFailが入っている状態でした。

SPFを有効にする

レコード内容と実体を確認したところ

  • Exchange Online
  • 電子請求システムからの送信(自ドメインアドレス)
  • 社内

の3か所から送信され、設定もその通りでした。
Exchange Onlineはもちろん、
電子請求システムもSPF対応しており
何を設定すればいいかもちゃんとかいてあったのでそれぞれincludeしてあります、

社内もIPアドレスは決まっているのでip4で定義です。

~allが入っている理由は謎でした、
たぶん「念のため」とかいうやつでしょう。
-allにして本当に問題がないのかは不明でした。
-allでも即拒否される可能性は低いと思われるので
次段階のDMARCのためにも-allに変更しちゃいます。

DKIMを有効にする

Exchange OnlineはDKIM対応ですが有効化されていませんでした。
手順に書いてある通りDNSに設定しExchange Onlineの管理画面から有効化するだけで対応完了です。

電子請求システムはサービス側依存なので手は出せませんが対応予定とのことでした。

問題は社内ネットワークから送信されるメールです。
これは一斉通知システムで
ExchangeOnlineの送信レートに引っかかる可能性が高いため
オンプレSMTPサーバーを使用して送信されていました。
これに関しては以前に書いた記事

を作り解決することにしました。

これでSPF,DKIMの対応が完了しDMARCに手を出します。

DMARC;p=?

DMARCを設定する場合ポリシーモードは3つ
none:何もしない
quarantine:隔離する
reject:拒否する

まずはnoneにしてレポートを確認するのが定石のようです。
なのでそのように設定しました。

DMARCレポートを解析する

多くの場合つまずくであろうDMARCレポートの解析ですが、

大変でした。

件数が少なかったので最初はXMLを目視してみたのですが、
かなりつらい。

レポートを分析してくれるサービスもありますがほとんど有償で使用許可が出ません。

何かないかと探した結果、
XMLを解析するサービスがありました。

DMARC_Analyze.png

しかし、失敗数(率)などを出してくれるだけで詳細がわかりません。
ここからIPアドレスの詳細を調べたり
IPアドレスを頼りにXMLファイルをみたりして
まとめてある程度は状況が見えてきました。

把握していない送信元が幾つかいるようです。

不明な送信元は誰だ?

IPアドレスから確認できた送信元は
幾つか大手のメールサービスと思われるものがありました。
しかし社内ではそのようなサービスを使っていないことが確認でき
正規に送信されているものではないと判断されました。

しかし詳細は謎のままなので
モードをquarantineに変更し様子を見ることにしました。

1年近くquarantineにしていましたが
特に問題報告はありません、しかもなぜかFail数が減っています。

DMARC Failが勝手に減った!?

Fail数が減ったのはありがたいのですが、理由が不明ではいつまた増えるかわかりません。
理由は完全に予測ですがGoogleがGmailの「メール送信者のガイドライン」を発表した時期に近いので
これが影響しているのでは?と考えています。

まだ残るDMARC Fail

レポートの解析から3つほどの送信元が日常的に送信しているところまで絞れました。
まれにまったく別のもありますがこれこそ拒否でいいでしょう。

この3つを何とかしなければなりません。

  • 某メールサービス
  • 某ISP
  • 取引先会社

送信元が取引先会社のFailレポートを調べてみると

  • DIKMが電子請求システムになっている
  • 電子請求システムのDKIMのメールも一部はPassしている

このことからFailとなるメールは
取引先で受信後にFromアドレスをそのままに別のアドレスに転送している可能性が高いと判断しました。

某ISPも同様にDKIMは電子請求システムのものになっています。
なのでこちらも同様に転送しているのではないかと判断。

某メールサービスですがこちらも転送している可能が高いし
検索すると結構DMARCレポートで引っかかるという情報を得ました。

転送でもDMARCに引っかからない方法はありますが
何もしなければ引っかかる可能で胃が高くなります。
先ほど述べた「メール送信者のガイドライン」の影響があって減ったというのは
転送する場合にも対応が進んだのではという判断も含まれています。

ではrejectしていいじゃん

結論として自社の人間ではないことろで転送している分に関しては
面倒は見ないとなりついに

DMARC; p=reject;

となりました。

その後

三か月ほど経ちましたが、
同じように約3つでDMAR Failとなりrejectされたとレポートを受けています。
メール到達に関して問題は報告されていませんので
相手は相手で何とかしているのでしょう。

最後に

半手動でDMARCレポートを解析しましたが
1日に3-5箇所からのレポート、
Failとなるのが当初20-30アドレス、
減ったあとで約10アドレスと少ないのでなんとかなりましたが、
本来手動でやるものではないです。

本来はレポートを見続けた方がいいのだと思いますが
さすがにきつく目標は達成したので
今月を最後にレポート解析はやめ、
今後は何か問題報告を受けない限りレポートを見ない予定です。

4
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?