本文へスキップ
SPFフラット化

SPFの10回上限の悩みを解消。ホスト型SPFフラット化で上限内に

SPFフラット化は、入れ子になったincludeをまとめ、レコードをDNSルックアップ10回の上限内に収めます。Palisadeは全送信元を1つのホスト型includeに集約し、ツールを追加しても上限を超えません。

SPFフラット化でできること

全送信元を1つのincludeに

入れ子のincludeの山を、Palisadeがホストする1つのincludeに置き換えます。公開レコードは短くなり、背後の送信元はそのままです。

permerrorを解消

ルックアップが10回を超えると、受信側はpermerrorを返します。SPFもアライメントも失敗し、DMARCは自社のメールを疑わしいと扱います。フラット化で評価を上限内に収めます。

ツール追加の余地を確保

新しい送信サービスを加えても、ルックアップ不足になりません。Palisadeで送信元を確認すれば、ホスト型includeに含まれます。

世界の主要ブランドが導入

提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ提携先ロゴ
仕組み

肥大化したレコードを1つのincludeに

フラット化は、一度公開するだけの1つのincludeの裏で動きます。

1

SPFをPalisadeへ向ける

DNSプロバイダーで、Palisadeのincludeを含むTXTレコードを1つ公開します。以後、手で管理するのはこのレコードだけです。

2

送信元はその裏で解決

Palisadeで確認した送信元がホスト型includeを構成します。確認していないものがSPFに入ることはありません。

3

ルックアップ削減

受信側は、入れ子のincludeに十数回ではなく、includeに1回だけルックアップします。レコード全体がSPFの上限内で評価されます。

4

変更は必ず確認

送信元の追加・削除はPalisade上の明示的な変更で、エージェントが作成し、お客様が承認します。レジストラでの手作業はありません。

含まれる機能

ホスト型SPFでできること

ルックアップ数を可視化

レコードが使うDNSルックアップの回数と、どのincludeが使っているかを、受信側がpermerrorを返す前に確認できます。MCPで接続したAIアシスタントも、get_spfツールで同じ情報を読めます。

冗長化されたDNS

ホスト型includeは、Palisadeの冗長マネージドDNSで配信されます。

確認済みの送信元から構成

includeは、実際のレポートで検証した送信元を反映します。手で管理するリストのように古くなることはありません。

一致も考慮

SPFに合格しても一致しなければDMARCは失敗します。Palisadeは両方を追跡し、構文チェックだけでなくポリシー強化に役立つレコードにします。

SPFの不具合には修正案を

SPFに失敗する送信元は、修正案付きのチケットになります。Palisadeのほかの機能と同じく、確認して承認する流れです。

送信元別の最終利用日

SPFで許可した各送信元に、SPFを通過したメールの最終日を表示します。1年間使われていない送信元はそう表示されます。どのincludeがまだ使われているか、推測せずにレコードを整理できます。

無料でレコード確認

無料のSPFチェックは、どのドメインでもルックアップ数を数え、上限超えを指摘します。フラット化前の確認に便利です。

大規模にメール認証を管理するチームの実績。手作業をなくした運用面の成果。

詳細

5.0 5点満点 (G2)導入実績1万ドメイン超

メール到達率: 商談獲得数が21%増加。 gaiiaが迷惑メール入りを解消。

メール到達率

商談獲得数が21%増加。gaiiaが迷惑メール入りを解消。

「商談獲得数が21%増えました。メールがきちんと守られているので、夜もぐっすり眠れるようになりました」

Marc-André Campagna、CEO、gaiia

導入事例を読む
gaiiaの展示会ブース。頭上のバナーに「grow better with gaiia」、ミントグリーンの壁に「If your BSS is kind of BS, talk to us.」の文字。
質問

SPFフラット化のFAQ

SPFフラット化とは

SPFでは1回の評価につきDNSルックアップは最大10回です。include、a、mx、redirectの各メカニズムが1回ずつ使い、入れ子のincludeは見えないところでさらに使います。フラット化はこのツリーを解決してコンパクトなレコードにし、受信側が上限内で評価できるようにします。Palisadeは結果をホストし、一度公開する1つのincludeで提供します。

上限を超えるとどうなりますか?

受信側は評価をやめ、permerrorを返します。SPFは正しく合格も失敗もしない状態になり、DMARCではSPFに通らないメールはDKIMだけが頼りです。DKIMにも不備があれば、自社の正規のメールが認証に失敗し始めます。

DMARCにとってなぜ重要?

DMARCは、SPFかDKIMが合格し、ドメインと一致すれば合格します。上限を超えたSPFレコードは、全送信元からその2つの経路の1つを黙って奪います。上限内に収めることは、ポリシー強化に向けた最初のチケットの1つになることがよくあります。

プロバイダーがIPを変えても大丈夫ですか?

それは自前でフラット化する場合の典型的なリスクです。プロバイダーのアドレスを一度コピーしても、いずれずれます。ホスト型SPFならinclude裏のレコードはPalisadeが管理するので、レジストラでプロバイダーの変更を手で追う必要はありません。

DNSプロバイダーの変更は必要?

いいえ。今のプロバイダーで、Palisadeのincludeを含むTXTレコードを1つ公開するだけです。ほかのSPFレコードと同じです。レジストラもDNSホストも変わりません。

ホスト型レコードの中身は管理できますか?

はい。includeはPalisadeで確認した送信元から作られます。新しい送信元は確認用のチケットになり、承認なしにSPFに加わることはありません。

SPFを上限内に保ち続ける

ドメイン診断は無料・カード不要。カード登録で15日間のトライアル開始。