Gravity Forms SMTP - WordPress Plugin

Guide to Setting Up Gravity Forms SMTP for Reliable WordPress Email Delivery

Gravity Forms SMTP is the name many users use when searching for the separate Gravity SMTP product from the Gravity Forms team. This guide focuses on practical use rather than marketing copy: how to prepare your site, choose a mail connection, enable logging, send a test email, verify the result, and understand why a message may not have gone out.

The main purpose of a plugin like this is to replace WordPress's unpredictable default server-based email delivery with controlled sending through a chosen mail service. But installation alone does not solve the problem automatically. You need to choose the right integration, verify the sender address, make sure no second SMTP plugin is still active, configure log retention, and know where to check delivery status.

This guide is intended for a WordPress administrator, site owner, support specialist, or developer responsible for registration emails, password resets, form notifications, WooCommerce emails, and other system messages. If you use Gravity Forms, the plugin is an especially natural fit, but according to the official documentation it works not only with Gravity Forms emails, but with all site emails sent through the standard wp_mail() function.

What Problem the Plugin Solves and Where It Is Actually Useful

WordPress can send email through the wp_mail() function. By itself, that function does not guarantee delivery to the recipient's inbox: a successful response only means the sending method handled the request, not that the email actually reached the recipient. In practice, a message may be accepted by the server and still get lost because of a mismatched sender domain, poor hosting reputation, a blocked port, missing sender authentication, or restrictions imposed by the external mail service.

Gravity SMTP moves sending into a more controlled setup. The site connects to a mail provider or its own SMTP server, and the plugin intercepts outgoing WordPress email, sends it through the chosen channel, and records the technical result in the WordPress admin area. This matters most when email is part of a business process: a form submission, password recovery, registration confirmation, order notification, admin alert, or message to a member of a private area.

The most common mistake when setting up an SMTP plugin is treating the test email as the only validation step. A test is useful, but it does not replace a real workflow check. A form email, a WordPress system email, and a store email may differ in sender, headers, attachments, trigger source, and send timing. That is why this guide checks more than just the Send Test button. We will also verify the log, the email source, the status, the email body, possible resend behavior, and the debug log.

The plugin is especially useful in several common scenarios:

• The site is not delivering emails from forms, password resets, or admin notifications.
• Emails are being sent, but they land in spam or appear to come from an unclear sender address.
• You need to see a log of sent emails without leaving WordPress.
• You need a backup connection so messages can still go out through another service if the primary channel fails.
• You need to temporarily disable some standard WordPress notifications so administrators are not flooded with unnecessary email.
• You need to diagnose problems with integrations, headers, attachments, or conflicts with another plugin.

At the same time, Gravity SMTP is not a mail service in the sense of having its own delivery infrastructure. It routes email to the provider you choose. If the domain is not verified with the provider, the API key is wrong, the SMTP port is blocked, or the mail service itself rejects the message, the plugin cannot magically force delivery. Its value is different: it makes the sending path clear, configurable, and verifiable.

Who Gravity Forms SMTP Is a Good Fit For and When Another Approach Makes More Sense

The plugin is a strong fit for sites that already have an active qualifying Gravity Forms license and want everything in one ecosystem. The official product page states that Gravity SMTP is available to owners of certain Gravity Forms licenses, while the documentation clarifies that the plugin itself does not require Gravity Forms to be installed on the site. That is an important distinction: access to download and activation is tied to the license, but functionally the plugin works as a standalone SMTP tool for WordPress.

Gravity SMTP is especially useful if you want to manage email delivery directly inside the WordPress admin area without juggling multiple disconnected tools. One interface gives you integrations, an email log, test sending, a debug log, a system report, logging settings, standard WordPress email controls, a backup connection, and dashboard reporting. On a small site that may feel like more than you need, but for a site with leads, registrations, and regular system emails, that visibility pays off quickly.

There are also cases where it may not be the best first choice. If you do not have a suitable Gravity Forms license and do not plan to get one, it makes sense to look at SMTP plugins from the WordPress.org directory. If you need complex routing that sends different email types through different providers, some alternatives may be more flexible. And if your site sends email through a plugin that does not use wp_mail(), Gravity SMTP will not see or process those messages, which the product FAQ states directly.

