レンタルサーバー上で作成したWordPressからのメールについて調べました。
また、SPFの設定のためにDNSレコードを追加しました。
WordPressからのメールの差出人
ファイアバードのレンタルサーバーでWordPressを簡単インストールしました。WordPressのサイトから、コメントの承認通知やユーザー追加によって送信されるメールの差出人のアドレスのデフォルトは次のようになっています。
送信者名：WordPress
送信メールアドレス：wordpress@サイトURL
このアドレスはダミーなので送信しても届きません。宛先不明エラーで戻ってきます。
リターンパスのアドレス
受信メールの「メッセージのソースを表示」で確認するとリターンパスのアドレスは、「firebirdのID＋サーバー名」になっていました。
SPFはpassになっていました。Gmailの受信サーバーが、「このメールのリターンパスはsv1.firebird.neowl.jpになっているけど、確かにそのサーバーから送られてきたメールだよ。保証するよ。」っていう意味だと思います。たぶん。
このReturn-Pathのアドレスもダミーなので、送信しても宛先不明エラーで戻ってきます。
フックによって差出人をカスタマイズ
ワードプレスから送信されるメールのFrom（差出人）を次のようにカスタマイズが可能です。
こんにちは。スタッフのユースケです。 今日はWordPressのメールに関するお話しです。 WordPressで新規ユーザー登録をしたときなどに送られてくるメール、 デフォルトのままだと差出人が「WordPress」となっていてどこからのメ
レンタルサーバー上でメールアカウントを作成してみた
WordPressとは別の件ですが、レンタルサーバーで作成したメールアカウントで送信するときのReturn-Pathがどうなるのか気になったので、メールアドレスを作成してみました。
ネットオウルのサーバー管理ツールを開きます。
メールアドレス設定から対象のドメインを選択します。
「メールアドレス追加」からアドレス情報を入力して「確認画面」をクリックします。
内容を確認して「確定する」をクリックします。
WebMailにログインしてテストメールをgmailに送信しました。
受信したメールのソースはreturn-pathが作成したアドレスになっていましたが、SPFがneutralです。
SPFレコードを追加する
DNSにSPFレコードを追加しました。
ネットオウルの「スタードメイン管理」から対象のドメインのドメイン管理ツールをクリックします。
ここで追加しようとしたら、スタードメインのネームサーバーではなくて、ファイアバードのネームサーバーが設定されていました。ファイアーバードのネームサーバー（DNS）の設定画面では、レコードを編集するところがありませんでした。よって、スタードメインのDNSに切り替えます。さきに、スタードメインのDNSレコードを編集後、ネームサーバーをスタードメインに変更する必要があります。
現在のネームサーバーの値を確認します。ファイアーバードのネームサーバーを利用しています。
| Category | Status | Test name | Informationsend feedback |
|---|---|---|---|
| Parent |  |
Domain NS records | Nameserver records returned by the parent servers are:
ns1.firebird.jp. [‘112.78.117.92’] (NO GLUE) [TTL=172800] a.gtld-servers.net was kind enough to give us that information. |
 |
