website form emails land in spam: why

Website form emails land in spam when the notice is sent by the web server under a domain that never authorized that server. We see it when the From line is the visitor's address, or a free inbox printed on the site, and when the domain the business owns has no usable SPF record, no DKIM signature, or a DMARC result the receiver will not accept. Since February 1, 2024, Google has required every sender of mail to personal Gmail accounts to set up SPF or DKIM, and it says messages that are not authenticated that way might be marked as spam or rejected with a 5.7.26 error [1]. A pass still does not promise the inbox. The May 2026 DMARC standard says a pass only means the domain owner authorized that use of the From domain, not that delivery is safe or desirable [2].

What the form is actually sending

A contact form collects the message on the page. A script on the web server then composes an email. The visitor did not send that email from their own mailbox. Your site did.

Providers look at more than one identity. The envelope sender, the SMTP MAIL FROM, is who should get a bounce. The header From is what people see. Reply-To is where a human answer should go. SPF, published in April 2014, checks whether the connecting host may use a domain in MAIL FROM or in the HELO name. It does not vouch for the other identities. The specification says a sender can pass SPF with its own domain and still put a different address in the From header [3]. Microsoft says the same thing more directly: SPF validates sources for the MAIL FROM domain only, and it does not consider the domain in the From address [4].

That gap is how an ordinary form gets treated like a forgery. The script sets From to the visitor, [email protected], so the owner can hit Reply. The website host submitted the message, not a Gmail server acting for Jane. Google's rules for every sender to personal Gmail accounts say not to impersonate Gmail From headers, and that doing so might affect delivery [1]. Google's sender FAQ defines that impersonation as a @gmail.com address in From on mail that was not sent from a Gmail server. The temporary-failure notices described there for this spoofing are aimed at bulk senders, so a low-volume form is not automatically in that wave [14]. The safe layout does not depend on the wave. From should be an address on your domain, such as [email protected]. Reply-To can be the visitor.

The FTC's CAN-SPAM guide, dated August 2023 and edited in January 2024 for penalty figures, requires the From, To, Reply-To, and routing information, including the originating domain and email address, to be accurate and to identify who initiated the message [5]. A notice to your own inbox is not a marketing blast. Transactional or relationship mail is exempt from most of the Act, but it still may not use false or misleading routing information [5]. The filter and the statute are different tests. Both object to someone else's domain on mail your server started.

A free inbox on the site is a different failure

Some footers still print [email protected], or a Yahoo or Outlook.com mailbox, and the form sends to that address or sends as that address. SPF, DKIM, and DMARC are DNS records the domain owner publishes. If the visible domain is gmail.com, the records that matter are Google's. You cannot add your web host to Gmail's authorized servers, and you cannot publish a DKIM key under Gmail's name.

Google's SPF guide says receivers check the record to verify that mail from the domain came from authorized servers, and that SPF helps keep outgoing mail out of spam [6]. That check only helps a domain whose DNS you control. A free mailbox can still be where a person reads mail. It should not be the address the website sends as, and it should not be the only address on the site if you expect the notice to authenticate. Use a mailbox on the domain you registered, print that address, and send the form from it.

SPF: which servers may use your domain

An SPF record is one DNS TXT record. The April 2014 standard says the domain publishes which hosts may use its name in MAIL FROM or HELO, and the receiver tests the connecting host against that record [3]. A pass means the client is authorized for that identity. A fail means it is not. A softfail means the host is probably not authorized. If no SPF record is found, the result is none, which is not a pass [3].

Two publishing mistakes break small sites. The domain must not publish multiple records that cause the check to select more than one SPF record, or the result is a permanent error [3]. A second TXT value that also starts with v=spf1, added beside the record you already had, is that mistake. SPF also limits the mechanisms and modifiers that cause DNS lookups to 10 in one evaluation, and past that limit the result is a permanent error [3]. A long chain of include: tags for old tools can fail the check even when the form host is "in there somewhere."

