Twikey の SPF、DKIM、DMARC 設定ガイド
by
最終更新日: 6 読了時間：約6分
主なポイント
- Twikey経由で送信するには、SPFが必須です。DKIMは任意ですが、配信率の向上に最も寄与するレコードであるため、強く推奨されます。
- Twikeyの標準設定では、SPFとDKIMのみが対象となっています。DMARCはこれとは別のドメインレベルのレコードであり、別途設定する必要があります。Twikeyのガイドでは、その設定手順については説明されていません。
- 新しいDMARCレコードは、すべてp=noneから開始してください。そうすることで、集計レポートを収集し、すべての正当な送信者が正しく認証されていることを確認した上で、適用に移行することができます。
- SPF および DKIM に関する DNS の変更が反映されるまで最大 48 時間かかる場合がありますので、導入スケジュールにはその余裕を十分に確保してください。
Twikeyを通じて支払いの督促メール、委任確認メール、または請求書をメールで送信する場合で、送信ドメインの認証をまだ行っていない場合は、このガイドでその手順を詳しく説明します。
Twikey を使えば、汎用的な Twikey アドレスではなく、ご自身のドメインからこれらのメールを送信できますが、この利便性は、受信側のメールサーバーがそれを信頼している場合にのみ機能します。SPF、DKIM、DMARC の3つのレコードが、その信頼を築くものです。これら 3 つが連携して、Twikey がユーザーに代わってメールを送信する権限があることを確認し、メッセージの内容が送信中に改ざんされていないことを証明し、さらに、両方のチェックに失敗したメールに対してメールボックスプロバイダーがどのように対処すべきかを指示します。
Twikeyでドメインを認証する理由
Twikeyは、企業が支払いの回収、SEPAやその他の引落許可の管理、および顧客への支払いリンクや請求書などの取引関連文書を送付するために利用する、定期請求およびデジタル引落許可プラットフォームです。これらのメールには金銭的な依頼が含まれることが多いため、なりすましの標的となりやすく、認証は単なる技術的な手続きというよりも、むしろ不正防止策としての役割を果たしています。
SPF、DKIM、DMARCを正しく設定することで、次のような具体的なメリットが得られます：
- なりすましリスクの低減：Twikeyを承認済み送信者として指定するSPFレコードがない場合、第三者がお客様の請求用ドメインから送信されたように見えるメールを偽造することを阻止する手段は一切ありません。
- 受信トレイへの配信率の向上：Gmail や Outlook などのメールプロバイダーは、認証されていない一斉送信メールやトランザクションメールを不審なメールとして扱う傾向が強まっており、その結果、こうしたメールがスパムフォルダに振り分けられやすくなっています。
- メールの送信状況の可視化：レポート機能を有効にした適切に設定されたDMARCレコードにより、ご自身のドメインを使用してメールを送信している送信者（忘れていた可能性のあるサービスも含む）を把握することができます。
- より厳格なポリシーの基盤：正当な送信者が問題なく認証されるようになれば、DMARCを監視モードから強制モードに移行させ、なりすましメールが受信トレイに届く前に実際にブロックできるようになります。
配送方法の選択
Twikeyでは、メールを送信する方法が2つ用意されており、どちらを選択するかによって設定手順が若干異なります。
1. Twikey SMTP サーバー
Twikeyがメールの配信を代行します。メールは送信キューに格納されるため、請求件数が急増する月初めなど、トラフィックが集中する時間帯には、配信に数分程度の遅れが生じる場合があります。
2. カスタムSMTPサーバー
SendGrid や Combell などの独自のプロバイダーを接続することで、送信を完全に制御し、Twikey のキューを完全にバイパスすることができます。なお、Gmail および Office 365 は、送信元アドレス（FROM アドレス）がアカウントのユーザー名と一致している必要があり、また送信量に制限が設けられているため、カスタム SMTP プロバイダーとしてはサポートされていませんのでご注意ください。
どちらのオプションを選択しても、以下のSPFおよびDKIMの設定は同様に適用されます。これは、どちらも送信方法そのものではなく、DNSレコードに依存しているためです。
手順 1：SPF レコードの設定
SPFは、受信メールサーバーに対し、どのサーバーがあなたのドメインを代表してメールを送信する権限を持っているかを通知します。もし、あなたのドメインから送信されたと主張するメッセージが、SPFレコードに記載されていないサーバーから送信された場合、受信サーバーはそのメッセージにフラグを立てたり、拒否したりする正当な理由を持つことになります。
すでにSPFレコードをお持ちの場合は、別のレコードを作成するのではなく、そのレコードにTwikeyのインクルード機能追加してください。ドメインにはSPF TXTレコードを1つだけ設定する必要があります。複数のレコードがあると、検証に失敗します。
たとえば、現在のレコードが次のような場合：
v=spf1 include:_spf.google.com ~all
次のように更新してください：
v=spf1 include:_spf.google.com include:_spf.twikey.com ~all
まだSPFレコードがない場合は、新しいTXTレコードを追加してください：
| フィールド | 価値 |
|---|---|
| 名前／ホスト | example.com。 |
| タイプ | TXT |
| 価値 | v=spf1 include:_spf.twikey.com ~al |
ITチームに伝えておくべき重要な点として、Twikeyは独自の検証チェックにおいてネストされたインクルードを解決しないため、SPFの設定にすでに複雑なインクルードの連鎖が含まれている場合は、これを追加した後に慎重にテストを行ってください。
DNS 検索の制限に近づいている場合、SPF の基本仕様では、1 レコードあたり DNS 検索をトリガーするメカニズムの数を 10 件までに制限しており、通常、各「include」は 1 件としてカウントされます。この上限に近づいている場合、Twikey では追加の検索を回避できる 2 つの代替メカニズムをサポートしています：
- v=spf1 a:mail.twikey.com ~all。これはTwikeyのメールサーバーを直接指し、基盤となるIPアドレスが変更された場合でも自動的に調整されます。
- v=spf1 ip4:52.29.184.146 ~all。これにより、TwikeyのIPアドレスが直接承認されます。このIPアドレスは現在静的ですが、Twikeyによると変更される可能性があるため、長期的にはa:メカニズムの方がより安全な選択肢となります。
複数のサービスでSPFレコードがすでに制限値を超えている場合は、今すぐ当社のホステッドSPFソリューションにご登録いただき、SPFエラーや制限を動的に解決してください。
ステップ2：DKIMの設定
DKIMは送信メッセージにデジタル署名を付与します。これにより、受信サーバーは、そのメールが実際にTwikeyのインフラから送信されたものであり、送信途中で改ざんされていないことを確認できます。Twikeyではこれを必須としていませんが、これは配信率を高めるための最大の要因です。なぜなら、SPFの整合性が完全でなかった場合でも、DKIMの検証に合格していれば、通常はDMARCへの準拠が認められるからです。
TwikeyのDKIM設定では、本番環境とテスト環境を分離しているため、CNAMEレコードを1つではなく2つ使用しています：
| 名前／ホスト | タイプ | 価値 |
|---|---|---|
| app._domainkey.example.com | CNAME | app._domainkey.twikey.com. |
| test._domainkey.example.com | CNAME | test._domainkey.twikey.com. |
アプリセレクターは本番環境の送信を対象としており、テストはTwikeyのベータ環境を対象としています。たとえ現時点でテスト環境を積極的に利用していなくても、DKIMが正しく検証されるためには、両方が存在している必要があります。
ステップ 3: Twikey で連携を設定する
DNSレコードが有効になったら、Twikeyダッシュボードの「設定」＞「連携」＞「メール」に移動し、送信方法を選択してください。
For either method, enter a FROM address with a friendly display name, for example Twikey Support <[email protected]>, so the recipient sees a recognizable name rather than a raw email address. If you added the DKIM records in Step 2, enable the DKIM checkbox before running the test.
カスタムSMTPサーバーを使用する場合は、プロバイダーからホスト名、ポート番号、および認証情報も別途必要になります。ポート番号を空欄のままにすると、Twikeyはデフォルトで25を、SSLが有効になっている場合は587を使用します。
「テスト」をクリックし、テストメールが届くことを確認してから保存してください。テストに失敗した場合は、ほぼ必ず次の3つのいずれかの原因が考えられます：DNSの反映がまだ完了していない、レコードに誤入力がある、または入力したドメインがDNSに登録されている内容と一致していない。DNSの反映状況を確認するツールを使えば、レコードが反映済みかどうかを確認できます。
ステップ4：DMARCの設定
これは、Twikeyの公式ドキュメントでは触れられていない部分です。なぜなら、DMARCは個々の送信プラットフォームの設定内ではなく、ドメインレベルで機能するからです。DMARCは、先ほど設定したSPFやDKIMレコードと連携して機能しますが、ドメイン全体に対して一度設定するだけで、Twikeyだけでなく、そのドメイン名義でメールを送信するすべてのサービスに適用されます。
構文を推測するよりも、PowerDMARCの無料DMARCレコード生成ツールを使用してレコードを作成してください：
- メール認証を初めて利用する場合は、ポリシーをp=noneに設定してください。これにより、受信サーバーは通常通りメールを配信しつつ、通過したメールと失敗したメールに関するレポートを生成し続けます。これは、すべての正当な送信者が問題なく認証されていることを確認する前の段階で、まさに望ましい動作です。設定に自信が持てるようになったら、ポリシーを p=reject/quarantine に更新するようにしてください。
- ruaフィールドに報告先住所を追加し、集計レポートが実際に確認できる場所に届くようにしてください。
- 生成されたTXT値をコピーし、新しいDNSレコードとして追加してください：
| フィールド | 価値 |
|---|---|
| 名前／ホスト | _dmarc.example.com |
| タイプ | TXT |
| 価値 | [生成されたレコードを貼り付けてください] |
数週間分のレポートを確認し、Twikey やその他の送信元が適切に認証されていることを確認したら、ポリシーをp=quarantineへ移行し、最終的には p=reject へと変更して、DMARC を完全に適用することができます。この監視期間を経ずにいきなり reject へ移行すると、自社の請求書や支払督促メールがブロックされてしまうリスクがあり、それでは本末転倒になってしまいます。
詳細については、Twikeyの公式メール認証設定ガイドをご参照ください。
設定の確認
Twikeyに組み込まれているテストとは別に、DNS側についても個別に確認しておく価値があります：
- ドメインをSPFチェッカーでチェックし、結果に「_spf.twikey.com」（または選択した代替メカニズム）が表示されていることを確認してください。
- DKIM検索ツールを使用して、「app」と「test」の両方のDKIMセレクタを確認してください。どちらについても、エラーなく有効なキーが返されるはずです。
- 当社のDMARCレコードチェッカーを使用して、DMARCレコードが公開され、読み取り可能であることを確認してください。また、最初の集計レポートを注意深く確認し、見落とした送信者がいないか確認してください。
公開直後にこれらのいずれかが「空」と表示された場合は、1日ほど待ってみてください。新しいレコードのDNSプロパゲーションには、レジストラや既存のTTL設定によっては、数分から最大48時間かかる場合があります。
まとめ
SPFとDKIMはメールを正常に受信させるための仕組みであり、DMARCは受信サーバーに対し、不正なメールに対してどのように対処すべきかを指示するものです。Twikeyの設定では、最初の2つは適切に処理されますが、ドメインレベルのDMARCレコードの設定と監視はユーザー自身の責任となります。このようなプラットフォームでは、金銭や業務上の指示に関するメールが大量にやり取りされることを考えると、DMARCを適切に設定しておくことは非常に重要です。
監視のみのDMARCポリシーから完全な適用への移行についてサポートをご希望の場合、またはご自身のドメインを名乗ってメールを送信している送信者を継続的に把握したい場合は、PowerDMARCチームまでお問い合わせいただくか、デモをご予約の上、プラットフォームの実際の動作をご確認ください。
ドメインおよびメールセキュリティの専門家（所属： PowerDMARC
ユネスはPowerDMARCのオペレーションチームリーダーで、メール認証とセキュリティの専門知識を持つ。マイクロソフト認定のAzureアドミニストレーターアソシエイトであり、CompTIA A+やその他多くの資格を持っています。
最新記事 by Yunes Tarada(全て見る)
- Twikey SPF、DKIM、DMARC 設定ガイド - 2026年8月11日
- サイバーセキュリティにおける「ホエーリング」とは？ - 2026年8月7日
- スパムフィルターとは何か、そしてそれが企業のメールをどのように保護するのか - 2026年8月6日
