How do I stop mail identified as spam getting deleted?

Thanks guys. You two need a stage name or something.;)
Good idea. :)

Interesting discussion.
I disagree. That's exactly what DMARC is supposed to do—inform the remote mail server what to do with mail that fails SPF and DKIM.
Correct. What to do with the mail that fails SPF and DKIM according to what the owner of the DMARC record set. So if that ownser set to do nothing on fail, then nothing should happen! Otherwise it would not even be possible to test the DMARC settings.
So we agree, but I think you did not understand what I mean.

That document is outdated IMO. (It was last updated in 2015.)
Which doesn't make it instantly outdated. I think you are mixing up things. SPF, DKIM and DMARC are all different things created by different designers.
SPF also is used a very lot stand alone by lots of hosters and providers. So it's still valid and a better solution to use -all than ~all. The latter just let everything pass with a softfail, which was definately not the intention of SPF. As far as I know this is more like a test like p=none with DMARC.
For real protection you need the -all otherwise SPF isn't really of any use.
You're only looking as to what DMARC is doing. But even for DMARC a fail is clearer then a softfail imho.
However you have to keep in mind that most providers and hosters are not using DMARC yet for every domain, neither am I for example.
So in that case your SPF has to be correct if you want to be as perfect as possible. Using a ~all works the same as don't use SPF at all. So using -all in SPF is not outdated but a good advice imho.

Me too! Unless the default sucks… which it kind of does in the case of that message.
Well.... I think I've also seen something as you presented as message.
I agree it looks better, but it lacks the warning of not enough content and cutting down html links because both are valid reasons to classify as spam. And imho it's not a good idea to leave out valid reasons for declaring the message as a spam message.

It might be good to leave out the "naughty words", except if this message is also specifically triggered on using words as mentioned before. Maybe another word than "naughty" would be in place, but which word would you prefer in that case?
Ofcourse, when triggered on those words. If not, it can be left out.
 
Correct. What to do with the mail that fails SPF and DKIM according to what the owner of the DMARC record set. So if that ownser set to do nothing on fail, then nothing should happen! … So we agree, but I think you did not understand what I mean.
Ah okay, I think I see where you're coming from now… Let's assume that a spammer sends from a domain with the DMARC record set to p=none. So you're saying that this would just nullify all the other tests? Good point. I hadn't fully thought that through. I guess that's where one of DMARC's other functions comes in, of checking domain alignment. If the domains don't align, we should probably ignore the sender's DMARC policy? What happens then? Look at the spoofed domain's DMARC policy? I received some DMARC reports from Google a few weeks ago that failed SPF because they were actually sent from a different IP address (one that I don't own). Is that what was going on there?

I think you are mixing up things. SPF, DKIM and DMARC are all different things created by different designers.
SPF also is used a very lot stand alone by lots of hosters and providers. So it's still valid and a better solution to use -all than ~all. The latter just let everything pass with a softfail, which was definately not the intention of SPF.
I haven't mixed these things up. I already acknowledged that the original intention of SPF was to declare policy on how to deal with validation failures, and the way it did this was to distinguish between -all and ~all. But SPF was found wanting. DMARC builds on both SPF and DKIM, and also handles policy on what to do with mail once it's assessed as spam. The writers of those articles I shared before (and others) have argued that it makes more sense to pass this function to DMARC, rather than drop mail instantly for a single SPF fail. Google seems to agree also… From their help doc Help prevent email spoofing with SPF records:
Add an SPF TXT record to your domain host …
Value/Answer/Destination: v=spf1 include:_spf.google.com ~all

If you scroll to the bottom of that same article and click on 'Use SPF with DKIM and DMARC', they explain the purpose of each protocol:
Along with SPF, we recommend setting up DomainKeys Identified Mail (DKIM) and Domain-based Message Authentication, Reporting & Conformance (DMARC):
  • SPF specifies the servers that can send email for a domain.
  • DKIM verifies that message content is authentic and not changed.
  • DMARC specifies how your domain handles suspicious incoming emails.
In describing the key functions of each method, they describe the basic workflow I'm talking about… Let SPF declare which servers are authorised to send mail; let DMARC declare what to do with mail that fails the tests.

I agree it looks better, but it lacks the warning of not enough content and cutting down html links because both are valid reasons to classify as spam. And imho it's not a good idea to leave out valid reasons for declaring the message as a spam message.
SPF, DKIM and DMARC are the best tools we have to validate mail. If configured properly (by both sending and receiving mail servers) they prevent the kind of spoofing that spammers do to avoid detection. Admittedly, they don't stop spammers who brazenly and openly comply with the standards! But then they are easily blocked. So, these are the tests which should (and are) given the most weight. Therefore, I'd argue again that a poorly configured mail server is by far the most likely cause of legitimate email being labelled as spam.

Those other factors (length of content, number of links, rude words, etc) don't enter into the SPF/DKIM/DMARC equation. SpamAssassin and other filters might concern themselves with these things, but overall it's not a big factor, and unlikely to be the cause of mail being dropped outright. So, I'd rather point people to the big issues, rather than waste their time by telling them to fiddle around with the wording of their email. If legitimate email is being dropped because the user wrote a short message or used a few naughty words therein, then clearly the incoming server's configuration is far too unforgiving, and that's where the real problem lies.
 
Just for starters, I like this discussion, because it triggers me (and maybe others) to rethink our policies and look at new insights. The Myths and Legends link was very interesting for me for example.

So you're saying that this would just nullify all the other tests?
I'm not 100% sure about that, but I don't think so. The p=none is only Dmarc policy. So the Dmarc owner will get a testresult that SPF failed and DKIM failed and normally this would be blocked, but at least DMARC won't block it.
SPF might, so that might be the reason to better use ~all in combination with DMARC.

