Facebook
Twitter-
The ImunifyAV extension is now deprecated and no longer available for installation.
Existing ImunifyAV installations will continue operating for three months, and after that will automatically be replaced with the new Imunify extension. We recommend that you manually replace any existing ImunifyAV installations with Imunify at your earliest convenience. -
The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
Resolved Google to soon require ARC for forwarded messages
cmartinez127
Basic Pleskian
I don't know, I already had this setting ON before installing ARC update.
At this time - no. However, "Allow signing outgoing mail" should be enabled.
ARC signing is enabled by default. So this effectively does nothing out of the box.
Can be disabled via
plesk bin settings -s mail_arc_sign=false plus repair mail.dkimpy
Oh, on my server ARC doesn't work when "Verify incoming mail" setting OFF.
But ARC works when setting ON.
Just a guess... Looking at the "Verification details", could it be related to using "strict" alignment mode (adkim=s; aspf=s). Try changing your DMARC record to use "relaxed" alignment (adkim=r; aspf=r)) and see what changes,
cmartinez127
Basic Pleskian
If I change to "relaxed" works, but the thing is we have another server with "strict" alignment mode and using Mailgun to forward too and it passes all tests. We don't know why, because email headers are not aligned (example.com not smtp.example.com) in the second server and works.
Still guessing here... Only one of either SPF or DKIM need to pass and be aligned. The other can fail. So, perhaps one of them is aligning, even with "strict" mode selected, on that other server.
cmartinez127
Basic Pleskian
That's the real question, how did the domain in the other server pass either DKIM or SPF with "strict" alignment. That's what I don't understand and would like to...
Examining the email headers from test messages sent from that server should reveal the answer. Mail-tester.com might, again, prove useful there.
cmartinez127
Basic Pleskian
I will check this on Monday and I will share what I find out comparing both. The only difference is:
Server 1: Plesk is the email provider, Mailgun forwarding, DNS zone in Plesk, strict dmarc.
Server 2: Microsoft is the email provider, Mailgun forwarding, DNS zone in Plesk, strict dmarc.
We will see what is different...
cmartinez127
Basic Pleskian
You aren't wrong.
In the end, with DMARC basically you just establish some actions for the email sent from your own domain.
Alex Presland
Basic Pleskian
All this makes me more and more convinced that those writing the RFCs have utterly messed up. I've read the DKIM & DMARC RFCs and it lists all sorts of scenarios which it should work in... but the bottom line is that it doesn't work with the MAJOR email hosts. I had a bounce forwarded to me last week which had gone from my originating server (non-Plesk; DMARC p=reject) to M365 which forwarded to Gmail... which rejected it!
So instead of fixing their broken security mechanisms they come up with more complication: ARC... a small sticky plaster on top of a gaping wound.
I don't quite get why SPF & SRS weren't enough. They were simple. They specified where a domain's email could come from and enabled forwarding to work.
Hey ho, we are where we are!
So instead of fixing their broken security mechanisms they come up with more complication: ARC... a small sticky plaster on top of a gaping wound.
I don't quite get why SPF & SRS weren't enough. They were simple. They specified where a domain's email could come from and enabled forwarding to work.
Hey ho, we are where we are!
cmartinez127
Basic Pleskian
Server 1: Plesk is the email provider, Mailgun forwarding, DNS zone in Plesk, strict dmarc:
As already shown:
Server 2: Microsoft is the email provider, Mailgun forwarding, DNS zone in Plesk, strict dmarc:
I didn't expect this, it says I do not have a DMARC record, but I have this in Plesk DNS zone. Even though this, test passed with a 10/10.
No DMARC record would explain the difference. Might be a DNS issue. Verify your DMARC record exists in the global DNS, here...
DMARC Check Tool - Domain Message Authentication Reporting & Conformance Lookup - MxToolBox
DMARC Check Tool - Domain Message Authentication Reporting & Conformance Lookup - MxToolBox
cmartinez127
Basic Pleskian
If I search "example.com", no DMARC found.
If I search smtp.example.com", exists and it's correct.
I verified DNS zone and indeed the DMARC was missing for example.com.
Anyways the problem is still in Server 1, which has a DMARC for both example.es and smtp.example.es
I think, in most cases, you should only have a DMARC for example.com (_dmarc.example.com) as it will, by default, apply to all subdomains. Unless you have a need for a more complicated set up, keep it as simple as possible.
I think the easy fix is to use "relaxed" DMARC mode so the FROM domain (example.com) and the DKIM/SPF domain (smtp.example.com) will "align" even though they are not identical. I don't believe you can use "strict" mode if the DKIM/SPF domain (smtp.example.com) is a subdomain of the FROM domain (example.com).
I think the easy fix is to use "relaxed" DMARC mode so the FROM domain (example.com) and the DKIM/SPF domain (smtp.example.com) will "align" even though they are not identical. I don't believe you can use "strict" mode if the DKIM/SPF domain (smtp.example.com) is a subdomain of the FROM domain (example.com).
Similar threads
