How form notifications are sent, and why they get rejected

Your visitor did not send that email — your web server did. What wp_mail actually does, what SPF, DKIM and DMARC check on the way in, and why a form's “sent” does not mean delivered.

The form says "Thank you, your message has been sent". The visitor believes you. Nothing arrives, or it arrives in a junk folder nobody opens, and you find out weeks later when a customer rings to ask why nobody replied.

Almost every case comes down to one fact that is easy to miss: the visitor did not send you an email. Your website did. Once you see it that way, the causes become fairly predictable, and most of them can be checked in an afternoon.

If you only want to know which of four things it is, the short version is on contact form emails going to spam, and nothing arriving at all is next door to it. This piece is the long version: what that mail actually is, and why a receiving server decides not to believe it.

How a form notification is actually sent

When someone submits a contact form, the form plugin takes the fields, builds an email and asks the web server to send it. On WordPress that goes through wp_mail(), which WordPress describes as sending "an email, similar to PHP's mail function". Unless a plugin changes the mailer, the function's source sets PHPMailer to "use PHP's mail()", which means the web server hands the message to whatever mail setup the hosting company has.

Two details in that reference page explain a lot of missing mail.

The default sender is an address you probably never created. If nothing sets a From address, WordPress uses wordpress@ followed by your site's domain. The code comment next to it says plainly that "Some hosts will block outgoing mail from this address if it doesn't exist".

"Sent" does not mean delivered. The same page states that "a true return value does not automatically mean that the user received the email successfully. It just only means that the method used was able to process the request without any errors." The thank-you message on your form reflects that return value. It tells you the server accepted the job, not that any mailbox accepted the mail.

So the notification is a message from your domain, sent by a web server that was set up to serve web pages. Whether a mailbox provider believes it depends on whether your domain has said that server is allowed to send for it.

Why the receiving server does not believe it

A receiving mail server has no way to know that [email protected] is really you, so it checks three published records.

SPF: is this server allowed to send for the domain? SPF lets a domain "explicitly authorize the hosts that are allowed to use their domain names", and a receiver checks the connecting server against that list (RFC 7208). If your SPF record lists your office mail provider but not your web host, mail from the web server fails. Two quieter failures catch people out as well: a domain "MUST NOT have multiple records" (adding a second SPF record when you sign up for a new email service produces an error), and evaluation is limited to 10 DNS lookups, beyond which the result is also an error.

DKIM: is the message signed by the domain? DKIM lets the domain owner "claim some responsibility for a message" with a cryptographic signature checked against a public key in DNS (RFC 6376). A web server sending through PHP mail only signs for your domain if someone has deliberately set up a key for it.

DMARC: do the checks line up with the From address? This is the one that catches form mail. SPF checks the envelope sender used by the server, not the From line you see. DMARC closes that gap: a message passes only if SPF or DKIM passed for a domain that aligns with the domain in the visible From header, and the domain owner publishes what should happen when it does not. The current specification is RFC 9989, published in May 2026 as a Proposed Standard, replacing the older RFC 7489. Its policies range from p=none ("no expression of preference") through quarantine ("such mail to be suspicious") to reject, where the owner considers failures "a clear indication that the use of the domain name is not valid" (RFC 9989, section 4.7).

A web server can pass SPF for the hosting company's own domain and still fail DMARC for yours, because the domain that passed is not the one in From.

The visitor's address in the From line

Many forms are configured so the notification appears to come from the visitor: From is set to whatever the person typed in the email field. It feels convenient, because pressing Reply goes straight to them. It is also the most reliable way to have the message junked.

Think about what the receiving server sees. A message claims to be from [email protected] but arrives from your web host's server, which Gmail has certainly not authorised. That is spoofing, whatever the intent. If the visitor's domain publishes a quarantine or reject policy, the receiver is being told to junk or refuse it. Google lists "Don't impersonate Gmail From: headers" among its requirements for all senders.

Contact Form 7's own best-practice guide makes the same point in plain terms: "in the From field, use an email address that belongs to the same domain as the site."

The correct pattern is:

From: an address on your own domain, such as [email protected], ideally a real mailbox.
Reply-To: the visitor's address, filled from the form field.

Reply-To exists for exactly this. The message format standard says it "indicates the address(es) to which the author of the message suggests that replies be sent" (RFC 5322, section 3.6.2). Your mail client still replies to the visitor; the mail no longer pretends to be from them. In Contact Form 7 you add Reply-To in the Additional headers field of the Mail tab; other plugins have their own setting, and our integrations pages show where each builder keeps its notification fields.

What the big mailbox providers now require

The rules tightened in 2024 and 2025. What matters for a contact form is the difference between requirements for everyone and requirements for bulk senders.

