MailData

SPFマクロ – 知っておくべき全て

SPFマクロ – 知っておくべき全て

2023年11月18日
著者: Ahona Rudra
翻訳: 竹洞 陽一郎

この記事はPowerDMARCのブログ記事 SPF Macros – Everything You Need to Know の翻訳です。
Spelldataは、PowerDMARCの日本代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。


SPFマクロは、ドメイン所有者が自分のメールドメインの認証のために、よりダイナミックでスケーラブルなSPFレコードを要求する際に使用される、効果的で重要なセンダーポリシーフレームワークの機能です。
SPFマクロ機能はSPFレコード構文の一部であり、SPF検証が必要な個々のメールからのメタデータによって置き換えられる文字列を定義しています。
これにより、簡略化されたSPFレコードの作成が可能となり、長く複雑なSPFレコードの生成を避けることができます。

私たちPowerDMARCでは、SPFフラットニングおよびSPFマクロ技術を利用して、SPF認証およびレコード最適化に関して広範な柔軟性を提供する方法で、高く評価されているSPF管理ソリューション「PowerSPF」を再設計しました。
PowerSPFは、その使いやすさと効果の高さから、年々お客様からのお気に入りとなっています。

詳しくは、公式のIETFドキュメントをご覧ください。

SPFマクロの解説

SPFマクロは、文字列のシーケンスであり、RFC 7208のセクション7で説明されているように、SPF DNS TXTレコード内で定義されたメカニズムを置き換えることで、SPFレコード構成を簡素化するために使用できます。

SPFレコードは大抵シンプルで、あなたのドメインから来る不正なメールに対する受信者のサーバの対処方法は、SPFメカニズム、修飾子、および変更子を使用して定義できます。
しかし、SPFメカニズムでは不十分な場合があり、その際にはSPFマクロが必要となります。

SPFマクロはパーセント記号(%)で表され、2つ以上の文字、変更子、および区切り文字の組み合わせを含みます。
SPF認証プロセス中に、SPFマクロは評価され、説明されている通り、それぞれの値に置き換えられます。

例えば、%s と %d はそれぞれ、検証されたアイデンティティに関連付けられた送信者のアドレスとドメイン名を表します。

修飾子の r、l、または o は、アドレスやドメインの特定の要素を抽出するために使用され、区切り文字の - や . はマクロ内の異なる要素を区切るのに役立ちます。

SPFマクロの種類

SPFマクロは、異なる単一のアルファベットまたは文字によって示され、これらは波括弧 { } で囲まれ、パーセント(%)記号が前置されます。
これは、SPFレコード内の特定のメカニズムを指します。ここに主要なマクロを挙げます。

%{s}
「s」マクロは送信者のメールアドレスを表します。
例:Mark@domain.com。
%{l}
送信者のローカルパートを示すために使用されます。
例:Mark。
%{o}
これは送信者のドメインを強調します。
例:domain.com。
%{d}
「o」と同様に、このマクロは権威ある送信ドメインを表します。
ほとんどの場合、送信者のドメインと同じですが、場合によっては異なることもあります。
%{i}
メッセージの送信者のIPアドレスを抽出するために使用されます。
例:192.168.1.100
%{h}
このマクロはHELO/EHLOドメインを表します。

レコードで指定できるマクロは他にも多くありますが、ここではいくつかの一般的なものをリストしました。

SPFマクロの仕組み

SPFマクロを使用することで、ドメイン所有者はSPFレコード内の特定のメカニズムを参照して置き換えることができます。
受信MTAによるDNSクエリ中に、これらの参照が使用され、メカニズムが抽出され、レコードが拡張されます。
これにより、より管理しやすく適応性の高いSPFレコードを作成することが可能となります。

以下にSPFレコードで使用されるマクロの例を示します。


v=spf1 include:%{i}_.%{d}._spf.powerdmarc.com ~all

SPFレコードでマクロが使用するケース