I received some DMARC reports from Google a few weeks ago that failed SPF because they were actually sent from a different IP address (one that I don't own). Is that what was going on there?
That might be. Could also be caused by the either the policy and/or percentage you set in the DMARC line.
I also sometimes get them when customers forward my mail. But in that case the mail should arrive. But in that case the SPF will probably fail because the customer is not allowed to send mail in behalve of my company. However, the original header is intact and DKIM will pass so the mail will be accepted (if I understood it correctly).
In this case I also get a SPF fail and DKIM pass DMARC report from Google.
Now suppose a spammer from a different ip uses my email adress, the email would be blocked because SPF will give a hard fail and DKIM is not aligned and I have a p=reject.
However, I've been testing before with p=none and pct=20. After that it went via pct=75 to pct=100 and p=quarantaine.
At this moment it's p=reject and pct=100.
So how would people be able to test their DMARC records, if ESF would check DMARC and block mails with SPF and DKIM not in line while the owner of the DMARC record has a policy let them pass for test?

The writers of those articles I shared before (and others) have argued that it makes more sense to pass this function to DMARC, rather than drop mail instantly for a single SPF fail.
Yes, when using DMARC, because that might be better when forwarding mails for example. There will not be an instant block on SPF already.

Indeed it says:
SPF specifies the servers that can send email for a domain.
But if ~all is used, *any* domain is allowed because it will only generate a softfail (so you can spoof all you want if I'm correct).
I've seen much more spam coming through on my server when ?all or ~all is used than when -all is used so that would be odd when reading the Myths and Legends of SPF link, which also says this:
Fact: In general, SPF authorization or lack thereof does not have a significant impact on the delivery of email messages.
Which I don't agree with. If I use -all, emails will be blocked when not coming from my server, so I don't understand how they can say it does not have a real impact on delivery because it does. However, there has to be an SPF check and that is the issue. The lack of the check is causing the unsignificant impact, because lots of even big ISP's do not even use an SPF check.
If they don't use this, I wonder if they even do a DMARC check. So I'm a bit stubborn about believing this particular fact.

Fact experience by myself. If no Dmarc is used (like on lots of hosts and isp's), there will be more spam arriving and more spoofing done when ~all is used, at least on servers who do an SPF check. I experienced this myself before I used dkim and dmarc. Stil found mails not from me, send by a spammer because they only got a softfail.
Indeed, this can cause issues on forwards, that is correct, so when used in combination with DMARC, it seems true that the ~all is better so things are passed to DMARC for getting investigated. Which would indeed mean the DA help file would need adjusting.
But this is -only- for systems which are really doing a DMARC check, to me it means if you send to systems not doing a DMARC check, spoofing will remain easy to do when ~all is used, nothing will be blocked.
So now I wonder if there is there a guarantee that all MTA's in the world (at least most hosters and most ISP's) are doing DMARC checks? If that is the case, I don't have to discuss anymore and we can use ~all in combo with DMARC.
But imho still not with SPF only records.

Something else which is really confusing to me.
-all can be used for domains that are not used for sending legitimate emails. DMARC considers -, ~ and ? as equivalents.
The second part I understand, but the first part I don't understand "are not used"?? I use -all and I'm only sending legitimate mails.
I'm not nativing English so I might miss the correct meaning of this.

So in short. I can agree that ~all might be better to be used when also DKIM and DMARC is used.
But I believe -all is better to prevent spoofing (and so spam), when DMARC is not used. And most hosting accounts still do not use DMARC if I'm correct.

hen clearly the incoming server's configuration is far too unforgiving, and that's where the real problem lies.
If I get an email which contains almost only links, it's mostly spam, so I personally don't see that as too unforgiving. The naughty words might not be used that much nowadays and the too little content maybe neither. So I agree there might be room for improvement in that text.
 
Yes, thanks for an interesting discussion Richard. :) Sorry I haven't had time to respond for a few days, and my brain is a little fried at the end of the day, so I won't try to string too many words together.

Thanks for sharing your real-world experience comparing ~all and -all. You might well be right to challenge that so-called 'fact'. My own personal experience shows that Google and Apple at least take the DMARC policy at its word, but then I've not experimented with SPF -all, so I don't know how they handle that in combination with a DMARC 'p=none'.

I mean, there's clearly no absolute consensus on this stuff. I guess when you take an old standard (email) that was never designed with security in mind, tack on a bunch of other standards (SPF, DKIM, DMARC) designed by different people at different times, then leave it up to server administrators to configure it all as they see fit (or not)… well, it's no wonder the whole thing is a little challenging!
 
Sorry I haven't had time to respond for a few days, and my brain is a little fried at the end of the day, so I won't try to string too many words together.
No problem at all. I fully understand.
You're quite correct that luckily already a lot of mail providers do use DMARC checks, Google, Apple and Microsoft indeed do.
I don't know either how they handle a SPF -all in combination with a p=none from DMARC either.

If everybody would implement such things, like SPF and later DKIM and later DMARC, we would have a lot less spam issues. Unfortunately name making and competition (concurrence) seems more important to some.
However, DMARC is growing and if we only could be sure that every MTA is checking DMARC, even when they don't use DMARC themselves, then we would be out of the woods. Because if we would use DMARC in that case, at least nobody could fake our mails.
 
  • Like
Reactions: Kal
As for the discussion, a little addition. I found a Cisco document (also 2017) which still said it's better to use -all than ~all, so I'm still wondering as what the greats of this earth think of what the better use is, especially when DMARC is not used.
 
It seems to me that the Greats Of The Earth need to get together and arrive at some kind of consensus so us mere mortals know what on earth we're supposed to be doing! 🙂
 
Back
Top