Recently I have a problem on sending e-mail with PHP Mailer
function. Every mail which I sent from my script is straight way goes
to spam folder on GMail, HotMail and other mail providers.
The issue has nothing to do with PHP Mailer, your code or even your host. But it has to do with overall outgoing mail settings on your hostname & even IP address. Meaning when you say this:
And I got result like SUCCESS which means Mail Successfully Sent.
But when I check on my GMail the mail which I sent is on SPAM folder.
Correct, your mail was actually sent by the server. Which is good. But the mail servers on the receiving end somehow do not trust your hostname or IP address. A few things can be done to remedy this. Such as setting and SFP record in your hostnames DNS & setting a PTR (reverse DNS) record for the IP address of the server that is sending out the actual e-mails.
First & foremost, is vendarcorporates.com an actual domain? Doing a ping for it on this tool that pings globally shows consistent Unknown host: vendarcorporates.com results. If that is the case & you are trying to send with that, there is your problem right there.
As far as SPF records go, that is a DNS record that means Sender Policy Framework which translates to basically meaning: You, as the owner of a hostname allow these other IP addresses & hostnames to send e-mail on your behalf. More details here specifically this:
Even more precisely, SPFv1 allows the owner of a domain to specify
their mail sending policy, e.g. which mail servers they use to send
mail from their domain. The technology requires two sides to play
together: (1) the domain owner publishes this information in an SPF
record in the domain's DNS zone, and when someone else's mail server
receives a message claiming to come from that domain, then (2) the
receiving server can check whether the message complies with the
domain's stated policy. If, e.g., the message comes from an unknown
server, it can be considered a fake.
"v=spf1 ip4:18.104.22.1680 ~all"
Assuming your domain is vendarcorporates.com, an SPF record like this would work as follows on the receiving end:
But this IP address is 22.214.171.1240 and it is not connected to vendarcorporates.com. So lets check the SPF record.
Okay, I am reading the SPF record, and 126.96.36.1990 is allowed to send e-mails for vendarcorporates.com, so lets let this message through.
Now that might not completely solve the issue. So in addition to an SPF record, you need to make sure your server has a valid PTR (reverse DNS) record that in some way matches your hostname.
Unlike a DNS record where a hostname is translated to an IP address, a PTR record is a reverse DNS record where an IP address is translated into a hostame. More info on Wikipedia.
How you can set a PTR is dependent on the way your host works.
And many others simply will not let you set a PTR record on your own. You need to contact your hosting service & ask them to setup a PTR record for you.
The reason PTR records are important is it is yet another check in the Is this SPAM? chain. So it would play out like this:
Hey, I just received an e-mail message from someone claiming to be vendarcorporates.com!
That second step where there is a check to see if an IP address of a mail is connected to vendarcorporates.com? That is the PTR record check.
Im fairly confident that having both the SPF & PTR record for your domain name & host set will clear up this issue.
And on the outside chance that you do have an SPF & PTR record set yet e-mails end up in SPAM? Well, that means your hostname and/or IP address is blacklisted. And that is a whole other can of worms for you to deal with. You can check your blacklist status with an online tool like MX Toolbox & follow individual service recommendations to request you be removed. But depending on the severity of your ranking in this list, this could either be a simple task or a very complex one.
Which is all to say, while tools like PHP Mailer ease the process of sending e-mails, the whole process of ensuring your e-mails are not tagged as SPAM is a whole other proverbial beast that has little to do with coding specifics.