It is also important to distinguish between "email sent" and "email delivered to the inbox." Gravity SMTP can show processing status, service, source, and technical details. But final deliverability depends on the domain, DNS records, sender reputation, provider limits, email content, and the receiving mail server's rules. So the plugin should be viewed as an email delivery control and troubleshooting tool, not as a guarantee that every message will reach every inbox.

What to Check Before Installation and First-Time Setup

Preparation matters just as much as the setup wizard itself. If you install a new SMTP plugin on top of an old solution, leave the previous router active, use the wrong sender address, or fail to prepare access to the mail service, your site may start sending email inconsistently. It is better to go through a short pre-check first and only then change live email delivery.

The WordPress Technical Environment

Gravity SMTP's official requirements are based on a current production version of WordPress, a supported PHP version, and an adequate memory limit. There is little value in hard-coding exact version numbers in an article like this because they go out of date quickly. In practice, what matters is that the site is updated, the hosting environment supports modern PHP, and the administrator has access to plugin screens, settings, and the system report.

Before installation, check the following:

• That you have WordPress admin access and permission to install plugins.
• That you have access to the Gravity Forms account used to download Gravity SMTP.
• That you have access to the mail service where the API key, OAuth connection, or SMTP credentials will be created.
• That the sender domain is ready: the from address should belong to a domain you control.
• That you have a backup or staging copy of the site if the plugin will affect critical email on a live project.

The Mail Service and Sender Domain

Gravity SMTP supports a set of ready-made integrations plus a Custom SMTP option. A built-in integration is usually easier because it uses an API or the provider's official connection method. Custom SMTP is the right choice when you are connecting through your hosting server, a company SMTP server, or a service that does not have its own dedicated integration card.

Do not start by using a random gmail.com or yahoo.com address in the sender field if the site runs on a company domain. For transactional email, it is better to use an address on your own domain, such as This email address is being protected from spambots. You need JavaScript enabled to view it. or This email address is being protected from spambots. You need JavaScript enabled to view it., and verify the domain and required DNS records with the provider. This is not a WordPress plugin setting by itself, but without it even a technically correct integration may still perform poorly.

Old SMTP Plugins and Routing Conflicts

If the site already has WP Mail SMTP, FluentSMTP, Post SMTP, Easy WP SMTP, or another similar tool installed, do not run two active mail routers at the same time. The Gravity SMTP wizard can offer migration from supported solutions and pull in some settings, but the documentation also makes a separate point of this: after migration, the old plugin still needs to be disabled once you have confirmed the new setup works.

Practical rule: set up Gravity SMTP on a staging copy or during a low-traffic period first, then send a test email, verify a real form or registration email, review the log, and only after that disable the old SMTP plugin on the live site.

Installation and the Setup Wizard Without Unnecessary Risk

After installation and activation, Gravity SMTP launches a setup wizard. Its purpose is to walk the administrator through the core steps: license activation, optional migration, choosing a mail solution, entering the required settings, and completing the initial configuration. You can close or skip the wizard, but in that case you will need to configure everything manually.

A Typical Setup Sequence

1. Download the Gravity SMTP ZIP archive from your Gravity Forms account if your license includes access to it.
2. In WordPress, open Plugins, then Add New, and upload the ZIP file through Upload Plugin.
3. Activate the plugin and start the setup wizard if it opens automatically.
4. Add the license key so the plugin can receive updates.
5. If the wizard finds an old SMTP plugin and offers import, use migration only for a supported provider and then manually verify any missing fields.
6. Select the primary integration or Custom SMTP.
7. Save the settings, wait for the integration to show as configured, and send a test email.

Migration is not a complete turnkey transfer. The documentation explains that passwords for custom SMTP are not migrated and must be entered again. Not every extra field can be carried over automatically either: it is worth manually checking the sender address, sender name, password, domain-related settings, and some provider-specific options.

When It Makes Sense to Skip the Wizard

Skipping the wizard makes sense if you already know exactly which provider will be used and want to configure everything manually in SMTP -> Settings -> Integrations. Another case is a WordPress multisite environment that is already prepared through constants and where individual sites do not need to go through OAuth setup. But for a typical site, the wizard is faster and reduces the chance of missing a basic field.

