概要
電子メールの送信元ドメインが詐称されていないかを検証する送信ドメイン認証(Sender Domain Authentication)。
本記事は、動作確認等のために、各送信ドメイン認証のDNSレコードを検索する方法をまとめたものです。
SPF、DKIM、DMARC、ARC、BIMIといった送信ドメイン認証を俯瞰的にまとめた記事はこちらです。
本記事の目的
目次
サマリ
以下のTXTレコードです。
- SPFレコード
ドメイン名
ドメイン名はエンベロープFromドメイン - DKIMレコード
セレクタ名._domainkey.ドメイン名
ドメイン名はDKIM-Signatureヘッダのdタグの値、セレクタ名は同ヘッダのsタグの値 - DMARCレコード
_dmarc.ドメイン名
ドメイン名はヘッダFromドメイン、もしくはその組織ドメイン - ARC用のDKIMレコード
セレクタ名._domainkey.ドメイン名(DKIMレコードと同様)
ドメイン名はARC-Message-Signatureヘッダのdタグの値、セレクタ名は同ヘッダのsタグの値 - BIMIレコード
セレクタ名._bimi.ドメイン名
ドメイン名はヘッダFromドメイン、セレクタ名はBIMI-Selectorヘッダの値(ヘッダが無ければ"default")
届いたメールをもとに検索
今回、InstagramからGmailに届いたメールを例にします。
Instagramのロゴが表示されているのでBIMI対応済みです。
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レコードを検索するコマンドは以下です。
- 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用の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レコードを検索するコマンドは以下です。
- 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を信頼する設定というのも考えにくいです。よく分かりませんでした。
