DMARC(ディーマーク)は、Domain-based Message Authentication, Reporting, and Conformance の略称で、RFC7489 で情報が提供されています。DNSサーバーに DMARCレコードと呼ばれるポリシーを登録することにより、自分が所有しているドメインを送信元としたメールを受信した先でそのポリシーに従ってメールを扱うように指定することができます。この仕組みにより、自分が所有しているドメインを使ったなりすましメールを防ぐことが期待できます。そこで今回は、DMARC 導入時の注意点と設定方法をまとめてみました。
DMARC の仕組み
冒頭にも書きましたが、DMARC は DMARCレコードを DNSサーバーに登録することにより、自分が所有しているドメインを使ったなりすましメールを、受信側で拒否するなどのポリシーを指定することができます。なりすましメールを検知する仕組みとして SPF(RFC7208)と DKIM(RFC6376)を利用します。
SPF(Sender Policy Framework)
正規の送信元となるメールサーバーのIPアドレスをDNSサーバーに登録しておきます。受信側では、送られてきたメールの送信元IPアドレスが、正規の送信元メールサーバーのIPアドレスであることを確認することで、なりすましメールを検知します。
DKIM(DomainKeys Identified Mail)
送信元となるメールサーバーが送信するメールに対してデジタル署名を行い、それを検証するための公開鍵をDNSサーバーに登録しておきます。受信側では、この公開鍵を使ってデジタル署名を検証することで、なりすましメールを検知します。
SPF と DKIM の弱点
SPF と DKIM それぞれ単体でもなりすましメールに対して一定の効果があるものの、SPF と DKIM は、メーラーなどに表示される送信元メールアドレス(これを「ヘッダFrom」と呼びます)と、実際の送信元のメールアドレス「これを「エンベロープFrom」と呼びます)が一致していることを確認していないため、攻撃者が少し工夫すればなりすましメールを検知できなくなるという弱点がありました。
DMARC では、ヘッダFrom のドメインと SPF もしくは DKIM で認証OKとなったドメインが一致していることを確認しているため、より正確になりすましメールを検知することができます。(詳しくは「DMARC アライメント」で検索してください)
DMARC 導入時の注意点
良いことづくめの DMARC ですが、導入にあたっては注意が必要です。 まずは、DMARC認証がOKになるメールとNGになるメールの例をご覧ください。
■DMARC認証がOKになるメール
SPF認証もしくはDKIM認証(またはその両方)がOKであり、ヘッダFrom と エンベロープFrom(メールヘッダのReturn-Pathに記録されます)のドメインが一致しているメールは、DMARC認証もOKになります。
■DMARC認証がNGになるメール
下は、ヘッダFrom のドメインを amazon.co.jp に偽装したなりすましメールです。エンベロープFrom のドメイン apar.jp に対するSPF認証はOKですが、ヘッダFrom のドメイン amazon.co.jp と一致しないため、DMARC認証はNGになります。
ヘッダFrom の偽装を検知できるのは良いのですが、送信しているメールのヘッダFrom と エンベロープFrom が異なっていると、これまでSPF認証やDKIM認証がOKであったのに DMARCレコードを登録したとたんに、DMARC認証がNGとなって、最悪の場合メールが届かなくなる事態もありえます。
会社などの組織では、一般的なメールの他に、メール配信サービスや顧客管理システムや問合せ管理システムなどから重要なメールを送信することもあり、特にクラウドサービスを利用している場合そのクラウドサービスから送信されるメールのヘッダFrom と エンベロープFrom が異なるケースはよく発生しますので、DMARCレコードを登録する前に各種送信されるメールのヘッダFrom と エンベロープFrom(メールヘッダのReturn-Path)のドメインが一致していることを確認しましょう。
SPF と DKIM の設定
DMARC は、SPF または DKIM またはその両方の認証結果に基づいて、DMARCポリシーを適用しますので、DMARCレコードを登録する前に、SPF や DKIM を設定し、正しく動作することを確認してください。
参考資料:SPF(Sender Policy Framework) : 迷惑メール対策委員会
関連記事:Postfix DKIM設定(OpenDKIM)
RFC7489 には「SPF または DKIM」の認証結果(認証済みドメイン名と一致しているかどうか)に基づいてDMARCポリシーを適用する旨が書かれていますが、受信側のプロバイダーによっては、SPF や DKIM の認証ができない場合は迷惑メールとして判定されてしまうこともありますので、送信側では SPF と DKIM の両方に対応することをオススメします。
DMARC、SPF、DKIM は、どれもDNSサーバーを使う仕組みのため混同しそうになりますが、それぞれ個別の技術です。そのため、DMARC、SPF、DKIM の3つに対応すると、対象のドメインを管理するDNSサーバーには以下の3つのレコードが登録されることになります。(どれもTXTレコードで登録します)
- DMARCレコード
- SPFレコード
- DKIMの公開鍵レコード
(補足)
DKIMの認証結果をどのように扱うべきかを示すポリシーとして、ADSPレコードが登録されていましたが、DMARCの登場により不要となりました。RFC5617(DKIM ADSP)の分類も「Historic」(利用は推奨されない)になっています。
DMARCレコードの作り方
前置きが長くなりましたが、本題の DMARC の設定方法です。DMARCレコードの書式は次の通りです。「v(バージョン)」タグと「p(ポリシー)」タグは必須であり、1番目が「v」タグ、2番目が「p」タグの順序で指定する必要があります。各タグはセミコロン「;」で区切ってください。
_dmarc.<ドメイン名>. IN TXT "v=DMARC1; p=<値>; <オプションのタグ>=<値>; <オプションのタグ>=<値>"
主な DMARCレコードのタグは次の通りです。詳細やこれ以外のタグにつきましては RFC7489の「6.3. General Record Format」のセクションをご参照ください。また、受信側によっては一部のタグに対応していない場合もありますので留意してください。(例えば、2024年2月時点でGmailは「ruf」タグに対応していません)
「v」タグと「p」タグ以外はオプションのタグになりますので、省略可能です。必要に応じて設定してください。
タグ | 必須 | 説明 |
---|---|---|
v | ○ | DMARCのバージョン「DMARC1」を指定します。「DMARC1」以外の値を指定した場合、DMARCレコード全体が無視されます。 【設定例】v=DMARC1 |
p | ○ | ポリシー(DMARC認証がNGのメールの扱い)を受信側に指示するための値を指定します。 指定できる値は次の通りです。 none:何もしないでください quarantine:不審なメールとして処理してください reject:受信を拒否してください 【設定例】p=none |
sp | サブドメインに別のポリシーを指定する場合はこのタグを使います。指定できる値は「p」タグと同じです。省略した場合は「p」タグの値が継承されます。 【設定例】sp=quarantine |
|
pct | ポリシーを適用するメールの割合(%)を指定します。値は0〜100の整数で指定します。省略した場合は100が指定されたとして受信側で処理されます。 【設定例】pct=20 |
|
rua | DMARCに関連する集約レポートの宛先をURI(mailto:<メールアドレス>)で指定します。宛先はカンマ「,」区切りで複数指定することもできます。 【設定例】rua=mailto:aggrep@example.com |
|
ruf | DMARCに関連する失敗レポートの宛先をURI(mailto:<メールアドレス>)で指定します。宛先はカンマ「,」区切りで複数指定することもできます。 【設定例】ruf=mailto:authfail@example.com |
|
adkim | DKIM認証結果の識別子アライメントの判定モード(ヘッダFromのドメインとDKIMで認証したドメインがどの程度一致しているか)を指定します。省略した場合は r(緩和モード)が指定されたとして受信側で処理されます。 指定できる値は次の通りです。 s:(厳格メード)完全一致が必要 r:(緩和モード)部分一致を許容(例えばサブドメインは許可されます) 【設定例】adkim=s |
|
aspf | SPF認証結果の識別子アライメントの判定モード(ヘッダFromのドメインとSPFで認証したドメインがどの程度一致しているか)を指定します。省略した場合は r(緩和モード)が指定されたとして受信側で処理されます。 指定できる値は次の通りです。 s:(厳格メード)完全一致が必要 r:(緩和モード)部分一致を許容(例えばサブドメインは許可されます) 【設定例】aspf=s |
各社のDMARCレコード
DMARCレコードの作り方は理解できたものの、どのような設定にすべきか迷ってしまいますね。参考のために各社のDMARCレコードを見てみましょう。(以下は2024年2月時点の設定です)
■Gmail
dig _dmarc.gmail.com TXT "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"
■Yahoo!メール
dig _dmarc.yahoo.ne.jp TXT "v=DMARC1; p=quarantine; rf=afrf; rua=mailto:ymail_dmarc_report@yahoo.ne.jp; ruf=mailto:ymail_dmarc_report@yahoo.ne.jp"
■三菱UFJ銀行
dig _dmarc.direct-11.bk.mufg.jp TXT "v=DMARC1; p=quarantine; sp=none; pct=100; ri=86400; aspf=s; adkim=s; rua=mailto:dmarc@bmp.bk.mufg.jp, mailto:mufg00001-ra@dmarc25.jp"
■楽天銀行
dig _dmarc.rakuten-bank.co.jp TXT "v=DMARC1; p=quarantine; rua=mailto:rua-mpse@mpub.ne.jp,mailto:dmarc-report-a@rx.rakuten.co.jp"
■セゾンカード
dig _dmarc.mail.saisoncard.co.jp TXT "v=DMARC1; p=quarantine; rua=mailto:saisoncard00001-ra@dmarc25.jp; ruf=mailto:saisoncard00001-ra@dmarc25.jp; fo=1; pct=100;"
各社とも設定はさまざまですが、以下の設定は共通しています。
- ポリシータグ「p」に「reject」は指定していない。
- DMARCに関連する集約レポート「rua」タグは設定している。
DMARC導入時にはメールが届かなくなる可能性もあることから、はじめはポリシータグ「p」は「none」(DMARC認証がNGになっても何もしない)に設定し、DMARCに関連する集約レポートで問題がないことを確認できたらポリシータグ「p」を「quarantine」(DMARC認証がNGの場合は不審なメールとして処理)設定するのがよさそうですね。
以上をふまえると DMARC導入時に設定するのが望ましい DMARCレコードは次のようになります。
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:aggrep@example.com"
また、「rua」タグで指定する宛先に DMARCに関連する集約レポートが大量に届く可能性がありますので、必要に応じて専用のメールボックスを用意するなどの対応をご検討ください。
DMARCレコードの登録(Amazon Route 53)
作成した DMARCレコードをDNSサーバに登録します。
今回は、DNSサービスの Amazon Route 53 への登録例になります。登録する DMARCレコードは次の通りです。
_dmarc.apar.jp. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-report@apar.jp"
対象のホストゾーン(今回の場合は「apar.jp」)を選択して、「レコード作成」をクリックします。
以下のように入力/選択して「レコードを作成」をクリックします。(ウィザード表示になっている場合は「クイック作成へ切り替える」をクリックしてください)
確認
手元のPCで登録した DMARCレコードの問合せが成功することを確認します。
dig _dmarc.apar.jp TXT (略) ;; ANSWER SECTION: _dmarc.apar.jp. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-report@apar.jp"
おわりに
メールの受信側となるGmailなど大手メールプロバイダーでは、SPF と DKIM に加えて、今回ご紹介した DMARC の対応を送信側に求めています。また、SPF と DKIM が導入済みであれば、DMARC の導入は容易にできますので、自分が所有しているドメインを使ったなりすましメールを防ぐためにも DMARC の導入を検討してみてはいかがでしょうか。
コメント