After the wizard is complete, do not assume the setup is finished. Verify that only one primary integration is active, that the previous SMTP plugin has been disabled, that the test email went out through the correct service, and that a real site email appears in the log with the expected source.

Choosing an Integration: API Service, Custom SMTP, or a Backup Connection

In the integrations section, Gravity SMTP shows cards for available mail services. The list continues to grow, but the official product page and documentation mention popular options such as SendGrid, Mailgun, Postmark, Brevo, Google / Gmail, Microsoft 365 / Outlook, Amazon SES, Mailtrap, Cloudflare Email Service, SMTP.com, MailerSend, Mailjet, SMTP2GO, SparkPost, Zoho Mail, Resend, and others. There is also Custom SMTP for your own server or for a provider without a dedicated card.

The choice should be based not on whichever name looks familiar, but on how the site actually operates. A small company website with a few forms may use a service the business already has. An online store needs dependable transactional email and clear sending limits. A site with a high volume of registrations needs logs, filters, bounce visibility, and straightforward troubleshooting. For form testing and development environments, Mailtrap or another sandbox-style service can be useful because messages do not go to real users.

Custom SMTP Settings That Most Often Break Delivery

In Custom SMTP, the key fields look familiar: SMTP Host, SMTP Port, Authentication, Encryption, Authentication Username, Authentication Password, Default From Email, Default From Name, Force From Email, and Force From Name. But a familiar interface does not mean you can safely guess the values.

If the provider requires TLS, do not switch to SSL just because "that is how the old plugin was set up." If the port does not match the chosen encryption mode, sending can hang until a long timeout expires. If you enable Force From Email, the plugin will replace the sender address on all outgoing messages. That may be exactly right for consistent branded sending, but it can be inconvenient for plugins that intentionally set their own From value. Enable forced replacement only when you are sure you want every email to use the same domain-based sender.

A Backup Connection as Protection Against Temporary Failure

A backup connection in Gravity SMTP acts as a fallback channel if the primary integration cannot send the email. In the interface, go to SMTP -> Settings -> Integrations, find the configured card, and choose Set As Backup from the card menu. Once you do that, the integration is marked as the backup route.

A backup should not be just a random second card with the same weaknesses. If both the primary and backup depend on the same domain, the same provider, and the same incorrect sender address, the fallback route may not help at all. It is better to choose a backup that truly differs: another provider, a separate API key, a verified sender, and clear limits. For a small site that may be more than necessary, but for a store, membership site, or lead-generation service, backup delivery lowers the risk of lost notifications.

Post-Installation Settings Worth Reviewing Manually

After the setup wizard, open SMTP -> Settings. This section contains the options that affect the plugin as a whole: license, general mode, integrations, WordPress email controls, logging, debugging, experimental features, and data removal during uninstall. You do not need to change everything at once, but you should review each tab.

The Settings Tab: License, Test Mode, and Analytics

On the basic tab, check the license status. This is not really about buying the product, but about updates and access. Then look closely at Test Mode. It is meant for testing the site without actually handing emails off to the provider. On a live site, it is easy to forget that it is still enabled and then spend a long time wondering why users are not receiving email. So after any configuration change, ask yourself a simple question: "Should this site be sending real email right now, or only simulating delivery?"

If usage analytics is enabled, evaluate it against your project's policy. The official documentation describes it as sending information that helps the product team improve integrations. For most sites this is not a critical setting, but on projects with strict data policies, any external transfer of metadata should be reviewed in advance.

The Integrations Tab: Status, Primary, and Backup

Here it is important to look beyond whether the card is merely filled out. The integration should have a clear status, it should be enabled, and when needed it should be set as primary. The card interface provides actions such as opening API settings, sending a test, setting the integration as primary, or setting it as backup. If the card is not fully configured, some of those actions will be unavailable.

For a typical site, one primary integration is enough. Add a backup only after the primary route has already been verified. Otherwise, troubleshooting becomes harder: when something fails, it is no longer obvious where the message tried to go or why the result differs from what you expected.

The Emails Tab: Managing Standard WordPress Emails