SPFマクロは、ドメイン所有者のニーズに応じて、様々なシナリオで使用できます。
複雑なメール認証インフラを簡素化したい場合、複数のサードパーティメール処理サービスを使用している場合、または単にSPFレコードのサイズを縮小したい場合に便利です。

以下に、SPFマクロが有利である一般的なケースをいくつか挙げます。

マルチドメインインフラを持つ組織

すべての規模の組織でSPFマクロは使用できますが、複数のドメインを運営するレベルの企業組織には最も適しています。
マクロは、従来のフラットニング方法(※)に比べて、SPFレコードの柔軟性と効果的な最適化を大幅に提供し、マルチドメイン環境でもSPFがスムーズに機能することを保証します。
これにより、複数のSPFレコードを作成する必要がなくなります。

※訳注: SPFフラットニングとは、事前にDNS側でSPFのincludeなどを名前解決しておいて、IPアドレスリストを1つに統合しておく技術です。
従来のPowerSPFでは、SPFフラットニングだけでしたが、今回のアップデートで、SPFマクロも使って、抽象化によるIPアドレスの隠蔽とより大規模なIPリストの統合に対応しました。

大規模なメールインフラ

複雑なメールインフラを持つ企業は、多数のSPFメカニズムを組み込む必要があり、これらはSPFマクロを使用して最適化されます。
これらのマクロは、メカニズムへの参照を定義する方法を提供し、レコードが長くなりすぎてRFCで指定された512オクテット(※)の長さを超えないようにします。

※訳注: オクテットとバイトは、基本的には同じなので、512バイトになります。
バイトではなくオクテットが単位として使われる理由は、歴史的に、バイトは古いシステムで6bitや7bitだったこともあり、オクテットは明示的に8bitとして定義されているからです。

サードパーティサービス

SPFが壊れることなく、サードパーティのインクルードを簡単に最適化し、DNSと無効なルックアップの許可された制限を超えないようにするSPFマクロの導入により、複数のサードパーティメールベンダーを使用している組織は安心できます。

組織はSPFマクロを使用してSPFの課題を解決

SPFマクロをレコードに複数含めることで、手動でのSPF検査やSPFチェッカーを使用した際に浮き彫りにされる一般的な問題を解消することができます。
以下は、事前にできることです。

Temperrorを引き起こす長いSPFレコードの防止

SPFレコードに複数のinclude:ステートメントが含まれている場合、レコードが長くなりすぎるのを防ぐことができます。
しかし、これは恒久的な解決策ではありません。
ドメインのSPF設定にSPFマクロを使用することで、RFCがDNS TXTレコード(512文字)に指定する長さの制限を超える可能性を排除します。(※)

※訳注: UDPからTCPに切り替わるタイミング

SPFは512バイト以内と定義されているのに、どうしてDNSではエラーにならず、Temperrorが引き起こされるのでしょうか?
SPFのTemperrorを出すのは、DNSではなく、受信側MTAである、という点を理解する必要があります。
DNSは通常、UDPを使ってクエリと応答を処理しますが、以下のような処理でTCPを使う場合があります。

パケットサイズ制限
UDPの場合、パケットサイズには512バイトの制限があります。
もし応答がこのサイズを超える場合、サーバは通常、応答の一部を含む「切り詰められた(truncated)」メッセージを送信し、クライアントにTCPを使用して再クエリを行うよう指示します。
信頼性と順序
TCPは接続指向型プロトコルであり、データの信頼性と順序を保証します。
大きなデータ転送や重要なトランザクションには、TCPが選択されることがあります。
たとえば、DNSゾーン転送(AXFR)はTCPを使用して行われます。
拡張機能の使用
DNSの拡張機能(例えばDNSSEC)は、応答サイズを大きくする可能性があり、このような場合、TCPの使用が選択されることがあります。
再試行とフォールバック
一部のDNSクライアントは、UDPによる初回クエリが失敗した場合や、切り詰められた応答を受け取った場合に、自動的にTCPを使用して再試行します。

