d_marc send my own emails in spam folders - dns

I have a website, with a mailbox using Roundcube. This mailbox is affiliate to my domain name.
I use Cloudflare on my website with a D_marc in DNS section, and this send my own emails as SPAM to anybody.
I don't understand why.
v=DMARC1; p=quarantine; rua=mailto:contact#sp-batiment.com; ruf=mailto:contact#sp-batiment.com; fo=1
whereas I thought it should only send email who are not sent from my domain to SPAM folders.

The first step is to change p=quarantine to p=none (reporting only) as that won't break your own email. Then, once you have SPF and/or DKIM passing and in alignment (using same domain as the visible from) such that DMARC passes for all your legit mail, then cautiously ramp your policy back up to an enforcing policy.
I'd say that changing your policy to none (reporting only) gives the time and space to fix email authentication problems without causing you real problems with your own email deliverability.

Related

SpamAssassin negative score for HEADER_FROM_DIFFERENT_DOMAINS

Some emails sent by our sever go to spam for certain recipients. E.g when sent to #outlook.com email addresses.
I have been testing our emails using https://www.mail-tester.com
SpamAssassin gives a score of -0.1 for the issue of 'HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different'
This is the only issue reported. Everything else, such as SPF and DKIM, passes. There is no documentation on their website for this issue and I don't understand what it means or how to fix it.
The email is sent using PHPMailer via AWS SES.
I solved this by completing the setup of 'MAIL FROM' in AWS SES. This set the mail from header in emails to be my domain name.
"HEADER_FROM_DIFFERENT_DOMAINS" and mail-tester.com now gives me a score of 10/10.
Note that for some email providers it took a few weeks before we were trusted and emails stopped going to spam.
It means that the envelope sender address (which is used at the SMTP level) is different to the address used in the From header. This is very common, but can be a problem if you try to implement DMARC alignment. For example, you might send a message with a from header containing user#example.com, but your envelope sender might be bouncehandler#mail.example.com. You should be able to see this in the Return path header of a received message. Whether you can change this depends on exactly how you're sending your message, but in PHPMailer the envelope sender defaults to the from address, and you can override it by setting the Sender property.
A -0.1 penalty is unlikely to be the entire cause of your mail being sent to spam.
Its outlooks rubbish filtering system. They have "AI" rules that look at the sending ip address for reputation. They score you on user reportsand lots of other bits they will not tell you about. Make sure you have SPF, DMARC, DKIM, and sign up for their JMRP and SDNS they will tell you. But it still is a game of cat and mouse. Its a slippery slope and even Microsoft trap their own mail to their own outlook users. PITA, to be honest and luckily we managed to get a mitigation to the issue. However some users in different domains still complain of email going to JUNK. Go figure. I hate having to work on issues with Outlook.com. They themselves send out spam and have the audacity to block well configured SMTP senders.
I wish you luck. You will need it.

Customer’s IT refuses set up SPF

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.

Receiving bounced spam messages sent from my domain

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

IIS SMTP used to relay Contact Us form messages to Gmail has been blacklisted by Google

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.

Can a mail-sending program send mails under my email?

I'm new to SMTP techniques so with just a few days work with it, I have this question - Can a mail-sending program send mails under my email?
It seems like I can put any email in to from field and if I put my friend's email there, I can disguise him!? This sound strange since I believe that being some one else is not that ease at all.
Please guide me if you have experiences on this.
Any email client can send an email using ANY email address as the from field.
That said, a lot of receiving mail servers are configured to do various tests to ensure that the email is coming from a real mail server.
For a list of those techniques used by receiving mail servers go here: http://en.wikipedia.org/wiki/Anti-spam_techniques Specifically the "automated techniques for e-mail administrators" section.
A short list from there is:
1. Reverse DNS - tests the IP address of the sender to ensure that the IP is listed as an MX record for the domain.
2. FCrDNS - receiving mail server will attempt to do an SMTP HELO or EHLO command back to the sender's IP. This makes sure the sender is an SMTP server.
3. Disallow Dynamic IPs - receiving server will test the sender's IP to see if it is DHCP'd. If so, then the mail is marked as spam.
Point is, you can send email as being originated from any email address. However, there is a huge possibility that the email will simply be deleted by the receiving server.
Actually, you can do what you say with an email client like Thunderbird where you can set the From address freely.
Anyway, you will need a SMTP server that will accept this any domain address (your provider SMTP will probably do).
That's also why some SMTP servers (like Gmail's one for instance) force the user to get athenticated and displays his user adress (it will sometimes display on behalf of when sending from another e-mail address. This is very well explained on Google site.
Regards,
Max

Resources