The record has to name the server that sends the form, not only the company that hosts the mailbox. If SPF lists only Google Workspace or only Microsoft 365, mail from the website host is not authorized. Microsoft's DNS guidance gives the case: if the sending server is not a Microsoft 365 server, the SPF check might fail and the message would not be delivered [7]. Google says the record should list the servers that send for the domain, and that SPF can take up to 48 hours to start working after you publish it [6]. A check five minutes later can still be using the old answer.

SPF is not the whole test. Because it does not authenticate the header From, a message can pass SPF for the host's hostname while the visible From is your domain, or the reverse [3][4]. DMARC is what asks whether those domains line up.

DKIM: a signature your domain can prove

DKIM, specified in September 2011 in RFC 6376, lets the signing domain claim some responsibility for a message with a cryptographic signature. The receiver fetches the public key from that domain's DNS and checks that the signed content was not changed [8]. No certificate authority is required. A failed check does not, by itself, force rejection [8]. A valid signature from some other domain does not mean your domain sent the mail.

In Google's setup, the public key is a DNS TXT record and the sending server uses the private key to sign outgoing mail. Receivers use the public key to authenticate mail from the domain, which helps protect it against spoofing [9]. If the form path never signs, Google says a header with no DKIM line means mail from the domain is not signed [9].

Microsoft 365 does not DKIM-sign a custom domain until you configure signing. Microsoft says the message needs to be signed by the domain in the From address, that DKIM passes DMARC only when those domains align, and that DKIM alone is not enough without SPF and DMARC [10]. A website form is often a sender that is not the mailbox host. Microsoft's troubleshooting guide says to add that service to SPF or, preferably, have it DKIM-sign with your domain [11]. The signature still matters when mail is forwarded. Forwarded mail fails SPF because the forwarding server's IP is not in the original SPF record, and Microsoft calls that expected [11].

DMARC: the visible From has to match

DMARC checks that the visible From domain lines up with a passing SPF or DKIM result. The current specification is RFC 9989, from May 2026, which obsoletes the March 2015 document RFC 7489 [2]. A pass needs an SPF or DKIM pass, and the domain on that pass must align with the Author Domain, the domain in the From header. Relaxed alignment means the same organizational domain. Strict alignment means an exact match. One aligned pass is enough [2].

The published policy is a preference: none (no preference stated), quarantine (you consider the failure suspicious), or reject (you consider that use of the domain invalid) [2]. A pass does not guarantee that inbox delivery is desirable, and a receiver is not required to apply the handling you requested [2]. Google's DMARC page, updated September 18, 2026, lists the receiver actions as reject, quarantine, or deliver, and it says the pass or fail depends on how closely the From domain matches the domain SPF or DKIM authenticated [12]. Google's troubleshooting page says strict alignment makes rejection or the spam folder more likely, and that a receiver may quarantine or reject mail even when DMARC passes [13]. If the policy is p=none and mail is still in spam, Google says the cause may be something other than the DMARC record [13]. The standard agrees on that point: a discovered p=none policy must not change existing handling [2].

Set it up in the order the standard describes. Use a MAIL FROM domain that aligns with From. Sign with an aligned DKIM domain. Publish p=none, send aggregate reports to a mailbox you read, and only then move toward quarantine or reject [2]. The reports are how a forgotten form host or plugin shows up. There is a trap in the SPF record itself. An SPF record ending in -all can cause a reject during the SMTP conversation, before DMARC runs, even when an aligned DKIM signature would have passed DMARC [2].

Bulk mail is a higher bar, and a contact form is usually not in it. Senders of more than 5,000 messages a day to personal Gmail accounts must set up SPF, DKIM, and DMARC, and the policy may be p=none [1]. Every sender to those accounts, at any volume, still needs SPF or DKIM, valid forward and reverse DNS (a PTR record) for the sending domain or IP, and TLS [1]. Google recommends all three checks for the domain that hosts the public website, and it says authenticated mail is less likely to be rejected or marked as spam [1].

What an owner can check this week

You can see the failure on one message the live form just sent.

The From address is on your domain, not the visitor's address and not a free mailbox. Reply-To may be the visitor. The address printed on the site is a mailbox on that domain that you can open.

There is one SPF TXT record. It includes the website host if the site sends the form, and the mailbox provider if people also send by hand. There is no second v=spf1 record, and the include: chain stays inside the 10-lookup limit [3].