Gravity SMTP can enable or disable standard WordPress notifications: emails about admin address changes, automatic updates, comments, new users, personal data requests, and other system events. This is not the same thing as "improving deliverability." It is about controlling which types of WordPress emails should exist at all.

Use this tab carefully. For example, it may make sense to disable noisy automatic update notifications on a staging site, but it is rarely a good idea to casually disable password reset emails or notices that administrators actually rely on. In multisite, some settings are available only with the appropriate permissions and network structure.

The Logging Tab: Email Log, Body, Attachments, and Retention

Email logging is enabled by default, while the documentation says the debug log is disabled by default. The Logging tab lets you control what data is stored and for how long. The goal here is to balance troubleshooting convenience against database load.

Do not store more data than support and maintenance actually require. The email log makes it easy to see what was sent, to whom, through which service, and with what status. But saving the email body and attachments increases storage volume and may involve personal data. If you only need proof that a message was sent, keep the stored data minimal. If you need to resend emails or review their content, enable body storage deliberately and choose a short retention period.

The documentation notes that attachments are stored in a folder such as uploads/gravitysmtp/attachments/[EMAIL LOG ID]/. That is useful for resending, but it also adds responsibility: keep an eye on retention, file access, and backup size. For a small site, a short log retention period is usually enough. For an active store or portal, it is better to agree on a retention policy with the data owner up front.

When to Enable the Debug Log

The debug log is for troubleshooting, not for continuous use. It records integration and send-process errors and also helps you prepare a system report for support. Enable it right before reproducing the issue: turn on Debug Logging, send a test or repeat the site action, open SMTP -> Tools -> Debug Log, review the entry, and then turn debugging back off if it is no longer needed.

If the issue only happens with one specific email, enable the debug log first and then trigger exactly that scenario. This gives you useful technical entries instead of a general log that does not contain the event you need.

How to Use the Email Log and Reports Without Unnecessary Stress

The email log is one of the most useful sections in Gravity SMTP. It lists emails in reverse chronological order and lets you review status, recipient, source, service, date, and available actions. For an administrator, that turns the question "Did the email even go out?" from guesswork into something you can verify.

In Email Log, pay attention to four things: status, source, service, and actions. Status shows whether the email was sent, is pending, or ended in an error. Source helps you identify which plugin or part of the site triggered the message. Service shows which integration handled it. Actions let you open the details, view the email, resend it, or delete the log entry.

Search and Filters

When there are only a few messages, looking at the latest entries is enough. On an active site, dozens or hundreds of records appear quickly, so search and filters become much more important. The documentation describes searching by sender, recipient, subject, and email content, along with filters by status, service, source, and date. That helps answer specific questions: "Was an email sent to this customer?", "Which form created this notification?", "Are all the errors tied to the same service?", "Did the problem begin after a settings change, or was it happening before that?"

Do not delete the log immediately after the first successful test. First, set a retention period that gives your support team enough history for troubleshooting. Then review it again a few days later to make sure the database is not growing too quickly. Separate documentation warns that large logs can slow down the interface, increase database size, and affect backups.

Viewing Emails, Resending, and Limitations

From the log, you can open an email and review its contents in a modal window, including switching between desktop and mobile views. That is especially useful for checking HTML emails: broken layout, missing text, a wrong link, or an incorrect address often becomes obvious right away.

Resending requires the right storage settings to have been enabled at the time of the original send. To resend an email, the log entry and the email body must have been saved, and if there were attachments, attachment saving must also have been enabled. If those conditions were not met when the email was first sent, the resend button will be unavailable. That is not an interface bug. It is protection against resending data the plugin no longer has.

Resending should not turn into a trial-and-error experiment. If the message failed because of a broken integration, resending it without fixing the root cause will produce the same result. First open the log details, review the technical information, correct the integration, send a test, and only then resend the important email.

Practical Example: Verify a Form Notification and a Password Reset Email

A test email from the Tools section confirms that the selected integration can send a message. But real websites do not run on test emails. After setup, you should verify two real scenarios: a form notification and a standard WordPress email. This kind of test shows that Gravity SMTP handles different sources correctly and that the log helps you distinguish between them.

Goal of the Example

