Brandon Fowler
Forum Replies Created
-
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.
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.
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!
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.
(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.
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.
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!
Hello @celebizs,
There currently isn’t any way to do what you’re asking, but it seems like it could be a useful feature. How are you storing the type of client that each user is?
Hi @sangredeespana, unfortunately that seems a bit out of scope for this plugin since it heavily relies on WooCommerce. Would something like Contact Form 7 with a file upload work?
On line 112 of
class-display.php, replacing$field_groups['order'] = array_merge( $processed, $field_groups['order'] );with$field_groups['order'] = array_merge( $field_groups['order'], $processed );should work.Hello Matthieu and thank you for the patch!
A setting to modify the title will be included in the next version, and I’ll look into adding filters to improve configurablility.