SPF、DKIM、DMARCの慎重な設定順序

SPF、DKIM、DMARCによるメール認証は、受信側が業務メールをどう評価し、拒否するかに影響しますが、それだけで配信を保証するものではありません。ドメインが身元の根拠を十分に示せなければ、受信側には重要な信頼信号が不足します。これは日常的な運用課題です。

三つすべてを省略していなくても、誤った順序で設定し、厳しいポリシーを早く公開すると、自社メールを止める場合があります。基本的な業務メールの選択がまだなら、先に基盤を決め、その後で認証を段階的に強化してください。

本ガイドでは、SPF、DKIM、DMARCの順に進める慎重な手順を示します。これは唯一の方法ではありませんが、典型的なリスクを減らします。急いだ設定は転送を壊し、マーケティングツールのアライメントを失敗させ、サポートメールへ影響する可能性があります。

TrekMailは一部DNSレコードの状態を確認し、プランと構成に応じてカスタムドメイン、IMAPメールボックス、catch-all、転送、移行、BYO SMTPまたはマネージドSMTPに対応します。ドメイン追加時はTrekMailのドメイン設定ガイドから始めてください。ゼロから構築する場合はドメインでメールを作成する方法も参照できます。

SPF、DKIM、DMARCが実際に行うこと

これは三つの部分から成るメール認証システムです。SPFは実際のMAIL FROMドメインに送信IPを承認し、DKIMは署名と署名対象データを確認し、DMARCは希望する処理を公開して表示上のFromドメインとのアライメントを検証します。

プロトコル	役割	確認対象	主な障害
SPF	承認	接続元IPがenvelopeドメインについて許可されているか	ルックアップ過多、送信元の欠落、転送によるIP変更
DKIM	完全性	署名対象のヘッダーと本文が署名に一致するか	誤ったセレクター、鍵の欠落、事業者が自社ドメインで署名しない
DMARC	ポリシーとアライメント	成功したSPFまたはDKIMがFromドメインとアライメントするか	SPFとDKIMの確認前に厳しいポリシーを適用する

SPFを来客名簿、DKIMを改ざん防止の封印、DMARCを規則集に例えられます。適用要件では三つすべてが必要な場合がありますが、DNSへ一度に追加するのではなく段階的に導入します。

慎重な設定順序

実務的な順序は、送信元を棚卸しし、SPFを公開し、DKIMを有効にし、DMARCを厳しくないポリシーから始め、アライメントを直して段階的に強化するものです。実際の送信元を把握する前に正規メールを拒否するリスクを減らせます。

ドメインとして送信するすべてのシステムを棚卸しする。
正規送信元を含むSPFレコードを一つ公開する。
対応する各送信元や事業者でDKIMを有効にする。
p=noneでDMARCを公開し、入手できるレポートを集める。
アライメント障害を修正する。
検証後にp=quarantine、続いてp=rejectへ進む。

難しいのはレコードの長さではなく、実際の送信環境が想定より複雑になりやすい点です。

フェーズ1：棚卸しとSPF

SPFは、MAIL FROMドメインについてどのIPが送信を許可されるかという基本的な問いに答えるため、最初の本番変更に適しています。すべては直しませんが、古い事業者の不要な承認も見つけやすくなります。

DNSに触れる前に、業務メール、請求、CRM、サポート、マーケティング、Webフォーム、プリンターなど、@yourdomain.comとして送信するものを列挙します。

次にSPFレコードを一つ公開します。Google用とマーケティング用を別々にしないでください。複数のSPF TXTレコードは評価エラーになります。TrekMailのDNS例にも記載されています。

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net include:amazonses.com ~all

トラフィックを検証中は~allが適する場合があります。-allは、レコードの完全性を確認し、選択したポリシーに合う場合に検討します。

SPFの大きな落とし穴はルックアップ上限です。RFC 7208により、SPF評価には、ネストした参照を含む対象メカニズムと修飾子について10回のDNSルックアップ上限があります。include:、a、mxを積み重ねるとpermerrorになり、評価が機能しなくなる場合があります。

Google、HubSpot、Zendesk、QuickBooks、Mailchimp、誰も覚えていない古いチケットシステムを追加しました。SPFは完全に見えますが、受信側が上限に達し、評価全体をエラーとします。

多くのドメインを運用すると、認証は継続的な作業になります。事業者を監査し、未使用と確認できたincludeだけを削除し、必要ならトラフィックをサブドメインへ分けます。その際は実際のenvelopeドメインとアライメントを検証してください。集中DNS確認を備えるマルチドメインメールホスティングを検討する理由の一つです。

フェーズ2：DKIMとアライメント

SPFは転送の影響を受けやすいため、次にDKIMを設定します。転送でSPFは失敗することがありますが、署名が有効で、正規化された署名対象データが互換性を保てば、DKIMは成功し得ます。

DKIMに対応する送信サービスで有効にします。メールボックス、トランザクション、マーケティング、サポートなどです。自社ドメインで署名できないサービスは、その製品制約をポリシーと経路の設計に反映します。

一般的なDKIM DNS：

Type: TXT
Host: trek._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqh...