Gmail. Since 1 February 2024, all senders to personal Gmail accounts must, among other things, set up SPF or DKIM, have valid forward and reverse DNS, and use TLS. Senders of more than 5,000 messages a day must have SPF, DKIM and DMARC, with the From domain aligned. Google says mail that is not authenticated "might be marked as spam or rejected with a 5.7.26 error" (Google's email sender guidelines).

Yahoo. Enforcement began in February 2024. All senders must "implement SPF or DKIM at a minimum"; bulk senders need both, plus a DMARC policy that passes (Yahoo sender best practices).

Outlook.com, Hotmail and Live. Microsoft's requirements apply to domains sending more than 5,000 messages a day to its consumer services: SPF and DKIM must pass, a DMARC record must exist and pass. Microsoft announced them in April 2025 and updated the post to say non-compliant mail would be rejected from 5 May 2025 with the error "550; 5.7.515 Access denied" (Microsoft Support).

A contact form will almost never hit 5,000 a day, so the bulk rules rarely apply directly. The all-senders floor does, and a web server sending unsigned mail from a domain whose SPF does not mention it does not meet it. Business mailboxes on Microsoft 365 or Google Workspace run their own filtering on top of all this.

A diagnostic checklist, in order

Work through these in sequence. Each one rules out a layer.

Confirm the form is sending at all. Many builders store submissions as well as emailing them. If the entry is in the site's dashboard but not in anyone's mailbox, the problem is mail, not the form.
Send a test to a personal Gmail address and open it (look in Spam too). Use More, then Show original to see the full header. Find the section starting with Authentication-Results; Google's SPF troubleshooting guide explains reading the result after spf=, and the same header carries the dkim= and dmarc= results.
Check the From and Reply-To in that header. If From is the visitor's address, fix that before anything else.
Check your DNS records. One SPF record, including every service that sends as your domain. A DKIM record if your sending service signs. A DMARC record, and know which policy it publishes.
Ask your host for the mail log. Hosting control panels often have a delivery report or mail log; if not, support can tell you whether the server sent the message and what the receiving server said.
Check the recipient's quarantine, not only Junk. On Microsoft 365, quarantine "holds potentially dangerous or unwanted messages" outside the mailbox, found at the Defender portal's Quarantine page; messages expire and some are admin-only (Microsoft Learn). Google Workspace admins can set up email quarantine, where messages are deleted 30 days after sending.
Send through a real mail service. An SMTP or transactional email provider, connected by a plugin, signs mail for your domain and sends from servers your SPF can list. WP Mail SMTP is one widely used option; it "reconfigures WordPress to use a proper SMTP provider". Any reputable provider plus correct DNS will do the same job.

Symptom	Likely cause	Where to look
Form says sent, nothing anywhere	Host blocking or discarding outbound mail	Host mail log, hosting support
Arrives in Gmail spam, headers show `spf=fail` or `dkim=none`	Web server not authorised or not signing for your domain	SPF and DKIM records, SMTP plugin
Arrives for some recipients, not others	Recipient's own filtering or quarantine	Microsoft 365 or Workspace quarantine
Arrives only when the visitor uses certain email providers	Visitor's address used as From	Form notification settings
Outlook.com bounce with 5.7.515	DMARC requirements not met	DMARC record, alignment
Stopped after a DNS or email provider change	SPF record replaced or duplicated	DNS zone

Where it is genuinely hard

Hosts that do not want you sending mail. Some hosting blocks outbound mail entirely. On Google Cloud, for example, "connections to destination TCP Port 25 are blocked when the destination is external"; Google points to ports 587 or 465 and third-party services instead (Google Cloud documentation). If your host works like this, no DNS change fixes it. You need an external mail service.

Hosted website builders. On Wix and Squarespace the form notification is sent by the platform, not your domain. Squarespace sends from [email protected] and suggests a filter to accept it (Squarespace Help); Wix lists addresses such as [email protected] to allowlist (Wix Help). Your SPF and DKIM are irrelevant here. What you can control is the recipient side: allowlists, quarantine, and the notification address.

Nobody owns the problem. The web developer owns the form, the IT provider owns the mailboxes, someone else owns DNS. Each can correctly say their part works. Getting all three to look at one test message's headers is usually the fastest way through.

Once the mail arrives: the other problem

Fixing delivery has a side effect people do not expect. Everything arrives now, including the spam that used to be lost with the enquiries. And modern form spam is not the obvious kind: it is fluent, polite and scraped from your own site, which we covered in why your spam filter stopped catching it and, for WordPress specifically, Contact Form 7 spam.

This is where Humainbox changes the path rather than the plumbing. You point the form's notification at a Humainbox inbox address instead of your own mailbox, and Humainbox reads each message and delivers real enquiries onward to your team, with the visitor's address as the reply address when the message carries one. It does not repair your site's SPF, and if your host is not sending mail at all, nothing reaches Humainbox either. What it changes is where the form sends to, and what reaches your mailbox. How it works has the detail, and the WordPress integration page shows the exact field to change.