How to fix WordPress emails that never arrive

Why this is happening now

Gmail, Yahoo, Microsoft and Apple have all tightened up what they’ll accept. If an email says it’s from you@yourbusiness.com.au, they now want proof that your domain actually authorized it. That proof is a cryptographic signature tied to your domain, not to whichever server happened to send the message.

Most web hosts send your site’s mail through a shared relay. It works, in the sense that the email leaves the building. But it’s signed by the host’s domain, not yours, so the receiving mail server sees a mismatch and treats it as suspicious. Depending on how strict your domain’s own policy is, that mail either lands in junk or gets rejected outright.

Nothing announces this. Your form says “thanks, we’ll be in touch”. WordPress reports the email as sent. You just stop getting enquiries.

If your site is hosted with Wordify

This applies to you, and their documentation says so directly. Wordify’s shared outbound gateway can’t sign mail with your domain’s own keys, so they recommend routing customer-facing email through a dedicated provider instead. Their relay is fine for admin alerts to yourself. It’s not fine for anything a customer or lead is meant to receive.

Most decent managed hosts are in exactly the same position. Wordify is just clearer about saying it out loud.

What you’ll need

• Access to your domain’s DNS records. This is usually wherever you bought the domain, or wherever your nameservers point.
• WordPress admin access.
• About 30 minutes.

If you don’t have DNS access, stop here and find out who does. Everything below depends on it, and there’s no workaround.

Step one: pick a sending service

You need something that will send your site’s mail properly and sign it as you. There are three sensible routes.

Postmark

This is what I use and what I set up for clients. It’s built specifically for the kind of mail websites send: form notifications, password resets, order confirmations. Deliverability is excellent, the setup is clean, and you get a log of every message so you can actually see what happened. Free up to 100 emails a month, then around US$15 a month after that. Most small service businesses sit comfortably in the free tier.

Google Workspace

If you’re already on Workspace and your site sends genuinely low volumes, you can route mail through your existing account. Be aware of the trade-offs though: there’s a daily sending cap, and the setup involves creating a project in Google Cloud and authorising it, which is more fiddly than it sounds. I’ve used this as a temporary fix and then moved off it. Fine as a stopgap, not what I’d choose to leave in place.

Microsoft 365

Same reasoning if your business runs on Microsoft. Same trade-offs.

If you’re not sure, go with Postmark. It’s the least work and the most reliable, and the free tier means the decision costs most folks nothing.

Step two: set up your sending account

Using Postmark as the example, since it’s the one I’d recommend:

1. Create an account and create a Server. A server in Postmark is just a container for one site’s mail. One per website.
2. Go to Sender Signatures and add your domain. Postmark will show you the DNS records it needs. Leave that page open, you’ll need it in step four.
3. Once the domain verifies, open your server, go to the API Tokens tab and copy the Server API token. Keep it somewhere safe for a minute.

One thing worth knowing: Postmark may not approve your account straight away. They manually review new accounts to keep spammers out. If you get knocked back, reply to them and explain what you’re actually sending, which for most people is “contact form notifications from my business website”. Mine was approved after a short back and forth. It’s an approval process, not an error.

Step three: connect your sending service to WordPress

You can add loads of code and mess about with a more technical and time-consuming setup (the Postmark guides have instructions for this). Or you can install the free FluentSMTP plugin. It’s lightweight, it doesn’t nag you to upgrade, and it works with every provider worth using. I’m using Fluent because it makes the whole process super easy.

Go to Settings → FluentSMTP, choose your provider and fill in the connection. A few settings matter more than the rest:

• From Email. Use an address on your own domain. Not Gmail, not Hotmail. If your site is yourbusiness.com, send from something like hello@yourbusiness.com. This is the whole point of the exercise, so don’t undo it here.
• Use the API rather than SMTP if the option is offered. It’s faster, more reliable, and sidesteps port issues entirely. If you do need SMTP, use port 587.
• Message Stream: outbound. Postmark separates transactional mail from bulk marketing mail. Your site’s mail is transactional and Fluent will know that the default outbound setting feeds to this. Getting this wrong muddles your sending reputation.
• Force Sender Name. Tick it. This makes sure bounce messages come back to you instead of vanishing, which means you’ll find out when something fails.
• Turn open and link tracking off. You don’t need to know whether someone opened their own password reset, and tracking adds redirect links that make legitimate mail look less legitimate.
• Save the connection.

Step four: publish your DNS records

This is the part people abandon. Take it slowly and it’s fine.

Your provider will give you the exact records to add. Go to your DNS host and add them as shown. Three things are in play:

• SPF lists which servers are allowed to send on your behalf. It’s a TXT record on your domain.
• DKIM is the signature that proves the mail genuinely came from you. This is the one that makes the whole thing work. Also a TXT record.
• DMARC tells receiving servers what to do when something fails the first two checks. It’s a TXT record at _dmarc.yourdomain.com.

If you’re adding DMARC for the first time, start permissive and tighten later:

v=DMARC1; p=none; rua=mailto:your-report-address

p=none means “don’t reject anything yet, just tell me what’s happening”. The rua part is where reports get sent, and there’s a section further down on setting that up properly. Don’t tighten the policy beyond p=none yet. Step six covers when and how.

