SPF／DMARC ジェネレーター

いいえ。ブラウザ内でレコードの「テキスト」を組み立て・チェックするだけで DNS には問い合わせないため、レコードが公開・反映されたことは証明できません。公開後は DNS 照会ツールで確認し、実際のテストメールで認証結果を確かめてください。

RFC 7208 では、SPF の評価で DNS 参照を起こす項目（include・a・mx・ptr・exists・redirect）は最大 10 個までで、include の内側にある項目も数えます。ip4・ip6・all は数えません。上限を超えると受信側は permerror を返し、SPF は失敗扱いになります。

内蔵の主要な送信サービスについては、2026-10-20 に公開 DNS で実測した内側の参照回数を使っています。ご自身で入力した include は内側の回数が不明なため、1 回として数え、注意書きを表示します。事業者はいつでもレコードを変更できるので、公開前に DNS ベースの SPF チェッカーでもう一度確認してください。

~all（ソフトフェイル）は「記載のない送信元はおそらく未承認だが、受け入れて印を付ける」という意味で、すべての送信元を確認し終える前の段階に向いています。-all（ハードフェイル）は明確な拒否です。Google の案内は ~all を推奨し、Microsoft は DKIM と DMARC も設定したうえでの -all を推奨しています。どちらでも +all は使わないでください。誰でもあなたのドメインでなりすませてしまいます。

RFC 9989（DMARCbis）が定義するタグは v・p・sp・np・adkim・aspf・fo・rua・ruf・psd・t です。RFC 7489 の pct・rf・ri は削除され、よくある用途は t（テストフラグ。t=y は従来の pct=0 にほぼ相当）に置き換わりました。このツールは既定で pct を出力せず、「詳細・互換オプション」で明示的にオンにしたときだけ追加します。

まず p=none と rua を設定し、集計レポートを 1 か月以上集めて正規の送信元をすべて洗い出します。各送信元の SPF または DKIM を From ドメインとアラインさせ、次に p=quarantine へ上げてさらに様子を見ます（不安なら先に t=y で試せます）。正規メールに影響がないと確認できてから p=reject にします。p=reject はメーリングリストや転送に影響することがあるため、事前にレポートを確認してください。