Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Spam Communications The Internet IT

Ask Slashdot: Is Reverse DNS a Worthy Standard For Fighting Spam? 301

drmartin66 makes it to the front page with this question: "Last weekend I installed a new spam filter server for a client, and enabled connection rejection if the sending server did not have a Reverse DNS record. Since then, I have had a number of emails rejected from regulator bodies that do not have a Reverse DNS record, and are refusing to have one created for their email server. What is your opinion of Reverse DNS records? Are they (or should they be) a standard, and required? Or are they useless for spam fighting?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Is Reverse DNS a Worthy Standard For Fighting Spam?

Comments Filter:
  • rDNS (Score:5, Insightful)

    by alphatel ( 1450715 ) * on Thursday October 13, 2011 @01:13PM (#37703576)
    Like all things spam, marking the message as bad automatically is generally discouraged. If you simply increase the SCL value by some reasonable number, and continue to raise SCL based on other soft violations (like spamhaus, surbl, etc), you will rarely put good senders in the junk email folder, and very frequently be able to reject most spam content.
    • Re: (Score:2, Troll)

      Yep, rDNS works really well until your DNS goes tits up, or until MY DNS goes tits up, or until Pakistan accidentally BGPs something that makes you unable to resolve the query... again.

      If the email you receive is anecdotal crap, it won't be a big deal. If the email you receive is of merit, then this test makes an unreliable protocol even worse.

      • by mellon ( 7048 )

        Yup, I tried this for a while years ago and lost a lot of good mail. Recently when my server on a rack in California died and I couldn't get to it for a couple of weeks, I set up a backup server on my home connection (which is Comcast Business, so they don't filter port 25, but I don't have an rDNS set up). Not a single message I sent was bounced. So I conclude that not only is it the case that this isn't an effective tactic, it's also not a technique that anybody uses, for some reasonable value of "a

        • Funny you mention comcast, because they do reject mail if it doesn't have proper rdns setup.

        • by tlhIngan ( 30335 )

          I set up a backup server on my home connection (which is Comcast Business, so they don't filter port 25, but I don't have an rDNS set up). Not a single message I sent was bounced. So I conclude that not only is it the case that this isn't an effective tactic, it's also not a technique that anybody uses, for some reasonable value of "anybody."

          Lots of anti-spam systems DO NOT send bounces anymore. Because it's useless - if it's spam, then it's probably got a forged From: header, so sending a bounce does nothi

      • by DarkOx ( 621550 )

        If your DNS goes tits up you are doing it wrong, DNS is teir1 infrastructure it should be AT LEAST as redundant and well protected/maintained as your mail server.

        If MY DNS goes tits up don't worry I can't resolve your domain to send you any mail anyway.

        If BGP gets hosed up, then DNS servers are no more able to reach each other than anything else, they won't be able to resolve A,AAA, and MX queries any more than they can PTR queries, and our mail servers won't be able to connect with each other even if we co

    • I soft fail for things like this. The issue will get resolved or it will time out on there end and they will get a note about it. I hard fair for more definite things like multiple RBL listings spammy content etc. In no event do I ever accept a message that does not go into somebody's inbox. Effectively if somebody sends a spammy message they should know within a few minutes that it was not delivered. If it temp fails there mail system may or may not tell them immediately but those are assumed to resol

    • Agreed, you can't hard fail on it because too many of your clients will have it configured incorrectly.

  • Yes. Absolutely. It works.

  • by Anrego ( 830717 ) * on Thursday October 13, 2011 @01:16PM (#37703608)

    In all but the most closed groups, having a system that generates lots of false positives is in most cases going to be a bad move in my opinion.

    • Mostly useless because the NSGA (National Spam Growers Association) spends untold millions of $'s lobbying congress to not pass any laws requiring revers DNS.
  • Better Question... (Score:5, Insightful)

    by RedACE7500 ( 904963 ) on Thursday October 13, 2011 @01:18PM (#37703624)

    What reason would anyone have to be running an SMTP server without a PTR record?

    • by Entrope ( 68843 )

      A lot of small organizations have ISPs (or just service plans) that will not let them choose RDNS records. They would have to outsource their mail services to send outbound mail through a computer with a valid RDNS record.

      • You don't have to choose the record. The ISP just has to ensure that the PTR for an IP resolves to a name, and the A for that name resolves to the original IP. The name can be completely up to them and doesn't even need to reflect the domain for which you're sending mail. However it should avoid using a name that makes it appear to be a dynamic IP, which some receivers may penalize you for.

        • by Entrope ( 68843 )

          In practice, that doesn't help much. Before switching to my current Internet connection, I had business-class cable modem service because that was required to get a static IP address from that ISP. My IP address had a PTR record with a non-resolving hostname (which looked a fair bit like a dynamic address, in spite of being static). When I tried to call the ISP about it, I got a bunch of confused tech support people who could never figure out who could fix the PTR.

          • You gave an example of a broken setup to demonstrate how a working setup doesn't help much?

            • by Entrope ( 68843 )

              No, I gave an example of a broken setup to demonstrate that a lot of small organizations (who still pay for business-class service that should work properly) cannot always get valid reverse DNS records for their mail servers. Clear enough now?

        • by Anon-Admin ( 443764 ) on Thursday October 13, 2011 @01:53PM (#37704084) Journal

          I hate to say it but you have way too high of an expectation of ISP's

          I have a static address on a business account via a major ISP. I have a Domain name and have DNS. My DNS resolves to but the ISP has the PTR set to 111.222.333.444.static.ISPDOMAIN.COM

          They will not change it no matter what I ask and E-mail from my domain through my e-mail server is rejected because the PTR does not match the A record. It has gotten so bad that I had to pay for a mail relay host to push my mail through. To me, this is a risk because they (The relay) could intercept, monitor, or filter the private e-mail between me and my customers which would directly effect my business.

          So, personally I say it is a bad idea!

          • by laffer1 ( 701823 )

            I think ISPs do this on purpose to make people pay more. I have the same problem with Comcast. I have business class cable for hosting my websites and they only allow you to change the PTR record if you buy hosting through them too.

            They used to allow me to relay through a mail server, but took that away earlier this year. I have static IPs and they know I'm doing this. It's in the contract. In fact, I had a few questions from them because of the anonymous FTP server used for ISOs and all the IPv6 tunne

      • by snsh ( 968808 )

        Those same ISP's which do not support rDNS for customers typically host a well-configured SMTP server which customers can use as a smarthost. So, you configure your SMTP server to relay mail through your ISP's SMTP server.

        This solves the rDNS problem.

    • by Enry ( 630 )

      Maybe they're hosting multiple e-mail domains from the same site? (I do).

      • Reverse DNS doesn't have to match the domain that they are sending mail from. It should just match the name that the mail server is presenting when it does a HELO. There should also be an A record out there for that hostname pointing to the IP.
        • Reverse DNS doesn't have to match the domain that they are sending mail from. It should just match the name that the mail server is presenting when it does a HELO.

          Absolutely. In fact, it's extremely rare for the mailserver to have the same name as the mail it's sending. For example, I got an inbound connection from to deliver a message from

    • by Qzukk ( 229616 )

      I've got a PTR record for mine, but my DNS server isn't authoritative for the colo's netblock, so nobody will ever ask for it.

    • by mellon ( 7048 )

      Lack of access to the reverse DNS tree, or else running multiple domains on the same server. Reverse DNS is not guaranteed to be correct, and is not useful for filtering spam; its highest use is in troubleshooting, because a human being is using it, and can evaluate how meaningful the data there is.

  • by Some Bitch ( 645438 ) on Thursday October 13, 2011 @01:19PM (#37703640)

    As with most spam fighting metrics it's up to you. Mail from a server without reverse DNS that doesn't trigger any of your other flags generally shouldn't be treated as spam if you care about false positives, if it's borderline then maybe the lack of reverse DNS will be enough to justify tagging it as spam. The decision of how heavily to weight the lack of reverse DNS is yours, personally I don't give it much weight but it does add a little to the score. Some people go hardcore and reject anything that doesn't have come from a machine with reverse DNS, they accept the significant false positive rate usually for idealogical reasons (while I like a properly configured system I'm not going to bite my nose off to spite my face).

  • If your email server does not have rDNS records then it's very likely half your mail is not getting delivered., gmail, hotmail, etc all require rDNS.

    Blocking on invalid rDNS, invalid or missing A records and not following proper smtp protocol is helpful on a email gateway. However, if you are a relay for clients you'll have problems.

  • Denying all wrong rDNS is a bit harsh, however, denying what's a DSL and the rDNS declaring as such is a good idea. I've yet found very very few cases where it was an issue. For such case, just white-list the entry your customer is complaining about. Here's how to do with postfix:

    smtpd_client_restrictions = permit_mynetworks,
    check_client_access regexp:/etc/postfix/maps/relaying_stoplist,

    And here's the content of my /etc/postfix/maps/relaying_sto
    • Human-readable error messages may also be a good idea. Surely you can do better than "We aren't accept direct connection not from dedicated SMTP servers."

    • Magnificent. Seriously, giving back retarded English is a stoke of genius, and I'm not being sarcastic. Real admins will chuckle, jerks and asshats will flame you (and now you know to add them to your deny), and machines aren't reading it anyways, you had them at 553.

      I think there's a recipe out there to automate dropping the connections after a set number of tries and rejects. For my denies, I just ignore the connection and let them timeout. This seems to trigger a lot of spammers to stop wasting time

    • So I shouldn't have used the as the outgoing SMTP server. And was available too, god damn it!

    • by laffer1 ( 701823 )

      You're part of the problem. Not EVERY CABLE MODEM IS AN END USER.

      I have a business class cable package. My employer also does. DHCP is one thing, but static blocks should be excluded from your list. You can get 3 cable packages for the cost of a T1 here. It's insane to buy a T1 to host a website.

      This is an attempt to make the internet smaller and get rid of the little guys.

  • by Above ( 100351 ) on Thursday October 13, 2011 @01:23PM (#37703700)

    It is possible to configure your mailer to require all sorts of things, like rDNS. If you configure all of them you will get almost no spam, but you'll also not get 50% of your legitimate e-mail. Perhaps that's ok with you, you're willing to only talk to the "clueful".

    Most people though want to get mail. The old Internet axiom "Be conservative with what you send, be liberal with what you accept" applies. WIth spam fighting this generally means use every mechanism at your disposal (including rDNS existence, or matching with forward DNS); but use it only to affect the score of a message. That way the guy who doesn't have rDNS right, but does everything else right will still get through.

    • It's been a long time since I wrote up some spam-filtering instructions [], but I'd still stand by most of my recommendations. In general, yes: just increase the spam score. I do have several litmus tests, though. If you fail one of these, I'm not accepting your mail:

      • Your HELO has to send something that actually looks like a hostname. "server" doesn't work, and neither does "5626^^^". Rationale: a server this badly misconfigured is either a spambot or so horribly broken that I don't want to talk to it. I look at the output of this rule from my logs and I've literally never seen anything blocked that looked like it might have been legitimate.
      • Don't send me my own hostname in the HELO. You're lying. The only reason to do this is to trick me into relaying for you.
      • Don't send mail From: an unresolvable address. "someone@server" isn't a legitimate email address. Neither is "". If it would be impossible to send you a reply because the address you've given can't possibly be valid, I don't need to hear from you.
      • I use,, and to generate a likely spam score for incoming servers. If their combined score exceeds a certain threshold, I outright block email from that server. A server might accidentally end up on a blacklist, but it's unlikely that one would accidentally end up on more than one of those (in my opinion and experience) very conservative lists.

      "Be liberal with what you accept" is a great idea to a point, but there are some things that correlate very strongly with spamminess. Back to the subject at hand: I don't think that lack of reverse DNS is one of those things.

  • by snsh ( 968808 ) on Thursday October 13, 2011 @01:23PM (#37703710)

    In an organization operating a mailserver without a PTR record for their SMTP, the users should be having so much difficulty sending outbound mail that they know something is wrong. I know this from experience, having set up an SMTP without reverse DNS, and then observing that half my test messages bounced back.

  • Many email servers do not have rDNS, therefore it is not advisable to filter based on a lack of rDNS alone.

    It can be argued that it should have an rDNS, but if they don't, you have no control over that since it's their system. Then you'll be spending way too much of your time tweaking spam filters and creating white lists, contacting the sending company's administrators...

    It's just a bad idea, don't do it.

    That said, I prefer SaaS email spam filtering like Symantec's Messagelabs. (Disclosure, I am an ML part

  • A bit over a year ago, I performed a reverse dns scan of the entire internet []. It took around 4 months and amounted to about 62GB of data which I haven't sorted through just yet, but I'd guess based on what I've seen so far that only 20-30% of the utilized Internet has reverse DNS entries. This is kinda what I suspected all along, but I now have data to back that up. How can anything properly use reverse DNS with that low of an adoption rate. Its sad because so many more services could be offered if it was

    • by pe1chl ( 90186 )

      Probably the number of addresses in the utilized Internet that are intended to send mail is much lower than that 20-30%.

      So it could still be a good method.

    • Real men would scan the IPv6 space too.... :)


      • by suso ( 153703 ) *

        Real men would scan the IPv6 space too.... :)

        I know you're joking as that would take longer than the age of the universe, even if you could scan it at a rate of 2^32 IPs per second.

        However, one of the reasons why I did it is to gather data about where hosts are going in the transition from IPv4 -> IPv6. Some of the information I have includes IPv6 and IPv4 data paired together. So although you couldn't scan someone's block, you can get an idea of where they put their stuff in the new IP era and maybe compare what people usually did in their migra

  • No (Score:4, Interesting)

    by TheCarp ( 96830 ) <sjc@carpanet.PERIODnet minus punct> on Thursday October 13, 2011 @01:26PM (#37703752) Homepage

    You know....I hate spam. It made usenet useless for years, it continues to degrade the usefulness of email, spamers steal resources and are underhanded dickwads.

    All that said, some of the anti-spam people are ridiculous zealots who don't care who gets caught in the crossfire.

    I have a server in colo. Its my mail server, but it also does a number of other things. Until recently, it ran a tor node. Why? Because i had sooo much more allocated bandwidth than I was using on a monthly basis that it cost me nothing extra to run. Ran it for at least 6 years on the same node.

    Its now shut off, why? Because some idiots at Spamhaus decided that running a tor server was suspect. Never mind that it was disallowed from exiting on port 25, which is publically posted info in its service Of course, I think they are also fooled by the fact that several windows users have shell accounts and use it as a web proxy.... so somehow my box also was infected with a Windows trojan according to these geniuses.

    We got it cleared up, but still are not able to donate excess bandwidth allowance to the tor network.... which is bad enough, but this isn't the first time I have had my server blacklisted for no good reason at all. I don't even remember what BS it was last time, just that it was... BS.

    Now will this kill me? No.... I have reverse DNS setup and have for years but...come on.... seriously? Bouncing mail sucks, especially when you suddenly start doing it to whole domains.

    If it were just me, my opinion is that anyone using one of these RBLs has a misconfigured mail server, I wouldn't have "fixed it".... but I host other peoeple's email domains, so the black ball tactics worked.

  • by StripedCow ( 776465 ) on Thursday October 13, 2011 @01:27PM (#37703754)

    Being fed up with postfix and exim, I recently wrote a simple e-mail server using python. I followed the RFC standard as well as I could, but to my surprise, I noticed there are numerous special undocumented tricks one needs to know to get mail through to the recipient in a reliable way (whitelists, blacklists, reverse dns, etc). I am wondering if anybody here knows if there is a place on the net where such tricks are documented.

    PS: IANAS (I am not a spammer, honestly)

  • Just whitelist any email that has a verified digital signature. Everything else you can't trust.

    Good luck getting anyone to actually set up and use digital signatures/encryption, though :-P But if you make it a matter of policy and give them the tools to use it, there's no better way.

  • Remember that not every non-spam email originates from a perfectly-configured self-hosted SMTP server. Many organizations outsource their email, spam filtering, compliance filtering, notice / statement delivery, etc. While it's easy to posit that the IT departments in such organizations have a duty to maintain reverse DNS records for all their partners' servers, don't fall into the trap of thinking that every organization has a fully-staffed, knowledgeable IT department... or an IT department at all.

  • Having a reverse DNS is a good practice, and anyone with a mail server should be doing it. That said, a lot of small businesses don't have reverse DNS set up, don't know what you mean when you tell them to do it, or have ISPs that are a pain to deal with. I'd mark up the spam score on a message without reverse DNS on the sending server (and I do on my own server) but I wouldn't block it entirely unless it sets off a lot more flags than just that one.

    I use Kerio Connect on my server - I add 2 points for lack

  • The windows admin where I work hates reverse DNS. He thinks it's stupid and refuses to keep it updated. So... if there are more people like him out there, you might have issues getting email from them.

    • Hope he likes updating his resume.

      • by djp928 ( 516044 )

        Lucky for him, Windows will keep reverse DNS reasonably well maintained (provided you're using a Windows DNS server) until you decommission a host and reuse a host name or IP address. Then it seems to have huge issues getting things cleaned up. I haven't any idea why because I try to stay away from it.

    • Hates what about it? That almost doesn't even make sense.

      • by djp928 ( 516044 )

        He hates that some apps/protocols use it as a security measure, by doing a reverse lookup on the IP they were just given and trying to match that to the host name they were given. That means he has to pay attention to whether or not Windows is maintaining that info correctly, and as I've said in other replies, it often doesn't if you've ever reused an IP or hostname.

  • Reverse DNS makes absolute sense as a means to counter spam, but the reality I've experienced is that there are too many IT admins that don't even know what a PTR record is, and since they don't experience an issue with all of their mail recipients, they assume it's an unnecessary step, even when you try to explain that it with a sock puppet show.
  • The requirement for reverse dns is in hindsight a part of the "security theater" where various claims are made, and remedies suggested against perceived ills. The suggestion for reverse DNS comes solidly from the era of TCP wrappers, another supposed saviour of ill maintained systems from outside evils.

    In reality, there is no actual increase of security from checking if some address has reverse dns as for ages most of the dial up and broadband lines all have reverse dns. Also, as reverse dns zones are by an

    • Checking for a matching reverse DNS that matches a forward DNS. Not all reverse DNS resolves forward. Apparently my ISP does that. Stupid ISP. Of course it's a consumer ISP and they block port 25 inbound AND outbound. That's right, they don't even want me RECEIVING spam for myself.

  • The real problem is that while this would really help fight spam, there's collateral damage. Just like the judicial systems in civilized countries tend to operate on the principle that it's better to set 100 guilty people free rather than imprison 1 innocent person, most people who receive email would rather receive and delete 100 spam messages than miss one legit email inquiry from a potential customer or long-lost friend.

    Sender Policy Framework seems even better than simple reverse DNS in theory, but it

  • This is simple stuff here. Firstly, it verifies ownership of the domain. I will never accept email from a host that does not resolve. Doing so will of course allow a ridiculous amount of spam from infected computers around the globe from regular IP addresses. The email address needs to match the host in which it is sending from as well. It requires hardly *any* work. Why are we even talking about this?

    HELO, ELO, wants the hostname as well. Are we expecting millions of mail servers to simple change the way t

  • The question "Is Reverse DNS a Worthy Standard For Fighting Spam?" is incorrect. Spam is not the reason; using it as a measure of clue is. Servers that emit spam and and clue level can be related, though. If someone is clueful enough to set up a mail server properly they're going to make sure it has reverse DNS. A mail server run by a less than clueful individual (or set-and-forget with no admin) is more likely to be a problem source either now or in the future than the ones that are cluefully configured and actively maintained.

    Of course you are going to have spammers that are clueful mail admins and will set up their servers properly. That's why you can't pigeonhole reverse DNS as some kind of spam fighting method alone. But it can always be used as a measure of cluefulness.

  • The only truly effective spam prevention technique I've seen is greylisting [].
    • ...for now. Spam has troubles with greylisting simply because they haven't built simple queuing into their zombies yet. As soon as the implement something that tries 15-20 minutes after initial rejection, greylisting becomes useless.

      I actually found SPF to work pretty well. That was until a business we work with didn't know how to configure theirs, and they created records to instruct all mail servers to reject any e-mail from them. Relayed this to them several times, but eventually, the order came do
    • by heypete ( 60671 )

      It's also an enormous pain.

      The email service for the department at the university I used to work for used greylisting, and incoming mail was routinely delayed for 30+ minutes. While I realize that email is not a time-critical service, it is still a hassle to wait for incoming email.

      Even if greylisting could completely eliminate all spam, I would rather tolerate a small amount of spam than deal with the delays. Google Mail (who provides email for my domain)'s spam filter is so good that it is a rare occasion

  • You have to do this (Score:2, Interesting)

    by DarkOx ( 621550 )

    Its right, its not fair; but its needed. Legitimate sites should have no problems setting up reverse records or getting their provider to do if for them.

    Anyone who is not in a position get PTR records in place for their mail server is not actually in a position to be running a mail server anyway. Sorry that is just the way it is. PTR records are nice to have for any number of mail delivery troubleshooting and validation issues outside of SPAM.

    As a mail admin I'd kinda consider them a requirement anyway.

  • I work for an ISP and we require rDNS records for all incoming mail. You will filter out a TON of spam email with that simple rule. It's much easier on the CPU load to filter on a simple reverse DNS check than to run spam assassin on that message. There are the occasional (not as many as you'd think) misconfigured servers that don't have rDNS. In those rare cases we contact the other end and let them know they're incorrectly setup, and usually add a temporary allow until they get the issue fixed.

    I highly re

  • You're going to read a lot of comments a long the lines of "Yes, because only a legitimate emailer will know {long list of obscure hoops you apparently have to jump through to send email, most of which are not documented in any RFC.}"

    In reality, the answer is no. It's a fucking stupid idea, and the fact that there are a lot of fucking stupid idiots choosing things like this as a way to block spam doesn't justify it. In reality, it's something a spammer (generally a person who knows a little more about se

  • Use other things as well, like, SPF, whether the connecting machine is an MX for the domain, greylisting of various kinds (possibly), and weighting on lists like SBL and XBL. PBL will block hobbiests like me, fortunately gmail doesn't do that.
    And then once you accept it you can do more thorough bayesian checks on headers and content.
    In any case, absolute reliance on any of 'em is a problem. Spam Assassin is awesome at doing weightings, IMO.

  • If the PTR request results in NXDOMAIN:
    then add a X-Warning-no-RDNS header.

    Customers are informed of this header. If they wish to make a client-side quarantine rule, they can. Customers are advised not to make rules to automatically delete such emails, as rDNS can get overloaded.

    Also - if the rDNS resolves, and the answer is a KNOWN "dynamic or residential" rdns type name, then graylist that sender for 15 minutes. Most spam bots will not queue and retry their spam... they just move on and attack an easier

  • I've been an Internet mail server administrator for over 20 years. About 10 years ago I experimented with a rule that would block all mail from any mail exchanger without a matching/existing reverse DNS record. I experienced the same problems that you are now experiencing. I tried to enhance awareness of this problem but didn't get very far. There are lots of small businesses (including mine) who run their own mail exchangers. Many administrators simply do not understand the technology enough, and they
  • by sjames ( 1099 ) on Thursday October 13, 2011 @03:06PM (#37705024) Homepage Journal

    Filtering based on lack of rDNS is an old technique that actually did a good job of detecting spam without an excess of false positives for about a week in the late '90s. It has for some reason become enshrined as policy by a great many people now. These days it is occasionally a better indicator of NOTspam since the spammers all make sure they have rDNS set up and have done so since that week or so in the '90s.

    Consider, if someone in a striped shirt wrote your business a bad check a decade ago, would you maintain a policy of not doing business with people who wear striped shirts?

  • I didn't read every comment, but the general theme seems to be that it's not absolutely required to have a reverse DNS entry. While this is true per the RFC - it's incredibly bad in practice. Google MX check, run the checker and if you don't have reverse DNS it'll point it out. Also people that say not one mail has bounced because of this must simply be wrong. Many blacklists will auto-add you if they notice you don't have reverse dns, then many companies will pick that up. Last time i had to move my compan
  • by FridayBob ( 619244 ) on Thursday October 13, 2011 @04:50PM (#37706246) Homepage

    My approach, using Exim4, is not to reject messages outright based on single issues, such as not having a proper reverse DNS entry, but to reject based on combinations of them. This is a great way to limit false positives.

    For instance, an incoming message may also have a bad HELO, a bad sender domain, be blacklisted locally or by a DNSBL service, or not have a working callout so that the existence of the sender's account can't be verified. There are more issues like these to look for. My systems count the number of these transgressions per message and reject when a certain value is reached, say three, while dumping messages that score one or two end in the recipient's spambox folder. With Exim, this kind of solution is surprisingly easy to construct using ACL statements with user-defined variables that include arithmetic statements. The last checks that are performed involve Clamd and SpamAssassin, because they are so resource-intensive.

    I should also mention that my systems also perform a number of checks up front for obvious spam that is rejected immediately, e.g. if the sender address domain is, but the sender HELO name is not part of the domain.

Always leave room to add an explanation if it doesn't work out.