You want to confirm that the site sends email through the selected integration, that the log shows the source, and that the administrator can find the message and understand its status. A contact form, a Gravity Forms submission, a test user registration, or a password reset email will all work for this example. If the site does not have a form, use a password reset for a test user, but do not run that check against a real customer account unless there is a clear need.

Preparation

• The primary Gravity SMTP integration is configured and enabled.
• The old SMTP plugin is disabled or no longer intercepts delivery.
• Test Mode is turned off if you expect real delivery.
• Email Logging is enabled so the message appears in the log.
• Save Email Body is enabled if you need to review the email content and the site's policy allows it.
• You have access to a recipient mailbox you can check.

Verification Steps

1. Open SMTP -> Tools and send a test email to your own address through the selected integration.
2. Go to SMTP -> Email Log and find the latest entry. Check the status, service, and recipient.
3. Open the form on the site or the password reset page and trigger a real send event.
4. Return to the log and find the new email by subject, recipient, or source.
5. Open the record details with the view icon. Check which service was used and whether there are any technical errors.
6. Check the recipient's inbox, spam folder, and any service-side markers provided by the mail provider.
7. If the message did not arrive, do not resend it immediately. First compare the log status with the provider's response.

Expected Result

In a healthy scenario, both the test email and the form email appear in the log under the expected service, show a successful send status, and are visible to the recipient either in the inbox or at least in the spam folder. If the status is successful but the message cannot be found, the investigation shifts to the mail service and DNS-related deliverability. If the status is failed, review the record details and the debug log inside WordPress.

A Detail That Often Causes Confusion

If the form email does not appear in the log but the test email does, that is not necessarily a Gravity SMTP problem. The form may not be sending the notification, the notification may be disabled, the recipient may be controlled by conditional logic, another plugin may be sending outside wp_mail(), or the form event may never have completed. In that case, check the form settings first and the Gravity SMTP log second.

Control Modes: Test Mode, Debug Log, System Report, and Activity Digest

Gravity SMTP is useful as more than a set-it-and-forget-it plugin. It includes control tools that help you separate setup, troubleshooting, and monitoring. If you use them without a clear process, it is easy to get confused. If you use them for the right purpose, they cut down troubleshooting time.

Test Mode for Safe Verification

Test Mode is intended for situations where you want to test site workflows without sending real email to users. For example, on a staging copy of a store you can go through registration, a test inquiry submission, and an admin notification without worrying about accidentally emailing a customer. But on a live site, this mode should be off if you expect actual delivery.

A good habit is to record a short note after each configuration change: whether test mode is on or off, which integration is primary, where the test email was sent, and what status appeared in the log. That small step saves time when you have to come back a few days later and remember why messages were not arriving.

Debug Log for Repeatable Errors

The debug log records integration and sending-process errors. It is not meant to replace the regular log for everyday review. Enable it before reproducing the issue, keep the logging window short, send a test, and then open SMTP -> Tools -> Debug Log. If you need to contact support, the system report may include a link to the debug file protected by a randomly generated key.

System Report for Working With Support

The system report shows site configuration details that may affect email delivery. It is useful when the problem is not obvious: a plugin conflict, an unusual hosting environment, an unavailable database table, outdated PHP, or a nonstandard WordPress structure. Before sending the report, review it for sensitive data and share it only through the official support channel.

Activity Digest and Reports

The reporting dashboard shows summary metrics: total email count, successful sends, failures, opens, send sources, frequent recipients, and active integrations. Some plugin versions have added digest summaries and improved reporting. For an administrator, this is not a reason to stare at charts every day, but it is a good way to notice an anomaly: errors suddenly increase, an active provider disappears, or one source starts generating too many emails.

Managing Standard WordPress Emails Without Losing Important Notifications

The Emails tab gives you control over standard WordPress email. This is a separate capability that is easy to underestimate. It not only helps you deliver email, but also lets you decide which emails should exist in the first place. For example, comment notifications may matter for a blog but be unnecessary on a site with comments disabled. New user emails are critical on a membership site but can become noise on a staging copy.

The right approach is not to disable everything across the board, but to review categories by role. Administrative emails cover changes to system addresses and network events. Update emails report background updates to core, themes, and plugins. Comment emails relate to moderation. New user and password reset emails directly affect access. Personal data emails may matter for privacy compliance.

