Gmailエイリアス経由で送信されるときにDMARCが原因でメッセージが拒否されるのを防ぐにはどうすればよいですか？
多くの人が 'エイリアスとして別のメールアドレス' をGmailアカウントに追加します-ここではGoogle AppsではなくパブリックGmailについて話します （を使用すると、ドメインサーバーではなくGmailサーバーをSMTPとして使用できます「エイリアス」設定として扱う ' 。 DMARCは「なし」で問題を引き起こしませんが、DMARCのp = "reject"またはp = "quarantine"が原因で、「別のアドレス」を使用してGmailから送信されたメッセージは、Hotmail、Yahooなどのサーバーによって拒否されます。
拒否されたメッセージの例を次に示します。
Yahooによって拒否されました
Delivery to the following recipient failed permanently:
[email protected]
Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the server for
the recipient domain ymail.com by mta6.am0.yahoodns.net. [98.136.216.26].
The error that the other server returned was:
554 5.7.9 Message not accepted for policy reasons.
See http://postmaster.yahoo.com/errors/postmaster-28.html
Hotmailによって拒否されました
Delivery to the following recipient failed permanently:
[email protected]
Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the server for
the recipient domain msn.com by mx3.hotmail.com. [65.55.37.72].
The error that the other server returned was:
550 5.7.0 (COL0-MC1-F8) Unfortunately, messages from (209.85.216.195) on
behalf of (any-domain-com) could not be delivered due to domain owner
policy restrictions.
DMARCレコードの効率性はありますが、解決策ではない「既知のフォワーダー」としてこれらのサーバーをホワイトリストに登録するようレシーバーに要求することを除いて、回避策はまだありません！
DMARCの拒否と検疫のポリシーを使用して、Gmailでこのような機能を使い続ける別の方法を知っている人はいますか？
更新：
ドメインのSPFは、他のすべてを許可しないように設定されています。
ドメインSPFv = spf1 mx include：somehost.net -all（〜allまたはinclode：_spf.google.comを使用しても同じ）
somehost.net SPFip4：1.2.3.4 ip4：5.6.7.8 -all
ドメインのDMARCに「拒否」ポリシーが設定されるまで、ドメインとホストの両方のDKIMとSPFは、パスの結果とYahooおよびHotmailに到達するために使用されるメッセージを受信するために使用されました。
Gmailで「エイリアスとして扱う」を「ドメインSMTPサーバーを使用する」に変更すると、確実に正常に送信されます。
YahooカスタムFromアカウントでも同じことが起こります...他のプロバイダーがメッセージを返送します。
アップデート2
私はdmarc-discussでディスカッションを開き、「noway（それはdmarcの機能です）」と返信しました....ここを見てください。 .blackops.org/pipermail/dmarc-discuss/2013-March/001692.html ...非常に悪い:( ..その場合は使用しません
Dmarcレコードに記載されているポリシーを回避したいようです。ドメインを使用するすべてのメールが、ドメインの制御下にあるメールサーバーによって送信されるポリシーが最も効果的です。これは、銀行、航空会社、宅配便業者、政府、およびアドレスのなりすましを防ぐことが重要なその他の送信者に適用されます。
他のドメインを使用してGMailから送信する必要がある場合は、そのドメインでGoogleを有効なソースとして追加するか、「none」などの弱いポリシーとして使用する必要があります。保護されたドメインからメーリングリストに送信すると、同様の問題が発生する可能性があります。
編集：Reply-Toヘッダーは、メールが他の誰かに代わって送信された場合の処理に役立ちます。 Fromヘッダーには、実際の送信者が含まれている必要があります。 Reply-Toアドレスは、要求側のアドレスでなければなりません。 DMarcポリシーは実際の送信者に適用され、それらのスプーフィングポリシーに従います。私がチェックしたところ、GMailはヘッダーへの返信の使用を許可していません。 （あまりにも多くの自動送信者がこのアプローチを適用していません。）
GMailをSPFレコードに追加するには、リダイレクトに従ってトレイルを含めます。 IPv6のサポートには_netblocks.google.comが必要ですが、_netblocks2.google.comのみを含めることで問題が解決されると思います。あなたのポリシーは、含まれている?allポリシーを上書きすると思います。
メーリングリストに別のドメインまたはサブドメインを使用し、サードパーティの送信者もオプションです。このドメインに緩いポリシーを設定します。代わりにメールを送信する各組織に個別のサブドメインを提供することは、適切なポリシーオプションです。これにより、特定の組織に関連する問題をすばやく特定できます。
制御しているドメインをスプーフィングするスパムの嵐に対応して、SPFを実装しました。 1日以内に流量が大幅に減少し、1週間以内に量は最小限に抑えられました。最後に、残りのトラフィックは、収集されたアドレスに送信されたスパムでした。
DMarcをスパム削減ツールと考える人もいますが、これは実際にはスプーフィング防止ツールです。そのため、メーリングリストなどの一部のEdgeケースや、サードパーティのホストを使用してメールを送信する送信者を破壊する可能性があります。私の場合、ネットワークの外側からWebMail、IMap、およびメール送信への安全なアクセスを提供します。
なりすましの削減により、スパムの量が減少する可能性がありますが、これは送信者（スパムボット）が自分のふりをすることができないためです。現在、SPF HELOチェックは、google.comであると主張するスパムボットを寄せ付けていません。
Googleのメールサーバーがドメインの有効な送信者であることを示すには、 GoogleのSPFレコードを含める をドメインのSPFレコードに含める必要があります。
例えば：
v=spf1 a mx include=_spf.google.com -all