• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • 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.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Resolved Google to soon require ARC for forwarded messages

I found the following command in another post, but doesn't seem to work.
Code:
plesk bin settings -s mail_arc_sign=true
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.
 
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,
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.
 
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.
 
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.
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...
 
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.
 
Examining the email headers from test messages sent from that server should reveal the answer. Mail-tester.com might, again, prove useful there.
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...
 
It will be nice to answer the question. Regardless of the answer, I have only ever used "relaxed" mode. Here is a quote that I agree with from Valimail..

The DMARC standard enables a domain owner to allow relaxed alignment or to require strict alignment. Note that there is no discernible increase in protection by using Strict mode.
 
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!
 
Examining the email headers from test messages sent from that server should reveal the answer. Mail-tester.com might, again, prove useful there.
Server 1: Plesk is the email provider, Mailgun forwarding, DNS zone in Plesk, strict dmarc:
As already shown:
1706521592902.png

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.
1706521981644.png
1706521802477.png
 
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
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).
 
Back
Top