Most websites will want to send mails one day. Usually people go the simple way and configure their CMS or whatever else to send mail using php’s mail() function. This works fairly well but without further work most of the mails being sent will be considered spam. This can have several reasons. Please ensure to do the following to send mail from your web server:
Some mail servers do a reverse lookup of the source ip connecting to them. They usually check that there is a PTR record resolving the IP to a DNS name but sometimes also validate that the resolved hostname matches the one the mailserver showed up with in the SMTP helo message. In best case you have your mailserver showing the hostname in the helo message and a pointer record for your IP resolving to that exactly same hostname.
A telnet to your mailserver shows the HELO message:
[email protected] ~ # telnet localhost 25
Connected to localhost.localdomain.
Escape character is '^]'.
220 mail.mydomain.com ESMTP mailgate
Your servers public IP address and its reverse lookup:
[email protected] ~ # ip a
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
init 188.8.131.52/32 brd scope global eth0
[email protected] ~ # host 184.108.40.206
220.127.116.11.in-addr.arpa domain name pointer mail.mydomain.com.
There you can see that the ip which is used to send mails to the internet resolves to the hostname the mailserver shows up with in it’s HELO message. This will work.
The Sender Policy Framework is another DNS based security layer to prevent unauthorized mail servers from sending mail on a domains behalf. It is as simple as a TXT DNS record which one can configure to define allowed sender systems for a domain. Many mail servers are checking this but not necessarily blocking mail based on SPF. Dig helps to see the actual SPF record if there is any:
[email protected] ~ # dig mydomain.com txt
; <<>> DiG 9.8.3-P1 <<>> mydomain.com txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9195
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;mydomain.com. IN TXT
;; ANSWER SECTION:
mydomain.com. 19711 IN TXT "v=spf1 a mx include:_spf.google.com ~all"
;; Query time: 69 msec
;; SERVER: 18.104.22.168#53(22.214.171.124)
;; WHEN: Mon Feb 15 22:13:54 2016
;; MSG SIZE rcvd: 83
The interesting part here is the answer section. “v=spf1 a mx include:_spf.google.com ~all” is the SPF record. If you don’t see a TXT record containing v=spf1, you probably have none. There is a lot of good and complete documentation about SPF around so I will limit to the simplest. “v=spf1” is kind of a version header. The “a mx” means, that all A and MX records for this domain are allowed to send mail. “include:_spf.google.com” means that all SPF records from _spf.google.com are valid for this domain (that google is allowed to send mails for this domain). And the “~all” part means that no other mail server is allowed to send mails and should be soft bounced. This can be to mark the mail as spam or bounce it. It depends on the mailserver implementation and configuration.
Easily test your configuration with www.spf-record.de tools.wordtothewise.com/spf.
Your application should correctly configure the sender address to be a valid one. Something like [email protected] is a fairly bad idea and leads to a higher spam score and irritation of the recipients. Use real existing addresses or something like [email protected]