This question comes on the heels of the question asked here.
The email that comes from our web server comes from an IP address that is different than that for the Exchange server. Is this okay if the SPF and Domain keys are setup properly?
Short answer: Yes
It should just fine. However some spam filters will do a reverse lookup on the originating IP address and see if it's assigned to the domain name the email claims to be from, and some may check to see if the IP is an actual MX for the domain.
So the downside is that some recipients may never get the email, and you may not know about it for a long time. I'd suggest routing your mail through an established MX rather than having a webserver do it directly (there are some security implications there too).
Related
I'd like to set up custom domain authentication using DKIM and SPF for our 3rd party email marketing company (like mail chimp or constant contact). We also run MS exchange. Our Exchange guy is convinced that setting up DKIM and SPF for email marketing company will forever tie the reputation of the email marketing company to our exchange server. Is he correct? If not, how do I convince him?
I think I have enough info now to make this an answer...
Yes, if this is a permission-based list that you have sent to recently (if it's old that means likely spam traps) then I think you are correct that there's not much risk at all.
One way to convince this person would be to find out what IP address your MailChimp emails originate from (maybe send to a small list with just yourself on it but a real send). And then check out the reputation of this IP address using the tools available such as MX Toolbox and others, then show him the output. I'd be surprised if your Mailchimp assigned IP address was on any blacklists or had reputation issues
When he says exchange server is he talking about your company domain name taking a reputation hit? Or is he worried about the IP address from which you send non-marketing email? If he's worried about a separate IP that you send day-to-day email from then explain to him that your marketing emails will go out from a Mailchimp assigned IP address. If he's worried about the domain two things: 1. Your list is opt-in and you've sent recently so it's not an issue 2. If it was a bad list that would cause your domain to be blacklisted then whether you have DMARC, SPF, and DKIM doesn't matter, the originating IP that sends spam can get blocked for spamming regardless.
So I think you are right here but it's a matter of making the case.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 4 years ago.
Improve this question
I have recently acquired a domain name via Google Domains. I have set some configuration to have it point at an OpenShift application via Cloudflare. Cloudflare requires me to set their DNS servers, which I did in Google Domain.
At Cloudflare, I have created two CNAME records (and nothing else). One is an alias from my mydomain.com to some.url.at.openfshit.com, and the other is from www to mydomain.com.
Yet, within Gmail Domain, I have also set an email using my domain name which is to be forwarded to a private email. But, I don't receive any emails when testing.
I am wondering whether I could have my emails forwarded properly. Is it a matter of creating a MX record at Cloudflare? If yes, with what configuration?
P.S.: I have set a MX record using instructions available here, but I get:
Delivery to the following recipient failed permanently:
contact#mydomain.com
Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the server for the recipient domain chartvibes.com by aspmx.l.google.com. [2607:f8b0:4001:c20::1b].
The error that the other server returned was:
550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1 https://support.google.com/mail/answer/6596 p123si522326ioe.111 - gsmtp
The MX records you're using are for G Suite accounts. You can still forward emails with Cloudflare and Google Domains, but you'll need different MX records. As Overdrivr pointed out in a comment below, you can find your MX records in the DNS settings in Google Domains. Once you're in the DNS settings page, look for a collapsible panel called "Email forward" under the "Synthetic records" section. You should see something like this
Then, make a backup of your Cloudflare DNS setup, erase all MX records and add the ones listed in your account using the number right before the mail server (e.g., 5, 10, etc.) as its priority.
It might take a few minutes for the changes to take effect. If you try to send an email right after changing the records, it's likely that you'll get a message saying that the address could not be found, but it'll have the G Suite mail server in the Remote-MTA field (aspmx.l.google.com) instead of gmr-smtp-in.l.google.com. If this is the case, just wait for a few more minutes and try again
I'm not sure if you already have a solution to this, but if you do, I'm interested in how to do it too. Could you please post your solution here if you find one ?
The bad news is, it cannot be done because the way Google Domains work. Google Domains has email forwarding, but it works only when you're using Google's DNS servers. It's the same with all hosting services or whatever they're called.
I think Google just has an email forwarding service that can forward upto 100 alias email addresses per domain to an actual email address. But the actual email address has to exist somewhere. The ones you set up in the Domains console are just aliases or forwarding instructions.
For Cloudflare email forwarding to work, you need to use the SMTP servers where the actual email addresses exist, but since Domains has no actual email service servers, the emails sent out are failing with email account does not exist. The instructions you mentioned are for the Google Apps, which have actual email/gmail addresses set up, but they cost $5/user/month.
The only solution that I can think of to get around this issue is to have our own mail server, and have cloudflare point to those, and then forward/deliver the emails from that mail server.
Hope this helps.
EDIT :
I probably didn't research this well enough before, but looks like people are getting around this issue by using a third party email forwarding service called mailgun
The actual article describing how to use it is on lowendtalk
Some discussion surrounding it is here
I think what I need is some general explanation as to how this works, but here is my problem.
I have a dedicated server with 1&1, everything is working perfect, I have several clients' websites on the dedicated server all running through different domains that I have purchased through 1&1.
The server is running ZPanel (Not for long, so please spare me the "risky choice" speech), and I have setup some mailboxes that RECEIVE e-mail perfectly!!! When it comes to sending e-mail, it doesn't for some recipients, and for others it goes straight to SPAM/JUNK.
What could be happening here? I understand it is a vague question, I can only assume the domain DNS settings are correct otherwise e-mails wouldn't be received at all right? Is this a mail server problem?
The dedicated server is running Linux 12.04-ish.
Any questions to help I am more than pleased to answer.
Thanks
From the top of my head, in order to avoid being flagged as spammer you will need a pointer record PTR mapping your domain to your ip address and a SPF record.
How it works:
Spam filters will check if your ip address belongs to the domain you're claiming it does. So it will do a reverse DNS lookup and if you don't have a PTR record it will flag the email as possible spam.
In addition to reverse dns lookup, some spam filters will also check the SPF Sender Policy Framework rules, if your ip address is not included in that rule it will flag the email as possible spam.
Take a look at rackspace email server:
tiago#dell:/tmp/test$ dig mx1.emailsrvr.com +short
108.166.43.1
Reverse DNS:
tiago#dell:/tmp/test$ dig -x 108.166.43.1 +short
mx1.emailsrvr.com.
SPF:
tiago#dell:/tmp/test$ dig txt emailsrvr.com +short
"v=spf1 ip4:67.192.241.0/24 ip4:98.129.184.0/23 ip4:173.203.2.0/25 ip4:173.203.6.0/23 ip4:50.57.0.0/27 ip4:108.166.43.0/24 ip4:173.203.187.0/25 ip4:204.232.172.40 ~all"
http://en.wikipedia.org/wiki/List_of_DNS_record_types#PTR
http://en.wikipedia.org/wiki/Sender_Policy_Framework
Thanks for the answer.
It turns out my Dedicated Server IP address was blacklisted which made Hotmail throw a hissy fit. Here is a tool you can use to check if your IP has been blacklisted: http://www.anti-abuse.org/multi-rbl-check/
It turns out, to be more specific about this issue, that I was using ZPanel which pretty much automatically blacklists IPs running ZPanel due to the obvious security flaws.
Thanks very much for the original answer and it did help me eventually track this problem down.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 4 years ago.
Improve this question
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?
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.
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:
require EHLO with fqdn verify sender PTR record matches and
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.
Use your access map to block foreign countries, etc., from which you
never expect to get email
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):
mailserver is inside a physical firewall.
barracuda or other anti-spam server is also inside firewall or dmz.
port 25 into your mailserver is blocked from the outside, but
allowed to your anti-spam/spamfirewall device
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).
Only your anti-spam device or internal-trusted systems should be
allowed to connect to your mailserver directly.
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
I don't understand this "reverse dns" thing at all.
So, I have a website - www.someurl.com, and I have an ip address - http://180.160.160.190 (fake).
Now, I want to setup a "reverse dns" thing, so that emails that I send out won't be marked as spam.
Questions!
why do i have to setup a "reverse dns" thing? What is it, and why do gmail, hotmail et al care about it?
all the examples online say I need to setup the "hostname" as mail.someurl.com (well, they say mail.domainname.com, but I cleverly solved for x). What the heck is a "hostname" and what is a "url"? The wikipedia page for hostname left me v. confused.
is a url a domain name? it sure isn't a hostname (i hope).
back to the mail.someurl.com hostname - why is it "mail" in the examples? Can I fecklessly set the value to "hello" or "mooseymooseymoose" (so it would be mooseymooseymoose.someurl.com)? Does it have any relevance to anything at all?
if i am sending emails out as no-reply#someurl.com, does that have any bearing on the first bit of the hostname? that is, should they come from "mail#someurl.com", given a hostname of mail.someurl.com?
cheers, andrew
It's an artificial requirement that was adopted under the assumption that spam servers wouldn't take the time to setup their rDNS (or wouldn't be able since they usually got setup in rogue environments like infected PC's), and legitimate servers would. There is no technical requirement to have a rDNS for the email protocol to work, and not every mail server does this check.
The hostname is the name of your machine within your internal network.
URL stands for uniform resource locator, it's the fancy name for stuff that looks like "http://www.google.com/page1/page2". a domain name is simply the base of the URL, for example google.com. It's always of the form domain.tld (domain name and top level domain like com, net, org)
Yes you can set it to anything you want. Mail protocol doesn't require you to hardcode the name to anything in particular. Ultimately, it's your domain's MX record that decides where the mail server handling its emails is located at, and you can point it to anything.
Not necessarily. Mail servers can send e-mails on behalf of several domains, a mail server isn't limited to sending emails from its hostname only. The "From" part of the e-mail header will tell the mail client where it's coming from.
Hope that helps clear up a few details.
Its to make sure that the email is coming from a verified source. Emails sent to anyone can display ANY email address on it, making it easy to spam and pish people. Thats why they use reverse DNS, to verify that the domain sending the email is yours.