迷惑メール判定の回避で試行錯誤したお話 | Netassist Blog
技術部 takaraです。こんにちは。 メールサーバを構築し、いざ稼働テストを始めた際に、問題としてよく挙がるのは、各種メールサービス側での迷惑メール判定。 その回避方法について相談頂き、SPFレコードの設定、IPの逆引き設定、DKIM設定を段階的に実装し、配送テストを行いました。 SPFレコードの設定 test@example.comのメールは、どのサーバから出るのが正しい、といった体で、メール送信元の情報をDNSゾーンに設定します。 今回は255個のIPアドレスを含むネットワークアドレスをソフトフェイルで指定しました。 TXT "v=spf1 +ip4:xxx.xxx.xxx.0/24 ~all" このネットワークアドレスに含まれるIPアドレスからのメール送信については、Gmail側に配送される場合は、下記のSPFチェックをパスしたヘッダ情報が含まれます。 Received-SPF:
AmazonSESから携帯キャリアメールに届く確率を上げる
この記事は とあるサービスを運営しています そのサービスでは、（よくある動きですが）一度ユーザ仮登録メールを送ってリンクをクリックして本登録画面に遷移するような動きをします AmazonSESからこのメールを送信しているのですが、携帯キャリアのメールアドレス（特にdocomoとau）の大半が本登録リンクをクリックしていない事象が発生しました どうやらそもそもメールが到着していないようです この記事はこの問題へ対処するにあたり色々調べたのでそのメモです よくあるワークアラウンド エンジニアの守備範囲としては「mydomain.netからのメールが到着するように許可してください」という注意書きを入れてお茶を濁してもいいのですが、はっきり言ってそんな設定してくれる人は一握りなので、もっと効果的な対処をしたかったです 結論からいうと あまりに当たり前みたいな結論ですが、DNSに自サイトのドメインの
間違いから学ぶSPFレコードの正しい書き方 : 迷惑メール対策委員会
岡山大学 山井成良 2011年4月 1. はじめに 2. 典型的な誤りと正しい書き方 2.1 SPFレコードが複数行存在する 2.2 機構（メカニズム）の記述に誤りがある 2.3 参照方法に誤りがある 2.4 必要な空白文字がない 2.5 その他の間違い 3. チェック方法 1. はじめに 迷惑メールは、現在のところ、送信元アドレスが詐称された状態で送られるものが大多数を占めます。これにより、迷惑メールの送信源追跡を困難にしたり、フィッシング詐欺に利用されたりします。そこで、送信元アドレスの詐称を防止する送信ドメイン認証技術が開発されました。 現在までに実用化されている送信ドメイン認証技術はいくつか存在しますが、そのうち最も普及しているものがSPF（Sender Policy Framework）です。平成22年6月時点におけるjpドメインでの普及率はドメイン数ベースで約40パーセントであ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
void GraphicWizardsLair( void ); //
