Prevent blacklistings

We use google for email.  I have blocked smtp at the firewall on our network.

We recently just got blacklisted again... not sure how yet.... I will be looking into that... but in the meantime I am trying to figure out if this really needs to happen.

So say we have a spambot on our network... why should people be refusing email from google's servers?   It's not as if the spam bot on our network can send mail from googles servers.  I assume this probably has something to do with the fact our domain name has subdomains that point to the firewall for our network... and so it's being blocked because the domain on the email matches the domain tied to an IP that someone saw some spam from.  

I don't know a lot about it, but this seems excessive to me.  I mean, sure, block email originating from the same IP as the spam... but if it comes from an IP (i.e. google) that you don't see spam from, them why block it?  

In any case - is there something I can do, DNS wise, to prevent a spam bot on our network getting use blacklisted such that people are refusing our email send from google servers?  (Granted... I know we need to get rid of the spam bots.... but not interrupting our perfectly safe business email in the meantime would be preferable)
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

btanExec ConsultantCommented:
typically if you have client (or becoming a spambot) sending out bulk emails or bounce email storming out using the domain, the chance of blacklisting is pretty high. indeed it is to identify that client and block its outbound email..likely also that the client is infected with malware (like waledec) hence the spam storming. ideally is to clean up that client (or clients). See this use case
I recently took over a client network with the same issue as yours and was running into road blocks at getting them delisted with a few of the more questionable RBL list providers. So, I contacted my clients ISP and obtained a second public side IP address, setup a one-to-one NAT from the new public IP to the internal IP of the Exchange server, updated the DNS / MX / SPF / PTR records with the ISP and hoster, and the problem was resolved. I have since successfully removed the original public IP from all RBLs. This will provide some level of future protection in the event my client gets hit with another spambot, etc., in that the Exchange server public IP should not be affected by the issues with the browsing public IP.
an online  tool to check for spambot specifically (if are in the CBL listing, you can delist it, see its FAQ first) (checking your email server)

also other case is that your dns server is being used as inadvertently as Open DNS servers for recursive call OR email server being used as Open Relay to send out email storm per se and causing distress to other machine and in turn is being blacklisted. Do check out using dnstuff on your domain to see your DNS and Email (MX) checks on the security posture to further lockdown if required, replace the "" with your domain e.g.|type=domain&&

Having publish SPF records and sign messages with DKIMused for email server and authentication will be good and if poss even to go for DNSSEC (they are part of the dnsstuff checks too...). Also make sure your client is not doing mass mailing from their Exchange server (as opposed to using a service like Exact Target or Constant Contact).

Regardless, further on the preventive front, some good practice to avoid being blacklisted are as below for considerations
To help ensure that your messages aren't flagged as spam, we also recommend that you:

Automatically unsubscribe users whose addresses bounce multiple pieces of mail.
Periodically send confirmation messages to users.
Include each mailing list they are signed up for, and offer the opportunity to unsubscribe from those in which they are no longer interested.
It's possible that your users forward mail from other accounts, so we recommend that you:

