4

TL;DR: We had SPF too permissive (+all) and spammers used this to send tons of spam "from" our domain. We restricted that to ~all and added DMARC (not DKIM though), now other providers do not trust our real emails. How to make them trust our domain/SPF record without making it too permissive again?

I've worked for this company for awhile now. However the DNS management is done by other people.

I've noticed that our SPF record was pretty bad (literally +all at the end) and the people who manage DNS argued that this is needed since many servers send automatic weekly/daily reports. However on close inspection they do not use our mailing domain name. So I suggested to fix SPF record to have at least ~all at the end and add DMARC record to receive reports of messages that are considered spam. We could not add DKIM as there are multiple systems that require sending emails (all proxied via GMail servers with their smtp-proxy servers).

Once we have done so we started receiving large numbers of reports about spam messages with our domain name as sender. All of them do look like spam and definitely not sent from our servers.

Obviously this is what we wanted to achieve, but now I see that our legit messages are sent to spam as well, even though all sending servers are added in SPF (we use Gmail for business).

Q: How can we recover from this and make other providers trust emails sent by hosts in our (now valid) SPF?

UPD: Below are examples of SPF and DMARC records we have:

v=spf1 ip4:xx.xx.xx.xx ip4:yy.yy.yy.yy ip4:zz.zz.zz.zz include:_spf.google.com ~all

v=DMARC1; p=none; rua=mailto:dmarc.report@company.com; ruf=mailto:dmarc.report@company.com; sp=none; fo=1; adkim=r; aspf=s
Alexey Kamenskiy
  • 774
  • 9
  • 22

1 Answers1

2

  1. DO DKIM for each legit sender. Is it done for all the senders you show in your SPF record?

  2. Change the ~ALL (softfail) to a -ALL (hardfail).

  3. When you're confident you've authenticated all legit email and have had p=none for a while and the reports aren't showing legit email as not authenticated, then graduate from p=none to p=reject. This will make your email authentication have teeth so to speak, as inbox providers will actually start rejecting non authenticated email.

Once you've changed to p=reject, it's important to make sure you are really good about keeping your email authentication up-to-date, meaning if an IP address changes or you change providers or whatever, it's critical to edit your SPF record and also set up DKIM.

This will help you clean up your reputation as spammers and scammers will no longer be able to spoof your domain name. That will help start to rebuild the rep because spammers will no longer be ruining your domain name by sending awful messages with it.

Outside of email authentication, you can also make sure you're using best practices for email. For example, do you do email marketing? If so, do you do double opt-in? Do you periodically sunset email addresses that have not engaged in a certain amount of time, say 3 months or 6 months, so that you're not sending to people who for whatever reason never engage with your emails.

Check all the IP addresses you send from for blacklists and so on and, assuming you've cleaned up the practices that got you on the blacklist, apply to be removed. If it's a shared IP address that's on blacklisted on serious blacklists then you may need to talk to the ESP about the shared IP block you are on.

Neil Anuskiewicz
  • 431
  • 1
  • 3
  • 15
  • Adding DKIM to all servers would be hard since we have multiple departments which do not communicate to each other about those things (I know it’s bad, but I alone can’t change that). I’ll consider that but probably as a last resort. As for other suggestions I’ve already planned to do those. And no marketing mails. Only transactional. So I am wondering if there is anything else I could do other than that (yes, I know the options are limited, but maybe I forgot about something that I could use to improve this situation) – Alexey Kamenskiy Aug 28 '18 at 00:51
  • @AlexeyKamenskiy Even if you only implement SPF, can and should still implement DMARC. See https://dmarc.org/2017/03/can-i-use-dmarc-if-i-have-only-deployed-spf/ – Neil Anuskiewicz Aug 28 '18 at 00:54
  • that’s already done. But as my post says right after that all has been implemented we started seeing our legitimate emails going to spam (via gmail which is already in SPF). Which is my main concern at the moment. – Alexey Kamenskiy Aug 28 '18 at 00:57
  • You have DMARC p=none or p=reject? DMARC is not going to cause emails to go to spam. It will protect your domain's reputation if it's set to p=reject as it will flat out stop spoofing, combined with setting your spf to -ALL. Stopping the damage of spoofing then you'll be able to build your sender rep back up. – Neil Anuskiewicz Aug 28 '18 at 00:58
  • Did you check the IP addresses reputation at Cisco Talos and Return Path's SenderScore? Also, check for blacklists of the IP's you send email from at mxtoolbox.com. Reputation is a combination of things. Email authentication is necessary but not sufficient. – Neil Anuskiewicz Aug 28 '18 at 00:59
  • please see the question, I’ve put our dmarc there already(only changed email addresses). Also as mentioned in question we do receive plenty of reports now due to spammers. We don’t get reports for our own legit emails. But those still appear in spam. And domain is not on any blacklist. – Alexey Kamenskiy Aug 28 '18 at 01:01
  • Check out https://www.mail-tester.com/ as this may help you narrow down the problem. It's not likely caused by email auth. Your DMARC record in the OP has p=none. It doesn't do anything but send reports. That's fine but it does not solve problems. – Neil Anuskiewicz Aug 28 '18 at 01:02
  • check the IP address reputation and blacklists not the domain only. The IP addresses you send from are where the email really comes from and so what will get blacklisted before a domain will. I'm assuming the return-path of the emails is the root domain in each case? Why would you not check the sending IP address's reputation, etc? With regard to DMARC, I'd sign up for a dmarcian.com account to monitor what sort of email is going out send from the domain. After monitoring for a while, switch p to something other than "none." That literally has zero effect on your deliverability. – Neil Anuskiewicz Aug 28 '18 at 01:10
  • I checked the IP reputation, all is clear there. Also those mails that I’ve seen went to spam were sent directly from gmail UI to an external domain. Which makes me think it’s not IP reputation. I’ll check those services you recommended though. Thanks for all the advice. – Alexey Kamenskiy Aug 28 '18 at 01:16
  • You have to look at headers (run them through mxtoolbox header analyzer) and I think a tool like https://www.mail-tester.com/ is going to be necessary for you to figure out what's causing the problem.I would bet money it's not caused by email authentication. Something else is going on. If people are spoofing your domain you have to put a stop to it with DMARC beyond reporting mode. Ideally, you'd also figure out a way to get DKIM implemented even from systems controlled by other departments. I'd at least try to sell them on the idea. – Neil Anuskiewicz Aug 28 '18 at 01:17
  • The aspf=s (strict) in your DMARC record. You might want to back off of that for now. Set to r for now. – Neil Anuskiewicz Aug 28 '18 at 01:30