Jose Mortellaro

Hi @loralora

You can check if the domain of the email exists with this custom code:

add_action( 'essential_form_before_sending', function( $name, $email, $message, $post_id ) {
    /*
    * Check if the email is valid and the domain exists
    */
    if ( ! is_email( $email ) ) {
        wp_die( 'Invalid email address.' );
    }

    $domain = substr( strrchr( $email, "@" ), 1 );

    if ( function_exists( 'checkdnsrr' ) ) {
        $valid = checkdnsrr( $domain, 'MX' );
    } elseif ( function_exists( 'dns_get_record' ) ) {
        $records = dns_get_record( $domain, DNS_MX );
        $valid = ! empty( $records );
    } else {
        $valid = true; // fallback: skip check
    }

    if ( ! $valid ) {
        wp_die( 'Email domain does not exist.' );
    }

}, 10, 4 );

If you add this code to the functions.php file of your child theme or to a functional plugin, it will run before the email is sent.

At least one of the functions checkdnsrr() or dns_get_record() must be available; otherwise, this code will not be able to check whether the email domain exists. On most servers, this should not be an issue, but if these functions are not available, you may need to enable DNS support in PHP on your server.

Please keep in mind that even if you check the existence of the domain:

• The email address itself might still not exist
• The inbox might not accept emails
• Only sending an email (or using a verification service) can truly confirm it

However, accepting only email addresses with a valid domain is already a good way to filter out many invalid emails.

This custom code is not implemented in the core of Essential Form because it slows down the sending process, as it requires a DNS lookup for each submitted email, which introduces an external network request and potential latency. However, if we receive more reports about the form sending a large number of spam emails, even if they are manually submitted, I will consider adding this check to the plugin core.

I hope it’s clear.

Have a great day!
Jose

You are welcome @codings !

Your settings will not be lost because there is nothing you need to configure. The plugin automatically adds the missing titles without you having to do anything.

There are no settings that will be lost because the settings don’t exist. It’s like worrying about losing your third arm. Sorry for the stupid example. It’s just to say that the sentence means that you can’t lose something that was never created in the first place.

When you deactivate the plugin, you don’t lose any work, because no permanent changes were ever made. You can’t lose something that doesn’t exist.

Of course, you lose the titles after deactivation. This is clear.

If you want the missing titles to appear again, simply reactivate the plugin.

In short:

• You activate the plugin → it automatically adds the missing titles to the content.
• You deactivate the plugin → it stops adding the missing titles, and everything returns to the way it was before activation.

In my opinion, after deactivating a plugin, you should have the same situation that was before activating that plugin. If you could still have the same functionality after plugin deactivation, it would be a nightmare when you decide to deactivate some plugins.

I hope it’s clearer now.

Best regards

Jose

Hi @carlodamo

add that line manually and that’s it.

The plugin is only for those users who have no FTP access for adding that line of code.

Best regards

Jose

Thank you very much @myjosephines !

Hi @eleventyseventy

Many thanks! I’m glad you like the plugin.

This issue is a bit unusual. Could you check if there are any mu-plugins?

You can find them on the Plugins page → Must-Use.

I’m not saying this is necessarily the case, but nowadays, on some hosting environments, a “fresh” installation can sometimes include unexpected bloat without you realizing it.

Have you experienced this issue only on SiteGround, or also on other hosting providers?

Do you know the PHP version that is running on the server?

Best regards

Jose

Again me. Do you maybe have this plugin: https://wordpress.org/plugins/wp-safe-mode/ ?

If you confirm this, I will test it and try to reproduce the same issue.
I also suspect it may cause conflicts with FDP because it manipulates the set of active plugins.

@gooloode

Hi @gooloode

Using FDP for the first time can be tricky. Have you tried reading the documentation?
https://freesoul-deactivate-plugins.com/how-deactivate-plugins-on-specific-pages/

Anyway, if FDP for any reasons wasn’t able to delete the mu-plugin, you should:

• See a clear notification in your backend.
• Be able to access the file wp-content/mu-plugins/eos-deactivate-plugins.php via FTP.

If you don’t see them, it means there is no FDP mu-plugin left on your site.

The 100% safe way to delete it is to remove the file wp-content/mu-plugins/eos-deactivate-plugins.php via FTP. If you don’t see the file, there’s nothing to delete.

If via FTP you don’t see that file, but still see it in the mu-plugins page of your backend, it means the pages of your backend may be served by full-page cache. Be careful. Having cached backend pages would not be safe.

I hope it helps.

Best regards

Jose