If you disable a notification type, record that decision in the project documentation. A month later, another administrator may start investigating why WordPress "is not sending" a certain email when that type was intentionally disabled. In that case Gravity SMTP is not at fault: the message is not being sent because that email type was turned off in the email management settings.

Mini Scenario for a Site With Forms and Registration

For a site with a contact form, user accounts, and several administrators, it is usually safer to leave password reset emails, new user notifications, and important administrator messages enabled. You might consider disabling some automatic update notifications if they are already being tracked by a separate monitoring system. Comment emails should be disabled only if comments are not used or are managed elsewhere.

After changing anything in the Emails tab, verify the result with a real event rather than a generic test email. If you disabled comment notifications, submit a test comment on a staging copy. If you kept password resets enabled, request a reset for a test user. That way you are checking not only the SMTP route, but whether WordPress is generating the message at all.

Security, Data, and Log Performance

Email logs can contain sensitive information: user addresses, email subjects, and sometimes message bodies and attachments. That means logging is not just a convenience setting, but also a data policy decision. The more you store, the easier it is to investigate incidents and resend messages. But that also means more data ends up in the database, backups, and file system.

The official documentation on retention warns that large logs can reduce WordPress performance, increase backup time, and slow down the SMTP interface. This becomes especially noticeable on sites where email is generated automatically: stores, portals, membership areas, and high-traffic forms. That is why the retention period should match the actual support need.

A Practical Retention Policy

For a small site with only a few messages per day, a short retention period is usually enough, and saving the email body should be enabled only during troubleshooting. For a store where order confirmations matter, you may want to keep logs longer, but you should explicitly discuss whether message bodies and attachments need to be stored. For a site handling personal data, it is usually better to minimize content storage and use the log as a technical trail: status, source, service, recipient, and time.

If you enable Save Attachments, make sure backups are not ballooning because of the attachments folder. If you enable Save Email Body, remember that resending becomes more convenient, but the volume and sensitivity of the stored data also increase. If you enable the debug log, turn it back off once the issue is resolved so you are not keeping an unnecessary technical trace.

A Safe Improvement Without Code

With Gravity SMTP, it is better not to invent PHP hooks or custom senders without confirmed documentation. A safer improvement is to tighten the verification process:

• Create a dedicated test recipient address for checking forms and system emails.
• Agree on the domain-based sender address and do not change it without verifying it with the mail provider.
• Enable the debug log only while reproducing a problem.
• Assign a backup connection only after the primary route has been successfully verified.
• Clean up old logs through the built-in settings rather than manually deleting database tables.

Code snippets are intentionally not included in this guide. Public sources confirm settings, constants for certain multisite scenarios, and a newer developer action mentioned in the changelog, but without the exact hook name and parameter contract, any "working" snippet would still be a guess. For publish-ready instructions, it is safer to stick to product settings and the developer's official documentation.

Migrating From an Older SMTP Plugin Without Double Sending

Migration from another SMTP plugin looks simple until the site starts routing email through two layers at once or the administrator loses access to the old settings. Gravity SMTP offers to import supported settings during the first-run wizard, but that is only one part of the move. A solid migration includes inventory, import, manual review, test sending, disabling the old plugin, and a short period of log monitoring.

Start by documenting what the old plugin is actually using. You do not need to record secrets, but you do need the structure: provider, connection type, sender address, sender name, whether forced From replacement is enabled, whether a backup route exists, whether logs are used, whether email bodies are stored, and whether there are separate settings for a store, forms, or multisite. If you simply click "import" and close the old plugin, you can easily miss the Custom SMTP password, an unverified address, a separate sender name field, or another setting that the wizard does not transfer.

What to Import and What to Verify Manually

The official documentation describes migration as part of the setup wizard. It may offer to import settings from supported solutions and attempt to bring over API keys for supported services. For Custom SMTP, available parameters such as host, port, and encryption mode can be transferred, but passwords are not migrated and must be entered again. That is a sensible limitation: secrets should not be transferred blindly, especially if the old plugin stored them differently than you expect.

