送信ドメイン認証 | Network

参照

• メールヘッダ入門
• 【詳細版】GmailとYahoo!が送信者に義務づける新しい要件
• https://www.kitasato-u.ac.jp/knc/mail/download/info_mail_header_v2.pdf
• Gmailの新スパム規制対応全部書く

前提知識

MX レコード

MXレコードは受信メールサーバーを指定するレコードのため、メールを送信するだけであれば関係ないと思われがちですが、送信に利用するドメインにMXレコードの設定がないと受信側のセキュリティチェックに引っかかり、送信したメールがブロックされたり、迷惑メールと判定されたりする可能性が高くなります。

ref. https://baremail.jp/blog/2022/05/31/2502/

エンベロープとヘッダ

https://baremail.jp/blog/2021/05/25/1377/?utm_source=google&utm_medium=cpc&utm_campaign=dsa&gclid=CjwKCAiAxvGfBhB-EiwAMPakqqxhQJs1WXBtrRSxwXiMtPTswKQGjZlif4ApuKTZ2BfwRlNhUjbcPBoCiC4QAvD_BwE

• エンベロープ To：「メールでは送信先のアドレスにあたります。メールの配送にあたっては、この宛先が正しく存在してさえいれば送信することができます。」
  ref. https://baremail.jp/blog/2021/05/25/1377/?utm_source=google&utm_medium=cpc&utm_campaign=dsa&gclid=CjwKCAiAxvGfBhB-EiwAMPakqqxhQJs1WXBtrRSxwXiMtPTswKQGjZlif4ApuKTZ2BfwRlNhUjbcPBoCiC4QAvD_BwE
• エンベロープ From：「実際に送信した差出人（送信元）」 宛先が存在しなかったときのエラーメールの送信先（メールソースの Return-Path で確認 ） ref. https://baremail.jp/blog/2021/05/25/1377/?utm_source=google&utm_medium=cpc&utm_campaign=dsa&gclid=CjwKCAiAxvGfBhB-EiwAMPakqqxhQJs1WXBtrRSxwXiMtPTswKQGjZlif4ApuKTZ2BfwRlNhUjbcPBoCiC4QAvD_BwE
• ヘッダ To：「メールではメールソフト上で確認できる宛先にあたります。「To」および「CC」の欄に入るアドレスです。」
  ref. https://baremail.jp/blog/2021/05/25/1377/?utm_source=google&utm_medium=cpc&utm_campaign=dsa&gclid=CjwKCAiAxvGfBhB-EiwAMPakqqxhQJs1WXBtrRSxwXiMtPTswKQGjZlif4ApuKTZ2BfwRlNhUjbcPBoCiC4QAvD_BwE
• ヘッダ From：メールではメールソフト上で表示される差出人（Fromアドレス）にあたります。
  ref. https://baremail.jp/blog/2021/05/25/1377/?utm_source=google&utm_medium=cpc&utm_campaign=dsa&gclid=CjwKCAiAxvGfBhB-EiwAMPakqqxhQJs1WXBtrRSxwXiMtPTswKQGjZlif4ApuKTZ2BfwRlNhUjbcPBoCiC4QAvD_BwE

実際の送信元はエンベロープ Fromだが、メールソフトに表示される差出人はヘッダ From です。

なりすましと SPF

ヘッダ From 、エンベロープ From の偽装は簡単だが送信元 IP の偽装は難しい¹ことを使用する認証が SPFです。

ヘッダFromとエンベロープFromの情報が異なっていてもメールを送ることができる仕組みを悪用したのが「なりすましメール」です。

ref. https://baremail.jp/blog/2021/05/25/1377/?utm_source=google&utm_medium=cpc&utm_campaign=dsa&gclid=CjwKCAiAxvGfBhB-EiwAMPakqqxhQJs1WXBtrRSxwXiMtPTswKQGjZlif4ApuKTZ2BfwRlNhUjbcPBoCiC4QAvD_BwE

実際は エンベロープ From も簡単に偽装できます。

送信元IP

• 送信元 IPはメールソースで以下のように確認する

  メールヘッダの情報の中で、特に重要なのがReceivedの情報です。
  Received はメールが送信されてきたサーバーの経路を示します。
  経路は下から上に読んでいきます（基本的に一番下が送信元、一番上が宛先）。
  よって、送信元を確認する場合は、一番下のReceived fromの情報を見ます。
  ※一番下を見てもよく分からない際は、下から二番目、三番目を見ると分かる場合があります。 ref.https://www.kitasato-u.ac.jp/knc/mail/download/info_mail_header_v2.pdf

