送信ドメインのSPF、DKIM、DMARCの設定方法

自動メールを設定する際に、メール認証を見落とすことは非常に一般的です。メールプロバイダーを接続し、テストメッセージを送信すると、それはスパムに届きます。あるいは、Gmailは認証されていない送信者に関する550 5.7.26エラーでそれをバウンスさせます。このガイドでは、送信ドメインがどのように認証されるかを説明しており、メッセージがスパムに入らないようにするのに役立ちます。 3つの主要なメールセキュリティコンポーネントは、SPF、DKIM、DMARCです。これらは、受信メールサーバーがメッセージがあなたのドメインを使用することを許可されているかどうかを確認できるようにし、連携して機能します。SPFは送信サーバーのIPアドレスを認証し、DKIMはメッセージの整合性を証明するために暗号署名を追加し、DMARCは両方の結果を使用して表示される送信者アドレスとの整合性をチェックし、ポリシーを強制します。 これらを正しく設定しても、必ず受信トレイに届くことが保証されるわけではありませんが、レコードが欠落していると通常のメールが届かなくなる可能性があります。パスワードリセットや請求書の送信は、ニュースレターと同様にこれらのチェックを必要とします。 Gmailの送信者ガイドラインでは、小規模な送信者であってもSPFまたはDKIMが必要であり、個人用Gmailアカウントに1日あたり約5,000通のメッセージを送信する送信者には3つすべてが必要です。ドメインを接続したら、すぐに正しく設定することをお勧めします。 このガイドでは、Mailfullyのドメイン設定を使用して、すべてがどのように機能するかを示します。別のプロバイダーを使用している場合、レコードの値は異なりますが、同じ2つのチェックを行います。レコードは正しく公開されていますか？アプリ経由で送信されたメッセージは実際に合格しますか？ 設定しているもの メッセージが到着すると、受信メールサーバーは3つの質問をします。各レコードが1つに答えます。 SPF (Sender Policy Framework): このメッセージを配信したサーバーは、このドメインからの送信が許可されていましたか？ DKIM (DomainKeys Identified Mail): このメッセージは本当にこのドメインから来たもので、変更されずに届きましたか？ DMARC (Domain-based Message Authentication, Reporting, and Conformance): それらの回答は、受信者がFrom行で見ているアドレスと一致しますか？一致しない場合、メッセージはどうなるべきですか？ これら3つすべてがDNSレコードです。CloudflareのようなDNSホストに公開される短いテキストで、どのメールサーバーでもルックアップできます。 以下の図は、1つのメッセージがメールプロバイダーから受信サーバーに届くまでの流れを追っています。各チェックがメッセージのどの部分を読み取るか、サーバーがそれを参照してどのDNSレコードをルックアップするか、そしてDMARCが合格または失敗した場合に何が起こるかを示しています。 各チェックが同じメッセージから異なるドメインを読み取っていることに注意してください。SPFはReturn-Pathを使用し、DKIMは署名のd=ドメインを使用し、DMARCはFromアドレスを使用します。ほとんどの設定問題は、これらのドメインのいずれかが予想したものではないことから生じます。表は同じ情報を1か所にまとめています。 レコード | チェック内容 | チェックするドメイン | 公開場所 ------- | -------- | -------- | -------- SPF | 送信サーバーが許可リストにあるか | Return-Path (エンベロープ送信者) | Return-PathドメインのTXTレコード DKIM | メッセージに有効な署名があるか | 署名のd=ドメイン | <selector>._domainkey.<domain>のレコード DMARC | Fromドメインと一致するドメインに対してSPFまたはDKIMが合格したか | 表示されるFromアドレスのドメイン | _dmarc.<domain>のTXTレコード SPF: 誰があなたのために送信できるか SPFは、ドメインからのメール送信が許可されているサーバーのリストであり、DNS TXTレコードとして公開されます。メッセージが到着すると、受信サーバーはそれを配信したIPアドレスをそのリストと比較します。アドレスがリストにあれば、SPFは合格します。なければ、レコードの末尾によって、SPFは失敗またはソフトフェイルします。 ホストexample.comのSPF例: v=spf1 include:_spf.google.com ~all 見落としがちなのは、SPFがどのドメインをチェックするかです。受信者が表示するFromアドレスは参照しません。エンベロープ送信者、つまりMAIL FROMまたはReturn-Pathと呼ばれるものをチェックします。これは、主にバウンスメッセージの送信先として、バックグラウンドで使用される別のアドレスです。受信者は生のメッセージを開かない限りそれを見ることができず、メールプロバイダーはデフォルトでそれ自身のドメインに設定することがよくあります。 封筒に入った手紙を考えてみてください。郵便配達員は封筒の差出人住所を使用します。読者は中のレターヘッドを見ます。SPFはレターヘッドではなく封筒をチェックします。 SPFはまた、メッセージを引き渡したサーバーにも関連付けられています。メールが転送されると、転送サーバーがそれを配信するサーバーになり、通常はリストにないため、SPFは転送後に失敗することがよくあります。 DKIM: あなたのメッセージであることを証明する署名 DKIMは、改ざん防止シールのように機能します。プロバイダーがメッセージを送信すると、プロバイダーのみが持つ秘密鍵で署名し、メッセージにヘッダーとして署名を追加します。対応する公開鍵はDNSに公開されるため、どの受信サーバーでもルックアップして署名を確認できます。 ホストs1._domainkey.example.comのDKIM例: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu3Xk...IDAQAB 署名がチェックアウトした場合、受信者は2つのことを知ります。メッセージは、そのドメインの鍵を制御する誰かによって署名されたこと、そして署名された部分が途中で変更されていないことです。署名された部分は本文と、常にFromを含み通常はSubjectを含むヘッダーのセットです。転送中にいずれかが変更された場合、チェックは失敗します。 各署名は、それが署名したドメインをd=フィールドで指定します。これは受信者がルックアップするドメインであり、DMARCが後であなたのFromアドレスと比較するドメインです。1つのメッセージが複数のDKIM署名を運ぶことができ、それぞれ異なるドメインに対してです。 DMARC: すべてをFromアドレスに結びつける SPFとDKIMは単独で使用するとギャップがあります。どちらも受信者が表示するFromアドレスをチェックしません。スパマーは、自分のドメインのSPFが合格し、自分のドメインのDKIM署名を持つ自分のサーバー経由でメールを送信し、それでもあなたのドメインをFrom行に入れることができます。両方のチェックが合格しますが、間違ったドメインに対してです。 DMARCは、チェックを表示されるFromアドレスのドメインに接続することで、このギャップを閉じます。メッセージがDMARCを合格するには、SPFまたはDKIMの少なくとも一方が合格し、Fromドメインと一致するドメインを使用する必要があります。その一致はアライメントと呼ばれます。 ホスト_dmarc.example.comのDMARC例: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=r; pct=100 アライメントは、同一である必要はありません。デフォルトの緩和されたルールでは、同じ組織ドメインを共有する任意の2つのドメインはアライメントします。組織ドメインは、example.comのようにレジストラから購入する部分です。したがって、mail.example.comとsend.mail.example.comは互いにアライメントしますが、どちらもexample.netとはアライメントしません。 例えば、receipts@mail.example.comからのメッセージは、send.mail.example.comのSPFを通じてDMARCを合格できます。あなたのメールプロバイダー自身のドメインでのSPF合格ではそれはできません。DKIMも同様です。無関係なプロバイダーのドメインからの有効な署名は、DMARCのためにあなたのFromアドレスを認証しません。 これにより、SPFとDKIMの両方が「合格」と言うのに、DMARCが「失敗」と言うという、otherwise confusingな結果が説明されます。チェックは間違ったドメインに対して成功することができます。 DMARCはまた、失敗したメール（p=none、p=quarantine、またはp=reject）をどのように処理するかを受信者に指示し、あなたが忘れていた送信者を見つける方法であるレポートを送信するように依頼することもできます。ステップ3では両方をカバーします。 DNS設定を開く前に 送信に使用するドメインを選択してください。アプリメールの場合、mail.example.comのようなサブドメインが良い出発点です。これにより、スタッフメールの設定と混同することなく、送信を設定するためのスペースが得られます。この選択については、トランザクションメールをサブドメインから送信するでカバーしています。 このガイド全体でmail.example.comを使用します。それをあなた自身の送信ドメインに置き換え、プロバイダーから実際のレコード値をコピーしてください。以下のDKIMセレクタは例です。それらを公開してもドメインは検証されません。 DNSをホストしているサービスにアクセスする必要があります。それはあなたのレジストラかもしれませんが、Cloudflareや他のホストである可能性もあります。不明な場合は、このコマンドがドメインのネームサーバーを示します。 bashCopydig NS example.com +short Mailfullyでは、Domainsページからドメインを追加します。各レコードのコピーボタンとステータスが表示されたリストが表示されます。DNS設定を操作しながら、そのページを開いたままにしておいてください。もし