Why Contact Form Emails Land in Spam: SPF, DKIM and DMARC for Business Owners
A contact form is only useful if its notification reaches someone. When the message from your website lands in a spam folder, or never arrives at all, the form still looks like it works. The visitor sees a thank-you page. Nobody on your side sees the lead.
This article is about the sending side of that problem: why a form notification can be treated as suspicious, and which three DNS-based records to check first. It is not about junk submissions coming in through the form. That is a separate problem, covered in our guide to stopping form spam without blocking leads.
Why a form email can look suspicious
A website form usually sends its notification through the web server or a mail plugin. The email is written to look as if it comes from your business address, but it may actually be sent by a server that your domain never authorised to send for it. A receiving mail system evaluates several signals before deciding how to handle the message. SPF, DKIM, and DMARC are three important authentication checks to review first.
Google’s email sender guidelines for Gmail state the consequence plainly: messages that are not authenticated might be marked as spam or rejected with a 5.7.26 error. The guidelines also say that if you do not meet the requirements, your email might not be delivered as expected, or might be marked as spam. Those are the guidelines for one mailbox provider, so other providers may apply their own rules, but the three records below are the common starting point.
The three records, in plain terms
Each mechanism relies on information published in DNS. DKIM also requires the sending service to sign outgoing messages with the corresponding private key. Each answers a different question.
SPF: which servers may send for this domain? The Sender Policy Framework is described in RFC 7208 as a way for a domain owner to explicitly authorise the hosts that are allowed to use their domain name, and for a receiving host to check that authorisation. If your form sends from a server that is not on the list, the check can fail.
DKIM: was this message signed by the domain? DomainKeys Identified Mail, described in RFC 6376, lets the owner of a signing domain claim some responsibility for a message. The claim is validated through a cryptographic signature and by looking up the signer’s public key in the signer’s domain.
DMARC: does the visible From address line up, and what should a receiver do if not? Domain-based Message Authentication, Reporting, and Conformance is described in RFC 7489 as a mechanism for expressing domain-level policies and preferences for message validation, disposition, and reporting. It supports handling that ranges from no action, through altered delivery, up to message rejection.
Put simply: SPF identifies hosts authorised to send for a domain, DKIM adds a verifiable domain signature, and DMARC checks whether SPF or DKIM authentication aligns with the domain in the visible From address, while publishing handling and reporting preferences.
What Google requires for authentication
Google’s guidelines separate two groups of senders.
- All senders to Gmail must set up SPF or DKIM for their sending domains.
- Senders of more than 5,000 messages per day to Gmail must set up SPF, DKIM, and DMARC. The guidelines add that your DMARC enforcement policy can be set to none, and that for direct email the domain in the From: header must be aligned with either the SPF domain or the DKIM domain.
If your domain sends fewer than 5,000 messages per day to Gmail accounts, Google’s stricter bulk-sender requirements may not apply to you. Google nonetheless says it recommends that you always set up SPF, DKIM, and DMARC for your domains. That is a reasonable default for a business that depends on form leads.
A short check you can run
You do not need to be a mail administrator to find out where you stand. Work through these in order.
- Find out what actually sends the notification. Is it your web host’s mail function, a form plugin, or a dedicated email service? Ask whoever built or maintains the site if you are not sure. Everything else depends on this answer.
- Check the From address. If the notification claims to come from your business domain, the sending service needs to be authorised for that domain. If it uses a different address, such as one belonging to the service, the picture is different.
- Look at your domain’s DNS records for SPF, DKIM, and DMARC. Your domain provider’s support information describes where these are set. If you use an email service provider for the form, Google’s guidelines say to verify that they authenticate your domain’s email with SPF and DKIM.
- Send a test through the real form. Submit the form yourself and note where the notification lands, how long it takes, and whether your mail system flags it. A single test is a data point, not proof, so repeat it from more than one mailbox if you can.
- Keep a record. Write down what sends the form email, what the records say today, and the date you checked. If a lead goes missing later, you will have somewhere to start.
What not to assume
- A passing test does not prove every notification arrives. Delivery depends on the receiving provider and its current rules.
- Setting up the records is not always a one-line change. If several services use your domain in their SPF identity, your SPF policy needs to account for each authorised sender. Other services may authenticate through aligned DKIM instead, so confirm each provider’s setup before changing DNS.
- A thank-you page is not an email delivery receipt. At most, it indicates that the website accepted the submission flow; it does not prove that the notification reached an inbox.
We are describing a general approach, not diagnosing your domain. The records, the sender, and the provider are specific to each business.
Make delivery part of routine care
Form notifications are easy to forget because they run in the background. Checking that they are authenticated, and that a test submission arrives, belongs in the same routine as checking that the form itself works. Our piece on why a website form is a revenue system covers the wider case for treating it that way.
If you would like someone to look at this for your site, you can ask for a form-delivery check through our website support and maintenance page, or contact us directly.
Jeremy Johnson
Owner
Jeremy co-owns Robben Media and directs strategy for every client engagement. With a Computer Engineering degree from Missouri S&T, he brings deep technical expertise in web development, SEO, and automation. Before acquiring Robben Media in 2023, Jeremy led marketing and branch management in the mortgage industry. He believes marketing should be measured by revenue generated, not impressions reported.