• SPF は送信元 IPが偽装されていないことを前提とする
• 送信元 IP は エンベロープ From / ヘッダ From とは異なる 👈👈👈👈👈

SPF

ref. https://www.nic.ad.jp/ja/basics/terms/spf.html

SPF（Sender Policy Framework）は送信元の正当性を DNS を使って認証する仕組みです。

エンベロープ From も ヘッダ From も簡単に偽装できます。SPF　は　エンベロープ From　の偽装を見抜く技術です。具体的には送信元ドメイン（ エンベロープ From のドメインとHELO ドメイン²）の DNS から SPF レコード を取得して、送信元 IP がレコードに含まれているかをチェックします（送信元IPは偽装が難しいことを前提にしている）。

foo.example.com TXT v=spf1 +ip4:xxx.xxx.xxx.xxx/24 +a:foo.example.com +mx ~all

上記は IP アドレスが xxx.xxx.xxx.xxx/24 または A レコードと等しい場合または MX レコードのドメインの IP は許可、それ以外は不正メールとして処理されるが、配信されます。
SPF はSMTPセッション中、エンベロープFrom を用いてメール本文（ペイロード）が送信される前の段階でチェックされるため、スパム判定を早期に行うことができます（送信元IPの偽装がTCPの仕組み上困難であることを前提としています）。

ref.

• https://baremail.jp/blog/2021/03/16/1124/
• SPFレコードの書き方とは？ 記述例を総まとめ
• SPF（Sender Policy Framework）
• 送信ドメインを認証するためのSPFレコードに詳しくなろう
• DNS configuration tips and tricks for Pardot
• 間違いから学ぶSPFレコードの正しい書き方

+、-、~、?の意味。

・「+」⇒正常なメールとして処理

・「⁻」⇒不正メールとして処理され、配信拒否の可能性あり

・「~」⇒不正メールとして処理されるが、配信される

・「?」⇒SPF指定なしとして処理される

省略した場合は+として処理される。

省略した場合は全て「+」（正常なメール）として処理されます。

ref. https://baremail.jp/blog/2020/02/28/579/

ref.

• https://sendgrid.kke.co.jp/blog/?p=3509&utm_source=google&utm_medium=cpc&utm_content=text&utm_campaign=dsa&gclid=Cj0KCQiAxoiQBhCRARIsAPsvo-y6P1r8PAGf-h18Q_Rq2yHUSeaI7SJiiqeZY6YsnlotbRBgCS7heroaAoMYEALw_wcB
• https://help.salesforce.com/s/articleView?id=000313465&type=1

-all：SPF　レコードで定義されていないアドレスからのメール送信を許可しない旨を受信側のサーバーに伝えるもの（またそのようなアドレスを拒否するように指示）

ref. https://kinsta.com/jp/knowledgebase/spf-record/

末尾の-allは、「SPFレコードのリストにないアドレスはメール送信を許可されておらず、拒否すべき」であることをサーバーに伝えています。 この部分は~allでもよいのですが、その場合は「リストにないメールはセキュアでない、もしくはスパムであると表示されるが、受信はすべき」という意味になります。

https://www.cloudflare.com/ja-jp/learning/dns/dns-records/dns-spf-record/

サブドメインと SPF

SPFのポリシーは、サブドメインには自動的に継承されません。 SPFを使用してメールを認証するとき、サブドメインを使用してメールを送信する場合は、DNS　エントリに変更を加え、これらのサブドメインに個別にSPFレコードを設定する必要があります。

ref. https://maildata.jp/blog/blog-2023-02-09.html

チェック

• エンベロープ From はメールソースの Return-Path （偽装ができる）

• 送信元を確認する場合は、一番下のReceived fromの情報を見ます。 ref. https://www.kitasato-u.ac.jp/knc/mail/download/info_mail_header_v2.pdf

用語

NDR 【Non-Delivery Receipt】 配信不能レポート / バウンスメール / bounce mail

NDRとは、電子メールが宛先へ送達できない場合に、メールサーバが送信者にその旨報告するメールのこと。

https://e-words.jp/w/NDR.html

1. IP アドエス は TCP コネクションの 3 way ハンドシェイクに使用されるためです。 ↩

2. HELOドメイン：SMTPのHELOコマンドで使用されたドメイン名) ref. https://www.nic.ad.jp/ja/basics/terms/spf.html ↩