Greatmail メール認証ガイド：SPF、DKIM、DMARC の設定

主なポイント

配信率への直接的な影響：SPF、DKIM、DMARCを正しく設定することで、Greatmailを利用する際、ビジネスメールがスパムとして判定されるのを防ぎ、受信トレイへの到達率を高めることができます。
SPFの単一レコードルール：ドメインに複数のSPFレコードを公開しないでください。すでにレコードが存在する場合は、2つ目のTXTエントリを追加するのではなく、そのレコードに「include:spf.greatmail.com」を統合してください。
ドメイン固有のDKIM：Greatmailは、ドメインごとに固有の秘密鍵とセレクタを生成します。値を推測するのではなく、オンボーディングの際にGreatmailのサポートにカスタム公開鍵をリクエストする必要があります。
安全な段階的な導入：厳格な適用（p=reject）に移行する前に、送信メールのフローを安全に監視できるよう、必ずp=noneのDMARCポリシーから開始してください。

貴社がメールホスティングや送信用SMTPサービスとしてGreatmailを利用している場合、メッセージはGreatmailの専用サーバーインフラを通じて送信されます。

適切なDNS認証が行われていない場合、メールボックスプロバイダー（GmailやYahooなど）は、送信されたメールを不正ななりすまし攻撃と見なす可能性があります。SPF、DKIM、DMARCのポリシーを整合させて導入することで、この信頼のギャップを埋め、ブランドアイデンティティを検証し、送信メールのセキュリティを確保することができます。

ステップ 1：ドメインのプロビジョニングとカスタムキーの申請

Greatmailでは、一意のセレクターとキーペアをアカウントごとに割り当てるため、カスタムホスティングパラメータについては、オンボーディングの手順書またはGreatmailのサポートから直接確認する必要があります。

1. ドメイン設定の提出：オンボーディング手続きの際に、送信元の正確なドメインをGreatmailに登録してください。

2. サービスの種類を決定する：お使いのドメインで、Greatmailの完全ホスティング型メールボックスを利用するのか、それとも送信用SMTPサービスのみを設定するのかを明確にしてください。

Important: If you only use Greatmail for SMTP-only outbound sending, do not change your MX records. MX records govern inbound mail. Only point your MX records to Greatmail (commonly smtp.greatmail.com with priority 10) if they are hosting your incoming mailboxes.

3. カスタムキーの依頼：Greatmailに、ご自身のアカウント固有のDKIMセレクターおよびDKIM公開鍵の提供を依頼し、ドメインに対して整合性のあるカスタムReturn-Pathが指定されているかを確認してください。

ステップ 2: Greatmail の SPF を設定する

SPFは、お客様のドメインに代わってメールを送信することが許可されている送信メールサーバーを認証します。

シナリオA：既存のSPFレコードがない場合

現在、ドメインにSPFレコードがない場合は、DNSゾーン内に新しいTXTレコードを登録してください：

タイプTXT
ホスト／名前: @（ルートドメインの場合は空欄のまま）
価値がある。

v=spf1 mx include:spf.greatmail.com ~all

（注：送信元の調整を行っている間は、正当なメールがバウンスされるのを防ぐため、初期の監視設定では、厳格な「-all」（ハードフェイル）ではなく、「~all」（ソフトフェイル）を使用することをお勧めします）。

シナリオ B：既存の SPF レコードがある場合（最も一般的なケース）

すでに他のツール（Microsoft 365 や Google Workspace など）を通じてメールを送信している場合は、決して 2 つ目の SPF レコードを作成しないでください。そうすると、即座に PermError が発生します。

その代わりに、Greatmailのinclude文を現在のレコードに組み込んでください：

以前：

v=spf1 include:spf.protection.outlook.com ~all

その後：

v=spf1 include:spf.protection.outlook.com include:spf.greatmail.com ~all

複数のサードパーティ製送信プラットフォームを追加すると、DNSルックアップの標準制限である10回を超えてしまう可能性があります。PowerDMARCのSPFチェッカーを使用してルックアップ回数を監視するか、Hosted SPFを利用することでこの制限を完全に回避することができます。

ステップ3：カスタムDKIMの設定

DKIMでは、送信メッセージに秘密鍵で署名を行い、受信サーバーはDNSに登録された公開鍵を使用してその署名を検証します。Greatmailでは一意の鍵ペアが生成されるため、他の顧客のセレクターをコピーしないでください。

Greatmailから提供された正確なセレクタと公開鍵を使用して、新しいDNSレコードを作成してください：

