I train customers how to use Emarketing tools. One important thing I tell them they have to do is have their IT set their Email domain DNS to allow the emarketing domains to send on their behalf via an SPF record and I give them most all the settings. Until this one current client where their IT is refusing to create one. My understanding is if they don’t, at minimum, all their Emarketing emails will basically all go to junk/spam or even get them blacklisted in places. So... is there a potential downside to making an SPF record that would make this person so adamantly against creating one?
The main downside of making an SPF record that actually helps deliverability (by confining mail sources) is that you have to know and limit the sources from which email may be sent, and that's not necessarily easy.
Say your domain is example.com and you want to send email from that domain using your gmail account (though gmail is not used to handle your domains email); your SPF would need to include gmail's SPF, and it therefore means that anyone on gmail gets to be able to send in your domain's name from gmail (other measures notwithstanding). Now imagine you're a big company and you have a long history of having employees routinely send email from company addresses using their local ISP. Your SPF needs to become very large, or very dumb, and includes so many email sources it becomes ineffective as a countermeasure.
Reluctance to have to deal with user complaints when you say that all outbound mail must go through company mail servers (when you have a long history of not requiring that) would be painful for a lazy IT support department. I have no sympathy for this policy - you reap what you sow.
You can of course have an SPF record "in name only" by having it set to something useless like +all - that would get a technical SPF "pass" for all sources, but in all other respects it's completely useless, marking fraudulent, spam & phishing messages as equally valid as legit email.
Any IT department that wilfully ignores the benefits of SPF is eventually going to have a major problem with deliverability and phishing, so you can reasonably argue they are failing to do their job, and I'd recommend reporting them to higher management.
Related
I purchased my domain through Google Domains. It's awesome because you get up and running with almost everything pre-configured for you.
Until you want to change a few things!
I'm using AWS SES to send emails from my platform through this domain. This means I need to tell DNS to allow SES to send emails on behalf of this domain by adding an SPF record.
According to RFC4408 a domain cannot have multiple SPF records. And this is where things get complicated.
Out of the box, Google Domains gives you pre-configured Synthetic Records, SPF being one of them:
There is no way to edit these pre-configured Synthetic Records and clicking on the Delete button feels intimidating.
There is a section to add Customer DNS Records but that would mean that RFC4408 would be violated.
How do you resolve this?
I don't think you have any choice; you need to scrap what they provide and build your own set manually. It shouldn't take you long – there are not many records there. You can probably drop the SPF-type record safely, leaving just the TXT one.
The RFC violation is a factor, but the practical reality is that no receiver will check for more than one SPF record (because of the RFC), so it wouldn't help even if you did add multiple SPF records.
Most important though – keep an accurate record of exactly how it was originally configured so that you can get back to it easily!
using email analysis we can find senders IP address through some tools only if they are from different domains like senders sends from yahoo mail to gmail user.
How to find senders IP if they are from same domain?
example:
from: abcd#gmail.com
to : wxyz#gmail.com
while in email analysis iam getting senders IP as google servers IP
What you can actually achive with any tools depends very much on whose IP address you want to find out:
If you want to get the address of the client, on which a user probabply typed the email and from which it was transferred to its provider's Mail User Agent (MUA), forget it. As long as you are not a government with the appropriate court decision or very good friends with the server operator, the latter one will not give you even slightly sensitive information about its clients, also not the IP address.
If you want the IP address of the MUA of the client's mail service provider, you have much better chances. Assuming that the from field is correct, then just check out which addresses this provider uses. Gmail has probably a lot of various server machines and I think you might not find the exakt IP of the server the sender's client connected to. If the from field is manipulated (junk mail), Gmail's Mail Transfer Agent (MTA) will probably reject the mail, so that it will never arrive in your inbox anyway.
The sender and the recipient may use different mail service providers, in that case your provider's admin could have a look into the server's log files to find out from which IP address the recipient's provider's MTA was connected. However, usually this is absolutely irrelevant, as long we are dealing with two respectable organizations. Also you explicitly mentioned that in this scenario, it is one and the same provider.
Finally, you can find out the address of your own MUA, but I think that has nothing to do with the author of the email.
So, in conclusion: technically you can't. The only really interesting information is the address of the client used by the author of the email. Google is a respectable enough company to never ever give this information to you, except if the sender's mail client explicitly wrote it into the mail header, which it probably never will.
If you want the IP address because of criminal activity or any kind of abuse by the sender, just contact Gmail. If that does not help, file a lawsuit. The latter one may actually take a long breath until you (may!) be successful, so be sure if your situation is really that bad.
However, if you have a lot of criminal energy you could use the more general metadata from the header to create a profile of the sender's client, like which client software of which version he*she uses and more. But I think this is going to be very, very much work until you get more relevant information (and it should be).
It would actually be very helpful to have a few more information on your scenario, e.g. what you need the address for, if you really mean the client's address or the mail provider's server address, how much work you are willing to invest and also which kind of mail service provider we are talking about. If you run your own mail server, you suddenly gain access to a lot of interesting information...
Feel free to clarify your needs, so maybe someone can help you better. Also, I hope I didn't hit you with too many words, I am new and excited about stackoverflow ;)
I recently noticed my gmail spam folder had some bounced messages to my business email address (which is configured to forward to my gmail). After some investigation it appears as though someone is using my domain name and randomly generated usernames as return address on their spam emails.
Mail.log shows these messages coming in, but not being sent. Is it possible that my server (Postfix or sendmail) is allowing a user to push out emails without generating log entries? What is the likelihood that somebody is spoofing my domain (not a very popular one at all) and not actually sending from my server?
Most importantly, what can I do to prevent spam emails from being sent out with my name on them, if anything? I'm concerned that gmail at least will mark me as a spammer since all the bounced spam messages are going to my gmail as though they were sent from my domain.
You can install the spamassassin in your server and connect it to the postfix. SpamAssassin uses a wide variety of local and network tests to identify spam signatures. This makes it harder for spammers to identify one aspect which they can craft their messages to work around.
It is very easy to config,SpamAssassin requires very little configuration; you do not need to continually update it with details of your mail accounts, mailing list memberships, etc. Once classified, site and user-specific policies can then be applied against spam. Policies can be applied on both mail servers and later using the user's own mail user-agent application.
You can refer the link to know more about the spamassassin
I have 2 Windows 2008 R2 boxes running in Microsoft Azure. My ASP.NET 4.0 site (let's imagine it's running at "example.com") has a standard Contact Us form.
When a user sends a Contact Us message, I use System.Net.Mail and SmtpDeliveryMethod.Network to deliver mail to an IIS6 SMTP server running on each box, which sends the mail to a Google Apps "enquiries#example.com" account, using the email address the user entered into the Contact Us form as the "From" address.
This was working beautifully for a year until I checked it today, and found this error in a .BDP file in the \Badmail folder:
550-5.7.1 Our system has detected an unusual rate of unsolicited mail originating from your IP address. To protect our users from spam, mail sent from your IP address has been blocked. Please visit http://www.google.com/mail/help/bulk_mail.html to review our Bulk Email Senders Guidelines.
Obviously Google upped their anti-spam strategies in the last 6 months - last time it worked was Feb 2013 (yeah, we don't get much mail luckily... yet).
I've read the Bulk Senders Guidelines linked above, but they're not really suited to my use case. My case is not sending emails from our server to users of our site (I simply use the Gmail API and send from our enquiries#example.com for that), but rather to collect users' enquiries so that we can easily respond by clicking Reply in that inbox.
I am looking for the easiest solution here. In response to the ones in Google's Bulk Senders Guidelines:
Use a consistent IP address to send bulk mail: I already do, doesn't seem to help
Reverse DNS: Godaddy, my domain and DNS provider doesn't seem to support them: http://support.godaddy.com/groups/domains-management-and-services/forum/topic/how-do-i-setup-reverse-dns/ Anyone know if there's a way?
Use the same address in the 'From:' header on every bulk mail you send: This is totally not my use case. I'll have different From headers in every email
SPF record: I think this only works if I am sending From ...#example.com every time. Is that right? My feeling is SPF doesn't help me here. Would love someone to enlighten me.
DKIM: This looks hellishly complicated, but I'll pursue it if someone thinks it can work in this case. Specifically is it OK that the From address doesn't match the "signing domain"? Anyone got any good "how to" links? And will this be sufficient for Google to un-blacklist me?
Sendgrid: Azure's preferred mail sending app. This means signing up, code changes, testing, and unknowns like "does Sendgrid allow any From address? It's non-trivial, and I'd like to avoid this, but again, will go there if it's what people think is the sanest option.
As a general answer to your questions, sending email on behalf of many different domains from one IP (e.g. example.net, example.org, and ex.co from 10.0.0.1) is generally seen as spammy behavior (and therefor not recommended).
Your points 1-5 only apply if you're sending from one domain. rDNS, SPF, and DKIM only improve delivery for one IP to one domain (in a generally 1:1) relationship.
Generally, the best way to avoid getting marked as spam in a situation like this is to set the From email as a consistent one that you actually control (e.g. enquery-sender#example.com), and then setting the Reply-To as the entered address (e.g. enquirer#someprovider.com). This way you consistently send from one domain, while still getting the benefit of replies going to the message originator (for example LinkedIn does it this way). Doing this will allow you to setup rDNS, SPF, and DKIM with benefit.
That said, if you decide that you don't want to use the recommended Reply-To method, you can use SendGrid to send from any arbitrary domain. It should not require any significant code change (just switching your current SMTP credentials to SendGrid's).
Disclaimer: I am a SendGrid employee.
In my website (under development), the members can send messages to each other which are sent directly to their email, now I'm worried that some members can send spam to other members (I have a spam filter but it doesn't give 100% protection as you know), I'm worried that my domain might get blacklisted on Yahoo, Gmail, Hotmail or AOL which will cause any messages sent from my domain to end up in the spam folder, this is why I want to add the domain of my website to their whitelists (if they exist).
P.S. I don't want to use private messages that members check on the site and I have my reason for this.
Thanks
Your email might not be considered "bulk" because it sounds like it's one->one as opposed to one->many, but these bulk mail help resources might still be helpful:
Yahoo! Mail Postmaster Help
GMail Bulk Sender Guidelines
Windows Live Hotmail Postmaster Services
AOL Postmaster Website
As Bevan mentioned, your task will be an ongoing one to keep your site clean on various services.
Not sure if you're already considering this, but you can send the email "on behalf of" the requesting user (i.e., set the from and reply-to fields to the user who is sending the message).
While there may be whitelists used by those sites, I suspect that they only contribute to whatever scoring system is in use - being on the list won't be sufficient in itself.
The overall controlling factor will be the "reputation" of your site - you need to work to ensure that reputation stays sound.
Unfortunately for your workload, I think this will be an ongoing task, not a one-off.