TLD Parent Check | Good. a.gtld-servers.net, the parent server I interrogated, has information for your TLD. This is a good thing as there are some other domain extensions like “co.us” for example that are missing a direct check. | |
|
Your nameservers are listed | Good. The parent server a.gtld-servers.net has your nameservers listed. This is a must if you want to be found as anyone that does not know your DNS servers will first ask the parent nameservers. | |
|
DNS Parent sent Glue | The parent nameserver a.gtld-servers.net is not sending out GLUE for every nameservers listed, meaning he is sending out your nameservers host names without sending the A records of those nameservers. It’s ok but you have to know that this will require an extra A lookup that can delay a little the connections to your site. This happens a lot if you have nameservers on different TLD (domain.com for example with nameserver ns.domain.org.) | |
|
Nameservers A records | Good. Every nameserver listed has A records. This is a must if you want to be found. | |
| NS | |
NS records from your nameservers | NS records got from your nameservers listed at the parent NS are:
ns2.firebird.jp [‘112.78.117.93’] [TTL=3600] |
|
Recursive Queries | Good. Your nameservers (the ones reported by the parent server) do not report that they allow recursive queries for anyone. | |
|
Same Glue | The A records (the GLUE) got from the parent zone check are the same as the ones got from your nameservers. You have to make sure your parent server has the same NS records for your zone as you do according to the RFC. This tests only nameservers that are common at the parent and at your nameservers. If there are any missing or stealth nameservers you should see them below! | |
|
Glue for NS records | OK. When I asked your nameservers for your NS records they also returned the A records for the NS records. This is a good thing as it will spare an extra A lookup needed to find those A records. | |
|
Mismatched NS records | OK. The NS records at all your nameservers are identical. | |
|
DNS servers responded | Good. All nameservers listed at the parent server responded. | |
|
Name of nameservers are valid | OK. All of the NS records that your nameservers report seem valid. | |
|
Multiple Nameservers | Good. You have multiple nameservers. According to RFC2182 section 5 you must have at least 3 nameservers, and no more than 7. Having 2 nameservers is also ok by me. | |
|
Nameservers are lame | OK. All the nameservers listed at the parent servers answer authoritatively for your domain. | |
|
Missing nameservers reported by parent | OK. All NS records are the same at the parent and at your nameservers. | |
|
Missing nameservers reported by your nameservers | OK. All nameservers returned by the parent server a.gtld-servers.net are the same as the ones reported by your nameservers. | |
|
Domain CNAMEs | OK. RFC1912 2.4 and RFC2181 10.3 state that there should be no CNAMEs if an NS (or any other) record is present. | |
|
NSs CNAME check | OK. RFC1912 2.4 and RFC2181 10.3 state that there should be no CNAMEs if an NS (or any other) record is present. | |
|
Different subnets | OK. Looks like you have nameservers on different subnets! | |
|
IPs of nameservers are public | Ok. Looks like the IP addresses of your nameservers are public. This is a good thing because it will prevent DNS delays and other problems like | |
|
DNS servers allow TCP connection | OK. Seems all your DNS servers allow TCP connections. This is a good thing and useful even if UDP connections are used by default. | |
|
Different autonomous systems | OK. It seems you are safe from a single point of failure. You must be careful about this and try to have nameservers on different locations as it can prevent a lot of problems if one nameserver goes down. | |
|
Stealth NS records sent | Ok. No stealth ns records are sent | |
| SOA | |
SOA record | The SOA record is: Primary nameserver: ns1.firebird.jp Hostmaster E-mail address: root.sv0.firebird.jp Serial #: 0 Refresh: 10800 Retry: 3600 Expire: 604800 1 weeks Default TTL: 3600 |
|
NSs have same SOA serial | OK. All your nameservers agree that your SOA serial number is 0. | |
|
SOA MNAME entry | OK. ns1.firebird.jp That server is listed at the parent servers. | |
 |
