Wrong diagnosis? (or too strict?)

Resolved cpoakl
(@cpoakl)

9 months, 3 weeks ago
Hello,

Thanks for creating this plugin!
I am happy with it, however I have troubles understanding the diagnosis it makes in the setting screen.

Indeed, I tested in parallel my current configuration successfully :
– works to send email to Gmail addresses,
– passes SPF+DKIM+DMARC tests at learndmarc.com
– passes SPF+DKIM+DMARC tests of that other WP plugin (no conflict with Email Auth as I removed it and the issue remained): https://wordpress.org/plugins/mailsure/

Neverthless Email Auth’s diagnosis claims that:
1. DKIM: “No TXT record found” (although the DKIM key was created with the plugin, and that I copied-pasted the DNS record it generated). Could this be due to the fact that my registrar adds spaces and double quotes to the record that the plugin doesn’t recognize ? i.e. I copied:
```
v=DKIM1; h=sha256; t=s; p=MIIBIjANBgkqhkiG9w0BAQEFCCOCAQ8AMIIBCgKCAQEAuC3bqopquA0/fj914ggBDJXe5HX7CHJOd56Dy6dgAiI1zkTccWTY0fxtvEpCLErjDzTW0bPvrox9FstLC3fyoRI4G4aGFpuuMAMnbsFxfOE2FcSF0opeoisTFRyhoqJv+HofJl16Q6HQwn/HsU/1ro370hKP9bHERUboZ6zHHhE6coIwBaPBzDCL+VIF2vMKtOUoFigmPHAFGjtoH01InmC37OU1pTFATSjR0iOjZQiCdKtXosW58V9iOeCf1Ooca3RStJOs1ComOKYYJfmUURUds+uKDhvqUCc0wtyMcCedxq58MwccEZShkhqqgIsrJsPINE3XLCD/OxeyvNrtIwIDALAB
```
and the TXT record saves as:
```
"v=DKIM1; h=sha256; t=s; p=MIIBIjANBgkqhkiG9w0BAQEFCCOCAQ8AMIIBCgKCAQEAuC3bqopquA0/fj914ggBDJXe5HX7CHJOd56Dy6dgAiI1zkTccWTY0fxtvEpCLErjDzTW0bPvrox9FstL" "C3fyoRI4G4aGFpuuMAMnbsFxfOE2FcSF0opeoisTFRyhoqJv+HofJl16Q6HQwn/HsU/1ro370hKP9bHERUboZ6zHHhE6coIwBaPBzDCL+VIF2vMKtOUoFigmPHAFGjtoH01InmC37OU1pTFATSjR0i" "OjZQiCdKtXosW58V9iOeCf1Ooca3RStJOs1ComOKYYJfmUURUds+uKDhvqUCc0wtyMcCedxq58MwccEZShkhqqgIsrJsPINE3XLCD/OxeyvNrtIwIDALAB"
```
2. SPF: “SPF check did not pass.” (although it does pass when tested with learndmarc.com or Mailsure). The reason mentioned is a “neutral” response caused by ?all at the end of my SPF record. Also it suggests adding to my current record: a:domain.tld due to the following reason: “Website host (domain.tld or xxx.xxx.xxx.xxx) is not included in a pass case of the SPF record”.
Here is what my full SPF record looks like:
```
"v=spf1 include:_domain1.tld include:_domain2.tld ?all"
```
3. DMARC: shows the following warning: “⚠️ DMARC will pass regardless of DKIM and SPF alignment. Add a p=quarantine or p=reject term.”, even though my current DMARC record is:
```
v=DMARC1; p=quarantine; rua=mailto:wordpress@domain.tld; aspf=s; adkim=s
```

Viewing 15 replies - 1 through 15 (of 15 total)

Plugin Author Brandon Fowler
(@brandonxlf)

9 months, 3 weeks ago

Hello and thanks for the feedback!

