-3

Someone is sending spam emails and is making it look like it was sent from my domain. How can i stop this email spoofing via cpanel. I read about SPF somehwhere.

Here is what my SPF in cpanel says 

Your current raw SPF record is : v=spf1 +a +mx +ip4:ipaddress -all

What can i do to prevent this?

user3455531
  • 775
  • 1
  • 14
  • 28

2 Answers2

2

There is nothing you can do to stop them from sending email that is spoofed. You can send an email and have it look like it's coming from anywhere, and your outgoing email server (if configured to accept it, which spammers obviously would) and it will accept it. Adding an SPF record might reduce the number of those emails received by people.

You need to add (or append) to a TXT record in DNS.

v=spf1 include:your.email.domain.here -all

You can include more domains by adding another include: like:

v=spf1 include:blah1.blach1.com include:blah.blah.com -all

Hope that helps! Email is basically the most insecure protocol in existence.

Paul Frederiksen
  • 384
  • 2
  • 8
1

You absolutely CAN stop spoofing. Have been doing it for 30+ years (before cpanel, etc.).

Regarding spoofing-- require all your users to authenticate before sending, this is the easiest way to stop spoofing on sendmail (see below for difference between spoofing and forgeries). If you are trying to block forgeries there are tools in the CPANEL (WHM) interface for require FQDN, EHLO, DKIM, etc. and other settings that will help you with this.

Also, check this thread out: https://www.webhostingtalk.com/showthread.php?t=669800

For more info on how to stop it on non-cpanel systems, continue reading. The concepts will help you understand what to change on cpanel systems as well.

The key rule to fight spoofing is that no email going through your MTA that is not on a "trusted" (e.g., internal) network should be allowed to have the sending and receiving domains be the same. Alone this will stop all spoofing. Once this rule is in placed, you add 2 more rules. The first says that internal "trusted" networks are exempted from this rule (thereby making external networks affected). The second rule is that any external connection that authenticates (username/password, etc.) is exempted from this rule. That allows your traveling sales team to send/receive email through your corporate server.

With sendmail you must require all connections to send a FQDN and that all FROM/TO address be fully qualified (so you can check the domain part).

In sendmmail.cf:

PrivacyOptions=needmailhelo,needexpnhelo,needvrfyhelo,restrictqrun,restrictexpand,nobodyreturn,authwarnings

By default in Sendmail 8.9 and later relaying from any network that is not considered "localIp" is denied via the checkrcpt() routine. So external email should only be "inbound" (unless being authenticated) and it should not have a sending domain matching your domain (unless authenticated).

Forging vs. Spoofing

There is a lot of confusion about "forging" and "spoofing". Forging is when someone sends an email claiming to be from one domain but they actually are not (such as someone pretending to be paypal). Spoofing is when an email outside of a network (e.g., outside of a business firewall) is sent to someone inside the network and both the sender and recipient have the same domain. This should never happen without the outsider being required to use authentication to bypass rejection. The reason is, that if you control an email network nobody outside your network should be originating email on your behalf without you knowing about it. If you know about it then there are various ways to adjust settings to allow it. But adjusting MX, SPF records etc. to stop spoofing is wrong. That is for identifying and stopping forgery.

Before we talk about solving spoofing in more detail, the best way to block forgeries is:

  1. require EHLO with fqdn verify sender PTR record matches and
  2. if not verify SPF It would be nice to use Domainkeys/DKIM, but the RFC states that if Domainkey/DKIM can't be valided you are supposed to treat it as thought it isn't there (so invalid DKIM should be ignored)... frustrating. If you do decide to block emails with bad/missing DKIM you will block almost everybody using ON365 as it's almost universally misconfigured.
  3. Use your access map to block foreign countries, etc., from which you never expect to get email
  4. Update your firewall to block networks you know are a problem.

I have learned a lot over the years with some hard lessons as I have administered email for some of the largest clusters/networks/providers in the world and some of the most well known dot-coms. Email is not an island unto itself. It is requires a tight integration with your DNS and firewall team and basics such as split-horizon DNS, DMARC, DKIM, SPF and good clean A/PTR records are critical to help manage the flow and authentication of valid email. Do not allow anybody from the outside to connect to port 25 to relay email (unless authenticated). Only internal users should be able to send OUT and external users be able to send IN. If someone inside is sending to someone inside, then they are connecting on the internal mail-servers port 25 and it is "trusted".

The best configuration works like this (does not matter what your MTA):

  1. mailserver is inside a physical firewall.
  2. barracuda or other anti-spam server is also inside firewall or dmz.
  3. port 25 into your mailserver is blocked from the outside, but allowed to your anti-spam/spamfirewall device
  4. your MX tree is set up so that your mailserver is the primary, but because it is not reachable from the outside, everybody will fall back to your secondary (which is your anti-spam device).
  5. Only your anti-spam device or internal-trusted systems should be allowed to connect to your mailserver directly.
  6. Use your firewall to prevent any internal system from sending email outside directly (unless you have a very good reason) and force them all to go through your internal mailserver to get outside (this is the number one way to prevent spam on the Internet and every ISP should do it)

Also, if you are using exchange, this will break inbound email because exchange needs more MX detail SOOOO (and it's a good idea anyway), you need to create a domain-level MX to your mailserver at the highest priority, but you ALSO need to create host-level MX, as follows (exch01 is your primary mail server):

@              IN       MX      10       exch01.mydomain.com.
@              IN       MX      20       barracuda.mydomain.com.
@              IN       MX      30       tertiary.externalmxprovider.xyz
exch01         IN       MX      10       exch01.mydomain.com.
exch01         IN       MX      20       barracuda.mydomain.com.
exch01         IN       MX      30       tertiary.externalmxprovider.xyz
barracuda      IN       MX      10       barracuda.mydomain.com.

Make sure this information is advertised both internally and externally in your DNS.

I also recommend using your spam firewall as an outbound relay for your corporate email so that you can prevent from sending spam going out (in case an employee's computer get's compromised). Just configure your internal mailserver to use the anti-spam device as your "smart relay" for outbound mail.

If you need help doing this please let me know. Happy to help. I'm happy to help with any email, dns, or firewall configuration issue (dmarc, dkim, spf, etcx.)

David

TekOps
  • 179
  • 2
  • 5