After import, open the integration card in Gravity SMTP and treat it like a brand-new configuration. Do not trust a green status without a test. Make sure the Default From Email address belongs to your domain, that Default From Name is not truncated and makes sense to the recipient, that Force From Email is enabled only when truly needed, and that the old SMTP plugin remains active only until verification is complete. Then send a test email, trigger a real form or password reset email, and review both entries in Email Log.

When to Disable the Old Plugin

Disable the previous SMTP plugin only after Gravity SMTP shows a successful send in the log and the recipient actually receives the message. If the old plugin remains active, it may continue modifying wp_mail(), headers, or the sender value. As a result, you could be looking at the Gravity SMTP log while not really knowing which component handled the email first. For clean troubleshooting, the site should have only one outgoing email router active.

On a critical site, it is better to do the switch in two windows. In the first window, configure Gravity SMTP on a staging copy and document the values. In the second, short window on the live site, repeat the settings, send a test, disable the old SMTP plugin, trigger a real event, and verify both the log and the recipient inbox. If email stops sending after the old plugin is disabled, restore the previous plugin only as a temporary rollback and then compare which field differs in the new integration.

Do not delete the old SMTP plugin immediately after the first successful test. Disable it first, verify several real emails, save notes about the new setup, and only then decide whether a full removal makes sense.

Post-Launch Checks: What to Watch in the First Few Days

After switching to Gravity SMTP, the administrator's job is not over. The first few days show more than whether email sends at all. They reveal how the real site behaves: which sources generate the most messages, which addresses repeat most often, whether failed statuses appear, how quickly the log grows, and whether unexpected emails started appearing after enabling standard WordPress email controls.

Start with the reporting dashboard. It helps you see the overall pattern rather than each message one by one: how many emails were processed, how many were sent successfully, whether errors occurred, which sources are most active, and which recipients appear most often. If the site has a lead form, store, or user area, this dashboard quickly shows that real activity often differs from testing. For example, the test email may send successfully, but emails from one specific form may come from a different source and occasionally fail because of an attachment.

Mini Checklist After the First Real Activity

• Open Dashboard and check whether failed events have increased unexpectedly.
• In Email Log, filter emails by failed status and see whether they are tied to a single source.
• Check several messages from different sources: a form, a password reset, a standard WordPress notification, and a store email if applicable.
• Compare the sender address and sender name in the actual email with what the site owner expects.
• Make sure Debug Logging was not left enabled after troubleshooting.
• Confirm that the log retention period fits the real email volume.

If there are no errors in the first few days, that does not mean you never need to revisit the settings. The mail provider may change limits, the domain may lose a correct DNS record after a migration, another plugin may start sending with a new header, or a form may begin including attachments it did not use before. A reasonable practice is to return to the log after major site updates, a theme change, form changes, adding a store, changing the sender domain, or moving to a new mail service.

How to Distinguish a Delivery Problem From an Email Creation Problem

If a record appears in the log with a successful status, Gravity SMTP has done its part of the route. From there, you need to investigate the mail service, the sender domain, DNS records, and the recipient mailbox. If there is no record at all, the cause is usually in the event source: the form, registration plugin, store, disabled notification type, a conflict, or sending outside wp_mail(). If the record exists but has a failed status, focus on the integration, API key, port, encryption, addresses, and the debug log.

This split saves a great deal of time. Instead of the vague statement "SMTP is not working," you get a precise question: was the email never created, did it never reach Gravity SMTP, did the integration fail, or did delivery fail after a successful send? Each question has its own tool: source settings, Email Log, Debug Log, the system report, the provider dashboard, and the recipient inbox check.

Why Emails Are Not Sending and How to Diagnose the Problem

Troubleshooting works best when you move from the simple checks to the more complex ones. Do not start by reinstalling the plugin or changing providers. First determine whether WordPress is creating the email, whether Gravity SMTP is intercepting it, which integration was used, what is recorded in the log, and what the mail service reports back.

The Email Does Not Appear in Email Log

Symptom: a user performs an action on the site, but no new record appears in Email Log. A test email may still send successfully.

Possible causes: the event does not create an email, the form notification is disabled, the email type is disabled in the Emails tab, another plugin sends outside wp_mail(), or an old SMTP plugin or custom code intercepts the send earlier.

