朝から昼寝

整理しておきたいIT関連の小ネタ

送信ドメイン認証のDNSレコード検索方法(SPF、DKIM、DMARC、ARC)(+BIMI)

概要

電子メールの送信元ドメインが詐称されていないかを検証する送信ドメイン認証(Sender Domain Authentication)。
本記事は、動作確認等のために、各送信ドメイン認証のDNSレコードを検索する方法をまとめたものです。
SPFDKIM、DMARC、ARC、BIMIといった送信ドメイン認証を俯瞰的にまとめた記事はこちらです。

本記事の目的

  • 各送信ドメイン認証技術のDNSレコード検索方法を理解する。

目次

サマリ

以下のTXTレコードです。

届いたメールをもとに検索

今回、InstagramからGmailに届いたメールを例にします。

Instagramから届いたメール
Instagramから届いたメール

Instagramのロゴが表示されているのでBIMI対応済みです。

ARヘッダ
ARヘッダ

Authentication-Results(AR)ヘッダには、"dkim=pass"、"spf=pass"、"dmarc=pass"が記載されています。 DMARCのポリシーは"p=REJECT sp=REJECT"です。

このメールの送信元ドメインは以下の通りです。

本記事では、このメールを例に、各DNSレコードを検索する例を記載します。

SFPレコード

SPFレコードを検索する場合、エンベロープFromのドメインを用いてDNS検索する必要性があります。
エンベロープFromのドメインが分からない場合、SPFレコードを検索することはできません。

届いたメールをメーラやWebMailで開く時点では、エンベロープFromドメインを正確には特定できません。100%正確な方法ではありませんが、便宜上以下のようにエンベロープFromドメインを特定しています。

今回は、Return-PathヘッダやAR(Authentication-Results)ヘッダのspfタグより、エンベロープFromドメインはmail.instagram.comであると推測しました。spfタグについては、spf=passの後のコメント部分(reasonspec)に、"smtp.mailfrom=xxxx@mail.instagram.com"というエンベロープFromアドレスと思われる記載があります。

このエンベロープFromドメインをもとにSPFレコードを検索するコマンドは以下です。

  • digコマンドの場合
    dig -t TXT mail.instagram.com
  • nslookupコマンドの場合
    nslookup -q=TXT mail.instagram.com

上記問合せにより得られるレコードは以下です(2022年9月時点)。
"v=spf1 include:facebookmail.com -all"

"include"があるので、include先も検索してみます。

  • digコマンドの場合
    dig -t TXT facebookmail.com
  • nslookupコマンドの場合
    nslookup -q=TXT facebookmail.com

上記問合せにより得られるレコードのうち、SPF用のものは以下です(2022年9月時点)。
"v=spf1 ip4:66.220.144.128/25 ip4:66.220.155.0/24 ip4:66.220.157.0/25 ip4:69.63.178.128/25 ip4:69.63.181.0/24 ip4:69.63.184.0/25" " ip4:69.171.232.0/24 ip4:69.171.244.0/23 -all"

DKIMレコード

DKIM-Signatureヘッダは以下です。セレクタ名とドメイン名を確認できます。

DKIM-Signatureヘッダ
DKIM-Signatureヘッダ

上記の内容に従い、DKIMレコードを検索するコマンドは以下です。

  • digコマンドの場合
    dig -t TXT s1024-2013-q3._domainkey.mail.instagram.com
  • nslookupコマンドの場合
    nslookup -q=TXT s1024-2013-q3._domainkey.mail.instagram.com

上記問合せにより得られるレコードは以下です(2022年9月時点)。

"k=rsa; t=s; h=sha256; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7twdVo+BW8Pv2poU5129KYmE6npHdxUU8fktUKTE9TNovCvLy5LVjYc3TQcUFjOH" "VaZ89ZCjmpAcrA2QnTEKZ/2QWV56gn6bWdFW4SFxnQdHjguBZQykfKe5KTxy2a/OxuA0x2dHfdnYfw7RVzr4uednpKcWJy4Rl3gM6XB1zDwIDAQAB"