DKIM is actually signing. Google has you publish the key and then start authentication. A key in DNS with signing never started still leaves no DKIM line [9]. Microsoft 365 does not sign custom-domain mail until that signing is configured [10].

A DMARC record exists at _dmarc. If you have not read reports, the policy is p=none and the report address works. You are not on p=reject while the form host is missing from SPF and unsigned [2].

If the notice goes to a personal Gmail account, the sending host has matching forward and reverse DNS, and the session uses TLS [1].

One test to an outside inbox

Submit the form to an inbox on a different provider, and open it there. Google says to send the DKIM test to someone on Gmail or Google Workspace, and that you cannot verify DKIM by mailing yourself [9].

Open the original message and find Authentication-Results. Google says the DKIM result should read DKIM=pass or DKIM=OK, and that no DKIM line means the mail was not signed [9]. Microsoft's example of the same header shows DKIM=pass or DKIM=OK together with spf=pass and dmarc=pass for the From domain [10]. The domain on those results should be yours, not the host's hostname and not the visitor's. If the copy is in spam, read the header anyway. The folder is the symptom.

If DNS changed today, wait. Google says SPF can take up to 48 hours to start, and that SPF and DKIM should be in place for at least 48 hours before you enable DMARC [6][13]. Test again from the live form after that window, using the same From address the page uses in production.

What a clean test does not promise

A pass means the receiver can see that your domain authorized the message. RFC 9989 says that is not a delivery guarantee, and that some legitimate mail still fails, including mail that forwarding changes [2]. Wording, links, and a burst of identical notices can still be filtered. If p=none is set and spam continues after aligned SPF and DKIM both pass, look past the policy, which is what Google's troubleshooting page says [13].

This is not a reason to delete the form or to replace it with a phone prompt or a chat widget. The form can store the lead while the notice never arrives. Fix the identity on the notice, and the DNS behind it, then prove it with one outside message.

Practical takeaways

• Send form notices From an address on the domain you control. Put the visitor in Reply-To, not in From.
• Stop using a free inbox as the address printed on the site. You cannot publish SPF, DKIM, or DMARC for a domain you do not own.
• Publish one SPF record that includes the server that actually sends the form. Stay inside the 10-lookup limit, and do not add a second v=spf1 record [3].
• Sign that same domain with DKIM. An aligned DKIM pass still counts when forwarding breaks SPF.
• Publish DMARC at p=none until reports show the form path passes, then tighten the policy. Confirm with an outside test and the Authentication-Results header, because a pass does not force the inbox.

How we can help

Have more questions or want to get in touch?

Our team checks this on live sites: the From address the form uses, the address printed on the page, and whether SPF, DKIM, and DMARC for that domain agree with the server that sends the notice. If you want a second set of eyes on a form that never shows up, or on the DNS behind it, start at our contact page. Ongoing care for the site and the records it depends on is part of website maintenance.

Citations

1. Google, "Email sender guidelines" (requirements effective 2024-02-01)
2. IETF RFC 9989, "Domain-Based Message Authentication, Reporting, and Conformance (DMARC)" (2026-05)
3. IETF RFC 7208, "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1" (2014-04)
4. Microsoft Learn, "How email authentication works in Microsoft 365" (2026-07-03)
5. Federal Trade Commission, "CAN-SPAM Act: A Compliance Guide for Business" (2023-08, edited 2024-01)
6. Google Workspace Help, "Set up SPF" (2026-09-18)
7. Microsoft Learn, "External Domain Name System records for Microsoft 365" (2026-06-26)
8. IETF RFC 6376, "DomainKeys Identified Mail (DKIM) Signatures" (2011-09)
9. Google Workspace Help, "Set up DKIM" (2026-09-18)
10. Microsoft Learn, "How to use DKIM for email in your custom domain" (2026-07-03)
11. Microsoft Learn, "Troubleshoot email authentication in Microsoft 365" (2026-05-27)
12. Google Workspace Help, "Set up DMARC" (2026-09-18)
13. Google Workspace Help, "Troubleshoot DMARC issues" (2026-09-18)
14. Google, "Email sender guidelines FAQ" (2025)