Website Emails Not Being Received? Causes and Fixes

If emails from your website or domain are not being received, the cause is almost always authentication, not the email itself. Since February 2024 Gmail and Yahoo, and since May 2025 Outlook.com, filter or reject mail that cannot prove it comes from your domain. The fix is to send through a proper sending service and publish three DNS records for your domain: SPF, DKIM and DMARC. On a working setup that is usually a few hours of developer work, not a rebuild.

This covers contact forms, web shop order confirmations, password reset and sign-up emails, and your own mail landing in your customers' spam folder.: the fixes overlap.

The first 15 minutes: what you can check yourself

1. Find out where the email went. Check spam and junk in the receiving inbox, and test with a Gmail and an Outlook.com address. Junk in one and missing in the other narrows it down.
2. Look for a bounce. If you sent the mail yourself, a reply from "Mail Delivery Subsystem" or "postmaster" holds an error code. Copy it. 550-5.7.26 ... DMARC policy from Gmail and 550 5.7.515 from Outlook both mean authentication failed.
3. Read the headers of a message that did arrive. In Gmail, open the message, then the three dots, then "Show original". You will see SPF, DKIM and DMARC each marked PASS or FAIL. Screenshot it.
4. Check what changed. New hosting, a new email provider (for example a move to Google Workspace or Microsoft 365), a new form plugin or a new newsletter tool are the usual triggers. Write down the date the problem started.
5. Look up your DNS records. Enter your domain in MXToolbox SuperTool and run the SPF, DMARC and blacklist checks. Two SPF records, no DMARC record or a blacklist listing are all findings a developer can act on.
6. Run a test score. mail-tester.com gives you an address; send a message to it from your website form or shop and it scores the message and lists what failed.

Keep the screenshots and error codes: they save a developer paid time.

SPF, DKIM and DMARC in plain words

• SPF is a list, published in your DNS, of the servers allowed to send email for your domain. If your website host, your mailbox provider and your newsletter tool all send as you, all of them must be on that list. You may only have one SPF record per domain, and it may trigger at most 10 DNS lookups; break either rule and SPF fails with a permanent error (RFC 7208).
• DKIM is a digital signature on every message. The sending service signs it, and the public key sits in your DNS so receivers can check the message was really sent by you and was not changed. Each sending service has its own DKIM key, so each needs its own DNS record.
• DMARC ties the two to the address your customers see in the From line. It tells receivers what to do when a message fails (nothing, spam folder or reject) and where to send daily reports. Those reports show you every service sending as your domain, including ones you forgot.

The detail that catches most sites is alignment: SPF or DKIM must pass for the same domain that is in the From address. A form that sends as info@yourshop.com from a server that only authenticates as the host's own domain passes nothing that counts.

What Gmail, Yahoo and Outlook now require

Sources: Google's sender guidelines, Yahoo Sender Hub and Microsoft's postmaster policies. Google adds that from November 2025 it is ramping up enforcement, with temporary and permanent rejections for non-compliant mail. Few small businesses send 5,000 a day, but the "all senders" rules apply to everyone.

Symptom, likely cause, what to do

The "test mail service" row is common in apps built quickly with AI tools. Supabase, for example, says its built-in email "is not meant for production use", only delivers to your own team and is limited to 2 messages per hour. Our launch checklist for vibe-coded products covers this and similar gaps.

Why website mail fails and what fixes it

Most websites send email the cheapest way: PHP's mail() function or the host's shared mail server. WPForms, which makes one of the most used WordPress form plugins, puts it bluntly: there is "no authentication, no retry logic, no logging", and on shared hosting one bad neighbour can get the shared IP blacklisted. Google's own help article on contact form messages not reaching Gmail makes the point that matters: "A contact form that automatically sends messages is an email sender for your domain." It needs SPF and DKIM like any other sender.

The fix is a transactional email service: a company whose whole job is delivering one-to-one mail such as confirmations and resets. It gives you DKIM keys for your domain, logs every message, and shows bounces. Published prices are low:

On WordPress you connect one with an SMTP plugin; in a custom app it is a small code change. The hard part is getting DNS, alignment and every sender right.

Rolling out DMARC without blocking your own mail

Google's recommended DMARC rollout is the safe order:

1. Set up SPF and DKIM at least 48 hours before DMARC.
2. Publish v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Nothing is blocked; you start receiving reports.
3. Read the reports for at least a week. Every service in them that is not aligned is a sender to fix: the booking tool, the invoicing software, the old form.
4. Move to p=quarantine with a small pct= value and increase it to 100.
5. Only then consider p=reject.

Jumping straight to reject is the classic self-inflicted outage: your invoices or your shop's confirmations start bouncing the same day. If you only want to meet the Gmail, Yahoo and Outlook rules, p=none with reports is enough.

When to call a developer

• Orders or password resets are not arriving. That is lost revenue and support tickets every hour. Treat it as an outage.
• You see bounces with 5.7.26, 5.7.515 or a blocklist name and do not know which sender causes it.
• You do not know which services send as your domain. DMARC reports will tell you, but someone has to read them.
• A blacklist listing came from a hacked site. Delisting before the hole is closed just gets you listed again. See our hacked WordPress checklist.
• Whoever set up your mail is unreachable.

What to have ready

• Login for your DNS (often the domain registrar or Cloudflare) or someone who can change records today.
• Admin access to the website or app, its hosting, and your mailbox provider (Google Workspace, Microsoft 365 or your host's mail).
• A list of tools that send email as you: form plugin, shop, newsletter, CRM, booking and invoicing.
• Your bounce messages, header screenshots and the date it started.
• An account at a sending service, or permission to create one in your name, so you own it.

What it costs at We Do Dev Work

Prices excluding VAT, billed for actual time:

• Emergency help: $85 an hour. A senior developer starts the same day, no minimum, no intake. Out-of-hours work is possible; weekends cost 50% extra ($127.50 an hour). We sign an NDA if you need one.
• Strip card: $1,050 for 14 hours (about $75 an hour). We start within 24 hours, hours are deducted as we work, valid 4 months. Good for "fix the mail now, then clean up SPF, DMARC and the other senders properly".
• Subscription: from $550 a month for 8 hours, with updates and monitoring. Growth is $2,200 for 32 hours with same-day response. Minimum 3 months.

A single misconfigured record is often found and fixed within the first hours. Moving a site or app to a sending service, setting up DKIM for every tool and running a DMARC rollout takes longer, and we tell you the expected scope before the hours add up. For context on emergency rates elsewhere, see what an emergency developer costs.

How to decide

• Order, booking or reset emails are failing right now: emergency help today.
• Mail works but lands in spam, no urgency: a strip card, so the fix and the DMARC rollout fit in one prepaid block.
• You keep adding tools that send mail, or it broke before: a subscription, so someone watches DMARC reports and checks each new sender.
• You have an in-house developer: give them this article, the DMARC rollout steps and access to DNS. It is a well-documented job.

How to prevent it next time

• Send all website and app email through one authenticated sending service, never PHP mail().
• Keep a DMARC record with rua reports and have someone look at them monthly.
• Add every new tool to SPF and DKIM before it sends its first email, and keep one SPF record.
• Recheck email whenever you change host, domain, DNS provider or mailbox provider. Our website maintenance cost guide shows what a monthly check costs.
• If you send thousands of emails a day, register your domain in Google Postmaster Tools to watch your Gmail spam rate. At low volumes it shows no data.
• Run a free EngineeringScore audit for a quick view of your site's security, performance and reliability.

Customers not getting your emails?

Send us your domain, the error message or a screenshot through the emergency help page. You do not need to know which record is wrong. A senior developer picks it up the same day at $85 an hour, finds the failing sender, and tells you what needs fixing before the hours add up. If you would rather have someone keep your mail and site healthy every month, look at our prices for strip cards and subscriptions.