PostmarkのSPF・DKIM・DMARC設定。
Postmarkでは、アカウントレベルのSender Signatures → Domainsでドメインを認証します。技術的には「SPF include」があるサービスとしては珍しく、ルートドメインに共有のSPF行を貼り付けないよう、意図的に求めています。代わりに追加するのは、自社ドメイン上に置く2つのレコードです。Postmarkが割り当てるセレクターに置くDKIM鍵のTXTレコードと、カスタムReturn-PathのCNAMEレコード（pm-bounces.yourdomain.com → pm.mtasv.net）です。両方の確認が済むと、メールはPostmarkから自社ドメインとして送信され、DKIMの署名も自社のものとなり、SPFはアライメントの一致したReturn-Pathで成功するため、DMARCにも問題なく成功します。ルートドメインにinclude:spf.mtasv.netを公開する必要は一切ありません。
Postmarkを認証すべき理由
Postmarkは、パスワードリセット、領収書、注文確認、ワンタイムコードなどのトランザクションメールを主軸とするサービスです。受信トレイへの到達は見た目だけの問題ではなく、製品そのものを左右します。2024年2月以降、GmailとYahooは、すべての送信者に対し、SPF、DKIM、DMARCにアライメントが一致した状態で成功することを義務付けています（1日あたり約5,000通以上の大量送信者には厳格に適用）。Microsoftも2025年に、要件を満たさないメールの拒否を始めました。ドメインを確認せずにPostmarkで送信してもメールは配信されますが、Postmark自身のドメインでDKIM署名され、Return-Pathもpm.mtasv.net上になるため、DKIMもSPFもFromアドレスとアライメントが一致しません。DMARCがp=noneならこれでも許容されますが、自社（または親ドメインを共有する誰か）がp=quarantineやp=rejectに移行した途端、アライメントの一致しないPostmarkのメールは隔離またはバウンスされます。ドメインを確認すれば、2つのレコードで解決します。DKIMは自社ドメインとアライメントが一致し、カスタムReturn-PathによってSPFも一致し、DMARCにはその両方で成功します。積み上げた送信レピュテーションも、Postmarkの共有インフラではなく自社ドメインに蓄積されます。
PostmarkにおけるSPFの実情
Postmarkには共有のSPFのincludeがあり、ホストはinclude:spf.mtasv.netです（mtasvはPostmarkのメール転送インフラのドメインです）。ただしPostmarkは、ルートドメインへの追加を顧客に求めることを意図的にやめており、ほとんどの場合はそれが正しい選択です。理由は次のとおりです。SPFは、表示上のFromアドレスではなくReturn-Path（エンベロープのMAIL FROM）に対して検証されます。デフォルトでは、PostmarkのReturn-PathはPostmark自身のドメイン（pm.mtasv.net）上にあるためSPFはすでに成功しますが、それはPostmarkのドメインに対する成功です。Fromドメインとアライメントが一致しないので、DMARCの助けにはなりません。ルートドメインのSPFレコードにinclude:spf.mtasv.netを追加しても解決しません。Return-Pathに現れるのはルートドメインではないため、このincludeは何の効果もないままルックアップを1回消費するだけです。正しい方法はカスタムReturn-Pathです。pm-bounces.yourdomain.comに、pm.mtasv.netを指すCNAMEレコードを追加します。このサブドメインは、Postmark自身が公開するSPF（pm.mtasv.netがv=spf1 include:spf.mtasv.net -allを公開していることを実際のDNSルックアップで確認済み）とバウンス用のMXレコードを引き継ぎます。そのためSPFはそこで成功し、しかもReturn-Pathが組織ドメイン上になるので、DMARCのアライメントも一致します。結論として、共有のinclude（spf.mtasv.net）は存在しますが、現在推奨されるPostmarkの設定は、カスタムReturn-PathのCNAMEレコードとDKIM鍵のTXTレコードで、ルートドメインのSPFレコードには何も追加しません。includeを検討する価値があるのは、ルートドメインからPostmark経由で送信し、そこで明示的に許可したいという稀なケースだけです。その場合でも、Postmarkは必須ではないとしています。
2つの設定方法
カスタムReturn-PathのCNAME + DKIM（推奨）
- DKIM鍵のTXTレコードと、pm-bouncesのCNAME → pm.mtasv.netを追加します。ルートドメインのSPFレコードには何も追加しません
- Return-Pathが自社ドメイン上になるので、SPFは成功するうえアライメントも一致します。そのためDMARCには、SPFとDKIMの両方で成功します
- ルートドメインのSPFレコードにDNSルックアップを追加しません。まとめるものが何もないためです
- これはPostmarkのダッシュボードが促す手順そのものであり、サポートされている方法です
ルートドメインのSPFレコードにinclude:spf.mtasv.netを追加（不要）
- v=spf1 a mx include:spf.mtasv.net ~allをルートドメインに自分で貼り付けることになります
- Postmarkは、これは必須ではないと明言しており、アライメントにも何の効果もありません
- ルートドメインはPostmarkが使うReturn-Pathではないため、ルートドメインに置いてもDMARCの助けになりません
- 意味があるとすれば、ルートドメインからPostmark経由で送信する場合だけです。それ以外では、ルックアップを1回消費するだけで得るものがありません
設定手順
- 1
Sender Signatures → Domainsを開く
account.postmarkapp.comにログインし、アカウントメニューからSender Signaturesを開いて、Domainsタブに切り替えます。確認済みの送信者1人だけでなくドメイン全体を確認することで、そのドメインのすべてのアドレスでSPF/DKIMのアライメントが一致します。
- 2
ドメインを追加
Add Domainをクリックし、yourdomain.comを入力します。Postmarkがレコードのセットを作成してドメインのDNS Settingsページを開きます。そこに、DKIMとReturn-Pathの行が確認待ちとして表示されます。
- 3
DKIMレコードをコピー
DNS Settingsページで、DKIMの行を確認します。TXTレコードで、HostnameはPostmarkが割り当てたpm._domainkeyで終わるセレクター（例：20260727pm._domainkey）、Valueは長いv=DKIM1; k=rsa; p=…の鍵です。セレクターと鍵はドメインごとに固有です。
- 4
Return-Pathのレコードをコピー
Return-Pathセクションで、CNAMEレコードを確認します。Hostnameのデフォルトはpm-bounces（つまりpm-bounces.yourdomain.com）で、Valueはpm.mtasv.netです。これが、SPFのアライメントを自社ドメインと一致させるレコードです。pm-bouncesのラベルは変更できますが、pm.mtasv.netへのCNAMEのままにする必要があります。
- 5
DKIMのTXTレコードを追加
DNSホストでTXTレコードを作成します。ホストはPostmarkに表示されるセレクター（例：20260727pm._domainkey）、値はv=DKIM1;…の文字列全体で、正確に貼り付けます。Postmarkが発行するのは2048ビットの鍵なので値が長くなります。管理画面に1文字列あたり255文字の制限がある場合は、分割に関する注意点を参照してください。
- 6
Return-PathのCNAMEレコードを追加
CNAMEレコードを作成します。ホストはpm-bounces、値はpm.mtasv.netです。pm-bouncesサブドメインには、TXTレコードやAレコードなど他のレコードを追加しないでください。同じ名前にCNAMEと他のレコードタイプを共存させることはできません。
- 7
ルートドメインのSPFレコードはそのままにする
ルートドメインのSPFレコードにinclude:spf.mtasv.netを追加しないでください。必須ではなく、アライメントにも効果がありません。他の送信者（Google Workspace、Microsoft 365など）のためにルートドメインのSPFレコードがすでにあれば、そのまま維持します。pm-bouncesのCNAMEレコードが、そのサブドメインでPostmarkのSPFをまかないます。
- 8
DMARCレコードを公開（既存なら1つのまま）
DMARCレコードがまだない場合は、_dmarcにv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comを指定したTXTレコードを追加します。すでにある場合はそのままにします。_dmarcレコードはドメイン全体で常に1つだけです。
- 9
PostmarkでVerifyをクリック
ドメインのDNS Settingsページに戻り、DKIMとReturn-Pathの横にあるVerifyをクリックします。DNSの反映は通常数分ですが、最大24～48時間かかることがあります。解決されると両方の行が緑になります。
- 10
実際にテストメールを送信してShow originalを確認
確認が済んだら、自社ドメインのアドレスからPostmark経由でテストメールを送り、Gmailで開いて⋮ → Show originalを選びます。SPF: PASSとDKIM: PASSがどちらもmtasv.netではなくyourdomain.comを示し、さらにDMARC: PASSと表示されていれば成功です。
追加するレコード
正確な値はPostmarkのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。
| タイプ | ホスト | 値 |
|---|---|---|
| TXT | 20260727pm._domainkey | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC…DKIM鍵です。セレクター（YYYYMMDDpm._domainkeyのラベル）と鍵はドメインごとに固有です。正確な値はPostmarkのDNS Settingsページからコピーしてください。2048ビットのため、引用符付きの文字列に分割が必要な場合があります。 |
| CNAME | pm-bounces | pm.mtasv.netカスタムReturn-Pathです。これによってSPFが成功し、DMARCのアライメントも一致します。PostmarkのSPF（実際のDNSルックアップで確認済み：pm.mtasv.netはv=spf1 include:spf.mtasv.net -allを公開）とバウンス用のMXレコードをpm.mtasv.netから引き継ぎます。このサブドメインにはCNAMEレコードだけを置いてください。 |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comDMARCポリシーです。ドメインごとに1つで、Postmarkとは別のレコードです。監視のためp=noneから始めます。 |
| TXT | @ | v=spf1 a mx include:spf.mtasv.net ~all必須ではなく、推奨もされません。追加しないでください。Postmarkはこれを求めなくなっており、ルートドメインに置いてもReturn-Pathのアライメントには効果がありません。すでに設定されている場合に、従来方式のincludeだと見分けられるよう掲載しているだけです。 |
ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。
DNSルックアップの10回制限
SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。Postmarkの設定がこの上限のうち何回を消費するかは、次のとおりです。
Postmarkの推奨設定はルックアップを消費しません。10回すべてを、includeが必要な他の送信元に使えます。
DKIM
PostmarkのDKIMは自分で公開するTXTレコードで、SendGridやMailchimpのようなCNAMEによる委任ではありません。Postmarkは、pm._domainkeyで終わる日付ベースのセレクター（例：20260727pm._domainkey）を割り当て、2048ビットのRSA鍵を生成します。そのHostnameでTXTレコードを作成し、DNS Settingsページに表示されるv=DKIM1; k=rsa; p=…の値全体を正確に貼り付けてください。公開鍵を保持するTXTレコードなので（秘密鍵はPostmarkが保持）、CNAMEで委任するサービスのようにPostmarkが自動でローテーションすることはできません。代わりに、手動のRotate DKIM Key操作が用意されています。新しいセレクターで新しい鍵を生成し、公開すべき保留中のレコードを表示します。新しいTXTの確認が済むとPostmarkが署名を切り替え、古いレコードは削除できます。定期的なローテーション（年に2回程度が妥当な頻度です）は良い習慣です。重要なのは、確認済みのDKIM鍵だけでPostmarkのメールはDMARCに成功できるという点です。DKIMのアライメントが自社ドメインと一致するためで、カスタムReturn-Pathはそれに加えてSPFのアライメントをもたらします。
DMARC
DMARCは、ルートドメインに設定する別のポリシーレコードです。Postmarkのレコードの1つではありません。送信者がいくつあっても、_dmarcのTXTレコードはドメイン全体で1つだけにします。_dmarc.yourdomain.comに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comで始まるレコードを公開します。p=noneは監視のみのため、Postmarkのメールが認証に成功することを確認している間、配信には影響しません。1～2週間、集計レポート（rua）を確認します。DKIMの確認が済んでいれば、Postmarkが、DKIMのアライメントが一致した成功している送信元として表示されます。pm-bouncesのカスタムReturn-Pathを設定すると、SPFのアライメントも一致と表示されます。Postmarkと他のすべての正規の送信者が、アライメントが一致した状態で成功するようになってから、p=quarantine、最終的にp=rejectへと段階的に引き上げます。Postmark自身も指摘している点に注意してください。ドメインがp=quarantine/rejectなのにカスタムReturn-Pathを省略すると、SPFのアライメントは一致しません。その場合はDKIMのアライメントだけに頼ることになり、機能はするもののSPFという予備がなくなるので、pm-bouncesのCNAMEレコードを追加してください。
正しく設定できたか確認する
緑の「Verified」バッジだけで判断せず、実際のメールで確認してください。自社ドメインのアドレスからPostmark経由で自分宛てにテストメールを送り、Gmailで開いて⋮ → Show originalを選びます。SPF: PASSとDKIM: PASSがどちらもmtasv.netではなくyourdomain.comを示し、さらにDMARC: PASSと表示されていれば成功です。Return-Path/mailed-byの行も確認してください。pm-bounces.yourdomain.comと表示されていれば、カスタムReturn-Pathが機能している証拠です。レポート形式で確認したい場合は、Qualisendのドメイン診断でドメインをチェックし、DKIMのTXTレコードとpm-bouncesのCNAMEレコードが解決されることを確認します。レコードをすばやく確認するには送信ドメイン認証チェックを使います。DMARCの集計レポートが届き始めたら、DMARCレポート解析にレポートをドロップします。Postmarkが、アライメントの一致した成功している送信元として表示されるはずです。
よくある注意点
- 認証失敗の原因
ルートドメインのSPFレコードにinclude:spf.mtasv.netを追加しないでください。Postmarkは意図的にこれを求めなくなりました。ルートドメインはPostmarkが使うReturn-Pathではないため、アライメントには効果がありません。代わりに、カスタムReturn-Pathとしてpm-bouncesのCNAMEレコードを追加します。
- 適用範囲
includeのホストはspf.mtasv.netで、postmarkapp.comではありません。MTASVはPostmarkのメール転送インフラのドメインで、Return-Pathの宛先（pm.mtasv.net）とバウンス用のMXレコードもそこにあります。
- DNS設定
pm-bouncesサブドメインはCNAMEのみにしてください。DNSでは、同じ名前にCNAMEと他のレコードタイプを共存させられないため、pm-bounces.yourdomain.comにTXTレコードやAレコードを追加しないでください。追加すると確認に失敗します。
- DNS設定
2048ビットのDKIM鍵の値は長くなります。DNS管理画面によってはTXTレコードの文字列が255文字までに制限され、鍵を引用符付きの複数の文字列に分割する必要があります。文字を削らずに分割し、p=の値の中に余分なスペースを入れないでください。
- DNS設定
Cloudflareでは、pm-bouncesのCNAMEレコードを「DNS only」（グレーのクラウド）に設定してください。オレンジのクラウドでプロキシが有効なレコードはpm.mtasv.netに解決されず、Return-Pathの確認に失敗します。
- DNS設定
ホスト欄のドメイン重複：多くのレジストラはドメインを自動で付加するため、20260727pm._domainkey.yourdomain.comと入力すると…yourdomain.com.yourdomain.comになります。管理画面がドメインを付加する場合は、ラベル（セレクターまたはpm-bounces）だけを入力してください。
- 適用範囲
確認済みのSender Signature 1つはドメイン認証ではありません。Fromアドレスを1つ確認するだけで、ドメイン全体でDKIM/SPFのアライメントが得られるわけではありません。Domainsタブでドメイン全体（DKIM + Return-Path）を確認してください。
- 認証失敗の原因
ルートドメインには、SPFのTXTレコードと_dmarcのTXTレコードを1つずつだけ置いてください。他のサービスからも送信している場合は、そのメカニズムを1つのv=spf1レコードにまとめます。SPFレコードが2つあると、それ自体がPermErrorになります。
SPFレコードを作成
Postmarkでは、ルートドメインにSPFのinclude:を追加する必要はありません。作成ツールを使って他の送信元用のクリーンなレコードを1つ組み立て、1行に収めてください。
送信元
メールの送信に使っているサービスを検索して、それぞれチェックを入れてください。
上の検索欄で利用中のメールサービスを検索するか、してください。
このドメイン自身のサーバー
ドメインが（上記のサービスを経由せず）直接メールを送信する場合は、ドメイン自体を許可します。
その他の送信元・IP
リストにないもの（別のサービスのSPFホストや特定のIPアドレス）を追加します。
接頭辞のinclude:は自動で付加されます。サービスのドキュメントに記載されているホスト名を入力してください。
その他すべての送信元へのポリシー
上記に記載されていないサーバーからのメールを、受信側がどう処理すべきかを指定します（allメカニズム）。
送信元がまだないため、すべてのメッセージに~allポリシーが適用されます。ステップ1で利用中のサービスを追加してください。
- ルートドメインにTXTレコードとして公開します。ホストは@（ドメインそのもの）、値は上記の文字列全体です。
- SPFレコードは1つのドメインにつき1つだけにします。すべての送信元をこの1行にまとめてください。v=spf1で始まるTXTレコードが2つあると、両方とも無効になります。
- DNSルックアップは10回以内に収めてください。include:、a、mxはそれぞれ1回とカウントされ、includeは内部でさらにルックアップを発生させることがあります。ip4:とip6:はカウントされません。
送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。
リストを検証PostmarkのSPFに関するよくある質問
関連記事
トランザクションメール・APIの他のサービス
すべてのSPFガイド公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。
認証の次は、リストをクリーンに保つ
SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。