For SPF, the “?all” record would cause a non-pass (neutral) if your URL is being matched by it, but assuming the include records match your domain, that should not happen. Would you be able to share the SPF records for _domain1.tld and _domain2.tld?

For DKIM and DMARC, I was able to confirm the plugin should parse the records correctly, so it seems like either your server’s DNS cache is outdated or the domains generated by the plugin are incorrect. Can you verify that the domains listed under DKIM and DMARC are what you expect them to be? After that, try to flush your server’s DNS cache if possible.

Hope to hear back soon!
Thread Starter cpoakl
(@cpoakl)

9 months, 3 weeks ago
Thank you for your answer!

In my first message, domain.tld refers to the domain name I control, but domain1.tld and domain2.tld are domains that belong to the hosting provider where the website is hosted. The first relates to the webmail infrastructure of that hosting provider (i.e. email hosting plan, which is actually not associated with domain.tld currently, but could be in the future so I thought it wouldn’t hurt to add it from now on) and the second the web hosting infra of that provider. Both domain1 and domain2 actually are with the format subdir1.domain1.tld if that matters.
So when checking for their SPF records using https://mxtoolbox.com/SuperTool.aspx, if that’s what you meant, I get “No SPF record found” for both of them.
By the way, another strange thing here with the comment saying “Website host (domain.tld or xxx.xxx.xxx.xxx) is not included in a pass case of the SPF record” is that the IP mentioned here is the not the same I find when performing an IP lookup on my domain (using various services). If I reverse lookup it, it gives nothing. [EDIT:] I see that the plugin uses $_SERVER['SERVER_ADDR'] (in api-routes.php) to get the IP so maybe this is due to some load balancing/CDN stuff happening at my web hosting provider (which is also my registrar)?

As for DKIM & DMARC, you are right, it looks like a caching issue – just checking the plugin’s diagnosis ~11h after my first message and it now shows that they are correctly configured (without me doing anything special in the meantime). Better that way as I am not sure whether I could have flushed the server’s DNS manually given that the website is on a webhosting plan (with no access to the machine itself).
Not such a big deal, but I wonder why the Mailsure WP plugin was able to diagnose immediately the correct configuration. As a suggestion, maybe just adding a mention in the “comments” warning about potential caching issue could help the others plugin’s users.
- This reply was modified 9 months, 2 weeks ago by cpoakl. Reason: remark after checking plugin's code
Thread Starter cpoakl
(@cpoakl)

9 months, 2 weeks ago

I wonder why the Mailsure WP plugin was able to diagnose immediately the correct configuration

After checking the code, the WP plugin Mailsure is actually sending an email to an external address belonging to the plugin author while retrieving the diagnosis via a REST endpoint. So it is basically working like https://learndmarc.com with a front-end integrated to WP.
Maybe the reason is that those external services flush the DNS cache more often than my hosting provider which Email Auth has to stick with.
Nevertheless I better like Email Auth approach which integrates the backend part to the plugin as well.

Plugin Author Brandon Fowler
(@brandonxlf)

9 months, 2 weeks ago

So when checking for their SPF records using https://mxtoolbox.com/SuperTool.aspx, if that’s what you meant, I get “No SPF record found” for both of them.

For the SPF check for the included domains, I believe the tool you are using is trying to look at “spf.DOMAIN”, which will not work in this case. Can you try doing an plain TXT record lookup for the “include:” domains to see if either your domain name or a recognized IP address is included in the returned SPF record (the ones that start with v=spf1)?

I see that the plugin uses $_SERVER['SERVER_ADDR'] (in api-routes.php) to get the IP so maybe this is due to some load balancing/CDN stuff happening at my web hosting provider (which is also my registrar)?

I figured $_SERVER['SERVER_ADDR'] might not be the most reliable since emails might be sent from a different server than the WordPress server. I will look into alternatives to this.

Maybe the reason is that those external services flush the DNS cache more often than my hosting provider which Email Auth has to stick with.

