DMARC レコードの例

簡単なレコードは次のようになります。

_dmarc.naritai.jp IN TXT “v=DMARC1; p=none; rua=mailto:report-a@naritai.jp; ruf=mailto:report-f@naritai.jp”

これで、DMARC 始めましたよって感じになります。p=none ですから、DMARC の認証の結果なりすましメールを見つけても、それだけで何かメールの受信処理を変更することはしないでください。というような意味になります。また、rua と ruf にそれぞれ、統計レポートと失敗レポートを受け取るメールアドレスを指定します。

このレコードを DNS で公開した後から、report-a@naritai.jp に統計レポート、report-f@naritai.jp に失敗レポートが送られてくるようになります。

メール認証成功に自信がついてきたら、

_dmarc.naritai.jp IN TXT “v=DMARC1; p=quarantine; rua=mailto:report-a@naritai.jp; ruf=mailto:report-f@naritai.jp”

や

_dmarc.naritai.jp IN TXT “v=DMARC1; p=reject; rua=mailto:report-a@naritai.jp; ruf=mailto:report-f@naritai.jp

なども、考えたいところです。quarantine を p に指定すると、”認証失敗したメールは隔離に送ってください”、reject だと”受信拒否してください”と受信側に伝えています。実際にどのように処理するかは受信側に委ねられますが、ユーザをなりすましメールの危険から守りたい送信側としては、quarantine や reject を宣言し、なりすましメールがユーザに届かないようにしたいと思います。

たとえば、受信側が Office 365 だと、DMARC 認証失敗したメールについて、p に quarantine や reject が設定してある場合、検疫に送ります。なりすましメールはとりあえず危険性の高いメールとして扱われるようになります。

quarantine や reject に進む判断の材料として、DMARC の統計レポートは非常に有効です。どこから送信された、何通ぐらいのメールが認証成功しているかが判ります。