Explicitly indicate the email address subscribed to your list.
Support a URL method of unsubscribing from your mailing list (this is beneficial if your mailing list manager can't tell who is unsubscribing based on the 'Reply-to:' address).
If you send both promotional mail and transactional mail relating to your organization, we recommend separating mail by purpose as much as possible. You can do this by:

Using separate email addresses for each function.
Sending mail from different domains and/or IP addresses for each function.
If others use your service to send mail (for example: ISPs), you are responsible for monitoring your users and/or clients' behavior.  

You must have an email address available for users and/or clients to report abuse (
You must maintain up-to-date contact information in your WHOIS record, and on
You must terminate, in a timely fashion, all users and/or clients who use your service to send spam mail.
You need to monitor traffic, at least by recording all 25/tcp attempts or by netflow, for same traffic.
How do you think spambot bypasses firewalls that block the port?
Daniel McAllisterPresident, IT4SOHO, LLCCommented:
OK - I was thinking about adding to this discussion, but it then dawned on me:
 - 1 - if you're using Gmail for mail, your block may (must) be coming from THEM, not the endpoint (recipient) -- otherwise, you wouldn't have even noticed it!
         if your messages are bouncing due to blacklists, you must NOT be sending via gmail's servers... you must be routing directly, which is out-of-compliance with your gmail hosting agreement...
 - 2 - if you're using Gmail for mail and your own IP address appears on a blacklist, other than being thorough and a good netizen, why do you care? You don't send LEGITIMATE mail from your own servers ANYWAY, so you shouldn't really care
       NOTE on being a good netizen: if you're using Gmail for mail, set your SPF record to indicate as much:
             v=spf1 -all
       This way, if someone ACCEPTS mail from your own location (not GMAIL), it's their own fault -- you already TOLD them (in the SPF record) that your mail is supposed to come from Gmail

My point is that something is either fishy or missing here...

Defend Against the Q2 Top Security Threats

Were you aware that overall malware worldwide was down a surprising 42% from Q1'18? Every quarter, the WatchGuard Threat Lab releases an Internet Security Report that analyzes the top threat trends impacting companies worldwide. Learn more by viewing our on-demand webinar today!

XetroximynAuthor Commented:
I figured out what happened... I temporarily disabled the smtp block on our network when I was toubleshooting something... (Setting up our NAS to send warning emails to me via googles smtp relay...)  (As you may have guessed the smtp block has an excaption for the NAS and certain servers that send warning emails to myself like this)

That said...

if you're using Gmail for mail, your block may (must) be coming from THEM, not the endpoint (recipient) -- otherwise, you wouldn't have even noticed it!
         if your messages are bouncing due to blacklists, you must NOT be sending via gmail's servers... you must be routing directly, which is out-of-compliance with your gmail hosting agreement...

Actually the block is from the endpoint servers... and I am seding through google, not directly smtp.... google sends a message back to me telling me the end recipients server rejected the message due to "greylist"

Technical details of temporary failure:
Google tried to deliver your message, but it was rejected by the server for the recipient domain by [].

The error that the other server returned was:
451 4.7.1 greylisted for 10 minutes and 0 seconds.

Open in new window

NOTE on being a good netizen: if you're using Gmail for mail, set your SPF record to indicate as much:
             v=spf1 -all

Aha!  I guess this is it... I have spf set up to google but also our self for those limited cases where we send emails to ourselves... like warning emails from NAS's or scans emailed to ourselves from our scanner.  (the only devices that SMTP is not blocked for)

I guess that is why a black list on our IP, causes email from google to still be rejected?  Still seems really odd to me... So what I have 2 things listed in my SPF... if only one of them is blacklisted why block mail from the other one?

Guess I don't need to understand really... seems strange to me though

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
btanExec ConsultantCommented:
greylisting happens if either below happened.
an anti-spam technique whereby a recipient MTA does not allow a message triplet (Sending Server IP, Mail From and RCPT To combination) that has not been recorded as having successfully delivered an email within a configurable amount of time.

a) you use to send email is not RFC 821 compliant

b) misconfigured to not automatically retry email messages that gets rejected with the "try later"-message. Maybe it's timing is off and it retries immediately (which it shouldn't)

c) recipient email server has got greylisting misconfigured, ie. an implementation that just doesn't let mails through even on later retries. Or maybe their error message is actually wrong: greylisting was not the reason your mail bounced - but something else.

Eventually, Google has this to say - Message delays due to greylisting. The long short is the whitelisting via SPF should work if those domain is added like google (which they have it done) and yours (which you added in).
With greylisting, the recipient domain temporarily rejects messages from IPs that it may not recognize, with the expectation that if the message is legitimate the sender will try again. However, Gmail may not always retry from the same IP. As a result, messages sent from Gmail to a domain that employs greylisting may be delayed.

If you are a domain owner and you're finding that messages from Gmail are delayed, we recommend not using greylisting, and instead use SPF or DKIM authentication to ensure fewer message delays from Gmail. If using SPF or DKIM isn't feasible, then we recommend whitelisting and specifically.
But SPF is not foolproof, it fails if someone forwards email to another server.  By default, the forwarding server is not listed in the SPF entry and the destination mail server will (correctly) reject the email.
XetroximynAuthor Commented:
I figured out why the blacklisting happened on my own... but I appreciate everyone's advice!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.