![554 5.7.5 permanent error evaluating DMARC policy [解決済み]](./images/554_5.7.5_Permanent_Error_Evaluating_DMARC_Policy.svg)
554 5.7.5 permanent error evaluating DMARC policy [解決済み]
2025年1月11日
著者: Yunes Tarada
翻訳: 竹洞 陽一郎
この記事はPowerDMARCのブログ記事 554 5.7.5 Permanent Error Evaluating DMARC Policy [SOLVED] の翻訳です。
Spelldataは、PowerDMARCの日本代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。
「554 5.7.5 Permanent Error Evaluating DMARC Policy」は、メール認証の失敗を示しており、誤ったDMARCレコードの設定によりメールの配信が妨げられています。
重要なポイント
- SPF、DKIM、または DMARCレコードの文法が誤っていると、「554 5.7.5 Permanent Error Evaluating DMARC Policy」が発生する可能性があります。
- このエラーは、SMTP ポートをブロックすることでメールの配信を妨げ、通信に支障をきたします。
- SPFレコードは -all または ~all で終わるように設定し、中立的なポリシーを回避しつつ、DNS ルックアップの制限に準拠する必要があります。
- DKIM署名の d= タグが送信ドメインと一致していることを確認し、DMARC検証の失敗を防ぎましょう。
- DMARCを一時的に p=none に設定することで、厳格なポリシーを適用する前にメールの流れを監視できます。
ドメイン所有者は、以下の理由により「554 5.7.5 Permanent Error Evaluating DMARC Policy」エラーに遭遇する可能性があります。
- SPF、DKIM、またはDMARCレコードの文法ミス
- DNSレコード内の不要な文字や欠落
- SPFに適合したメールの未対応
- DKIM署名ドメインの不一致
「554 5.7.5 Permanent Error Evaluating DMARC Policy」は、SMTPポートがドメインからのメールを受け付けない原因となる一般的なエラーです。
この問題は通常、SPFレコード、DMARCレコード、またはメールサービスの設定が組み合わさることで発生します。
このガイドでは、この問題を迅速かつ簡単に解決する方法を説明します。
なぜ「554 5.7.5 Permanent Error Evaluating DMARC Policy」エラーが発生するのか？
「554 5.7.5 Permanent Error Evaluating DMARC Policy」エラーが発生する主な原因は以下の通りです。
1. DMARCレコードの設定が不完全または誤っている
不完全なDMARCレコードは、DMARCポリシーの評価エラーを引き起こす可能性があります。
例えば、p=タグが欠落している場合です。
v=DMARC1; pct=100;
これはp=（ポリシータグ）が欠落しているため、不完全なレコードとなります。
DMARC設定では、p=none、p=quarantine、またはp=rejectのいずれかを必ず指定する必要があります。
また、構文エラー（余分な文字やスペースなど）も、このエラーを引き起こします。
v=DMARC1; p:none; pct=100; rua:mailto:reporting@example.com;
この場合、rua: の「:」は誤りです。
正しくは=記号を使用する必要があります。
正しいDMARCレコードの構成
- v=DMARC1 で始める
- p=none/reject/quarantine のポリシータグを必ず含める
- すべてのDMARCタグは=値の形式で記述し、セミコロン（;）で終える
- タグやメカニズム間には1つのスペースのみ入れる
- 各メカニズム内にはスペースを入れない（例：p=none;）
2. DKIMアライメントの誤り
DKIM（DomainKeys Identified Mail）は、メール送信者の真正性を検証するための技術であり、不正な第三者が送信者のドメイン名をなりすますことを防ぎます。
DKIM 認証に問題が発生することがあります。
特に、DKIM 署名の d= タグと送信ドメインが一致しない場合、DMARC の評価に失敗します。
例えば、ドメイン名を変更したにもかかわらず、DKIM レコードを更新していない場合、DMARC ポリシーの評価に失敗します。
3. SPFレコードの誤り
PF（Sender Policy Framework）は、メールが正規の送信サーバから送信されたかどうかを検証するためのメール認証技術です。
DMARC は、SPF レコードをチェックし、その有効性を確認することで機能します。
このエラーを回避するために、SPF レコードが正しく設定され、ドメイン名と適切に連携していることを確認する必要があります。
SPF 設定に関して避けるべきポイントは以下の通りです。
- SPF レコードは -all または ~all で終わるようにする
- SPF 評価において中立ポリシーを使用しない
- SPF の DNS ルックアップ制限を超えないようにする
4. メールサービスプロバイダ（ESP）の SPF アライメント非対応
「554 5.7.5 Permanent Error Evaluating DMARC Policy」エラーが発生する原因は、メールサービスプロバイダ（ESP）側にある場合もあります。
すべてのメールサービスプロバイダが SPF に適合したメールをサポートしているわけではありません。
一部のプロバイダは SPF ポリシーを内部的に処理しており、ドメインで SPF を有効にしているとエラーが発生する可能性があります。
「554 5.7.5 Permanent Error Evaluating DMARC Policy」エラーを修正する 5 つのステップ
以下の手順に従うことで、「554 5.7.5 Permanent Error Evaluating DMARC Policy」エラーを解決できる可能性があります。
ただし、必ずしも解決が保証されるわけではありません。
もし、これらの手順を試してもエラーが解決しない場合は、無料のドメインセキュリティ評価をご利用ください。
1. 余分な文字を削除する
「5.7.5 Permanent Error Evaluating DMARC Policy」エラーは、さまざまな要因によって発生しますが、主な原因として以下が挙げられます。
- 不適切な引用符の使用
- レコード内の不要な文字や記号
- レコードの最後にセミコロン（;）が欠落している
このエラーを引き起こした DMARC レコードの例を見ましょう。
v=DMARC1; p=none; rua=mailto:Demarc@onmicrosoft.com; ruf=mailto:Demarc_forensic@onmicrosoft.com; fo=1:d:s.
このレコードは一見正しく見えますが、テストを行ったところ、「5.7.5 Permanent Error Evaluating DMARC Policy」エラーが発生しました。
再確認すると、レコードの末尾に不要なピリオド（.）があることが判明しました。
このピリオドを削除し、再度テストを行ったところ、正常に動作しました。
修正後の正しい DMARC レコードは、以下の通りです。
v=DMARC1; p=none; rua=mailto:Demarc@onmicrosoft.com; ruf=mailto:Demarc_forensic@onmicrosoft.com; fo=1:d:s
2. SPF レコードの「Neutral（？all）」を変更する
「5.7.5 Permanent Error Evaluating DMARC Policy」エラーが発生する場合、SPF レコードが Neutral（？all） に設定されている可能性があります。
SPF（Sender Policy Framework） は、メールが正規のサーバから送信されたことを検証するための仕組みです。
単にメールを送信できるサーバがあるだけでは不十分で、そのサーバが正規のものであることを証明する必要があります。
SPF は、この認証を行うための技術です。
なぜ SPF レコードを「Neutral」のままにしてはいけないのか？
「Neutral」の SPF 設定では、どのサーバから送信されたメールもブロックされません。
そのため、詐欺師があなたのドメインを使って偽のメールを送信することが可能になります。
受信者はそれを本物と信じ、危険なリンクをクリックしたり、不正なファイルをダウンロードしたりするリスクがあります。
そのため、DMARC を導入する際には、少なくとも SPF レコードを SoftFail（~all） または HardFail（-all） に変更するべきです。
これにより、あなたのドメインから送信されたメールが安全である可能性が高いことを受信者に示すことができます。
3. メールサービスプロバイダが SPF アライメント対応か確認する
このエラーを受け取る最も一般的な理由の一つは、あなたのメールサービスプロバイダが SPF アライメント対応のメールをサポートしていないことです。
MailChimp や ProtonMail のようなメールプロバイダは独自の SPF レコードを持っており、それらを通じてメールを送信すると、SPF アライメント対応のメールを送信していません。
したがって、あなたのメールサービスプロバイダの SPF 処理タイプを確認し、それが SPF アライメント対応のメールをサポートしているかどうかを確認することが重要です。
もしサポートしている場合、送信プロセス中に DKIM 署名が変更され、From アドレスが MailChimp のドメインではなく、あなた自身のドメインに一致するようになり、DMARC ポリシー評価に合格することを保証します。
もしサポートしていない場合、SPF アライメント対応のメールを送信できるように、異なるメールサービスプロバイダを使用するか、現在のプロバイダの設定を変更する必要があります。
4. DMARC のポリシーを p=none に変更する
「554 5.7.5 Permanent Error Evaluating DMARC Policy」エラーが発生している場合、それはドメインのDMARCポリシーがメール送信を妨げていることを意味します。
この問題を解決するには、DNS プロバイダで DMARC レコードを変更し、p=none ポリシーを設定する必要があります。
DMARC ポリシーは、SPF と DKIM のチェックに失敗したメールを拒否（reject）するか、隔離（quarantine）するかを、メールプロバイダに指示するものです。
もし、これらのチェックに失敗してもメールを送信できるようにしたい場合は、一時的にポリシーを p=none に設定することで制限を緩和できます。
DMARCのp=none は 「緩和された（no-action）または監視専用のポリシー」 と呼ばれます。
そのため、メールのなりすまし（スプーフィング）対策としては推奨されませんが、DMARC エラーの影響を受けずにメールを送信できるようになります。
例えば、以下のレコードを
_dmarc.yourdomain.com TXT v=DMARC1; p=reject; rua=mailto:reporting@example.com;
このように変更します。
_dmarc.yourdomain.com TXT v=DMARC1; p=none; rua=mailto:reporting@example.com;
これは何を意味するのでしょうか？
DMARCに合格しなくても、メールを送信できるようになります。
しかし、最終的にはドメインのメールなりすまし（スプーフィング）を防ぐために、p=reject または p=quarantine ポリシーに戻すことが望ましいです。
5. DomainKeys Identified Mail（DKIM）認証を設定する
「554 5.7.5 Permanent Error Evaluating DMARC Policy」エラーが発生する場合、ドメインに DKIM（DomainKeys Identified Mail）メール認証が設定されていない可能性があります。
そのため、DMARC に合格するには、DKIM 認証レコードを設定する必要があります。
（SPF が設定されていない場合は特に重要）
DKIM 設定手順は以下の通りです。
- PowerDMARC にサインアップし、Power Toolbox から DKIM レコードジェネレーターを選択
- ドメイン名を入力し、レコード用のセレクタ（例：selector1）を指定し、「Generate」ボタンを押す
- ツールが DKIM の公開鍵と秘密鍵のペアを自動生成
- 生成された TXT レコード名と TXT レコード値（公開鍵の値）をコピーし、DNS 管理コンソールにアクセスして DNS に公開
DMARC ポリシーのフォーマット要件
DMARC はメール認証プロトコルであり、受信者が 送信元のドメインを偽装したメールが本当にそのドメインから送信されたものかどうかを検証することを可能にします。
このガイドでは、DMARC を初めて設定する際に重要なフォーマット要件を説明します。
1. DMARC レコードは「v=DMARC1」で始める必要がある
DMARC レコードの最初の部分は 「v=DMARC1」 である必要があります。
これにより、メールプロバイダは 現在使用されている DMARC のバージョン（1）に従ってレコードがフォーマットされていることを認識できます。
2. ポリシー（p=）を指定する
DMARC ポリシー（p=）は 「p=none」「p=quarantine」「p=reject」 のいずれかで指定する必要があります。
これは メールが認証チェックに失敗した場合に、メールプロバイダがどのように処理するか を決定します。
DMARC レコードのポリシーフィールドは、v= バージョンフィールドの後に必須のフィールドです。
ポリシーには、p=none、p=quarantine、p=reject、3つのいずれかを指定できます。
- p=none は、メールプロバイダに対し、ドメインからの疑わしいメールを発見しても何もしないよう指示するものです。
そのまま放置され、場合によっては配信されることもあります。 - p=quarantine は、ドメインからの疑わしいメールをスパムまたは迷惑メールフォルダに振り分け、通常の受信トレイには配信しないようにする設定です。
- p=reject は、ドメインからの疑わしいメールを拒否し、一切配信しないようにする設定です。
3. 値の区切りには「コロン（:）」を使用する
値を区切る際には、コロン（:）を使用し、セミコロン（;）は避けるのが推奨されます。
特に、1行内で複数の値を指定する場合、セミコロンを使うと問題が発生する可能性があります。
4. 余分な文字や不適切な引用符を使わない
行末の余分な空白は、レコードの一部として処理され、エラーの原因になることがあります。
不要な特殊文字や間違った引用符 を使用しないように注意してください。
v=DMARC1; p=reject; rua=mailto:55ysaox6s3@rua.powerdmarc.com,mailto:reporting@example.com; ruf=mailto:55ysaox6s3@ruf.powerdmarc.com; pct=100;このレコードでは、 v=DMARC1 でバージョンを指定 p=reject で認証に失敗したメールを拒否する設定 rua= で DMARC レポートの送信先を指定（集計レポート） ruf= でフォレンジックレポート（詳細レポート）の送信先を指定 pct=100 ですべてのメール（100%）に DMARC を適用 これらの要件を守ることで、DMARC 設定の誤りを防ぎ、スムーズに運用することができます。