The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Why didn't my email get delivered? or where did my email go?

Discussion in 'E-mail Discussions' started by cPanelPeter, Jan 27, 2014.

  1. cPanelPeter

    cPanelPeter Technical Analyst III
    Staff Member

    Joined:
    Sep 23, 2013
    Messages:
    569
    Likes Received:
    15
    Trophy Points:
    18
    cPanel Access Level:
    Root Administrator
    Twitter:
    At cpanel, Technical Analysts will get asked this question many times. Unfortunately the question
    is a little vague since there are really hundreds of reasons why an email may not get delivered.

    These can be:

    • Authentication issues (the most common).
    • DNS related issues (is your rDNS set up correctly?).
    • SPF, DKIM and/or DMARC settings (misconfigured or missing completely).
    • Firewall issues (or proxying of port 25 by the NOC, Datacenter, Host or customers ISP) or other networking issues.
    • Blocked IP addresses (Customers IP address may be blacklisted).
    • cpHulkd brute force lockouts.
    • SpamAssassin settings too strict.
    • Spammer (or more likely a compromised email account) has filled up your exim mail queue with spam messages and legit messages are now waiting to be sent.
    • Exim misconfiguration.
    • Sender Verify and even Greylisting or other temporary soft-errors.
    • An incorrect setting within your /etc/resolv.conf file.
    • A misconfigured filter.
    • Mailbox is over quota (5.2.2. error).
    • Virus was attached to message and virus scanner redirected your email to /dev/null.

    A very important thing to remember is that email either gets delivered or it bounces back with an error. There is no in-between and mail doesn't just "disappear into limbo" as many people believe.

    What are bounce messages?

    A bounce error is also called a Non-Delivery Report/Receipt (NDR), a (failed) Delivery Status Notification (DSN) message, a Non-Delivery Notification (NDN) and is an automated electronic mail message from the mail server informing the sender about a delivery problem. There are two types of errors. Temporary errors (which start with a 4.x.x) are known as soft-bounce errors, and permanent delivery errors (which start with 5.x.x) and are known as hard-bounce errors. Temporary errors will usually be re-delivered, while permanent errors will be returned or bounced.

    That being said, the most common cause is usually user error in setting up the email on their mail client (Outlook, Thunderbird, Eudora, etc...) So the first thing that should be checked is the configuration settings. In cPanel all user names for both POP (Post Office Protocol) and IMAP (Internet Mail Access Protocol) are the full email address.

    The mail server in most cases is mail.DOMAINNAME.TLD (where DOMAINNAME.TLD is the domain name in question). Verifying authentication issues for sending email is fairly trivial and not part of this post.

    Below, I've outlined some of the things that should be checked when trying to troubleshoot email delivery. These are just some of the more common error messages we (as technical analysts) have seen.

    550 errors

    Take a look at the following error...

    Code:
    someemail@somedomain.com <root@this.server.com> R=dkim_lookuphost T=dkim_remote_smtp: SMTP error from remote mail server after initial connection: host somedomain.com [xx.xxx.xx.xxx]: 550 Your host is not allowed to connect to this server. Frozen (delivery error message)
    
    See the "550" Your host is not allowed to connect to this server message? That means point blank that the host you are trying to send to, has blocked your server. This could be do to spam complaints or other abuse issues, or even because that server is misconfigured. You would need to contact the host in question to ask why they have decided to block your server. You should also check to see if your server has been blacklisted. A good site to use to check that is:
    MX Toolbox.

    521 errors

    Another error that might creep up from time to time is this one:

    Code:
    SMTP error from remote mail server after end of data: host someserver.mx.domain.com [xx.xx.xxx.xxx]: 521 5.2.1 : http://postmaster.someserver.com/errors/521.html
    
    This one actually contains a link (obscured for security) to a site that will explain why the message failed, and usually why it failed.

    421 errors

    I mentioned earlier about soft-errors vs hard-errors, take a look at the following error message:

    Code:
    2013-12-29 23:41:45 1VxPzN-3420m0-1p SMTP error from remote mail server after initial connection: host mx.somedomain.com [xxx.xxx.xxx.xxx]: 421 mx.someserver.com Service unavailable - try a gain later
    
    The temporary error could very well be Greylisting. Greylisting is a method of defending e-mail users against spam. A mail transfer agent (MTA) using greylisting will temporarily reject" any email from a sender it does not recognize. If the mail is legitimate the originating server will, after a delay, try again and, if sufficient time has elapsed, the email will be accepted.

    It might be some other temporary issue however so you would need to contact the mail service provider of the host in question to find out what that temporary reason is (or just wait to see if it goes through later).

    Firewall issues?

    We've also seen a few issues with the big mail servers (Gmail, Yahoo, Hotmail/Outlook.com) rejecting mail connections. The majority of them have been firewall related (either your servers firewall or one upstream from your server).

    To test if it's a firewall issue, you can try a simple telnet command to port 25 from your server. First you have to obtain the correct MX record, which can be done via a dig (Domain Information Groper) query.

    Code:
    root@server [~]# dig gmail.com MX +short
    
    5 gmail-smtp-in.l.google.com.
    30 alt3.gmail-smtp-in.l.google.com.
    40 alt4.gmail-smtp-in.l.google.com.
    10 alt1.gmail-smtp-in.l.google.com.
    20 alt2.gmail-smtp-in.l.google.com.
    
    Now armed with the MX records, you can try to telnet to port 25 on one or more of them.

    Code:
    root@server [~]# telnet alt3.gmail-smtp-in.l.google.com 25
    Trying 173.194.75.27...
    Trying 2a00:1450:4008:c01::1b...
    telnet: Unable to connect to remote host: Network is unreachable
    
    root@server [~]# telnet mta6.am0.yahoodns.net 25
    Trying 66.196.118.240...
    Trying 98.138.112.37...
    Trying 98.136.217.203...
    Trying 98.138.112.34...
    Trying 66.196.118.36...
    Trying 98.136.216.25...
    Trying 63.250.192.45...
    Trying 98.138.112.35...
    telnet: Unable to connect to remote host: Connection timed out
    
    root@server [~]# telnet mx4.hotmail.com 25
    Trying 65.54.188.126...
    Trying 65.55.92.152...
    Trying 65.55.92.136...
    Trying 65.55.37.72...
    Trying 65.54.188.94...
    Trying 65.55.37.120...
    Trying 65.55.92.184...
    Trying 65.55.92.168...
    Trying 65.54.188.72...
    Trying 65.54.188.110...
    Trying 65.55.37.104...
    Trying 65.55.37.88...
    telnet: Unable to connect to remote host: Connection timed out
    
    As you can see from the above, all of them sit there simply Trying to connect. That's a big indication that a firewall (either yours or one upstream from you is blocking the connection). To test this thoroughly, you should also try to telnet to each one of the above to port 25 from another location that is not your server and not using your servers internet connection. If it works from the other location, then chances are it is your server or your data center, NOC or hosting provider that is blocking (also known as proxying) port 25.

    NOTE: The MX records for them can change at any time without notice. So you should verify the servers to use for testing each time.

    Here's another one where a server administrator added a DROP rule for port 25 to his server and wondered by email was not being delivered...

    First the rule:

    Code:
    12 14 NNN DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25
    
    Here's the resulting log file entries:

    Code:
    2013-12-24 17:19:25 1VvSpO-0006ga-QZ SMTP error from remote mail server after initial connection: host mx.aol.com [xx.xx.xx.xxx]: 421 mx.aol.com Service unavailable - try again later
    
    SPF/dkim/dmarc issues

    Let's talk a little about SPF (Sender Policy Framework). Lots of information can be found at www.openspf.org.

    A message in the /var/log/exim_mainlog file might look like this:

    Code:
    SMTP error from remote mail server after HELO server.someserver.com: host backup.anotherserver.net [xxx.xxx.xx.xx]: 550-SPF HELO check failed (Fail): 550 See http://www.openspf.org/why.html?sender=postmaster%40server.someserver.com&ip=xxx.xxx.xxx.xx&receiver=backup.anotherserver.net
    
    This message indicates that the message was rejected by the mail server because it didn't have a valid SPF record. To check the SPF record of the domain in question we would again use the dig command:

    Code:
    root@server [~]# dig anotherserver.net TXT +short
    
    If you get nothing back, then you need to have the customer add an SPF record to their DNS. Documentation on how to set up SPF and DKIM records can be found here.

    Additional note: There is another form of email authentication that Google/Gmail is using called dmarc.

    If you have email that is either being rejected or is landing in the Spam folder at Gmail, look at the full headers (Show Original) and look for "dmarc=fail If you don't yet have a dmarc record, you can learn how to set one up here.

    There is a Feature Request for adding dmarc to cPanel's Email Authentication section.

    If you do get something back, then using the information at openSPF.org should help you decipher what the record is doing (or not doing). Then armed with that information you can go to the link in the error message (if one is provided) and find out why they are blocking the message.


    Not permitted to relay errors

    Another common message we see is this one:

    Code:
    Please turn on SMTP Authentication in your mail client. mx.someserver.net (mx.someserver.net) [xxx.xxx.xxx.xx]:4471 is not permitted to relay through this server without authentication.
    
    This is pretty self explanatory, and usually means that the MUA (Mail User Agent) which is usually Outlook doesn't have the "My SMTP server requires authentication" option checked.

    However, it can also mean that you have a script or program/application that is not authenticating properly before attempting to send email.

    UNKNOWN email address

    Here's a log entry showing a rejection due to an invalid email address:

    Code:
    2013-12-12 12:44:55 1Vr5dP-0004RG-6a SMTP connection outbound 1386852295 1Vr5dP-0004RG-6a someserver.com user.name@someserver.com
    2013-12-12 12:44:56 1Vr5dP-0004RG-6a ** user.name@someserver.com R=dkim_lookuphost T=dkim_remote_smtp: SMTP error from remote mail server after RCPT TO:<user.name@someserver.com>: host mail.someserver.com [xx.xxx.xxx.x]: 553 sorry, unknown email address;
    
    In this case, the person obviously tried sending to an email address that doesn't exist.

    No such user here (but with a slight twist)

    This one had us scratching our heads at first. See if you can figure out what is going on here:

    Code:
    2013-12-14 02:01:57 1VrkAf-0007F8-30 <= someuser@onthisserver.com H=localhost (onthisserver.com) [127.0.0.1]:53861 P=esmtpa A=dovecot_login:someuser S=853 id=a460ba02532956bad8e1b98fee9c5b12.squirrel@onthisserver.com T="test from cPanel - please ignore" for anotheruser@yahoo.com
    2013-12-14 02:01:57 1VrkAf-0007F8-30 ** anotheruser@yahoo.com R=virtual_aliases: No Such User Here
    2013-12-14 02:01:58 1VrkAf-0007F8-30 Completed
    
    See the R=virtual_aliases line? That means it is routing to a virtual alias on this server, and that user doesn't exist. But wait, it's going to a @yahoo.com account??? The problem here was that the server administrator added the following line to the /etc/userdomains file:

    Code:
    # grep yahoo /etc/userdomains
    yahoo.com: yahoo
    
    Obviously this server is not answering for Yahoo :) Simply removing that line from /etc/userdomains fixed that issue.

    Custom SpamAssassin Rules

    Let's look at SpamAssassin and a message that was marked as spam and bounced back to the recipient even though it really isn't spam at all. In the exim_mainlog file, you may see something like this:

    X-Spam-Status: No, score=0.8
    X-Spam-Score: 8
    X-Spam-Bar: /
    X-Ham-Report: Spam detection software, running on the system "server.somedomain.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email.

    This particular message got a score of 0.8 (less than 1) so it wasn't really flagged as spam, but as ham. Now, you may be asking your self, what the heck is ham?? "Ham" is email that is not Spam. In other words, "non-spam", or "good mail".

    So why was this message returned? It's not considered spam so shouldn't it have been delivered? Once again, looking at the exim_mainlog file, we see the following:

    Code:
    spamd[17011]: config: score: requires a symbolic rule name and 1 or 4 scores
    spamd[17011]: config: SpamAssassin failed to parse line, no value provided for "score", skipping: score 2
    
    Hmmm. Looks like a SpamAssassin configuration problem. Looking at:
    SpamAssassin Configuration Documentation, the correct syntax for using the score option, is "score SYMBOLIC_TEST_NAME n.nn" So a configuration of "score 2" is syntactically incorrect.

    Spam detected - Message bounced

    So here's one where spam was actually detected and the message was bounced. I've included this just so you can see what it looks like in your /var/log/exim_mainlog file.

    Code:
    2014-01-15 11:39:48 1W3TVL-003z0J-Lq H=(server.domain.com) [xx.xx.xxx.xxx]:44151 Warning: "SpamAssassin as server detected message as spam (26.2)" 2014-01-15 11:39:48 1W3TVL-003z0J-Lq <= A_SPAMMER@somespamdomain.net H=(server.domain.com) [xx.xx.xxx.xxx]:44151 P=esmtp S=11026 id=604.464760276.906@server.domain.com T="Update Your Biography" for innocentuser@somedomain.com 2014-01-15 11:39:48 1W3TVL-003z0J-Lq => /dev/null <innocentuser@somedomain.com> R=central_filter T=**bypassed** 2014-01-15 11:39:48 1W3TVL-003z0J-Lq Completed
    
    Here, you can tell that it was NOT delivered because of the "central_filter" and "bypassed" line.

    Filters... Friend or foe?

    What exactly is a filter? A filter is a way of processing and email message but with certain criteria. Common uses for mail filters include organizing incoming email and removal of spam or viruses.

    Code:
    2014-01-02 10:19:53 1Vykza-0005s5-La <= an_outside_user@someplace.net U=root P=local-esmtp S=449 T="This is a test message with filters" for newuser@cptest.net
    2014-01-02 10:19:53 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1Vykza-0005s5-La
    2014-01-02 10:19:53 1Vykza-0005s5-La => /dev/null <newuser@cptest.net> R=virtual_user_filter T=**bypassed**
    2014-01-02 10:19:53 1Vykza-0005s5-La Completed
    
    If you see this: (R=virtual_user_filter and T=**bypassed**), that means that a filter has been set up to discard or delete the message. You can also see that it was redirected to /dev/null. Let's see if we are correct by going to:

    Code:
    # cd /home/cptest/etc/cptest.net/newuser
    # ls -al filter*
    -rw-r--r-- 1 cptest cptest 339 Jan  2 10:13 filter
    -rw-r--r-- 1 cptest cptest 232 Jan  2 10:13 filter.cache
    -rw-r--r-- 1 cptest cptest 253 Jan  2 10:13 filter.yaml
    # cat filter
    # Exim filter
    
    # Auto Generated by cPanel.Do not manually edit this file as your changes will be overwritten. If you must edit this filter, edit the corresponding .yaml file as well.
    
    if not first_delivery and error_message then finish endif
    
    #Fubar Rule
    if
    $header_from: is "an_outside_user@someplace.net" then
    save "/dev/null" 660
    endif
    
    
    So, any message sent from an_outside_user@someplace.net is automatically deleted by saving it into /dev/null

    Those by the way are user level filters. For Account Level Filters, you would look in the /etc/vfilters directory.

    Blacklisted IP Address

    How about if your servers IP address is blacklisted? First of all, you can check to see if your IP address is blacklisted or that of the customers ISP. It's more common that your customer's IP address is blocked.

    Code:
    SMTP error from remote mail server after initial connection: host mx.ayahooserver.net [xx.xxx.xxx.xx]: 421 4.7.1 [TS03] All messages from xx.xxx.xxx.xxx will be permanently deferred; Retrying will NOT succeed. See http://postmaster.yahoo.com/421-ts03.html: retry timeout exceeded
    
    This particular message means that Yahoo's server has blacklisted you (or your customers IP address). You should check with them (using the link they provided) as to why. Notice that Yahoo is using a soft-error code (421)? They *should* be allowing retries and not state that Retrying will NOT success. It's technically against RFC.

    Here's a similar one from Google:

    Code:
    SMTP error from remote mail server after end of data: host ASPMX.L.GOOGLE.COM [74.125.129.27]:
    550-5.7.1 [xxx.xxx.xx.xxx 1] Our system has detected an unusual rate of
    550-5.7.1 unsolicited mail originating from your IP address. To protect our
    550-5.7.1 users from spam, mail sent from your IP address has been blocked.
    550-5.7.1 Please visit http://www.google.com/mail/help/bulk_mail.html to review
    550 5.7.1 our Bulk Email Senders Guidelines. xa2si10793227pab.345 - gsmtp
    
    Remember that you can use MX Toolbox to check an IP address to see if it is blocked on any other lists. No matter how you get on a blacklist, your first priority is to contact the blacklist and find out how to get removed. some lists, you don’t need to do anything; for others, you may need to make changes and prove that you have made those changes. The procedures are as varied as the lists themselves.

    Invalid PTR/rDNS (reverse) record

    rDNS (Reverse or PTR). Another common problem with email being returned is if the IP address that you are using to send email from does not have a PTR (or rDNS/reverse DNS) record set up. Let's use cPanel's MX IP address to test this:

    Code:
    # dig -x 208.74.121.68 +short
    mx1.cpanel.net.
    
    That happens to be correct, so we know that mx1.cpanel.net points to 208.74.121.68 and the reverse of that IP address points back to mx1.cpanel.net. If you get back nothing at all, or something other than what you expected, then that can be a problem as some mail servers will reject email if the PTR does not match or is missing. To set up an rDNS properly, your ISP/Hosting provider, NOC or Datacenter must have delegated the IP address to you. The following documentation will show you the steps you need to set up your own rDNS.

    If they have NOT delegated the IP address to you, then they will need to set up the proper rDNS entries for you.

    Invalid entry in /etc/resolv.conf

    An invalid /etc/resolv.conf file can also hinder delivery messages. In that case the log file may look something like this:

    Code:
    2014-01-02 12:45:59 1VynH0-0006D0-Oc <= newuser@cptest.net U=root P=local-smtp S=417 T="Test2" for some.user@gmail.net
    2014-01-02 12:45:59 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1VynH0-0006D0-Oc
    2014-01-02 12:46:00 1VynH0-0006D0-Oc == some.user@gmail.net R=dkim_lookuphost defer (-1): host lookup did not complete
    
    So if your /etc/resolv.conf file contains an IP address that can not resolve gmail.com then this is a problem. Once fixed the same message can be seen as having been successfully sent.

    Code:
    2014-01-02 12:48:52 1VynJq-0006DL-OO <= newuser@cptest.net U=root P=local-smtp S=425 for some.user@gmail.com
    2014-01-02 12:48:52 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1VynJq-0006DL-OO
    2014-01-02 12:48:57 1VynJq-0006DL-OO => some.user@gmail.com R=dkim_lookuphost T=dkim_remote_smtp H=gmail-smtp-in.l.google.com [173.194.77.27] X=UNKNOWN:ECDHE-RSA-AES128-GCM-SHA256:128 C="250 2.0.0 OK 1388688538 jb8si45146276obb.27 - gsmtp"
    2014-01-02 12:48:57 1VynJq-0006DL-OO Completed
    
    Sender verify failures

    Here's one where the server shows Sender verify failed...

    Code:
    SMTP error from remote mail server after RCPT TO:use@somedomain.com: host someserver.com [xxx.xxx.xxx.xxx]: 550-Verification failed for root@host.someserver.net 550-The mail server could not deliver mail to root@host.someserver.net. The account or domain may not exist, they may be blacklisted, or missing the proper dns entries. 550 Sender verify failed
    
    In this particular case, the problem was that there was no A record for the host.someserver.net account. The error message was pretty much right on the money with the account or domain may not exist.

    Once the customer was advised to add an A record, the problems went away.

    FQDN Problem

    Here's another interesting error...

    Code:
    2013-12-24 13:08:21 H=mail.someserver.com [xx.xxx.xxx.xx]:56035 F=<bounce-452_HTML-12895432-34269-7000791-787@bounce.someserver.com> temporarily rejected RCPT <USER.NAME@DOMAIN.COM>: remote host address is the local host
    
    This was caused because the host name was not a Fully Qualified Domain Name (FQDN). To fix this, make sure your hostname for the server is always a FQDN.

    Summary

    As you can see there are dozens of reasons why an email message may not be delivered. Log files don't lie, and they will always be able to tell you why the message could not be delivered. It just takes a little research on your part. I hope that the above information is helpful to you and if you have anything to add to this please let me know.

    As an additional note, if you haven't read it yet, I recommend reading the SPAM Primer by Randy Cassingham. This truly explains in laymans terms what spam is, who sends it, and how they got your email address in the first place.

    Please feel free to post questions or comments below. I'm sure there are dozens of other reasons for mail delivery failure that I have not covered in this post. The point however is that you should always check the log files and remember that email does NOT just disappear.

    Thank you,
    cPanelPeter
     
    gaza331, Jabir and vdc like this.
  2. sawbuck

    sawbuck Well-Known Member

    Joined:
    Jan 18, 2004
    Messages:
    1,367
    Likes Received:
    5
    Trophy Points:
    38
    cPanel Access Level:
    Root Administrator
    Thanks Peter for bringing this together in one location.
     
  3. _brendan

    _brendan Registered

    Joined:
    Mar 20, 2013
    Messages:
    1
    Likes Received:
    0
    Trophy Points:
    1
    cPanel Access Level:
    DataCenter Provider
    When using an external filter service, the "Mail Exchanger" configuration needs to be set to "Local Mail Exchanger". Else, what happens here is that with the default config of "Automatically Detect Configuration", cPanel automatically detects that the MX record "points elsewhere" and disables local delivery. The end-result is that when the filter service attempts to deliver the mail, the server responds with the "Please turn on SMTP Authentication" error above.

    Currently there is no feature to tell cPanel that the MX IP address(es) is/are "local", thus you have to manually (or via default-config/script) ensure that the mail is set to "Local Exchanger" explicitly.

    An alternative, if the MX IP addresses are *NOT* used by the inbound filters to deliver *to* the cPanel server, may be to put the MX IP addresses onto the "lo" interface (remember to enable ARP filtering!), thus ensuring that the server *thinks* the IP address is local, thereby ensuring that "Automatic" works as intended.

    Though the server admin may have configured this correctly in the beginning, there isn't much to stop resellers/end-users from breaking the configs when they see the "recommended" text next to the "Automatic" option.
     
  4. syam1353

    syam1353 Registered

    Joined:
    Aug 7, 2014
    Messages:
    1
    Likes Received:
    0
    Trophy Points:
    1
    cPanel Access Level:
    DataCenter Provider
    As for Gmail, any email account @mydomain.com are still being routed directly to
    the "Spam" folder. I have not heard any reported issues with other
    major email providers. Just Gmail. But I tested it myself yesterday sending to
    my own Gmail account and the email was delivered to the Spam folder. I am
    completely stumped with regards to what is causing this issue, but it is
    becoming a problem as Gmail is such a popular email provider and we have many
    clients with Gmail addresses. I am not sure how this can fixed and also not sure
    as to why the situation is not being replicated on your end.
     
    #4 syam1353, Aug 7, 2014
    Last edited by a moderator: Aug 8, 2014
  5. crazyaboutlinux

    crazyaboutlinux Well-Known Member

    Joined:
    Nov 3, 2007
    Messages:
    938
    Likes Received:
    0
    Trophy Points:
    16
    superb explanation about NDR
     
  6. Mark Francis

    Mark Francis Registered

    Joined:
    Oct 31, 2014
    Messages:
    1
    Likes Received:
    1
    Trophy Points:
    1
    Location:
    Perth, Western Australia, Australia
    cPanel Access Level:
    Website Owner
    I would like to point out that in some situations, emails cansimply disappear. Some ISPs silently delete incoming emails that they consider to be spam. They do not send it to a spam folder, nor do they reply with a bounce message. The email is simply deleted.

    One such ISP is Heart Internet, which is why I took my business elsewhere after they started deleting emails from - Removed -, which is a perfectly respectable peer-to-peer finance business.
     
    #6 Mark Francis, Oct 31, 2014
    Last edited by a moderator: Nov 1, 2014
    ritchiestreet likes this.
  7. cPanelPeter

    cPanelPeter Technical Analyst III
    Staff Member

    Joined:
    Sep 23, 2013
    Messages:
    569
    Likes Received:
    15
    Trophy Points:
    18
    cPanel Access Level:
    Root Administrator
    Twitter:
    Hello,

    They are not really supposed to delete messages. However, spam is not considered to be legitimate email so if a message has been determined to be spam (spam score in the double digits), I personally have no problem with the ISP deleting it for me. I always recommend reading the terms and conditions carefully and I expect they'll be covered for deleting the if they are coming in via a known cluster of spam servers. I would expect an ability to whitelist however.
     
  8. justjaph

    justjaph Member

    Joined:
    Oct 17, 2013
    Messages:
    8
    Likes Received:
    0
    Trophy Points:
    1
    cPanel Access Level:
    Root Administrator
    That is particularly true with M$ services (hotmail/Office365/live.com/outlook.com): the message is "250 accepted for delivery" and then disappears in some blackhole without any warning to either parties whatsoever.

    The topping on the cake is that there isn't a way to know if the email sent from your IP addresses is or isn't "sinkholed" until your customers start reporting that their messages aren't going anywhere fast (and then the "delist" process that is a (bad) joke)...

    Regards,
     
  9. arjunrishi

    arjunrishi Registered

    Joined:
    Feb 21, 2015
    Messages:
    1
    Likes Received:
    1
    Trophy Points:
    1
    cPanel Access Level:
    Website Owner
    Good explanation , thanks a lot . its very use full for me also.
     
    Nguyen Van Tuan likes this.
  10. mutilateadoll2

    mutilateadoll2 Registered

    Joined:
    May 31, 2015
    Messages:
    1
    Likes Received:
    0
    Trophy Points:
    1
    Location:
    USA
    cPanel Access Level:
    Website Owner
    This is what I need to solve the same problem of email delivery! Thanks much!
     
Loading...

Share This Page