It may be that filling out their stupid form makes it work for a few days, but then it comes right back.
550 5.7.606 Access denied, banned sending IP [3.16.178.106]. To request removal from this list please visit https://sender.office.com/ and follow the directions. For more information please go to http://go.microsoft.com/fwlink/?LinkID=526655 (AS16012609)
I guess this is any recipient who has the poor taste to be using Outlook for their email, in this, the year 2019?
I actually received an email with a WINMAIL.DAT attachment the other day. Remember those? That was back when MICROS~1.EXE was still planning to "Embrace, Extend and Extinguish" the MIME format. They hadn't even set their sights on destroying the nascent web, yet.
Not for the first time, I find myself wondering if you're haunted by the ghosts of dead technologies with some kind of grudge
One of the companies with which I routinely do business (by which I mean we have a contractual agreement whereby my company provides labor and they give us money) sends attachments in winmail.dat format.
Mercifully, the tnef software which decodes it still works, since apparently Microsoft is no longer "innovating" and changing the format.
(I assume that noise I now hear in the distance is that of sudden changes being developed.)
Any specific reason preventing you from using Sendgrid or Mailgun, like most people do in this day and age? Yes, it's annoying that it requires an extra service, but that's partly to blame on the big mail parties like MS and Google, and mostly on the spammers and fishers.
Or, depending on your hosting location, maybe a relay host? I have a server at home and no way in hell mail is going to be received reliably if I send it directly, so I use my ISPs relay and all is good.
I remember them well. That was something to do with RTF in emails, when every right thinking person knew that plain text was the only way to go. But then some thoughtless fucker invented HTML email, and boy, have we been paying the price ever since. And, I know you'll never believe it, but MICROS~1.EXE is a different company in a good way these days, since Monkey Boy left to run the Clippers, much as Hewlett Packard became a different company only in a bad way when Hewlett and Packard left and the likes of Carly fucking Fiorina legged it over. Sorry. Old man shouts at cloud. Kids, get off my lawn.
Sewer rat may taste like pumpkin pie, but I'll never know.
textfiles:
I can't believe anything could taste worse than pumpkin pie, even sewer rat. But hey, I'm old, and I remember when Microsoft technical support was free, apart from the cost of a toll call (Young people! Look it up!) from New Zealand, and you got to speak to an actual helpful engineer who would fax (Young people! Look it up!) you an answer, sometimes on their own time because they were interested. We're talking late 1980s here. Then they got big and cuntish and started charging for support, and people like me said "It's not like it was!". Before your time, young man. Maybe I'm fooling myself into thinking they are improving.
I presume Pumpkin Pie is for the Pulp Fiction generation what Turkish Delight is for those of us who grew up reading Narnia books. You imagine based on the fiction you consumed that it is awesome, then you finally try some and it tastes like shit.
Literally your entire premise is wrong, yet you somehow managed to fall ass-backward into the actual meaning of the simile.
It doesn't taste like shit. It tastes like soap. Like, really, soap.
Are they better, or are we just comparing them with companies which are much worse? I'm sure they still want to be an abusive monopolist, because all companies want that, but perhaps they were never willing to destroy the democracies of the countries that hosted them, or worse, in the pursuit of that goal, in the way that seems now to be acceptable.
(Meanwhile, while we're distracted, ExxonMobil & the other oil majors are betting billions of dollars on a dramatic expansion of oil use by 2040: an expansion which will kill billions of humans by 2150. We are fucked so badly it's hard to describe. But their shareholders will be rich: mostly dead, but rich.)
You're running your server on AWS, correct? I suspect every RBL has all the EC2 IPs permanently listed.
Suspect all you like, but you are demonstrably wrong.
It might not be on the public RBLs but AWS is a well-known source of spam so most of the larger email providers just block it outright, silently, based on the premise that anyone "serious" wouldn't use AWS for a mail server.
Just passing along my experiences.
And as the owner of a mail server that's in AWS, I can say you are still demonstrably wrong and/or bad at email hygiene. Gmail, Yahoo, the various flavors of MSFT, even AOL; all of them accept mail from me.
The only provider I had to ask for whitelisting was ProofPoint. Once I figured out how to get off the list it took about 12 minutes for them to remediate my IP. (Based on contacts I have there I know for a fact they don't blacklist all of AWS, either.)
One question: do you have issues with AT&T? I run a not-in-AWS mailserver to support a volunteer organization because I'm a glutton for punishment and they seem to be annoyed with us. They don't provide a webpage any longer for reviews, just an email address to contact.
I did initially, but after mailing them a few times they fixed it.
"Dance with us Gir, dance with us into oblivion..."
I'm starting to suspect that the only long-term solution for routing mail through these petty fiefdoms involves of a shimmering curtain of radioactive fire...
So, I'm curious...your SPF (TXT) records say:
dnalounge.com. 3542 IN TXT "google-site-verification=GK9TastKl3ofEQ3qt9dE678XK5Lp_v8AjvW8mmPrpTo"
dnalounge.com. 3542 IN TXT "v=spf1 a mx ptr include:_spf.google.com ~all"
The second one implies your mail should be originating from Google, not AWS. If you fix this, there's a pretty good chance your problem will go away. I know MSFT is pretty anal about SPF.
That SPF record says mail can also originate from the host in the A record for the domain, or any MX for the domain, or any host described by a double resolution of the PTR record. For the current configuration, I don't think the ptr term adds anything to the SPF record and could be removed.
I believe that does not say “should”, it says “can”. And that’s there because several of my employees use gmail to send from their dnalounge.com addresses. In addition to my own server doing it direct.
That's not how many people interpret it, despite the SOFTFAIL you have in there. I had this same problem with Gmail - without an SPF record saying "this mail can come from this IP/server," the odds of it getting thrown in the spam folder (or rejected, as you've seen) goes up astronomically. I wouldn't be surprised if Gmail is doing that to you right now.
I think you can keep that google spf record in there if it's necessary. It's an unusual use case so I can't comment on it. But I'd definitely add a: and mx: entries to it for both http://www.dnalounge.com and mail.dnalounge.com, and an ip4: for 3.16.178.106. And like Jacob said, you don't need the PTR.
(and if I were you I'd run everything through http://www.spfwizard.net to make sure what I said is right...)
To elaborate a little, as I fear my original response is a little vague:
Your current SPF record says mail "can" come from google. It also says it "can't" come from anywhere else, including your current MX. Hence my recommendation to include those other entries. And you need to have them all in one record; multiple SPF records are not a valid setup. So I think something like this would work:
"v=spf1 a mx a:www.dnalounge.com mx:www.dnalounge.com a:mail.dnalounge.com mx:www.dnalounge.com ip4:3.16.178.106 include:_spf.google.com ~all"
But again, it's a weird use case, I've never tried both an include: and other records in there, so YMMV.
With what you typed there, this SPF validator says "Warning: One or more duplicate mechanisms were found in the policy." And this one says "SPF Ambiguity Warning: No MX records found for mx mechanism: www.dnalounge.com".
I think that "ambiguity warning" was trying to say "www.dnalounge.com does not have an MX record", which it doesn't: "dnalounge.com" has the MX record. Maybe what you meant was:
"v=spf1 a mx a:dnalounge.com mx:dnalounge.com ip4:3.16.178.106 include:_spf.google.com ~all"
But 3.16.178.106 resolves to www.dnalounge.com so I don't know which one someone might be a stickler for.
Also how is "a:dnalounge.com" any different from just plain "a"?
You're right about the "duplicate mechanism", I accidentally copy-pasted www in both mx records. One should have been www and one should have been mail.
I think the string you posted above should work just as well as what I was trying to do, and it's a bit cleaner.
To answer your last question: "a" means "authorize any IP that is also an A record for the domain". "a:foobar.com" means "allow any IP with an A record of foobar.com to send mail as well." So what you have is redundant, but valid, and probably safer long-term.