We want to go to the destination without a glitch. However many things can go wrong, especially if we are talking about commercial email also known as Gray mail. This section will help email senders adopt and use best practices that will improve their email deliverability.
Reputation, reputation and reputation
Your reputation gateway (domain and IP) is the number one thing you should check. Your domain and IP can be blacklisted by third party operators without you knowing it. You should always maintain a reputation and promptly react in case of blacklisting. This will be you blacklisted: http://multirbl.valli.org/
Do not flood us
Sending a high volume of messages. If you need to send a large volume of messages, make sure that you use them in your batches. If you're going to reach the limits you will be throttled and a '421 Temp Fail' error will occur, which should cause your server to retry later. Use pipelining with care as having a very high message rate will penalize you.
Do not use a dynamic IP
Dynamic IPs are not suitable for mail servers, Exchange or other. They are frequently used by spammers and will downgrade your reputation.
Having a valid SPF record improves deliverability. Spoofing another's SPF blocks you right there. Make sure you understand that your SPF record is clear.
Be polite (the SMTP way)
That's what protocol is all about - respecting the rules. This means that your mailer has to be well behaved. It should be supported by RFCXXX helo banner, it should support TLS and it should wait.
What about the content?
Of course your content can make or break delivery. Anything that is commercial and unsolicited will be suspect. We all ask for any bulk sender. If the email is commercial or is a newsletter, it must have a working unsubscribe link. Not having such a link, or no working link will have you permanently blocked.
Use a third party sender
If you are sending commercial email, it is not your job that you do not know it. Reputable emailing operators will offer you a service that respects the protocol, provides deliverability and open statistics at very reasonable prices.
Get your Postmaster address working
Postmaster@domain.com and firstname.lastname@example.org are your answer for your domain. If we can not reach you, we will not be able to take care of you.
How should I write my email campaigns so they do not get blocked?
This is a question that is often asked to our technical team. Email security providers and antispam appliances all different algorithms and scoring schemes and some common denominator do exist. Your email will have a better chance of going the following way ::
- Do not write in all capital letters
- Include a valid and detailed subject line
- Do not send just an image or just a URL
- Beware of terms like Free offer, click now, urgent
- Avoid using URL shortners
- Personalize your email with the full name
- Any dear <email address> introduction will be suspicious
- Use validated HTML content
- Send from a domain / IP that maintains a reputation
- Use third party emailing services
- Process your bounce messages and clean your lists when you get them
No MX Record
ZEROSPAM will not accept any message from this domain that will not validate this file. In other words it takes two to dance!
We think it's SPAM
SPAM rejection will be the obvious case of mail being rejected. Given the fact that ZEROSPAM has a very low measured false positive rate, your legitimate, person to person. If that happens, a bounce message may be returned that allows the sender to dispute the blocking decision. All disputes are handled within 24 hours. Messages classified as spam - and they are up to the user 's quarantine and it is up to them Your best option is to contact the recipient and ask for a quarantine release. ZEROSPAM will not whitelist a domain just because of sender asks.
You have been blacklisted by the recipient
Sorry to say but that's a case where an organization has decided it does not want to receive any email from a particular domain. It is entirely the customer's decision and it is up to the sender to convince them otherwise.
We found that many Web apps are sending a message that can increase the risk of getting blocked. Web apps should not break SPF; that is not send messages on behalf of another domain. They should accept and forward bounces to a human. Web apps typically will not behave like a true mail server, for example not respecting or being able to set outbound throttling limits. For this reason it is best if your web app relays to a dedicated outbound server before it goes out on the internet. Last but not least, your Web app must be able to handle temporary failures (421 response codes) and requeue messages that have been received at Temp fail.