DNS changes usually take effect within minutes but can take a few hours. If verification doesn’t go through immediately, wait before you start pulling things apart.

Step five: test it

FluentSMTP has a test email function. Use it first to confirm the connection works at all.

Then do the real test, because that’s the one that counts:

1. Fill in your own contact form as though you were a client.
2. Send it to an address on a different platform from your own. If your business email is Google, test to a Microsoft or Apple address, and vice versa. Testing to the same platform you send from tells you very little.
3. Check it arrived in the inbox rather than junk.
4. Open the message and look at the technical details. In most mail apps you can view the original message or message source. Look for the authentication results and check that SPF, DKIM and DMARC all show as passing.

If all three pass and the message is in the inbox, that’s the outcome you want.

If you’d rather not squint at raw headers (because who wants to do that?!), two free tools do this pain-free:

• MXToolbox looks up what your domain is actually publishing right now. Use the SPF, DKIM and DMARC lookups to confirm your records are live and correctly formed. This is the one that catches typos and duplicate records.
• Mail-tester works the other way around. It gives you an address to send a test email to, then scores the result out of 10 and tells you what’s dragging it down. Good for a single overall verdict.

Use both. They answer different questions: one checks what you published, the other checks what actually happens when you send.

Step six: monitor DMARC before you tighten it

This is the step almost everyone skips, and it’s the one that stops you breaking your own email.

Your DMARC record has a policy setting. Right now it’s on p=none, which means you’re collecting information but not acting on it. The temptation is to jump straight to p=reject because it sounds more secure. Don’t. If you tighten the policy before you know every legitimate source of mail using your domain, you’ll start blocking your own email, and you won’t necessarily find out quickly.

Think about everything that might send as you. Your website. Your mailbox provider. Your email marketing platform. Your booking system. Your invoicing software. Your CRM. Anything that sends a notification “from” your domain. Every one of those needs to be authorized before you turn enforcement on.

DMARC monitoring is how you find them. Receiving mail servers send reports back to the address in your rua tag, but the raw reports are XML files that are genuinely unpleasant to read. A monitoring service collects them and turns them into something a human can use.

Free options worth using:

• Postmark’s DMARC tool sends you a weekly email digest. No dashboard, no login, and you don’t need a Postmark account to use it. Simplest possible setup and the reports are clear. This is what I use.
• Cloudflare DMARC Management is free and unlimited if your DNS is already on Cloudflare. Worth knowing about, though I wouldn’t move nameservers just to get it.
• EasyDMARC and dmarcian both have free tiers with an actual dashboard, capped at one domain and a modest monthly volume.

Postmark also sells a paid version called DMARC Digests at around US$14 a month per domain, which adds a live dashboard, longer history and full source detail. For a small business site, the free weekly digest is plenty.

One warning on setup. When you add your domain to Postmark’s tool it will hand you a DMARC record to publish, but it doesn’t check whether you already have one. If you paste it in blindly you can end up with two conflicting DMARC records, which is worse than having none. Check first, and if you already have a record, add Postmark’s reporting address to your existing rua tag rather than replacing the whole thing. You can list more than one address there.

And if any tool generates a DMARC record for you, check it for sp=none and take it out before you publish. The gotchas section explains why that one matters.

Then wait. Watch the digests for four to six weeks. Once every legitimate source is showing as aligned and passing, move to p=quarantine, which sends failures to junk instead of the inbox. Give that a few more weeks, and if nothing legitimate has been caught, go to p=reject.

There’s no prize for rushing this. p=none with monitoring switched on is a perfectly respectable place to sit while you work out what’s actually sending as you.

The gotchas nobody mentions

These are the things that cost me time when I set this up, and which other designers have asked me about.

• Your DNS panel might be lying to you. I had a registrar panel showing one DMARC policy while live DNS was serving something completely different. Two separate checking tools and the mail headers themselves confirmed the panel was wrong. Never trust the interface you typed the record into. Verify every record against live DNS with MXToolbox or similar, because that’s what the rest of the world is actually seeing.
• Strip sp=none out of any generated DMARC record. Some tools, including Postmark’s own generator, include this. It means “apply no policy to subdomains”, which quietly leaves every subdomain of your domain unprotected. Unless you have a specific reason to want that, remove it so subdomains inherit your main policy.
• Your email marketing platform can’t do this job. Kit, Mailchimp and the rest are built for newsletters. They have no way to handle the individual messages your website generates, and no amount of configuration will change that. These are two different systems doing two different jobs.
• Watch out for services that brand your mail. Some cheaper sending providers add their own logo or footer to transactional email unless you pay to remove it. Check before you commit, because a password reset with someone else’s branding on it looks like a phishing attempt.
• One server per site. If you look after multiple websites, give each one its own server and its own API token. If one site develops a problem, it won’t drag the others down with it.

Or I can sort it for you

If you’ve read this far and decided you’d rather not faff around with this yourself, that’s a reasonable conclusion. This is a one-off job that needs to be done properly once, and the failure mode is silent, which is the worst kind.

I set this up for clients as a US$300 piece of work. That covers the sending account, the plugin configuration, all DNS records, DMARC monitoring, and testing across platforms so we know it’s actually working before I hand it back.

Get in touch and I’ll let you know what’s involved for your setup.