SOA Serial | Your SOA serial number is: 0. This can be ok if you know what you are doing. | |
|
SOA REFRESH | OK. Your SOA REFRESH interval is: 10800. That is OK | |
|
SOA RETRY | Your SOA RETRY value is: 3600. Looks ok | |
|
SOA EXPIRE | Your SOA EXPIRE number is: 604800.Looks ok | |
|
SOA MINIMUM TTL | Your SOA MINIMUM TTL is: 3600. This value was used to serve as a default TTL for records without a given TTL value and now is used for negative caching (indicates how long a resolver may cache the negative answer). RFC2308 recommends a value of 1-3 hours. Your value of 3600 is OK. | |
| MX | |
MX Records | Your MX records that were reported by your nameservers are:
0 memordm.com 112.78.117.102 [These are all the MX records that I found. If there are some non common MX records at your nameservers you should see them below. ] |
|
Different MX records at nameservers | Good. Looks like all your nameservers have the same set of MX records. This tests to see if there are any MX records not reported by all your nameservers and also MX records that have the same hostname but different IPs | |
|
MX name validity | Good. I did not detect any invalid hostnames for your MX records. | |
|
MX IPs are public | OK. All of your MX records appear to use public IPs. | |
|
MX CNAME Check | OK. No problems here. | |
|
MX A request returns CNAME | OK. No CNAMEs returned for A records lookups. | |
|
MX is not IP | OK. All of your MX records are host names. | |
|
Number of MX records | OK. Looks like you only have one MX record at your nameservers. You should be careful about what you are doing since you have a single point of failure that can lead to mail being lost if the server is down for a long time. | |
|
Mismatched MX A | OK. I did not detect differing IPs for your MX records. | |
|
Duplicate MX A records | OK. I have not found duplicate IP(s) for your MX records. This is a good thing. | |
|
Reverse MX A records (PTR) | Your reverse (PTR) record: 102.117.78.112.in-addr.arpa -> sv1.firebird.netowl.jp You have reverse (PTR) records for all your IPs, that is a good thing. |
|
| WWW | |
WWW A Record | Your www.memordm.com A record is: www.memordm.com [112.78.117.102] |
|
IPs are public | OK. All of your WWW IPs appear to be public IPs. | |
|
WWW CNAME | OK. No CNAME |
Processed in 1.221 seconds.
スタードメインのDNSレコードを編集します。
レコード追加でAレコードを選択し、IPアドレスを追加します。
確認画面で「確定する」をクリックして追加します。
つづいてCレコードを追加します。
続いてMXレコードを追加します。
最後にTXTレコードを追加します。
レコード一覧を表示しました。
ネームサーバーをファイアバードからスタードメインに変更します。
スタードメインを選択して設定します。
その後、http://www.intodns.com/memordm.com で確認しました。
時間がかかるかと思いましたが、数分でスタードメインに切り替わっていました。
| Category | Status | Test name | Informationsend feedback |
|---|---|---|---|
| Parent | |
Domain NS records | Nameserver records returned by the parent servers are:
ns1.star-domain.jp. [‘112.78.117.88’] (NO GLUE) [TTL=172800] h.gtld-servers.net was kind enough to give us that information. |
|
TLD Parent Check | Good. h.gtld-servers.net, the parent server I interrogated, has information for your TLD. This is a good thing as there are some other domain extensions like “co.us” for example that are missing a direct check. | |
|
Your nameservers are listed | Good. The parent server h.gtld-servers.net has your nameservers listed. This is a must if you want to be found as anyone that does not know your DNS servers will first ask the parent nameservers. | |
|
DNS Parent sent Glue | The parent nameserver h.gtld-servers.net is not sending out GLUE for every nameservers listed, meaning he is sending out your nameservers host names without sending the A records of those nameservers. It’s ok but you have to know that this will require an extra A lookup that can delay a little the connections to your site. This happens a lot if you have nameservers on different TLD (domain.com for example with nameserver ns.domain.org.) | |
|
Nameservers A records | Good. Every nameserver listed has A records. This is a must if you want to be found. | |
| NS | |
NS records from your nameservers | NS records got from your nameservers listed at the parent NS are:
ns2.star-domain.jp [‘112.78.117.89’] [TTL=3600] |
|
Recursive Queries | Good. Your nameservers (the ones reported by the parent server) do not report that they allow recursive queries for anyone. | |
|
Same Glue | The A records (the GLUE) got from the parent zone check are the same as the ones got from your nameservers. You have to make sure your parent server has the same NS records for your zone as you do according to the RFC. This tests only nameservers that are common at the parent and at your nameservers. If there are any missing or stealth nameservers you should see them below! | |
|
Glue for NS records | OK. When I asked your nameservers for your NS records they also returned the A records for the NS records. This is a good thing as it will spare an extra A lookup needed to find those A records. | |
|
Mismatched NS records | OK. The NS records at all your nameservers are identical. | |
|
DNS servers responded | Good. All nameservers listed at the parent server responded. | |
|
Name of nameservers are valid | OK. All of the NS records that your nameservers report seem valid. | |
|
Multiple Nameservers | Good. You have multiple nameservers. According to RFC2182 section 5 you must have at least 3 nameservers, and no more than 7. Having 2 nameservers is also ok by me. | |
|
Nameservers are lame | OK. All the nameservers listed at the parent servers answer authoritatively for your domain. | |
|
Missing nameservers reported by parent | OK. All NS records are the same at the parent and at your nameservers. | |
|
Missing nameservers reported by your nameservers | OK. All nameservers returned by the parent server h.gtld-servers.net are the same as the ones reported by your nameservers. | |
|
Domain CNAMEs | OK. RFC1912 2.4 and RFC2181 10.3 state that there should be no CNAMEs if an NS (or any other) record is present. | |
|
NSs CNAME check | OK. RFC1912 2.4 and RFC2181 10.3 state that there should be no CNAMEs if an NS (or any other) record is present. | |
|
Different subnets | OK. Looks like you have nameservers on different subnets! | |
|
IPs of nameservers are public | Ok. Looks like the IP addresses of your nameservers are public. This is a good thing because it will prevent DNS delays and other problems like | |
|
DNS servers allow TCP connection | OK. Seems all your DNS servers allow TCP connections. This is a good thing and useful even if UDP connections are used by default. | |
|
Different autonomous systems | OK. It seems you are safe from a single point of failure. You must be careful about this and try to have nameservers on different locations as it can prevent a lot of problems if one nameserver goes down. | |
|
Stealth NS records sent | Ok. No stealth ns records are sent | |
| SOA | |
SOA record | The SOA record is: Primary nameserver: ns1.star-domain.jp Hostmaster E-mail address: root.sv0.star-domain.jp Serial #: 0 Refresh: 10800 Retry: 3600 Expire: 604800 1 weeks Default TTL: 3600 |
|
NSs have same SOA serial | OK. All your nameservers agree that your SOA serial number is 0. | |
|
SOA MNAME entry | OK. ns1.star-domain.jp That server is listed at the parent servers. | |
|
SOA Serial | Your SOA serial number is: 0. This can be ok if you know what you are doing. | |
|
SOA REFRESH | OK. Your SOA REFRESH interval is: 10800. That is OK | |
|
SOA RETRY | Your SOA RETRY value is: 3600. Looks ok | |
|
SOA EXPIRE | Your SOA EXPIRE number is: 604800.Looks ok | |
|
SOA MINIMUM TTL | Your SOA MINIMUM TTL is: 3600. This value was used to serve as a default TTL for records without a given TTL value and now is used for negative caching (indicates how long a resolver may cache the negative answer). RFC2308 recommends a value of 1-3 hours. Your value of 3600 is OK. | |
| MX | |
MX Records | Your MX records that were reported by your nameservers are:
0 memordm.com 112.78.117.102 [These are all the MX records that I found. If there are some non common MX records at your nameservers you should see them below. ] |
|
Different MX records at nameservers | Good. Looks like all your nameservers have the same set of MX records. This tests to see if there are any MX records not reported by all your nameservers and also MX records that have the same hostname but different IPs | |
|
MX name validity | Good. I did not detect any invalid hostnames for your MX records. | |
|
MX IPs are public | OK. All of your MX records appear to use public IPs. | |
|
MX CNAME Check | OK. No problems here. | |
|
MX A request returns CNAME | OK. No CNAMEs returned for A records lookups. | |
|
MX is not IP | OK. All of your MX records are host names. | |
|
Number of MX records | OK. Looks like you only have one MX record at your nameservers. You should be careful about what you are doing since you have a single point of failure that can lead to mail being lost if the server is down for a long time. | |
|
Mismatched MX A | OK. I did not detect differing IPs for your MX records. | |
|
Duplicate MX A records | OK. I have not found duplicate IP(s) for your MX records. This is a good thing. | |
|
Reverse MX A records (PTR) | Your reverse (PTR) record: 102.117.78.112.in-addr.arpa -> sv1.firebird.netowl.jp You have reverse (PTR) records for all your IPs, that is a good thing. |
|
| WWW | |
WWW A Record | Your www.memordm.com A record is: www.memordm.com -> memordm.com -> [ 112.78.117.102 ][Looks like you have CNAME’s] |
|
IPs are public | OK. All of your WWW IPs appear to be public IPs. | |
|
WWW CNAME | OK. You do have a CNAME record for www.memordm.com.Your CNAME entry also returns the A record for the CNAME entry, which is good. |
info@memordm.comアカウントからgmailへメールを送信すると、SPFがpassになっていることを確認できました。
WordPressからのメールの差出人とリターンパスを変える？
info＠ドメインなどのような実在するアドレスに変えたほうがいいのか検討中です。基本的に自分にしか届かないメールなので、初期値でもいいような気がします。
問い合わせフォームの入力時に相手に自動返信する際は変えたほうがいいのかな？
後日、ContactForm7を使ってみます。