When I try to use POP3 with SSL, Gmail complains: "Certificate is self-signed"

[cmyden]

Doublechecked. On new server dkim from server is different than domain it's from so yes they are different.

Thanks!

In this one I'm confused about 3 and 4. They are switched now compared to the previous one but that could be due to cloudflare. So you might be correct there with 4, I don't know as I don't use cloudflare.

Yes, sorry, my latest example doesn't really correlate to the previous one.

These are just the 4 records I've ended up with when all is said and done.

So in the last example 1 and 2 look good, but be aware that in Directadmin, the domain is always added, so if DNS there says x._domainkey it will end up in being (for number 3) x._domainkey.server.primarydomain.com. in fact.

On CloudFlare, there's not really an option to add a record to 'server.primarydomain.com', you can only add records to 'primarydomain.com'

According to this info about adding DKIM for subdomains:

https://community.cloudflare.com/t/dkim-for-subdomain/106707/3

The name of the text record needs to be selector._domainkey.market.domain.com where the value for ‘selector’ needs to be obtained from your mail provider (eg for GSuite the selector is ‘google’ so the name of the text record would be google._domainkey.market.domain.com

Since our selector is X, I assume the Name of my record should be:

x._domainkey.server.primarydomain.com

But, when you try adding it this way in CloudFlare, with the name above,
and you click Save, it automatically changes the name to just:

x._domainkey.server


If I go to: https://mxtoolbox.com/dkim.aspx

And try:

Domain Name = server.primarydomain.com
Selector = X

It claims everything is perfect.

Same goes for Domain Name = primarydomain.com and Selector = X


Any other tests I can perform to make sure all is well?

 

[Richard G]

and you click Save, it automatically changes the name to just:

x._domainkey.server

Ah oke now I understand. Then Clouldflare probably does the same as DA does too, adding the rest of the domain after it, so x._domainkey.server will be converted to x._domainkey.server.primarydomain.com which ofcourse will show everything correct when checking with mxtoolbox or another one.

I've got one which always checks a bit more deeper. If there are any errors or improvements it normally will display it.

Free DKIM Checker Tool - Lookup And Verify DKIM Record

The free DKIM checker tool helps verify your DKIM record & ensure your emails reach inboxes. Get started now & protect your domain!

powerdmarc.com

You can switch off the auto selection thing and then use x so only your dkim record with selector x will be checked.

 

[cmyden]

Ah oke now I understand. Then Clouldflare probably does the same as DA does too, adding the rest of the domain after it, so x._domainkey.server will be converted to x._domainkey.server.primarydomain.com which ofcourse will show everything correct when checking with mxtoolbox or another one.

I've got one which always checks a bit more deeper. If there are any errors or improvements it normally will display it.

Free DKIM Checker Tool - Lookup And Verify DKIM Record

The free DKIM checker tool helps verify your DKIM record & ensure your emails reach inboxes. Get started now & protect your domain!

powerdmarc.com

You can switch off the auto selection thing and then use x so only your dkim record with selector x will be checked.

Awesome thanks - it found no issues with primarydomain.com or server.primarydomain.com and selector x

 

[cmyden]

Just as an update to this.

My external (CloudFlare) SPF record for my primarydomain.com is currently:

v=spf1 a mx ip4:ip.add.re.ss include:_spf.google.com include:amazonses.com include:server.primarydomain.com ~all

Which matches my local record.

There was some question about whether my hostname (bold) should actually be included in the SPF record.

The only difference is that external DNS doesn't have separate records, so you could include it in the SPF of primarydomain.com in external DNS, however, it should in fact not fail because MX is already pointing to the mailserver (so the hostname). But one never knows. I don't work with external DNS, it can't hurt in anyway to add it. But locally in the DA server it should be present also.

Just to mention that MX toolbox gives me this error:

"A null DNS lookup was found for include (server.primarydomain.com)

primarydomain.com Domain Health

mxtoolbox.com

As far as I can tell this has not caused any actual problems with my SPF record.

When I send an e-mail to mail-tester from primarydomain.com everything is perfect.

I assume I can't do anything to get rid of this error, other than removing the include.

 

[Richard G]

"A null DNS lookup was found for include (server.primarydomain.com)

That seems to be an SPF record issue according to what I found.

What is a null record value in SPF?

Error: SPF record null value
This error typically occurs when the SPF record has invalid characters or if it does not adhere to the approved SPF syntax; having additional spaces within the SPF record is one of the most common causes of this error.

So it seems somewhere it looks there is either some small error in the SPF record or the hostname record has a dns issue.

I assume I can't do anything to get rid of this error, other than removing the include.

Well... probably you can.
There are SPF testers which can test the SPF line for wrong syntax for example here:

ORF Fusion. Simply different.

Award winning e-mail security and monitoring software for Microsoft Exchange and IIS. Fully scalable from SMB to enterprise with a budget-friendly price.

vamsoft.com

and here

Try EasyDMARC SPF Checker | Free SPF Lookup Tool

EasyDMARC's SPF lookup tool is free and lists trusted email senders. Sender Policy Frameworks are the best way to keep your organization safe and secure.

easydmarc.com

 

[cmyden]

That seems to be an SPF record issue according to what I found.

So it seems somewhere it looks there is either some small error in the SPF record or the hostname record has a dns issue.

Well... probably you can.
There are SPF testers which can test the SPF line for wrong syntax for example here:

ORF Fusion. Simply different.

Award winning e-mail security and monitoring software for Microsoft Exchange and IIS. Fully scalable from SMB to enterprise with a budget-friendly price.

vamsoft.com

and here

Try EasyDMARC SPF Checker | Free SPF Lookup Tool

EasyDMARC's SPF lookup tool is free and lists trusted email senders. Sender Policy Frameworks are the best way to keep your organization safe and secure.

easydmarc.com

Hmmm, thanks, I'm pretty confident the syntax is correct.


SPF record for primarydomain.com

v=spf1 a mx ip4:ip.add.re.ss include:_spf.google.com include:amazonses.com include:server.primarydomain.com ~all


vamsoft says: syntax validation passed

easydmarc says: Invalid SPF domain: "server.primarydomain.com". Make sure the domain has a valid "SPF" record.


Am I supposed to also have another SPF record, like this?

SPF record for server.primarydomain.com

v=spf1 include:server.primarydomain.com ~all

 

[Richard G]

If I'm correct it's because there is not seperate domain.
And if you can't enter server. primarydomain.com seperately in the external DNS as seperate domain, then it won't work.
So in that case just leave it like it is or remove this include and see if system messages come through to gmail.
Because only system message are send from the hostname, not normal mail.

 

[cmyden]

If I'm correct it's because there is not seperate domain.
And if you can't enter server. primarydomain.com seperately in the external DNS as seperate domain, then it won't work.
So in that case just leave it like it is or remove this include and see if system messages come through to gmail.
Because only system message are send from the hostname, not normal mail.

Thank you,

So, for Amazon SES, I am required to use a subdomain if I want my SPF to have perfect alignment.

So I use: from.primarydomain.com

And then in CloudFlare I have:



And according to all my DMARC reports, the e-mail being sent through Amazon is aligned with SPF and DKIM and working perfectly.


So it seems like I can indeed enter server.primarydomain.com in the external DNS as a separate domain ?

I assume it probably can't hurt much to try adding the SPF record and just go through all the tools and monitor the DMARC reports again to make sure all is well.

Would there be a chance of servers looking up the wrong SPF record?


And this would the best SPF record to try adding ?

v=spf1 include:server.primarydomain.com ~all


I don't need to add anything like...

a mx ip4:ip.add.re.ss

?

Thank you

 

[Richard G]

Would there be a chance of servers looking up the wrong SPF record?

No I don't think so, though I can't give any guarantees on that. As said I never work with external DNS systems. Normally if DNS is correct then SPF is checked against the domain name (or host name or sub domain name) and will use the according present SPF record.

And this would the best SPF record to try adding ?

v=spf1 include:server.primarydomain.com ~all

It might be. I would say try it, but indeed I would ad the A MX and ip4 too, so treat it as a normal domain.

 

[cmyden]

Hi Richard,

For many months, since February, everything was working perfectly.

And I haven't touched a thing.

But apparently starting last month, Gmail has been unable to retrieve mail from my server. I only became aware of it after wondering why I haven't been receiving any e-mails in a while!

Upon investigation, Gmail says:

Server returned error "SSL error: Leaf certificate is expired"

Apparently this issue started on July 17th.

Taking a look at DirectAdmin, my notifications show:

July 13th: DirectAdmin has been updated to v1.665

August 17th: Error during automated certificate renewal for server.domain.com

^^ When I click on that, it shows:

exec ["/usr/local/bin/lego" "--accept-tos" "--email=[email protected]" "--key-type=ec256" "--server=https://acme-v02.api.letsencrypt.org/directory" "--path=/usr/local/directadmin/data/.lego" "--http" "--http.webroot=/var/www/html" "--domains=server.domain.com" "run" "--no-bundle" "--preferred-chain=ISRG Root X1"]
2024/08/17 19:54:14 [INFO] [server.domain.com] acme: Obtaining SAN certificate
2024/08/17 19:54:14 [INFO] [server.domain.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/123456789
2024/08/17 19:54:14 [INFO] [server.domain.com] acme: Could not find solver for: tls-alpn-01
2024/08/17 19:54:14 [INFO] [server.domain.com] acme: use http-01 solver
2024/08/17 19:54:14 [INFO] [server.domain.com] acme: Trying to solve HTTP-01
2024/08/17 19:54:22 [INFO] [server.domain.com] The server validated our request
2024/08/17 19:54:22 [INFO] [server.domain.com] acme: Validations succeeded; requesting certificates
2024/08/17 19:54:25 [INFO] [server.domain.com] Server responded with a certificate for the preferred certificate chains "ISRG Root X1".
exec ["/usr/local/directadmin/directadmin" "build" "sync_server_cert"]
Wrong php3_release set in the options.conf: 5.4.
exit status 1

- One of the versions of PHP I have installed is really old, and only used to run some legacy code internally. I use newer versions for most things.
Is that really the issue here?

- I notice in DirectAdmin I now have a page that looks like this:

View attachment 8520


- I clicked on 'Renew Certificate Now' and everything seems fine, but Gmail still complains...

Server returned error "SSL error: Leaf certificate is expired"


What can I try? Thank you for your time, much appreciated.

 

[cmyden]

One of the versions of PHP I have installed is really old, and only used to run some legacy code internally. I use newer versions for most things. Is that really the issue here?

Ok, it turns out that really was the issue.

# nano /usr/local/directadmin/custombuild/options.conf

php3_release=5.4

^^ change to:

php3_release=no


# cd /usr/local/directadmin/scripts
# ./letsencrypt.sh request_single server.domain.com 4096

Previously where the PHP version caused it to prematurely exit the process, this time it continued on with...

DirectAdmin certificate has been setup.
Setting up cert for Exim...
Setting up cert for Dovecot...
Setting up cert for apache...
Setting up cert for Pureftpd...

And now...

# openssl s_client -showcerts -connect ip.add.re.ss:995

Before: Verify return code: 10 (certificate has expired)

After: Verify return code: 0 (ok)

Gmail is happy again.