Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
In Cuba, web access is extremely censored, so I created a tool that allows more than 50,000 people to browse the Internet through email. Cubans send me an email with an URL in the subject line, and I email them back with the response. Read more at https://apretaste.com.
It was working like a charm, till the communist government of Cuba started blocking my emails. My solution was rotation.
I started with Amazon SES, and I was changing the domain each time it was blocked, but Amazon adds a header to all emails, and once they blocked the header no email from SES was able to reach Cuba any more. The same happened with Mailgun and others, they all add headers.
Currently I am creating Gmail accounts and sending via SMTP, but Google blocks me for no reason and only allows to send 100 emails a day per account. Also I can only create few emails using the same IP address/phone, so I was forced to use anonymous proxies and fake Chinese phones. Now I am fighting a war on two fronts.
An email can be blocked by three parameters: IP address, domain, and email address.
It will be terrific if I can set up my own Postfix server at a VPS that auto-rotates the IP address. Even better if I can simulate "gmail.com", to avoid purchasing a new domain every day.
All the intents to create what I call "the ultimate sender" just either reach the spam folder or add unwanted headers making it too easy to block. I feel exhausted. I hit a knowledge barrier here.
I know I am crossing to the dark side, but this is for a very good cause. Thousands count on this service as their only source of unbiased news, social network and to feel part of the 21st century.
Can you please help me implementing "the ultimate sender", or pointing to another solution that I may be missing?
I have a few suggestions for you.
The first one relies on The Onion Router also known as Tor.
Since you are crossing to the dark side, why not also take a look into the darknet?
Take a look at this list of Tor email providers. If you have your own email server that can be accessed through Tor, it becomes much harder for anybody to stop people from using this service. After all, Tor was developed to offer people uncensored access to the web.
You can read about Tor in detail here, it uses Onion Routing and this is how you would set up your server to use Tor.
Here is an example how you could use it:
The steps that involve the setup, receiving an URL request and sending back the reply are as follows:
Set up an email server.
Configure your email server to use Tor.
Publish the public service name. (e.g. "duskgytldkxiuqc6.onion")
Deploy a client that takes the service name and a URL, and let it send an email with a request to your server.
The client now waits for a reply.
You send a reply and the client receives it.
You can change your service name on a regular basis, but you need to make it accessible to those who will use this service.
Having an own email server means being able to control the email header.
Here is one example how you could make use of it:
Configure your email server so that it receives and recognizes
emails which contain the requested URLs.
Before you send a reply modify the email header so that it shows a random IP address and a random sender email address including a random domain name.
Send your reply.
Sending an email that way means that you cannot be replied back to. But since your reply already contains the requested information there is no need to.
I hope this helps.
Crowd source it.
Find a way that volunteers can send some emails for you. This is the only long term approach that I can think of. A simple web interface with mail to links would be be enough to get started although there are other potential problems with this approach too.
Because you are talking about low numbers of users, you could also use crowdsourcing to create the single email address per person approach. They can create an account on a specific set of email providers and give you the credentials. This would allow the single email per user approach or could be used to rotate through a large set of email accounts to send emails.
The simplest solution is perhaps to set up a local SMTP server on your own computer. You don't even need a server per se.
https://sourceforge.net/projects/winsmtpserver/
There are many other such applications. They are usually used to test SMTP functions during local development, but there is nothing against actually sending spam through them.
I know this would be quite a large task, but how about pairing the users with one or just a few emails so they always receive an email from that email.
I'd assume people wouldn't have more than 100 queries per day, if so they could start receiving them from a backup email
I'd imagine it would look less suspicious for them to appear to be in constant contact with one unique email rather than 50,000 being in contact with one
I know this would be a huge undertaking, but I feel like it solves your issue.
Since the users are willing to receive emails form you then your shouldn't be blocked.
When you mentioned you are getting block does it mean your mail is going in spam or is getting lost in between sending and receiving or it is getting bounced back??
My suggestion would be to setup your own mail server and follow as below:
-Get approx 25 or more ip to rotate. (IP is the most imp part which is tracked and is accountable for the reputation of your mail server)
Don't start sending emails in bulk from the word go it is better to gradullay increase the email volume so that mail server reputation nicely built
keep changing the format of the email often
encourage user to add yourself to there contact list
your best part is user are willing to receive emails from you and you would reply to revived email is the USP of yours but still i will recommend you to register for FBL so that you would know which user is reporting you as spam and you can remove him from your list and never send him email again.
using best practice to send emails like dkim, SPF, dmarc are also vital.
Hope my answer was of some help to you. If you need step by step guide to step up mail server let me know.
My friend, do you remember what made Hillary Clinton lose the last elections to Trump?
It was the "mail" affair. And what was it? People discovered she shared confidential information through a non-official, non-governmental email account (i.e., she used some Gmail, Yahoo or another of a kind). Until here, nothing new with direct relation to your matters. But there is an small particularity on this history, and this can put, maybe not a solution, but maybe a light on a new path you could follow: Clinton actually never sent those emails; the email account she used had the password shared and the communication between people (Clinton-someone) occurred only using the drafts of the account.
How? One side logs in and accesses the drafts folder. There he/she reads the last message and edits it, cutting and writing new data - then save the draft message. On the next turn, the other side of the communication line logs in and do the same. And so forth, so never really sending those messages, but instead just updating the drafts (this "Hillary" method does schooled people... Dilma Rousseff, impeached ex-president of Brazil, actually did this method down there in Brazil too).
So, maybe if you could establish a pact with your user that he/she doesn't delete the account's password, you could pass those information by this method - without "really" exchanging emails. Maybe a "parent" email account (some that could reset a lost password) could be useful too.
Alternative: aren't you able to contract a regular HTTP webserver? You could rely on FTP to publish data to your user, he/she asks for it and you publish a page with that content.
Salvi, have you tried something with Telnet? OK, we are talking here about a text-only environment, but if nothing more would rest in the future, this could be better than nothing. Maybe you could implement a podcast-like, or push-like service based on it. Look what people do with it with references to your walk on the dark side...
If in Windows, open your command prompt.
Type telnet and press Enter.
Type "o" without quotes and press Enter.
Type "towel.blinkenlights.nl" without the quotes and press Enter.
My company is developing a cloud contact management service and on our iOS app we're having some problems launching a particular enterprise email client app when the user presses the "Email" button on one of their contacts.
One member of our team came up with an idea to get around the problems with this enterprise app:
We let the user specify their email address in the app's settings and create our own email composing screen. Tapping the email button on a contact would open the composing screen, they would write their message and then we would send it on their behalf from our servers (or via service like mailchimp).
Basically, this would mean we would have to create an endpoint on our api that would accept a POST request with 'from', 'to', 'subject', and 'body' fields which would send the appropriate email.
This seems like a very bad idea as it's essentially creating a free, anonymous email service that could easily be abused send spam.
A few extra notes about our setup:
We don't verify an accounts email when they sign up
Even if we did verify the account's email, the user would need to be able to specify any email, as they may have signed up with personal email, but want to email someone from their work email.
Our API doesn't currently have any kind of rate limiting
Instead of having a from field in the request, we could instead send the id of the contact they want to email. This doesn't really change anything because if someone wants to abuse the send email endpoint they can also abuse the create contact endpoint.
So exactly how much of a bad idea is this, and how can I convince my team not to do this?
A few thoughts against doing it:
This is the perfect spamming service, which could damage the reputation of your company (reputational risk).
Your email servers would very quickly make it into blacklists (RBLs), making your outgoing emails land in spam folders in very many recipients' mailboxes.
Even if your servers are not yet in RBLs, if you send a forged email like that and proper email security is set up at the recipient end, your emails will still have a good chance to get classified as spam. Have a look at things like SPF and DKIM.
This could even have legal implications. Imagine the scenario when one of your users uses this service for something like blackmail. Would you be able to prove it was not you? Probably yes with the right controls, but would you want the hassle?
Still on the legal side, many countries (the EU, mainly) have data protection regulations which strictly control how personal data like email addresses can be used, especially for commercial advertisement. You probably want to adhere to that, but that would be hard with such a service (note that I'm not a lawyer, in such a case it's probably the abuser of your service that would offend these regulations and not you, I don't know, but it's something to consider).
If anyone can just send emails, it will be fairly easy to perform a denial of service attack against your services.
A few controls you could implement to mitigate some risks:
When adding a sender (from) address, you should validate that by for example sending a (cryptographically random) token and checking if the user can send it back (eg. by clicking a link in the email). If he can, that proves to some extent that he controls the email address and is probably a valid sender.
Limit the possible recipient addresses if you can. The best would be if recipients had to opt in to receive emails. If this is not possible, at least let recipients opt out from further emails. For this, you would have to add something like a footer to emails with "never again" links, and implement a facility to maintain recipients to which you must not send anymore.
Implement rate limiting. Depending on your exact scenario and use case, only allow to send the least number of emails acceptable for your application.
Implement proper logging so that you have an audit log of who exactly sent what email to whom. For this, log metadata like IP addresses as well. For this, you will likely have to authenticate your users.
On an operational level, have monitoring in place, and be prepared to ban offending users, based on a clear ToS shared with your users.
Let say I have a website that allows users to send articles on that website to a friend.
The way it works is that when the "send to a friend" link is clicked a form appears and it allows users to fill in the details and an email is sent to their friend.
The user can put in a "from" email address and a "to" email address into this form and a small amount of content.
When the email is received the from email address appears in the FROM and REPLY TO.
This website also sends a great deal of its own email communications to its users.
My question is:
Is there risk to allowing users (bots, attacks etc) to use this application to send emails from my SMTP, and how great is the risk?
My assumption is yes, this is not ideal.
Is it possibly worse than "not ideal"?
I do not know about bots using your form. Should it be a problem? I don't know.. I do know they program bots to be pretty clever, using your custom forms and all.
I do know that some email servers check if the FROM email address has the same IP address as the IP the mail was sent from. So imagine I put in my hotmail email address, and the mail server sees your server, it might flag the email as spam.
In the past I've an e-card websystem. It was a small joint venture with a girl I knew. She created the (cute) cards and I build her an e-card system. The website was pretty simple. Select card, enter email address, placing senders email address in the FROM and sent the email that you would have received an e-card.
Life was good...
Until I found that my entire web server IP was blacklisted at three major spam filtering mechanisms. And that 15% of all email recipients who used to receive e-cards from my site, would not receive their e-cards, because all my emails were blacklisted as spam from the get go. We have receive many many emails from angry "customers" demanding that their e-cards did not arrive. (I still find it funny how some people demanded the service, especially since it was a free service, go figure). My automatic reminder function was telling them the e-card still were not viewed, and they perhaps mistyped the email address, so that might have ticked them off :P
It was pretty annoying for my other customers as well, since they relied on sending out played newsletters and such and calling me that over 20% of the customers did not receive the newsletters.
Sending e-mails is hard. You should also check out Jeff's blog about this. So, learn from my mistake, and please put an email address associated with your email server in the FROM. This will spare you a lot of headaches ;)
yes this is definitely not ideal if this is a public website that any bot can access. but there are easy ways for you to limit spam use.
have your code limit any email
address to send ~50 emails a day and
only ~10 an hour based on your
needs. a bot would probably try to
send a million at once so limit them
on an hourly and daily basis.
store every email communication in a
database and come up with a good
program to monitor the most active
email senders. if you can verify
that an email is trusted, then let
them send as many emails as they
want
think about this site itself, it has very defined actions and reputation guidelines that limit you until you have proved you are trusted.
It may depend on whether you do any authentication to determine who's allowed to send emails. If the user has to be logged in to send articles, then you're probably fine. Bots will fail because they'll never be logged in.
The risk will increase the greater traffic you get to your site, and yes it's probably less than ideal. Unprotected, a bot will inevitably find your unprotected form, and start sending emails from your server.
There are some pretty easy solutions though, the most common probably being to implement something like Captcha
Fairly safe. I assume you do check the "From" address, if only by sending it one (standard!) mail first and asking the owner of that email address to confirm they are really humans ? This prevents most bots from finding and abusing your form. Of course, a directed attack with a human responding to your verification email will still allow spamming. But you've got a much better trail if you have received at least one reply from the alleged "From" address.
However, I don't think this will work reliably. The introduction of techniques like SPF will mean that mails from "example.com" will only be accepted if they originate from an outgoing SMTP server in the *.example.com domain. If you're faking emails with From: addresses #example.com, the receiving SMTP server will see that you are in fact not part of *.example.com and reject the email - and probably blacklist your IP range for good measure.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
As per this question I asked previously on Google App Engine, if I have access to all the information in a standard email, not just the From, To, Subject, Body fields, but also all the headers and MIME information, how can I verify that two incoming emails with the same From address are actually from the same sender.
What I've considered thus far:
Check the IP address of the email's sending server
Check the DNS records of the email's sending server
Verify the sending agent of the email (i.e. web interface, Outlook, Thunderbird, etc)
Check the reply-to field
Etc.
I realize this is a complicated question (I'm sure companies like Posterous have spent tons of time on this problem). I'm just looking for a few criteria to get started preliminarily. Thanks!
Update:
The answers so far are really helping, but just to help them out, the context of my project is that I would be receiving tons and tons of email as a web app from my users. They would use their email as the primary way of inputting data into my system. This I why I made the Posterous analogy. The use case is very similar.
You're right that all of the headers together, and 'known good' email to compare to can help identify likely spoofed emails.
What you're developing would probably be at best a heuristic rather than an algorithm.
I'd consider weighting the fields by time-of-day and how close to 'known good' emails' time-of-day ...
Also, if the 'known good' emails are structured differently than the suspect; i.e. Inline images, html, shortened url's, etc.
Why not run the emails through spamassassin or some such filter that will attach a bayes score. You can then just read that score. It will save you reinventing the wheel.
You could bayes score the email against a database of all previous emails from the individual.
There is also looking up the Sender Permitted Framework and DomainKeys, which SpamAssassin can do for you.
Probably not practical but something that would work:
When an incoming mail arrives, have a "reply to sender" function and simply ask if they sent it. This could be in the form of a confirmation link that is automatically generated or something.
But since I don't know the specifics of the project this may not be practical... like if you had to do this multiple times for each user, no one would put up with it.
Just to compliment my brothers posting earlier:
Not knowing the context under which you want to analyse this, and being very general I would suggest your first port of call is SPF or DomainKeys in order to limit the possibility of email coming from a rogue source being accepted. I would also recommend using only one SMTP server with SSL security. I do this and travelling worldwide I have rarely been in a situation I couldn't send mail and in those cases the only thing that did work was webmail (no safe local SMTP).
Additionally to that: if you are verifying mail is really coming from yourself then you could also use PGP tools to sign your mail upon sending and then filter any mail that didn't have a valid signature. Enigmail in Thunderbird is a good source of automatic signing and there are plugins for Outlook as well.
After that if you really want to do a more forensic job on an email then you could use a Spam Bayes to score the email against a database of previous emails. You would build up a database of tokens around the non-unique data (excluding entries such as "To:") and then score the email for the probability that it is like the previous emails. In theory you should score very highly for any mail.
Obviously I don't know your situation, but I think that there are many techniques but sometimes it is easier to go to the root of the issue than try and fix it down the line.
Update
Based on the context supplied:
I would consider using "Address Extensions" this is where your user can send mail to an address which contains a reference using the email address: emailname+extension#domain.com
GMail and many other servers support delivery of email with a +extension# through to the correct emailname#domain.com without hi-jinx. You could get the user to deliver mail with a unique ID as the extension and that way you would know it had come from them and they would feel more special. Obviously someone could steal their unique code by sniffing their outgoing or your incoming mail but that is always possible and if someone can do that they can probably inject mail as well.
If you really just want to go down the analysis route then I would suggest just using the reverse of a SpamAssassin per-user Bayes match. Where you compare every mail to a database of mails from a sender (instead of the traditional matching of mails 'to' an account). Remembering that once your database is polluted with a false positive you will have to remove the false positive or risk the integrity of the matching for that sender.
Maybe look into using Sender Policy Framework. It might not be exactly what you are looking for but it might help.
Briefly, the design intent of the SPF record is to allow a receiving MTA (Message Transfer Agent) to interrogate the Name Server of the domain which appears in the email (the sender) and determine if the originating IP of the mail (the source) is authorized to send mail for the sender's domain.
Ripped from wikipedia:
Sender Policy Framework (SPF), as
defined in RFC 4408, is an e-mail
validation system designed to prevent
e-mail spam by addressing a common
vulnerability, source address
spoofing. SPF allows e-mail
administrators the ability to specify
which Internet hosts are allowed to
send e-mail claiming to originate from
that domain by creating a specific DNS
SPF record in the public DNS record.
Mail exchangers then use the DNS
record to verify the sender's identity
against the list published by the
e-mail administrator.
This is a tricky one and I've always relied on techniques, such as permission-based emails (i.e. only sending to people you have permission to send to) and not using blatantly spamish terminology.
Of late, some of the emails I send out programmatically have started being shuffled into people's spam folder automatically and I'm wondering what I can do about it.
This is despite the fact that these particular emails are not ones that humans would mark as spam, specifically, they are emails that contain license keys that people have paid good money for, so I don't think they're going to consider them spam
I figure this is a big topic in which I am essentially an ignorant simpleton.
Use email authentication methods, such as SPF, and DKIM to prove that your emails and your domain name belong together, and to prevent spoofing of your domain name. The SPF website includes a wizard to generate the DNS information for your site.
Check your reverse DNS to make sure the IP address of your mail server points to the domain name that you use for sending mail.
Make sure that the IP-address that you're using is not on a blacklist
Make sure that the reply-to address is a valid, existing address.
Use the full, real name of the addressee in the To field, not just the email-address (e.g. "John Smith" <john#blacksmiths-international.com> ).
Monitor your abuse accounts, such as abuse#yourdomain.example and postmaster#yourdomain.example. That means - make sure that these accounts exist, read what's sent to them, and act on complaints.
Finally, make it really easy to unsubscribe. Otherwise, your users will unsubscribe by pressing the spam button, and that will affect your reputation.
That said, getting Hotmail to accept your emails remains a black art.
Sign up for an account on as many major email providers as possible (gmail/yahoo/hotmail/aol/etc). If you make changes to your emails, either major rewording, changes to the code that sends the emails, changes to your email servers, etc, make sure to send test messages to all your accounts and verify that they are not being marked as spam.
A few bullet points from a previous answer:
Most important: Does the sender address ("From") belong to a domain that runs on the server you send the E-Mail from? If not, make it so. Never use sender addresses like xxx#gmail.com. User reply-to if you need replies to arrive at a different address.
Is your server on a blacklist (e.g. check IP on spamhaus.org)? This is a possibility when you're on shared hosting when neighbours behave badly.
Are mails filtered by a spam filter? Open an account with a freemailer that has a spam folder and find out. Also, try sending mail to an address without any spam filtering at all.
Do you possibly need the fifth parameter "-f" of mail() to add a sender address? (See mail() command in the PHP manual)
If you have access to log files, check those, of course.
Do you check the "from:" address for possible bounce mails ("Returned to sender")? You can also set up a separate "errors-to" address.
You can tell your users to add your From address to their contacts when they complete their order, which, if they do so, will help a lot.
Otherwise, I would try to get a log from some of your users. Sometimes they have details about why it was flagged as spam in the headers of the message, which you could use to tweak the text.
Other things you can try:
Put your site name or address in the subject
Keep all links in the message pointing to your domain (and not email.com)
Put an address or other contact information in the email
Confirm that you have the correct email address before sending out emails. If someone gives the wrong email address on sign-up, beat them over the head about it ASAP.
Always include clear "how to unsubscribe" information in EVERY email. Do not require the user to login to unsubscribe, it should be a unique url for 1-click unsubscribe.
This will prevent people from marking your mails as spam because "unsubscribing" is too hard.
In addition to all of the other answers, if you are sending HTML emails that contain URLs as linking text, make sure that the URL matches the linking text. I know that Thunderbird automatically flags them as being a scam if not.
The wrong way:
Go to your account now: http://www.paypal.com
The right way:
Go to your account now: http://www.yourdomain.org
Or use an unrelated linking text instead of a URL:
Click here to go to your account
You may consider a third party email service who handles delivery issues:
Exact Target
Vertical Response
Constant Contact
Campaign Monitor
Emma
Return Path
IntelliContact
SilverPop
Delivering email can be like black magic sometimes. The reverse DNS is really important.
I have found it to be very helpful to carefully track NDRs. I direct all of my NDRs to a single address and I have a windows service parsing them out (Google ListNanny). I put as much information from the NDR as I can into a database, and then I run reports on it to see if I have suddenly started getting blocked by a certain domain. Also, you should avoid sending emails to addresses that were previously marked as NDR, because that's generally a good indication of spam.
If you need to send out a bunch of customer service emails at once, it's best to put a delay in between each one, because if you send too many nearly identical emails to one domain at a time, you are sure to wind up on their blacklist.
Some domains are just impossible to deliver to sometimes. Comcast.net is the worst.
Make sure your IPs aren't listed on sites like http://www.mxtoolbox.com/blacklists.aspx.
I hate to tell you, but I and others may be using white-list defaults to control our filtering of spam.
This means that all e-mail from an unknown source is automatically spam and diverted into a spam folder. (I don't let my e-mail service delete spam, because I want to always review the arrivals for false positives, something that is pretty easy to do by a quick scan of the folder.)
I even have e-mail from myself go to the spam bucket because (1) I usually don't send e-mail to myself and (2) there are spammers that fake my return address in spam sent to me.
So to get out of the spam designation, I have to consider that your mail might be legitimate (from sender and subject information) and open it first in plaintext (my default for all incoming mail, spam or not) to see if it is legitimate. My spam folder will not use any links in e-mails so I am protected against tricky image links and other misbehavior.
If I want future arrivals from the same source to go to my in box and not be diverted for spam review, I will specify that to my e-mail client. For those organizations that use bulk-mail forwarders and unique sender addresses per mail piece, that's too bad. They never get my approval and always show up in my spam folder, and if I'm busy I will never look at them.
Finally, if an e-mail is not legible in plaintext, even when sent as HTML, I am likely to just delete it unless it is something that I know is of interest to me by virtue of the source and previous valuable experiences.
As you can see, it is ultimately under an users control and there is no automated act that will convince such a system that your mail is legitimate from its structure alone. In this case, you need to play nice, don't do anything that is similar to phishing, and make it easy for users willing to trust your mail to add you to their white list.
one of my application's emails was constantly being tagged as spam. it was html with a single link, which i sent as html in the body with a text/html content type.
my most successful resolution to this problem was to compose the email so it looked like it was generated by an email client.
i changed the email to be a multipart/alternative mime document and i now generate both text/plain and text/html parts.
the email no longer is detected as junk by outlook.
Yahoo uses a method called Sender ID, which can be configured at The SPF Setup Wizard and entered in to your DNS. Also one of the important ones for Exchange, Hotmail, AOL, Yahoo, and others is to have a Reverse DNS for your domain. Those will knock out most of the issues. However you can never prevent a person intentionally blocking your or custom rules.
You need a reverse DNS entry. You need to not send the same content to the same user twice. You need to test it with some common webmail and email clients.
Personally I ran mine through a freshly installed spam assassin, a trained spam assassin, and multiple hotmail, gmail, and aol accounts.
But have you seen that spam that doesn't seem to link to or advertise anything? That's a spammer trying to affect your Bayesian filter. If he can get a high rating and then include some words that would be in his future emails it might be automatically learned as good. So you can't really guess what a user's filter is going to be set as at the time of your mailing.
Lastly, I did not sort my list by the domains, but randomized it.
I've found that using the recipients real first and last name in the body is a sure fire way of getting through a spam filter.
In the UK it's also best practice to include a real physical address for your company and its registered number.
That way it's all open and honest and they're less likely to manually mark it as spam.
I would add :
Provide real unsubscription upon click on "Unsubscribe". I've seen real newsletters providing a dummy unsubscription link that upon click shows " has been unsubscribed successfully" but I will still receive further newsletters.
The most important thing you can do is to make sure that the people you are sending email to are not likely going to hit the "Spam" button when they receive your email. So, stick to the following rules of thumb:
Make sure you have permission from the people you are sending email to. Don't ever send email to someone who did not request it from you.
Clearly identify who you are right at the top of each message, and why the person is receiving the email.
At least once a month, send out a reminder email to people on your list (if you are running a list), forcing them to opt back in to the list in order to keep receiving communications from you. Yes, this will mean your list gets shorter over time, but the up-side is that the people on your list are "bought in" and will be less likely to flag your email.
Keep your content highly relevant and useful.
Give people an easy way to opt out of further communications.
Use an email sending service like SendGrid that works hard to maintain a good IP reputation.
Avoid using short links - these are often blacklisted.
Following these rules of thumb will go a long way.
I have had the same problem in the past on many sites I have done here at work. The only guaranteed method of making sure the user gets the email is to advise the user to add you to there safe list. Any other method is really only going to be something that can help with it and isn't guaranteed.
It could very well be the case that people who sign up for your service are entering emails with typing mistakes that you do not correct. For example: chris#gmial.com -or- james#hotnail.com.
And such domains are configured to be used as spamtraps which will automatically flag your email server's IP and/or domain and hurt its reputation.
To avoid this, do a double-check for the email address that is entered upon your product subscription. Also, send a confirmation email to really ensure that this email address is 100% validated by a human being that is entering the confirmation email, before you send them the product key or accept their subscription. The verification email should require the recipient to click a link or reply in order to really confirm that the owner of the mailbox is the person who signed up.
It sounds like you are depending on some feedback to determine what is getting stuck on the receiving end. You should be checking the outbound mail yourself for obvious "spaminess".
Buy any decent spam control system, and send your outbound mail through it. If you send any decent volume of mail, you should be doing this anyhow, because of the risk of sending outbound viruses, especially if you have desktop windows users.
Proofpoint had spam + anti-virus + some reputation services in a single deployment, for example. (I used to work there, so I happen to know this off the top of my head. I'm sure other vendors in this space have similar features.) But you get the idea. If you send your mail through a basic commerical spam control setup, and it doesn't pass, it shouldn't be going out of your network.
Also, there are some companies that can assist you with increasing delivery rates of non-spam, outbound email, like Habeas.
Google has a tool and guidelines for this. You can find them on: https://postmaster.google.com/ Register and verify your domain name and Google provides an individual scoring of that IP-address and domain.
From the bulk senders guidelines:
Authentication ensures that your messages can be correctly classified. Emails that lack authentication are likely to be rejected or placed in the spam folder, given the high likelihood that they are forged messages used for phishing scams. In addition, unauthenticated emails with attachments may be outrightly rejected, for security reasons.
To ensure that Gmail can identify you:
Use a consistent IP address to send bulk mail.
Keep valid reverse DNS records for the IP address(es) from which you send mail, pointing to your domain.
Use the same address in the 'From:' header on every bulk mail you send.
We also recommend the following:
Sign messages with DKIM. We do not authenticate messages signed with keys using fewer than 1024 bits.
Publish an SPF record.
Publish a DMARC policy.
I always use:
https://www.mail-tester.com/
It gives me feedback on the technical part of sending an e-mail. Like SPF-records, DKIM, Spamassassin score and so on. Even though I know what is required, I continuously make errors and mail-tester.com makes it easy to figure out what could be wrong.
First of all, you need to ensure the required email authentication mechanisms like SPF and DKIM are in place. These two are prominent ways of proving that you were the actual sender of an email and it's not really spoofed. This reduces the chances of emails getting filtered as spam.
Second thing is, you can check the reverse DNS output of your domain name against different DNSBLs. Use below simple command on terminal:
**dig a +short (domain-name).(blacklist-domain-name)**
ie. dig a +short example.com.dsn.rfc-clueless.org
> 127.0.0.2
In the above examples, this means your domain "example.com" is listed in blacklist but due to Domain Setting Compliance(rfc-clueless.org list domain which has compliance issue )
note: I prefer multivalley and pepipost tool for checking the domain listings.
The from address/reply-to-id should be proper, always use visible unsubscribe button within your email body (this will help your users to sign out from your email-list without killing your domain reputation)
The intend of most of the programmatically generated emails is generally transactional, triggered or alert n nature- which means these are important emails which should never land into spam.
Having said that there are multiple parameters which are been considered before flagging an email as spam. While Quality of email list is the most important parameter to be considered, but I am skipping that here from the discussion because here we are talking about important emails which are sent to either ourself or to known email addresses.
Apart from list quality, the other 3 important parameters are;
Sender Reputation
Compliance with Email Standards and Authentication (SPF, DKIM, DMARC, rDNS)
Email content
Sender Reputation = Reputation of Sending IP address + Reputation of Return Path/Envelope domain + Reputation of From Domain.
There is no straight answer to what is your Sender Reputation. This is because there are multiple authorities like SenderScore, Reputation Authority and so on who maintains the reputation score for your domain. Apart from that ISPs like Gmail, Yahoo, Outlook also maintains the reputation of each domain at their end.
But, you can use free tools like GradeMyEmail to get a 360-degree view of your reputation and potential problems with your email settings or any other compliance-related issue too.
Sometimes, if you're using a new domain for sending an email, then those are also found to land in spam. You should be checking whether your domain is listed on any of the global blocklists or not. Again GradeMyEmail and MultiRBL are useful tools to identify the list of blocklists.
Once you're pretty sure with the sender reputation score, you should check whether your email sending domain complies with all email authentications and standards.
SPF
DKIM
DMARC
Reverse DNS
For this, you can again use GradeMyEmail or MXToolbox to know the potential problems with your authentication.
Your SPF, DKIM and DMARC should always PASS to ensure, your emails are complying with the standard email authentications.
Here's an example of how these authentications should look like in Gmail:
Similarly, you can use tools like Mail-Tester which scans the complete email content and tells the potential keywords which can trigger spam filters.
To allow DMARC checks for SPF to pass and also be aligned when using sendmail, make sure you are setting the envelope sender address (-f or -r parameter) to something that matches the domain in the From: header address.
With PHP:
Using PHP's built-in mail() function without setting the 5th paramater will cause DMARC SPF checks to be unaligned if not done correctly. By default, sendmail will send the email with the webserver's user as the RFC5321.MailFrom / Return Path header.
For example, say you are hosting your website domain.com on the host.com web server. If you do not set the additional parameters parameter:
mail($to,$subject,$message,$headers); // Wrong way
The email recipient will receive an email with the following mail headers:
Return-Path: <your-website-user#server.host.com>
From: <your-website-user#domain.com>
Even though this passes SPF checks, it will be unaligned (since domain.com and host.com do not match), which means that DMARC SPF check will fail as unaligned.
Instead, you must pass the envelope sender address to sendmail by including the 5th parameter in the PHP mail() function, for example:
mail($to,$subject,$message,$headers, '-r bounce_email#domain.com'); // Right way
In this case, the email recipient will receive an email with the following mail headers:
Return-Path: <bounce_email#domain.com>
From: <your-website-user#domain.com>
Since both of these headers contain addresses from domain.com, SPF will pass and also be aligned, which means that DMARC will also pass the SPF check.