WordPress’s default mail function, wp_mail(), routes through PHP’s built-in mail() function on most shared hosting, and that path has a bad reputation for a specific reason: it does not authenticate with the receiving mail server the way a proper SMTP connection does, which is a big part of why password reset emails, order confirmations, and contact form notifications land in spam or vanish entirely on so many WordPress sites. Connecting SendGrid through SMTP fixes this by routing outgoing mail through an authenticated, reputation-managed service instead.
This covers the full setup: creating and verifying a SendGrid account, generating an API key with the right scope, configuring WP Mail SMTP to use it, and the specific things that go wrong when this setup does not work on the first try.
Why PHP’s Default Mail Function Fails So Often
PHP’s mail() function hands an email off to whatever local mail transfer agent is configured on the server and walks away, with no confirmation of delivery and, critically, no authentication that proves your domain actually sent the message. Receiving mail servers increasingly treat unauthenticated mail with suspicion by default, and shared hosting IP addresses in particular tend to carry a mixed reputation since they are shared across many other sites, some of which may have sent spam in the past.
SMTP through a dedicated service like SendGrid solves this because the connection is authenticated with your API key, and the sending domain can be verified through DNS records (SPF, DKIM), giving receiving mail servers a much stronger, verifiable signal that your mail is legitimate.
Step 1: Create a SendGrid Account
- Go to SendGrid’s signup page and create an account.
- Choose a plan. SendGrid’s free tier covers a meaningful volume of monthly emails, enough for most small to mid-size sites’ transactional email needs (password resets, order confirmations, contact form notifications), though check current limits since free tier allowances change over time.
- Complete SendGrid’s account verification steps, including confirming your own email address.
Step 2: Verify Your Sending Domain
Domain authentication is the step that actually improves deliverability, skipping it and just sending from an unverified address undermines much of the point of switching to SendGrid in the first place.
- In your SendGrid dashboard, go to Settings > Sender Authentication.
- Choose Authenticate Your Domain and enter your site’s domain.
- SendGrid generates a set of CNAME records specific to your domain.
- Add these CNAME records to your domain’s DNS settings, through your domain registrar or DNS host, whichever manages your DNS.
- Return to SendGrid and click Verify once the records have been added. DNS propagation can take anywhere from a few minutes to (rarely) up to 48 hours, so if verification fails immediately after adding records, wait and retry rather than assuming something is wrong.
Skipping domain authentication and sending from a generic or unverified address is one of the most common reasons people set up SendGrid and still see mail landing in spam, the SMTP connection working correctly is only half the deliverability picture; domain reputation is the other half.
Step 3: Generate an API Key
- In SendGrid, go to Settings > API Keys.
- Click Create API Key.
- Name it something identifiable, like “WordPress SMTP.”
- Choose Restricted Access rather than Full Access, and grant only Mail Send permission. This follows the principle of least privilege: if the key is ever compromised, its damage potential is limited to sending mail rather than exposing your entire SendGrid account.
- Copy the generated key immediately. SendGrid shows it only once; if you lose it before pasting it into WordPress, you will need to generate a new one rather than retrieve the same key again.
Step 4: Install and Configure WP Mail SMTP
- In wp-admin, go to Plugins > Add New, search for “WP Mail SMTP,” and install and activate it.
- Go to WP Mail SMTP’s settings, usually added under Settings or its own top-level menu item.
- Under Mailer, select SendGrid.
- Paste the API key you generated into the corresponding field.
- Set the From Email to an address on your verified domain, and the From Name to whatever you want recipients to see.
- Save the settings.
Step 5: Send a Test Email
- In WP Mail SMTP, find the Email Test tab.
- Enter an email address you can actually check.
- Click Send Email.
- Check the inbox, and check spam too, for the first test, since a brand-new sending domain occasionally lands in spam for its very first few messages before reputation builds.
If the test succeeds, the SMTP connection itself is confirmed working. That does not automatically mean every plugin on your site that sends mail (WooCommerce order emails, a contact form plugin, a membership plugin’s notification emails) is now routing through it correctly, most well-behaved plugins use wp_mail() internally and will automatically pick up the new SMTP configuration, but check a real order confirmation or form submission separately rather than assuming the single test email covers every mail-sending feature on the site.
A small number of plugins, usually older ones or ones that predate WordPress’s standardization around wp_mail(), send mail through their own direct PHP mail() calls rather than the standard WordPress function. These will bypass your new SendGrid configuration entirely regardless of how correctly it is set up, since there is nothing for WP Mail SMTP to intercept. If a specific plugin’s emails still fail to arrive after everything else tests successfully, check its documentation or support forum for whether it uses wp_mail() at all before assuming your SMTP setup itself is broken.
Troubleshooting When the Test Email Fails
An “authentication failed” error almost always means the API key was mistyped, has expired, or was created with insufficient permissions. Regenerate a fresh key with Mail Send permission specifically and re-paste it, rather than debugging the exact character that might be wrong.
Emails send successfully according to WP Mail SMTP but never arrive. Check SendGrid’s own Activity Feed (under Activity in the SendGrid dashboard) first, it shows the actual delivery status SendGrid recorded for that message, which tells you whether the problem is on SendGrid’s side (bounced, blocked, or genuinely never sent despite what WordPress reported) or somewhere further downstream, like the receiving server’s own spam filtering.
Emails land in spam consistently. This almost always traces back to incomplete domain authentication. Recheck Settings > Sender Authentication in SendGrid and confirm every CNAME record shows as verified, not just added. A partially completed authentication, some but not all records verified, provides weaker deliverability signal than a fully completed one.
Setting Up DMARC for a Complete Authentication Picture
SPF and DKIM, both established through the domain authentication step above, verify that SendGrid is authorized to send on your domain’s behalf. DMARC adds a policy layer on top, telling receiving servers what to do with mail that fails SPF or DKIM checks, and it is worth setting up as a genuine third piece, not an optional extra, for domains that want the strongest possible deliverability signal.
Add a DMARC record through your DNS host, structured as a TXT record at `_dmarc.yourdomain.com`, starting with a monitoring-only policy (`p=none`) rather than an enforcement policy while you confirm legitimate mail is passing correctly, then tightening to `p=quarantine` or `p=reject` once you have confidence nothing legitimate is failing the check.
Monitoring Deliverability Over Time
Getting the initial setup right does not mean deliverability stays good forever without attention. SendGrid’s dashboard reports bounce rates, spam complaint rates, and open rates (for the emails it can track opens for) over time, and a rising bounce or complaint rate is worth investigating rather than ignoring, since it can affect your sending reputation for all future mail, not just the specific messages that bounced.
A common, avoidable cause of rising bounce rates on a WordPress site specifically: a contact form or account registration flow with no email validation, allowing typo’d or fake addresses to accumulate in a mailing list or user database, which then generates hard bounces every time a newsletter or notification goes out to them.
Spam complaints matter more than bounces for long-term reputation, since a receiving mail provider treats a recipient marking your mail as spam far more seriously than a simple bounce from an invalid address. If your site sends anything beyond strictly transactional mail through this same SendGrid connection, a promotional newsletter mixed in with order confirmations, for instance, keep a close eye on complaint rates specifically, since a spike there can degrade deliverability for your transactional mail too, even though the two are conceptually different kinds of email sharing the same sending reputation.
SendGrid API Versus SMTP Relay: Which One WP Mail SMTP Actually Uses
SendGrid offers two distinct ways to connect: the Web API (which WP Mail SMTP’s SendGrid mailer option, described above, actually uses under the hood despite being commonly described as “SMTP setup”), and a genuine SMTP relay connection using a username and password rather than an API key.
The Web API approach is generally preferred and is what most WordPress SMTP plugin integrations default to, including WP Mail SMTP’s built-in SendGrid mailer, because it is faster, provides better error reporting back to WordPress when something fails, and avoids some of the connection reliability issues that can affect traditional port-25 or port-587 SMTP relay connections on certain hosts that restrict outbound SMTP ports entirely.
If your specific host blocks outbound SMTP connections on the ports SendGrid’s relay option needs (some budget shared hosts do this as a spam-prevention measure), the API-based connection sidesteps the problem entirely since it communicates over standard HTTPS rather than a dedicated SMTP port. This is one of several good reasons to default to the API method rather than the traditional SMTP relay username/password approach unless you have a specific reason to need the latter.
Comparing WP Mail SMTP to Alternative Plugins
WP Mail SMTP is the most commonly used plugin for this specific integration, but it is not the only option, and knowing the alternatives helps if you run into a limitation or conflict.
Post SMTP is a capable alternative with a similarly free core feature set and its own detailed delivery logs, useful if you want deeper visibility into exactly what happened to each sent email without relying entirely on SendGrid’s own dashboard for that information.
Easy WP SMTP covers the basics with a lighter interface, suited to sites that want a straightforward connection without the additional reporting and multiple-mailer-provider options WP Mail SMTP’s free version already includes.
For most sites, WP Mail SMTP’s combination of broad mailer support (SendGrid alongside many other providers, useful if you ever switch services later), a reasonably capable free tier, and wide community adoption (meaning more existing troubleshooting resources for common problems) makes it the sensible default rather than a decision requiring extensive comparison shopping.
What Happens During the Migration Window
If you are switching an already-live site from default PHP mail to SendGrid rather than setting this up on a fresh install, there is a brief window worth planning around. Emails queued or in-flight at the exact moment you save the new SMTP configuration are unaffected either way, WordPress does not maintain a persistent outgoing mail queue by default, each email attempt is a discrete, immediate action.
What is worth doing deliberately: test the new configuration on a staging copy of the site first if one is available, rather than the first live test being a real customer-facing order confirmation email. And schedule the actual production switch for a lower-traffic period if your site processes a meaningful volume of transactional email, purely so that if something is misconfigured, the number of affected real emails during the brief troubleshooting window stays small.
A Note on Sending Volume and Rate Limits
SendGrid’s free tier caps monthly sending volume, and it is worth actually calculating your site’s realistic transactional email volume before assuming the free tier will comfortably cover it long-term. A site processing meaningful order volume through WooCommerce, sending an order confirmation, a shipping notification, and potentially an abandoned cart reminder per transaction, can burn through a free tier’s monthly allowance faster than the raw number of “orders” might suggest, since each order can trigger several separate emails.
SendGrid’s dashboard shows current usage against your plan’s limit, worth checking periodically rather than discovering the limit has been hit only when customers start reporting missing order confirmations. Hitting the cap does not necessarily mean total mail failure, depending on plan and configuration it may mean throttled or delayed delivery, but either way it is a signal to review whether an upgrade is warranted before it becomes a customer-facing problem.
Frequently Asked Questions
Is SendGrid free to use with WordPress?
SendGrid offers a free tier covering a limited monthly email volume, sufficient for most small sites’ transactional email needs. Higher-volume sites, or those sending marketing newsletters in addition to transactional mail, will need a paid tier.
Do I need to verify my domain, or is an API key enough?
An API key alone gets the SMTP connection working, but domain verification through SPF and DKIM is what actually improves deliverability and keeps mail out of spam. Treat both as required, not one as optional.
Will this fix WooCommerce order emails not arriving?
In most cases, yes, since WooCommerce uses wp_mail() internally, which WP Mail SMTP intercepts and routes through SendGrid once configured. If order emails still fail after setup, check WooCommerce’s own email settings (WooCommerce > Settings > Emails) to confirm the relevant email types are enabled, separately from the SMTP transport layer working correctly.
Can I use SendGrid alongside a different SMTP provider for different types of email?
Not through a single WP Mail SMTP configuration, which routes all wp_mail() traffic through one configured mailer at a time. Running two providers for different purposes (transactional through SendGrid, marketing through a separate service) typically means using SendGrid for wp_mail() and a separate dedicated marketing plugin or service entirely outside the wp_mail() pathway for the other.
What is the difference between the API key’s Full Access and Restricted Access permission levels?
Full Access grants control over your entire SendGrid account, including billing, other API keys, and account settings, not just mail sending. Restricted Access with only Mail Send enabled limits what the key can do if it is ever exposed or compromised, for instance through a config file accidentally committed to a public repository. There is no functional reason a WordPress SMTP integration needs Full Access, so use Restricted every time.
Does switching to SendGrid change how fast emails arrive?
Typically yes, noticeably. Default PHP mail on shared hosting often queues through a local mail transfer agent with variable, sometimes slow processing, while SendGrid’s infrastructure is built specifically for fast, reliable outbound delivery. Most sites see transactional emails, password resets in particular, arrive within seconds after switching, compared to sometimes minutes-long delays beforehand.