pタグの部分が公開鍵です。
TXTレコードの255文字の制限があるので、複数の"xxxx"に分割されています。

DMARCレコード

ヘッダFromドメインに従い、DMARCレコードを検索するコマンドは以下です。

  • digコマンドの場合
    dig -t TXT _dmarc.mail.instagram.com
  • nslookupコマンドの場合
    nslookup -q=TXT _dmarc.mail.instagram.com

上記問合せにより得られるレコードは以下です(2022年9月時点)。
"v=DMARC1; p=reject; rua=a@dmarc.facebookmail.com; ruf=fb-dmarc@datafeeds.phishlabs.com; pct=100"

p=rejectです。
DMARCレポートのうち、RUFの方は別ドメインの解析ツール?を利用しているかもしれません。

ARC用のDKIMレコード

今回のメールでは、mail.instagram.comドメインから送信される時点ではARC署名は追加されていません。
Gmailで受信した際に最初のARC署名(i=1)が追加されていますので、このARC署名に対応するDKIMレコードを検索してみます。

ARC用のDKIM(とほぼ同等の)署名が格納されるARC-Message-Signatureヘッダは以下です。セレクタ名とドメイン名を確認できます。

ARC-Message-Signatureヘッダ
ARC-Message-Signatureヘッダ

上記の内容に従い、ARC用のDKIMレコードを検索するコマンドは以下です。

  • digコマンドの場合
    dig -t TXT arc-20160816._domainkey.google.com
  • nslookupコマンドの場合
    nslookup -q=TXT arc-20160816._domainkey.google.com

上記問合せにより得られるレコードは以下です(2022年9月時点)。

"k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1Lztpxs7yUxQEsbDFhjMc9kZVZu5P/COYEUIX4B39IL4SXAbv4viIlT9E6F6iZmTh1go7+9WQLywwgwjXMJx/Dz0RgMoPeyp5NRy4l320DPYibNqVMWa5" "iQ2WiImQC0en1O9uhLLvzaSZJ03fvGmCo9jMo0GwKzLNe14xMgn/px2L5N/3IKlKX4bqUAJTUt8L993ZlWzvgMnSFSt8B+euSKSrtAiopdy4r1yO4eN5goBASrGW0eLQc1lYouNvCrcTQpos4/GEAqiGzpqueJLmBfOO4clNvVvpPkvQs2BHw9I9LmIjaMxTNGxkGBRaP3utDiKXXqu1K+LRzl0HCNSdQIDAQAB"

BIMIレコード

BIMI-Selectorヘッダは以下です。セレクタ名を確認できます。
(BIMI-SelectorヘッダがDKIM署名に含まれていませんが)

BIMI-Selectorヘッダ
BIMI-Selectorヘッダ

上記の内容に従い、BIMIレコードを検索するコマンドは以下です。

  • digコマンドの場合
    dig -t TXT fb2021q2v1._bimi.mail.instagram.com
  • nslookupコマンドの場合
    nslookup -q=TXT fb2021q2v1._bimi.mail.instagram.com

上記問合せにより得られるレコードは以下です(2022年9月時点)。

"v=BIMI1; l=https://instagram.com/images/bimi/ig-logo.svg; a=https://instagram.com/bimi-vmc.pem;"

上記のSVGやPEM(VMC)については、別の記事で触れています。

BIMIレコード(余談)

当初twitter.comから届いたメールを例にしようとレコード確認していたのですが、BIMIレコードを検索できなかったので見送りました。
twitter.comからのメールはGmail上でロゴ表示されているので、BIMI対応はしていると思います。BIMI-Selectorヘッダが無いのでデフォルトのセレクタ名(default)を用いてdefault._bimi.twitter.comで検索したところ、レコードが存在しませんでした。

Instagramからのメールの例より、Gmailは既存のBIMI-SelectorヘッダがDKIM署名対象外であってもヘッダ削除しないようなので、twitter.comからのメールにも最初からBIMI-Selectorヘッダは存在していなかったと推測されます。あるいは、Gmail側のBIMI動作として個別にtwitter.comを信頼する設定というのも考えにくいです。よく分かりませんでした。