これらの基準により、DNSの通信は、状況に応じてUDPまたはTCPを使用するよう適応的に変化します。
通常、DNSクエリはUDPを使用して効率的に行われますが、必要に応じてTCPに切り替わることがあります。

以上から、もしSPFレコードを512バイト以上で定義しても、DNSはUDPからTCPに切り替えて配信することで、DNSのエラーを発生させません。
しかし、SPFを参照して処理するのは受信側MTAですから、そちらで512バイトの超過を検出してTemperrorを出します。
これを通知として知るには、DMARCを設定し、RUAレポートを定期的に分析することが大事です。

DNSおよび無効なルックアップを制限し、Permerrorを緩和

複数のサードパーティ送信元およびメールベンダーを使用する組織は、DNSクエリに対するRFCで指定されたルックアップ制限を超える傾向があります。
これは、各ベンダーが少なくとも1回または複数回のルックアップを追加するためです。
これが積み重なると、SPFレコードが壊れてSPF permerrorを引き起こす可能性があります。

これらの外部ベンダーのIPアドレスまたはドメインへの参照をSPFマクロで追加することで、不正なソースを制限しつつ、ルックアップ制限の範囲内に収まるようにします。

PowerSPFを使ったSPF設定でマクロの利点を活用する

SPFマクロは、SPF認証、レコード作成、および管理の点でダイナミズムとスケーラビリティを可能にするために、MTA(メール転送エージェント)によって広くサポートされています。
PowerSPFはSPFマクロをシームレスに統合し、クライアントが柔軟性を高めたSPFレコードを生成できるようにしています。

なぜSPFレコードのフラットニングだけでは不十分なのか?

従来のSPFフラットニング方法は、小規模から中規模の組織で単純なセットアップと少数のSPFメカニズムを持つ場合に効果的です。
しかし、メカニズムが増えると次のような不利な状況になる可能性があります。

SPFマクロ - より良いアプローチ

複雑なSPFセットアップを持つ企業を念頭に置いて構築されたSPFマクロは、小規模から中規模の組織にも同様に効果的です。
以下の方法で、従来のフラットニングアプローチと比較して、レコードをより効率的に最適化および管理できます。

SPFフラットニング VS SPFマクロ

初期のSPFレコード
(5回の参照)
SPFマクロ
(1回の参照)
SPFフラットニング
(2回の参照)
v=spf1 include:_spf.google.com include:zcsend.net -all v=spf1 exists:%{i}.abcde12345.macrospf.powerspf.com -all abcde12345.powerspf.com:

v=spf1 ip6:2c0f:fb50:4000::/36 ip6:2a00:1450:4000::/36 ip6:2800:3f0:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2404:6800:4000::/36 ip6:2001:4860:4000::/36 ip4:74.125.0.0/16 ip4:35.191.0.0/16 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:72.14.192.0/18 ip4:64.233.160.0/19 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ip4:172.217.192.0/19 ip4:172.217.128.0/19 ip4:172.217.0.0/19 ip4:108.177.96.0/19 ip4:66.249.80.0/20 ip4:66.102.0.0/20 ip4:172.253.112.0/20 ip4:172.217.32.0/20 include:_s1.abcde12345.powerspf.com -all

_s1.abcde12345.powerspf.com:
v=spf1 ip4:172.217.160.0/20 ip4:172.253.56.0/21 ip4:108.177.8.0/21 ip4:130.211.0.0/22 ip4:136.143.160.0/23 ip4:135.84.82.0/23 ip4:35.190.247.0/24 ip4:165.173.128.0/24 ip4:135.84.81.0/24 -all

今すぐ私たちのSPFソリューションをお試しください。
経験豊富なドメインおよびメールセキュリティ専門家による1対1のデモについて、お問い合わせください!