TXT公開鍵ではなくCNAME方式のDKIMを使う事業者もあります。現在の文書に従い、実際のメールで有効化を確認してください。

対応していれば、事業者ごとのセレクターで個別に失効できます。プラットフォームを停止する場合も、そのセレクターが使われていないと確認してから削除します。

次はアライメントです。認証だけでは足りず、DMARCは認証ドメインと表示上のFromドメインとの関係を確認します。Googleの現在の送信者ガイダンスは、対象送信者についてFromヘッダーの組織ドメインとSPFまたはDKIMのアライメントを求め、可能な場合は両方の構成を推奨しています。Googleの送信者ガイドラインFAQを参照してください。

Mailchimpが自社ドメインで署名し、既定のReturn-Pathを使うと、SPFとDKIMは成功しても、表示上のFromについてDMARCが失敗する場合があります。対応するなら、事業者内でカスタムドメイン認証を有効にし、実際のメールで確認します。

転送は典型的な複雑な場面です。頻繁に使うならメール転送の設定と修正を参照してください。

フェーズ3：制限を要求しないDMARC

DMARCは厳しい適用ではなくp=noneから始める方が慎重です。これはDMARC失敗による制限を要求せず、quarantineやrejectを求める前に利用可能なレポートを集められます。受信側独自のフィルターは引き続き適用されます。

基本レコード：

Type: TXT
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s

実際のドメインとリスクに応じてrelaxedアライメントも使えます。strictが普遍的に優れるわけではありません。正規送信元を把握してテストする前にrejectへ進まないでください。

DMARCレポートは有用ですが、任意であり不完全です。解析ツールを使い、ログや実際のメールと照合します。転送ではSPF failと、有効でアライメントしたDKIM passの組み合わせが想定内の場合があります。両方の失敗は、なりすましまたは見落とした正規送信元の可能性があります。TrekMailでは迷惑メールのトラブルシューティングが出発点になります。

この段階で、忘れたシステム、故障したスキャナー、古いニュースレター、なりすましの疑いを発見できます。棚卸し、ログ、実メッセージで各送信元を分類します。

フェーズ4：レポートの内容を修正する

DMARCレポートは、アライメント済み、認証のみ、未知の送信元について部分的な証拠を示しますが、偽物を自動判定しません。正規の失敗と疑わしい利用を実システムに照らして分け、確認できた問題を修正します。

多くの障害は次の種類です。

正規送信元がSPFにない。
事業者はDKIM署名するが、自社ドメインではない。
マーケティング基盤が既定のbounceドメインを使い、SPFアライメントに失敗する。
デバイスが認証SMTPリレーを通らず直接送信する。
未知の送信元がFromドメインを悪用している可能性がある。

プリンターとスキャナーは直接送信しがちです。可能なら適切なSMTPリレーを通します。現在のTrekMail有料プランにはマネージドSMTPが含まれる場合があり、NanoではBYO SMTPを使います。現在のホストとポートはIMAPとSMTP設定にあります。現在の文書ではTrekMailはIMAPのみで、POP3ではありません。

一律に数週間後とせず、複数の代表期間、ログ、実メッセージ、低頻度の重要フローを確認し、ロールバックを準備してから強化します。

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

quarantineを緩やかな中間段階として要求できます。棚卸しとアライメントを確認後にrejectを要求し、最終的な処理は受信側が決めることを忘れないでください。

コマンドラインでレコードを確認する方法

DNS画面や事業者画面への反映が遅れて見える場合があり、キャッシュはTTLの影響を受けるため、検証が重要です。DNSを直接問い合わせ、ドメインを使う各システムから実際のテストメールを送ります。

SPFを確認：

dig txt example.com +short

DKIMセレクターを確認：

dig txt trek._domainkey.example.com +short

DMARCを確認：

dig txt _dmarc.example.com +short

SPFレコードが一つ、有効なDKIM公開鍵、意図したDMARCポリシーがあるか確認します。変更時はTTLとキャッシュを考慮し、必要なら外部resolverへ問い合わせます。

逆引きDNS、TLS、苦情率も確認してください。SPF、DKIM、DMARCは基礎ですが、質の悪いリストや無謀な送信を補うものではありません。

従来の方法と新しい方法

従来は大規模スイートをメールボックス単位で契約するか、メール基盤、DNS、TLS、DKIMセレクター、レピュテーションを自社運用しました。別の方法ではメールボックスと送信を分離し、プラットフォーム上でドメイン、SMTP経路、認証を管理します。

TrekMailはこのモデルで利用できます。本記事に記載した現在の条件では、Starterは月額$3.50から、Nanoは$0でBYO SMTPを使用し、有料プランはマネージドSMTPを含む場合があります。カスタムドメイン、IMAPメールボックス、catch-all、転送、サーバー側IMAP移行、APIアクセスはプランによって異なります。最新料金、機能、上限を確認してください。すべての状況で費用が下がる保証はありません。

運用上の要点は、認証を一度設定するだけでなく継続して保守することです。モデルを検討する場合は自分のドメインでメールを設定するを読み、TrekMailの現在の料金を確認してください。