As said, we do not run on service providers, we have dedicated ip's so these are from a data center.
And as also said alraedy about bad quality ip's due to previous owners, been there, done that and now the ip's are fine, one can solve these situations.
You have a 9.5 out of 10 on mailtester. Our customers never get at that point, they always have 10/10.
Feel free to do so once you show all of us your "perfect" email delivery from an MTA that has NO DMARC/DKIM/SPF and ONLY rDNS entry utilizing the commonly accepted service I pointed out to you earlier.
AGAIN say something that I NEVER have said in this discussion. You're just trying to be a knowitall by constantly stating things I never said.
You choose to just ignore my last reply about how I think (and experience) things are working with perfect email delivery.
First you try to get a 10/10 like me and my customers get, then we can talk further. Then we can start to discuss who knows better.
Yep... seems Amazon SES shared IP (which I'm pretty sure their infrastructure squashes yours) is listed in SORBS.... We can ALL see your better than Amazon SES at running an MTA infrastructure.
And that's easily solved by my getting a static IP for my SES instance... which currently based upon my site size is not a "justified" use of funds. I could more easily (and justifiably) spend the money on getting some scopes for my local astronomy group since my email easily gets delivered ot Hotmail.. the biggest PITA of all mail delivery sites.
Err.. you were the one that indicated to us all you needed was a valid rDNS and you would be fine.
And in that case they should know that rDNS is more important than DKIM or DMARC and even SPF, because mail wont'get blocked by not having SPF either. It raises the score a bit, but not as high as not having rDNS.
You see... you simply FAILED to mention that upon almost EVERY instance of the creation of a VPS/dedi an rDNS entry is ALREADY configured by the hosting provider.... so there is NOTHING needed to be done... but DMARC/DKIM/SPF IS a manual intervention item, and DOES need to be done for reliable delivery. You make it out to sound like it's some "magic" that the admin needs to do to create a "custom" rDNS entry.. it's simply NOT.
I'm STILL waiting on your rDNS only delivery test.
So, in other words.. you run on a provider... THEY provide the network backbone, THEY provide the IP to you and probably THEY provide the IP/rDNS issuance, THEY provide the electricity to keep the box running... the question is.. Do you CoLo or do you "rent" the server. If you "rent" the server, you use a provider. Even if you CoLo, you are using a providers services...
The exception to this would be if YOU ran the datacenter.
The simple point remains.. for MOST providers used by ANY user here, rDNS will be set by their provider. That is MORE than sufficient for mail delivery as they typically also set DNS entries up based upon that IP that tie back to the rDNS/PTR (never mind your apparent need to set a specific one for the MTA). The PRIME thing that ANY person that is setting up mail delivery (shared/dedicated/VPS) needs to be concerned about are DKIM/SPF/DMARC in that order.
If you want to have a screenshot of mailtester that is no problem at all, only shows a lack of believe on your behalve.
And you should know as to -why- amazon SES is present in SORBS.
It's because loads of spam and attacks come from them. Last month I reported at least 5 ip's of them, which is only a handfull of the 20 ip's doing various attacks.
The bigger the provider the more issues, however, also very big providers can do better.
You see... you simply FAILED to mention that upon almost EVERY instance of the creation of a VPS/dedi an rDNS entry is ALREADY configured by the hosting provider....
There was no reason to mention that, next to that there are still loads of VPS providers which do not provide an rDNS record, so this is a non argument on your behalve.
Which I CAN'T USE and have to change, because I will be configuring my server with my own hostname and my MTA will answer differently. As you can see also Amazon has it's domain name in there.
And you are so keen on SPF/DKIM. You never did shared hosting... start there first and then complaint to me about rDNS and if you can or can not use the one provided by the isp or datacenter or whatever.
Try to get an SSL certificate for that hostname, since you don't OWN the domain... Good luck. There is more to it then you think. Well... you might get one, but it's really not advisable to use auto-created stuff, because it's not in your control.
Nonsense. But I won't discuss this with you further since you have no clue on what has to be done with the hostname too.
If you have your SPF/DKIM/DMARC fully correct, then that is the ONLY reason your mail still will be accepted because as you can see, you will loose points (and a lot) for not having the correct rDNS and there will be issues because your hostname has no SSL certificate.
Start learning first from professional panel forums and then start discussing.
For every further reply I refer to my post #19.
I've got better things to do then keep discussing non-arguments with somebody who does not have any shared hosting experience as root admin.
And you should know as to -why- amazon SES is present in SORBS.
It's because loads of spam and attacks come from them. Last month I reported at least 5 ip's of them, which is only a handfull of the 20 ip's doing various attacks.
pretty much what I commented on.. and why I commented the fact that I could get a static IP and eliminate that, but my mail delivery even to HotMail still progresses happily onward... and they are one of the toughest to get mail in through.
There was no reason to mention that, next to that there are still loads of VPS providers which do not provide an rDNS record, so this is a non argument on your behalve.
They may not "provide" it to you.. but ultimately rDNS YOU as an end user do not need.. the simple fact that it exists is all that is needed. You seem to be fixated on the point that one should create a "custom" rDNS.... simple fact is, almost always they are already created... and YOU as an admin/end user really don't need to customize them. IF you are using a provider that does NOT create rDNS entires and you are targeting them for mail usage, you simply should go to a provider that does the bare minimum.
Which I CAN'T USE and have to change, because I will be configuring my server with my own hostname and my MTA will answer differently. As you can see also Amazon has it's domain name in there.
And the point STILL REMAINS.. you appear to"fixate" on the belief that you have to have a custom domain that somehow ties back to your MTA. MY point is that is incorrect. Mail delivery doens't really care if the rDNS tied to an "MTA name" or a simple domain name.
Are you trying to blow smoke up our posteriors and hint that your rDNS MUST be the same as your MTA hostname... WRONG. Otherwise the large part of shared hosting providers would NEVER be able to send email, now would they.
Hopefully you have a little more knowledge than you have reflected here... heck, by your very statement that I quote just above... shared hosting email shouldn't work because those folks can't tie to an rDNS.... as I have said multiple times (but you apparently still have problems comprehending) the rDNS does NOT have to be tied to a specific MTA domain name. AS long as the PTR and the DNS A entries match... they will be valid, the system can be set up to send email.
But remind us... exactly HOW many that will be reading this will be setting up a shared hosting environment for others to send email through compared to setting up a VPS instance of an MTA for them to send email (either via a panel or even using a packaged solution).
Now... let's see you expand that and where ONLY rDNS is "important". You see, the simple fact is... apparently you actually don't realize that most hosting environments provide a default rDNS that works for a VPS or even a dedicated server. As I have said time and again.. one does NOT need to "massage" that to salve ones ego and give it a custom name. If they have that option, then they can.. but it is NOT required as most decent providers create a default rDNS entry AND a DNS A entry to correspond to it.
I am working for one of Germanys largest forum operators. We send emails from our owned servers colocated at a Tier 1 datacenter, connected via RIPE registered PA address space.
We usually don't have DMARC set up and only semi-recently started to use DKIM for all projects.
From my experience (about 15 years), the most important thing for a MTA is correct hostname configuration, eg. the FQDN presented in HELO / EHLO should resolve to the source IP address in forward lookup and and a reverse lookup on that IP should match the FQDN.
If this is not the case it would be pretty problematic to have outgoing mails accepted by users MX; large providers like United Internet (GMX, Strato, Ionos, etc.), Deutsche Telekom, Google, Microsoft, etc. would reject it right away.
IMHO proper rDNS is the basis and way more important than SPF and DKIM (let alone DMARC).
Wether the FQDN is smth. "fancy" like mail.mydomain.com or 162-105-133-213-static.hetzner.de is less important and usually doesn't totally block delivery, though chances are pretty high that such automatically provider generated FQDNs will increase spam score.
Many mail servers only accept incoming emails if the sender's IP address has a reverse DNS entry.
[...]
The reverse DNS entry should not take the form of an automatically generated name, such as <162-105-133-213-static.hetzner.de>; spam filters might identify these as "spam".
So realistically you wouldn't want to use such an automatically assigned entry and if it can't be changed it would be quite a challenge to achieve good delivery rates with such a setup.
Missing SPF will not block delivery but an incorrect record most certainly will block delivery to some extend.
Furthermore SPF does cause problems with forwarding (unless all intermediate servers implement SRS which also has its own problems).
While pretty much all major providers do support DKIM checks by now it is even less important and like SPF not having DKIM set up will not block delivery but an incorrect setup most certainly would at least increase spam score.
The least important thing is DMARC which certainly does help to protect against abuse and to monitor delivery performance but doesn't (yet?) have that much impact on score.
TL;DR
rDNS > SPF > DKIM > DMARC
Ideal Setup
Custom FQDN with PTR on your own domain that also matches envelope and From using a clean IP that is exclusively used for email delivery, proper SPF, DKIM (and DMARC if you want the extra "icing" on top and BIMI with VMC if you have too much spare money).
Wether the FQDN is smth. "fancy" like mail.mydomain.com or 162-105-133-213-static.hetzner.de is less important and usually doesn't totally block delivery, though chances are pretty high that such automatically provider generated FQDNs will increase spam score
This is pretty much the point I've been trying to get across.... almost EVERY provider generates a default rDNS... is it perfect? Nope.. but is it REQUIRED to create a "custom rDNS"... again nope. As long as the rDNS and the A DNS entry match, you will typically be good. As long as they match, I've personally never seen it "increase" the spam score, as long as you had DKIM/DMARC/SPF present. Now, going without those (DMARC not that important, and is something I only recently set up and it's more a PITA for me than anything) and using ONLY rDNS... it's like using php mail from a baseline VPS setup... there's a reason those emails don't get delivered reliably (if at all) even though the "software is there".
Now, does it involve some additional work.. yes, it can.... but hopefully if you are running your own VPS (or dedi) you are somewhat knowledgeable on what it requires or you have some money to spend, or you simply install a panel and let it take care of most of it for you.
The individual in question apparently had an issue with the fact that I said rDNS wasn't "as important" (basically because EVERY competent provider I've ever dealt with auto-created a base rDNS for the server instance) as DMARC/DKIM/SPF... of MORE import are those entries that you have to MANUALLY create (sometimes including the MX entries).
Exactly my point. Which is to get "most reliable" delivery, what Tracy was talking about, one can better use something which does not increase spam score, being the fqdn hostname or the helo/ehlo name the MTA provides.
On our servers that is always the same name so hence never has been an issue.
You were talking about most reliable way of sending mail and saying rDNS was not important, the opposite is true.
And therefore I said this -was- important. You said rDNS is less important. As you can see now there is a pretty high chance they will increase the spam score, which one rather not want.
That was the point I was trying to get across to you. But you did not see the importance of it, you denied it.
Edit... Have you read this:
should resolve to the source IP address in forward lookup and and a reverse lookup on that IP should match the FQDN.
If this is not the case it would be pretty problematic to have outgoing mails accepted by users MX; large providers like United Internet (GMX, Strato, Ionos, etc.), Deutsche Telekom, Google, Microsoft, etc. would reject it right away.
No, I NEVER said it wasn't important... mayhap you need to go back and read the original post. What I inferred was that for MOST they don't need to worry about rDNS because, specifically in the instance of a quality provider it is ALREADY CREATED FOR YOU. You therefore should concentrate on DKIM/DMARC/SPF to get reliable delivery.
That's the point that I've been trying to get across to you consistently but you simply close your mind to it.
And.... rDNS is created by almost EVERY provider when they gen out your server instance (as stated by Kirby)... but no, it's not custom/fancified to what you want... but it STILL works. And THAT is the point... you use what works, concentrate on what you need to add to further it.
Please, feel free to show me ANYWHERE that a default valid rDNS configuration resulted in a "spam" penalty.
As long as the rDNS and the A DNS entry match, you will typically be good. As long as they match, I've personally never seen it "increase" the spam score, as long as you had DKIM/DMARC/SPF present.
This (somewhat) contradicts what your provider (you do use Hetzner, right?) is stating in their documentation - and I am pretty certain they know what they are doing and don't state this for fun
This (somewhat) contradicts what your provider (you do use Hetzner, right?) is stating in their documentation - and I am pretty certain they know what they are doing and don't state this for fun
Yes... and the primary word is "may"... that is not a "will". In fact, one of the reasons that they say that (and from a ticket I submitted to them inquiring bout rDNS prior to getting the larger VPS) was the fact that at one point (before they started blocking ports for MTA use) they had a somewhat "sloppy" history for their IP's.... and many of their "default domains" are apparently still in block lists. Again, it was simply one more reason I decided to go with Amazon SES instead of burning out another VPS and installing mailcow-dockerized.
There is a reason they have this document avialable.
BTW, one way around it is simple CName DNS entries, as explained in that very document.
The simple fact is... which has (and specifically historically here for actual license holder) had a bigger impact...lack of SPF/DKIM/DMARC or lack of a "special" rDNS entry... I'll leave YOU to research it... I readily know what it is, as I've helped in MANY of those threads and gotten the users issues resolved either via the thread or via conversation.
And sorry @Kirby, you are are going to try to act like DKIM/SPF/DMARC isn't a priority when there is already an EXISTING rDNS entry (but may not be customized)... I have to wonder about your advise also.
With an existing rDNS (albeit not a preferred one), do you actually believe that mail is going to be delivered without at LEAST valid SPF/DKIM reliably? I can tell you for a fact that even with a clean IP, until your domain develops "history" hotmail is going to kick your sent email to the curb, and not even let it get as far as their "junk/spam" list... seen it WAY to many times.
Look at the ENTIRE sentence for understanding. The first 3 are priority because the latter typically exists and the former do NOT.... duhhhh...
concentrate on fixing what doesn't exist... THEN if you have issues, you can fine tune. Once more.. is it REALLY that hard to understand, especially considering that by far and way a noticeable number of admins here have NO knowledge of what DKIM/SPF/DMARC is?
Not sure how there's an argument here. I've used 100s of servers and 1000s with clients, and sometimes you can get an email delivered to a users inbox without PTR/SPF/DKIM/DMARC, even sometimes only with PTR and sometimes some servers manage with just PTR/SPF/DKIM. It ultimately depends on the recipient's mail server that decides. Microsoft/Hotmail/Yahoo receiving servers can be problematic for email deliverability but MS have a guide for that https://learn.microsoft.com/en-us/m...nti-spam-protection-about?view=o365-worldwide
Use email authentication: If you own an email domain, you can use DNS to help insure that messages from senders in that domain are legitimate. To help prevent spam and unwanted spoofing in EOP, use all of the following email authentication methods:
SPF: Sender Policy Framework verifies the source IP address of the message against the owner of the sending domain. For a quick introduction to SPF and to get it configured quickly, see Set up SPF to help prevent spoofing. For a more in-depth understanding of how Microsoft 365 uses SPF, or for troubleshooting or non-standard deployments such as hybrid deployments, start with How Microsoft 365 uses Sender Policy Framework (SPF) to prevent spoofing.
DMARC: Domain-based Message Authentication, Reporting, and Conformance helps destination email systems determine what to do with messages that fail SPF or DKIM checks and provides another level of trust for your email partners. For more information, see Use DMARC to validate email in Microsoft 365.
So you can all be right from your own experience. But ultimately, if you want the highest chance of mail deliverability, you'd have PTR/SPF/DKIM/DMARC for the sending mail server domain correctly set. That should be the message for everyone reading this thread
The entire sentence does not speak further of rDNS at all.
That rDNS already exists is something which you came up with much later when you understood I was right and wanted to win the discussion and even then you kept saying it's less important then the SPF/DKIM while it's not. But even with the typically existing (which does not everywhere) it's still a no go thing as you can see and even Hetzner states.
Once more.. is it REALLY that hard to understand, especially considering that by far and way a noticeable number of admins here have NO knowledge of what DKIM/SPF/DMARC is?
You keep turning and turning to be right. Now suddenly you put this in. It's of totally no use. This was never part of the discussion. And weren't you the one that "everyone" (in capitals written even) could setup DKIM/SPF/DMARC and now you're sayint they have no knowledge?
So if that is true (which might be) then my addtion of the importance of SPF when using an own VPS of dedi is just as important. Is that really so hard to understand? So why start a discussion on my addition, it's already prooven I was right posting my addition.
Your point of view is clear but it does not make you right, you are wrong about your opinion about my addition in my first reply, end of story.
Now even 3 professionals showed you and still you keep going at me.
And stop shouting every few words, it's not done. And grow some balls and stop replying endlessly like you always to trying to be right anyway in some part if you are wrong in another part because you will not, not even when I will not reply further.
I was just stating an addition for security in my first reply and there was totally no need for you to start a discussion over my being wrong about my statement, which I wasn't anyway as you can see from 3 pro's and Hetzner now that rDNS/PTR with correct FQDN is the most important thing.
You're making a fool of yourself.
Thank you for showing the same experience I have had over the years with my company.
I don't hug people who can't admit they are wrong and keep an irritating discussion going for nothing. I'm not mad at him tho, it's just stupid.
Good chance I will ignore further reply's, not sure yet.
As @eva2000 already pointed out there will always be a recipient server that accepts just anything - so stating that a sub-optimal FQDN config will cause mail getting flagged as Spam would be wrong.
(Besides that, stating so wouldn't look nice from a marketing perspective )
So you may see email flagged as spam (with a high probability) with a sub-optimal FQDN - unless you are lucky enough to talk to a recipeint server that just doesn't care.
Hmm ... not sure what you are talking about nor how a CNAME would help setting up "proper" FQDN for use in HELO / EHLO if you can't change the PTR record?
And sorry @Kirby, you are are going to try to act like DKIM/SPF/DMARC isn't a priority when there is already an EXISTING rDNS entry (but may not be customized)...
IIRC I never said that SPF/DKIM isn't important (I said that about DMARC though) - I just said that having a proper FQDN / PTR setup is more important than SPF/DKIM.
With an existing rDNS (albeit not a preferred one), do you actually believe that mail is going to be delivered without at LEAST valid SPF/DKIM reliably?
No, I don't believe that - I know (from our experience) that the overall chance to have an email delivered to the users mailbox with just proper FQDN/PTR setup is much higher than with just a proper SPF / DKIM setup (but inconsistent or bad FQDN/PTR).
So to repeat myself:
First things first - make sure that the FQDN presented in HELO /EHLO is consistent with Forward / Reverse Lookup (and not a provider-generated name if possible) and afterwards setup SPF and DKIM (and DMARC after SPF & DKIM has been verified to be correct).
First things first - make sure that the FQDN presented in HELO /EHLO is consistent with Forward / Reverse Lookup (and not a provider-generated name if possible) and afterwards setup SPF and DKIM (and DMARC after SPF & DKIM has been verified to be correct).
Agreed... but the fact is that the provider rDNS works... if not ideal. It exists whereas the SPF/DKIM does not and has to be created by the end user. So, in order of importance to work with it is
DKIM/SPF (not automatically created, so has to be manually done)
rDNS (since it typically already exists and can be tweaked for custom use)
DMARC (most testers will mark you down for not having this - and is more a PITA than anything and really rarely comes into play for delivery, but why not configure it since it's so easy to do)
Is it better to have a custom rDNS set up? Yep... but as I said, not ALL providers allow you to create a custom rDNS. I've come across several in my years of trying out different VPS providers that did not... some you had to submit a ticket to have it done, others simply refused (and those I quit using).
I think a certain party involved in this conversation may have issues with the English language (not being a native speaker?)... but I clearly stated
... which basically means that those two are important, and "let's not even start talking about rDNS", not "you don't have to worry about rDNS" (because of THIS VERY conversation which is going on).
Can you deliver mail with only a custom rDNS .. yep, you can do the same with the pre-configured one also though. But the simple fact is, way to many providers will either simply ash can your email and then some will (if you are lucky) simply put it into spam folder if there are no SPF/DKIM set up. We aren't talking about simply being able to "send" mail... it's sending RELIABLE mail.
Now, let's get to the point that the OP wasn't asking about "how to set up an MTA" but was specifically asking about DKIM.... And he may NOT have been familiar with setting up the SPF entry also, which is as important. If he's on shared hostiing or cloud, he has NO ability to set that "custom rDNS".
I know several admins that simply block certain email domains from being used to register... and not necessarily because of spam (because otherwise they'd also block GMAIL addresses in that list) but because they simply could not get reliable email delivery to them (looking straight at Hotmail/Live/Outlook here) and got tired of the users complaining about them not getting the email alerts.
After working with some clients and seeing how bad a domain sending reputation due to spoof etc can get with missing or misconfigured SPF/DKIM/DMARC/PTR records over time. It prompted me to get paid DMARC monitoring via dmarcdigest for my important domains https://dmarcdigests.com/comparison and for other domains use their free monitoring. You'll get better real-world insights into how your domain sending/deliverability is doing over time At $10/month very small price to pay
If you have a big company yes. We already monitor SPF/DKIM/DMARC via rua and ruf combined with Easydmarc and Postmarkapp services.
Users don't use PTR records for customers as they don't need them (we don't rent VPS or dedi's) and we manage the SPF/DKIM for the customers automatically. Never had issues yet.
We support the customers if SPF needs change or adjustment.
Hi, Does anyone know of any VPS Management Tutorials or courses, I checked Udemy and cant find many new ones? I'm wanting to learn how to manage a VPS so I don't have to pay for one managed. Thankyou
xenforo.com
I'm FULLY aware of the requirement of rDNS/PTR records.... and have been so for a quite a while. The simple fact is.. rDNS exists on almost EVERY VPS/dedicated instance one obtains from their provider.. .is it the "best" solution? Nope.. .but it STILL EXITS. Guess what DOES NOT exist... SPF/DKIM. Guess which most "major" providers will kick your inbound email to the curb for lack of.
And exactly how does that apply to a user here who does NOT have someone administering their services... simple fact IS and REMAINS, if one is setting up their own MTA, then they should have sufficient knowledge of how to do so.. but ANY OTHER user that uses existent MTA services are going to HAVE to set up their OWN DKIM/SPF entries (not to mention their MX records) in most cases.