タイプTXT
ホストレコード／名前：[selector]._domainkey（[selector]の部分は、Greatmailのサポートから提供された特定の文字列に置き換えてください）
TXT値：

v=DKIM1; k=rsa; p=[Greatmail-公開鍵]

Note:When copying the public key, ensure you do not introduce accidental spaces or line breaks. Once published, confirm with Greatmail support that the record has propagated so they can toggle active signing on their servers. If you want to check your keys, you can do so by using PowerDMARC's DKIM checker.

ステップ4：DMARCレコードの設定

DMARCは、メールの真正性を検証するために、SPFまたはDKIMのいずれかによる認証結果に依存しています。DMARCの検証に合格するためには、表示されている「From」ヘッダーのドメインが、SPF（Return-Path）またはDKIM（d=署名タグ）で使用されている認証済みドメインと一致している必要があります。

PowerDMARCの無料DMARCレコード生成ツールを使用して、初期レコードを作成してください。

1. DNS設定を開き、新しいレコードを作成します：

タイプTXT
ホスト／名前: _dmarc
値：v=DMARC1; p=none; rua=mailto:[email protected];

2. 新しいレコードを保存してください。

「p=none」ポリシーを採用することで、正当なメール配信に支障をきたすリスクを冒すことなく、集計XMLレポート（rua）ですべての送信元を安全に監視することができます。

ステップ 5: 確認、トラブルシューティング、および適用

認証が正しく行われていることを確認するには、実環境でのテストを実行してください。

DNSの伝播テスト：PowerDMARCの「DMARCレコードチェッカー」を使用して、SPF、DKIM、およびDMARCのTXTレコードが正しいホスト名で解決されることを確認してください。

テストメールの送信：GreatmailのSMTP認証情報を使用し、本番環境の「送信元」アドレスから、ご自身が管理するメールボックス宛てに実際のメールを送信します。

ヘッダーを確認する：メッセージの生のヘッダーを表示し（Gmailの場合は「オリジナルを表示」など）、Authentication-Results ヘッダーを確認します：

「spf=pass」と表示されていることを確認し、smtp.mailfrom のドメインが「From」のドメインと一致していることを確認してください。

「dkim=pass」を探し、d=タグがご自身のドメインと一致していることを確認してください。

「dmarc=pass」が実際に記録されていることを確認してください。

Common Pitfall: If SPF passes for a Greatmail-owned return-path domain and DKIM passes for a Greatmail-owned signing domain, DMARC will still fail because neither domain aligns with your personal "From" domain. Ensure Greatmail has configured a custom aligned return-path and custom DKIM under your specific domain.

p=棄却への安全な経路

1ビジネスサイクルにわたって、p=none の監視ポリシーを維持してください。これにより、季節的なメール、取引関連のメール、および自動送信されるメールが、レポートに反映されるまで十分な時間が確保されます。承認済みのすべての送信元が整合性のある認証を通過していることを確認したら、なりすましやスプーフィングを防ぐために、ポリシーを「隔離」に更新し、最終的には「拒否」に設定してください：

隔離（ステージング）：v=DMARC1;p=quarantine; rua=mailto:[email protected];
拒否（強制適用）：v=DMARC1; p=reject; rua=mailto:[email protected];

まとめ

メールセキュリティを最大限に強化する準備はできていますか？PowerDMARCチームが、Greatmailのトラフィックを確実に監視し、DMARCの適用へ安全に移行し、BIMIを活用して顧客の受信トレイにブランドロゴを表示できるようサポートいたします。

今すぐ弊社チームにお問い合わせいただくか、PowerDMARCのデモをご予約いただき、ビジネスコミュニケーションのセキュリティを確保しましょう！

について
最新記事

ユネス・タラダ

ドメインおよびメールセキュリティの専門家（所属： PowerDMARC

ユネスはPowerDMARCのオペレーションチームリーダーで、メール認証とセキュリティの専門知識を持つ。マイクロソフト認定のAzureアドミニストレーターアソシエイトであり、CompTIA A+やその他多くの資格を持っています。

最新記事 by Yunes Tarada(全て見る)

StripeのDKIM、DMARC、SPF設定ガイド - 2026年9月11日
オンデマンド出席管理のメール認証ガイド：SPF、DKIM、およびDMARC - 2026年9月11日
Greatmail メール認証ガイド：SPF、DKIM、DMARC - 2026年9月11日

Greatmail メール認証ガイド：SPF、DKIM、DMARC