I do believe this is the case. I will try adding an option to directly query Google’s/Cloudflare’s DNS servers from WordPress to the plugin.
Thread Starter cpoakl
(@cpoakl)

9 months, 2 weeks ago
Can you try doing an plain TXT record lookup for the “include:” domains to see if either your domain name or a recognized IP address is included in the returned SPF record (the ones that start with v=spf1)?

Using “TXT Lookup” at https://mxtoolbox.com/SuperTool.aspx results in “DNS Record not found” for both subdir1.domain1.tld (email server of the hosting provider) and subdir2.domain2.tld (webhosting server of the hosting provider). I would not expect my domain name to be included here (if not they would have to do that for each domain name registered at their company – that sounds strange). As for the IP address, I don’t know but FYI this is a shared hosting plan.

Doing the same on domain2.tld (i.e. without the subdir2 part) returns:
```
"v=spf1 include:_subdir1.domain2.tld -all"
```
(If that helps I can send you a private message with the SPF content including domain names).

I figured $_SERVER['SERVER_ADDR'] might not be the most reliable since emails might be sent from a different server than the WordPress server. I will look into alternatives to this.

Thanks. In my case, I believe the email is sent by the webhosting server on which runs my WordPress instance and included phpmailer. Maybe $_SERVER['SERVER_ADDR'] refers to a specific machine of the webhosting cluster (the one for shared hosting plans) of the infra of my provider and that the Domain IP Lookup sends to some routing machine at the top of their infra. However, I don’t know for sure – I could ask them to confirm if you think it can help.

I will try adding an option to directly query Google’s/Cloudflare’s DNS servers from WordPress to the plugin.

That would be even better although more work. A simple warning about the caching issue with a link to an external service could make it easier when DKIM/DMARC display a failed status could work for me as the lazier way to go. Anyway, thank you for your interest in that feedback.
Plugin Author Brandon Fowler
(@brandonxlf)

9 months, 2 weeks ago

(If that helps I can send you a private message with the SPF content including domain names).

Yes that would be great, I am still quite confused about what’s going on. I think the easiest way would be through https://www.brandonfowler.me/contact/ unless there’s something on this support form.

Maybe $_SERVER['SERVER_ADDR'] refers to a specific machine of the webhosting cluster (the one for shared hosting plans) of the infra of my provider and that the Domain IP Lookup sends to some routing machine at the top of their infra.

$_SERVER['SERVER_ADDR'] will always refer to the IP of the server running WordPress, which isn’t inherently the same one that is exposed through DNS. I thought of two possible solutions which I am deciding between:

A – Get the IP using the domain from the bounce address. I think this would be the correct IP most of the time.
B – Adding an input to provide a custom IP. This would always work, but it’s not realistic to expect everyone to know the IP of their outbound email server.

Let me know if you have any thoughts.

That would be even better although more work. A simple warning about the caching issue with a link to an external service could make it easier when DKIM/DMARC display a failed status could work for me as the lazier way to go. Anyway, thank you for your interest in that feedback.

Of course, this seems to be a rather significant usability issue with the plugin that I’d love to get fixed. In fact, this was an issue I encountered myself, but I’ve been instinctively clearing my server’s DNS cache without giving it much thought, so thanks for bringing it up! Luckily, I found a PHP package that should make it rather simple to implement direct DNS querying.

Thread Starter cpoakl
(@cpoakl)

9 months, 2 weeks ago

through https://www.brandonfowler.me/contact/

Done!

Let me know if you have any thoughts.

I don’t really know what’s the bounce address – I am not legitimate to comment for A.
As for B, yes that’s not so easy, it guess couldn’t go without a dedicated tutorial. What you call “outbound email server” is the one exposed through DNS or the server running WordPress (when different)?

Luckily, I found a PHP package that should make it rather simple to implement direct DNS querying.

Great news!

Plugin Author Brandon Fowler
(@brandonxlf)

