お名前.comからAWS Route 53にゾーンを委譲する。
Mailgunが発行する情報をRoute 53のゾーンに追加する。
mxa.mailgun.org
、mxb.mailgun.org
を設定ref. DKIMとは?
Mailgunで受けるものはinfo@info-town.jpに転送。
以下コードは分かりやすさのためにセキュリティをまったく考慮していない。
実運用で使用しないこと。
<?php
# Include the Autoloader (see "Libraries" for install instructions)
require '../vendor/autoload.php';
use Mailgun\Mailgun;
$name = $_POST['name'];
$email = $_POST['email'];
$content = $_POST['content'];
$template = <<<EOF
名前:%s
メールアドレス:%s
お問合せ内容:
%s
EOF;
$text = sprintf($template, $name, $email, $content);
# Instantiate the client.
# @see https://documentation.mailgun.com/en/latest/user_manual.html#sending-via-api
$mg = Mailgun::create('`mailgun key`');
$mg->messages()->send('mg.hiroshi-sawai.com', [ // SMTPサーバとしてmg.hiroshi-sawai.com、つまりmxa.mailgun.orgが使用される。
'from' => 'info@hiroshi-sawai.com',
'to' => 'info@example.com',
'subject' => 'hiroshi-sawai.comからお問い合わせがありました',
'text' => $text,
]);
header('Location: https://hiroshi-sawai.com/thanks.html');
exit;
MXレコードは、メールサーバーのアドレスをドメイン名に関連づけるもので、メールを配信するメールサーバーを決定するために使われます。メールを送信するとき、送信元のメールサーバーは宛先のドメイン名を見てDNSサーバーに問い合わせを行い、MXレコードを取得します。つまり、MXレコードに記載されているホスト名に対応するIPアドレスのメールサーバーに対し、SMTPプロトコルを使用してメールを送信します。
増井 敏克. 実務で使える メール技術の教科書 基本のしくみからプロトコル・サーバー構築・送信ドメイン認証・添付ファイル・暗号化・セキュリティ対策まで (p.167). Kindle 版.
MX は(外部からの)メールを配信するサーバ。
MX レコードでは、複数記述したときにアクセス先の優先順位が決められます。 優先度の数字によってある程度分散することができます。 数字が低いほど優先度が高く、数字が高いほど優先度が低くなります。
mg.example.com MX 5 mxa.mailgun.com
10 mxb.mailgun.com
mxa.mailgun.comの優先度が高くなるのでこちらを使用する。
mxa.mailgun.comが使用できない場合はmxb.mailgun.comを使用する。
example.com MX 10 mail.example.com
mg.example.com MX 5 mxa.mailgun.com
10 mxb.mailgun.com
推測
ref. 複数の MX レコードを使用する例
推測
MXレコードがない場合。
Aレコードに配信される。
以下コードは分かりやすさのためにセキュリティをまったく考慮していない。
実運用で使用しないこと。
<?php
# Include the Autoloader (see "Libraries" for install instructions)
require '../vendor/autoload.php';
use Mailgun\Mailgun;
$name = $_POST['name'];
$email = $_POST['email'];
$content = $_POST['content'];
$template = <<<EOF
名前:%s
メールアドレス:%s
お問合せ内容:
%s
EOF;
$text = sprintf($template, $name, $email, $content);
# Instantiate the client.
# @see https://documentation.mailgun.com/en/latest/user_manual.html#sending-via-api
$mg = Mailgun::create('`mailgun key`');
$mg->messages()->send('mg.example.com', [ // SMTPサーバとしてmg.example.com、つまりmxa.mailgun.orgが使用される。
'from' => 'info@example.com',
'to' => 'info@hoge.com',
'subject' => 'example.comからお問い合わせがありました',
'text' => $text,
]);
header('Location: https://example.com/thanks.html');
exit;
実際の送信もとはエンベロープ From
だが、メールソフトに表示される差出人はヘッダ From
。
ヘッダFromとエンベロープFromの情報が異なっていてもメールを送ることができる仕組みを悪用したのが「なりすましメール」です。
加えてエンベロープ Fromも簡単に偽装できる。
送信元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
とは異なる(こちらはドメイン) 👈👈👈👈👈ref. https://www.nic.ad.jp/ja/basics/terms/spf.html
SPF
(Sender Policy Framework)は送信元の正当性をDNSを使って証明する仕組み。
エンベロープ From
もヘッダ From
も簡単に偽装できる。SPF
はエンベロープ From
の偽装を見抜く技術。具体的には送信元ドメイン(エンベロープ From
のドメインとHELOドメイン
[^hello])のDNSからSPFレコード
を取得して、送信元IP
がレコードに含まれているかをチェックする(送信元IP
は偽装が難しいことを前提にしている)。
[^hello]:HELOドメイン:SMTPのHELOコマンドで使用されたドメイン名) ref. https://www.nic.ad.jp/ja/basics/terms/spf.html
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
はTCP層
で処理されるので実際のペイロードが送信される前にスパム判定ができる.
ref.
+
、-
、~
、?
の意味。
・「+」⇒正常なメールとして処理
・「⁻」⇒不正メールとして処理され、配信拒否の可能性あり
・「~」⇒不正メールとして処理されるが、配信される
・「?」⇒SPF指定なしとして処理される
省略した場合は+
として処理される。
省略した場合は全て「+」(正常なメール)として処理されます。
ref. https://baremail.jp/blog/2020/02/28/579/
ref.
-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を使用してメールを認証するとき、サブドメインを使用してメールを送信する場合は、DNSエントリに変更を加え、これらのサブドメインに個別にSPFレコードを設定する必要があります。
ref. https://maildata.jp/blog/blog-2023-02-09.html
NDR 【Non-Delivery Receipt】 配信不能レポート / バウンスメール / bounce mail
NDRとは、電子メールが宛先へ送達できない場合に、メールサーバが送信者にその旨報告するメールのこと。