What to check: the settings of the email source, whether the notification is enabled, whether the user action actually completed, whether Email Logging is enabled, and whether a second SMTP plugin is still active. For plugins that use their own mail transport, Gravity SMTP may not see the message at all.

How to fix it: enable the notification in the source plugin, re-enable the necessary email type in the Emails tab, disable the conflicting SMTP plugin, and test sending through a standard WordPress scenario. If the email is generated by an external service outside WordPress, the fix needs to happen in that service instead.

The Log Shows Failed Status

Symptom: the record exists, but the send ended with an error. The recipient never sees the message.

Possible causes: an invalid API key, the wrong SMTP port, the wrong encryption mode, an unverified sender domain, an invalid recipient address, provider limits, or a temporary service error.

What to check: the record details, the sending service, the debug log, the integration card, the Default From Email and Force From Email settings, and for Custom SMTP, the port and encryption mode. If the error repeats, enable Debug Logging, send a test, and review the technical log entry.

How to fix it: update the key, reconnect OAuth, change the port and encryption according to the provider's documentation, verify the domain, correct the recipient address, or temporarily switch to the backup integration. If the cause is still unclear, prepare a system report for support.

The Test Email Sends but the Form Email Does Not

Symptom: Send Test succeeds, but the form or store notification never arrives.

Possible causes: the form is not sending the notification, conditional logic is preventing delivery to the recipient, the message uses a different From value, the email includes an attachment, the source sends earlier than the normal WordPress lifecycle, or another plugin alters the headers.

What to check: the form notification settings, the recipient, the email subject, attachments, the log entry, the header details, and the source of the email. If the form email appears in the log, compare it with the test email: service, status, recipient, and technical details.

How to fix it: correct the form notification, verify the addresses, enable email body storage temporarily for troubleshooting, send the message without attachments, and test for plugin conflicts on a copy of the site. If the issue only appears with one specific plugin, follow that plugin's official conflict-testing procedure.

The Email Was Sent but Lands in Spam

Symptom: the status is successful, the provider shows the message, but the recipient finds it in spam or never sees it in the inbox.

Possible causes: the sender domain is not verified, DNS records are incomplete, the From address does not match the domain, the email content looks suspicious, the provider has weak sender reputation, or the recipient's mail server applies its own filtering rules.

What to check: the domain settings in the mail service, the sender address, the email content, the headers, the spam folder, and the provider logs. Gravity SMTP helps you verify sending, but final deliverability depends on the external mail infrastructure.

How to fix it: verify the domain, use a domain-based sender, do not spoof the From address with someone else's domain, review the email content, and choose an appropriate provider. Do not switch plugins immediately if the problem is clearly related to the domain or sender reputation.

The Log Is Growing Too Quickly

Symptom: the log interface opens more slowly, the database grows, and backups become heavier.

Possible causes: an overly long retention period, email body and attachment storage are enabled, the site sends a high volume of automated notifications, or the debug log was left enabled.

What to check: the Logging tab, the retention period, Save Email Body, Save Attachments, and source activity on the reporting dashboard.

How to fix it: shorten the retention period, disable unnecessary body and attachment storage, turn off the debug log after troubleshooting, and disable unneeded standard WordPress emails only where it is safe to do so.

When Gravity Forms SMTP Is the Right Choice

Gravity Forms SMTP is worth using if you need a managed SMTP layer inside WordPress, have license-based access to Gravity SMTP, and want to verify sending through logs, reports, test emails, and debugging tools. It is especially strong for sites running Gravity Forms, user registrations, system notifications, admin email, and regular workflows where someone needs to answer the question, "What happened to this email?"

Before rolling it out on a live site, make sure the mail provider is ready, the correct sender address has been chosen, the old SMTP plugin is not causing a conflict, logging is configured with a sensible retention period, and a real form or password reset email has completed the full path: event on the site, log entry, successful service response, and receipt in the recipient's inbox.

If you are ready to continue working with the product on your own site, the most practical next step is to get the Gravity Forms SMTP file, install it on a staging copy, and follow the step-by-step verification process from this guide. Do not move the setup to the production site until you clearly understand which service is primary, which sender address is being used, and what the log shows when an error occurs.