9 months, 2 weeks ago

Taking a look at the SPF records, the issues does seem to indeed be that the WordPress server’s IP address is not present anywhere in the SPF record, so I will need to find an alternative to using $_SERVER['SERVER_ADDR'] to resolve this.

For the DNS issue, I will have the fix out in the next update.

Thread Starter cpoakl
(@cpoakl)

9 months, 2 weeks ago

Thanks for checking!
Plugin Author Brandon Fowler
(@brandonxlf)

9 months, 2 weeks ago
Hello @cpoakl,

I’ve released version 1.4.0 of the plugin, which resolves both the DNS and SPF issues:
- DNS records are now fetched from public DNS servers directly, which should dramatically improve how quickly updates are shown.
- I added a “Configure Server IP” button next to the SPF test result that lets you set which IP emails are sent from. In your case, I would recommend following the guide video, but “Use the bounce address’s mail exchange IP” should also work.
Let me know what you think of the changes!
Thread Starter cpoakl
(@cpoakl)

9 months, 2 weeks ago
Hello @brandonxlf,
Thank you for the quick move!
- Good news for the DNS point. I can’t really test for now as I don’t want to change the current configuration which has entered into “production”.
- As for the SPF, I can now say that:
  - IP associated to the domain is XXX.XXX.XXX.XXX (checked with a third party service).
  - IP from a test email sent from Email Auth has only the last section different from above IP. (i.e. XXX.XXX.XXX.YYY). I intended to follow the video guide here, but outside of WordPress no email are sent from this domain (no mailbox or so associated to the domain).
    When adding that IP to the custom input box of the “Configure Server IP” popup, then SPF status becomes “Configured with warnings.”, which is an improvement! The only warning being “An ~all or -all term is recommended to (soft) fail all other servers.”. Note that the SPF record still is the one mentioned in my first post here above.
  - IP indicated by Email Auth in the SPF section is totally different from the two IP above (i.e. ZZZ.ZZZ.ZZZ.ZZZ). That was the one used in previous version of Email Auth.
I don’t really get what means the warning that remains with the SPF config and whether it is important, but overall this issue seems indeed resolved! Thanks again.
Plugin Author Brandon Fowler
(@brandonxlf)

9 months, 2 weeks ago

No problem! I’m glad to hear that setting the server IP worked for you.

As for the warning, it does seem to be a valid warning that you might want to look into. Currently, your SPF records end with a “?all” term, which means any emails that fail the SPF check are treated as if the check never happened. If you instead use a “~all”, they will be instead treated as if the check failed, so they will need to pass DMARC to be accepted by common email providers like Gmail.
Thread Starter cpoakl
(@cpoakl)

9 months, 2 weeks ago
If you instead use a “~all”, they will be instead treated as if the check failed, so they will need to pass DMARC to be accepted by common email providers like Gmail.

But ain’t that already what is supposed to happen with p=quarantine in the DMARC record, independently from the SPF setting ?
Edit: this article says DMARC has precedence over SPF settings (although I don’t know how trustworthy it is): https://knowledge.progist.net/index.php/2024/02/06/understanding-dmarc-policies-and-its-independence-from-spf-qualifiers/
- This reply was modified 9 months, 2 weeks ago by cpoakl. Reason: add source
Plugin Author Brandon Fowler
(@brandonxlf)

9 months, 1 week ago

I believe you’re right for the most part, but depending on your DMARC setting, I would image a ~all term in SPF might be more strict than the DMARC check. Regardless, it’s just a warning which means your SPF setting will still work fine for your emails, but they’re just not as strict as it should be, which may or may not be ok.

Thread Starter cpoakl
(@cpoakl)

9 months, 1 week ago

Well, I followed your advice!
Thanks again for follow-up.

Viewing 15 replies - 1 through 15 (of 15 total)

The topic ‘Wrong diagnosis? (or too strict?)’ is closed to new replies.