Why contact form emails land in spam: SPF, DKIM and DMARC in order

Contact form emails usually land in spam when they are sent by a server your domain has not authorised, or when the message carries no signature from your domain. The fix is 3 DNS entries: SPF for every sender, DKIM at your sending provider, and DMARC, which at first only collects reports. The form itself is rarely the problem. What matters is how the message is sent and authenticated (Google Workspace Help).

Why does a form email end up in spam?

A form on your website sends a message “from” an address on your domain, for example office@example.com, but your mailbox does not send it. A hosting server, a plugin or a separate sending service does. To the recipient this is a different server using your address, which is the same pattern scammers use. So the recipient’s server asks your domain’s DNS whether that server may send for you. If there is no answer, or the answer is no, the message goes to spam or is rejected. Like a mailbox, the form has to be listed in those records.

The website shows “message sent” because your server handed the message on. The problem only appears at the recipient’s end.

The second common cause is the From field. If the form puts the visitor’s address there, say a Gmail address, the message looks like impersonation. Google’s sender guidelines tell senders not to put a Gmail address in the From field of mail that does not come from Gmail, because it can hurt delivery. Put an address on your own domain in From and the visitor’s address in Reply-To, so replies still go to the visitor.

How can you find out what is wrong in 10 minutes?

1. Send a test message from the form to your own Gmail address.
2. Open it and choose “Show original” (in Outlook, view the message headers).
3. At the top find the SPF, DKIM and DMARC results. In the Authentication-Results header each one says pass or fail.
4. For a second opinion, email a test message to a free tool such as learndmarc.com, which shows how a receiving server validates SPF, DKIM and DMARC. Test with a real message, not just a domain name: DKIM only shows up on an actual email.

Read the result like this:

If all three say pass and the message still lands in spam, the cause is elsewhere. See the section on deliverability below.

The headers say fail and you are not sure which entry to fix? Tell us what they show and we will tell you where to start.

Check your email setup

Step 1: SPF for every sender

SPF is a TXT record in DNS listing the servers allowed to send email from your domain. Start with a list of senders: mailboxes (Microsoft 365 or Google Workspace), the web server with the form, the tool that emails your subscribers, your invoicing software, your online shop. Each one has to be in SPF, usually through an include entry from the provider. An example for a domain on Microsoft 365 with one extra sender:

v=spf1 include:spf.protection.outlook.com include:spf.sender.example -all

Watch out for 3 things:

• One SPF record per domain. Two records make SPF return a permerror, a permanent error (RFC 7208). Add new includes to the existing record.
• At most 10 DNS lookups. The include, a, mx, ptr, exists and redirect mechanisms all count, and nested includes add their own (RFC 7208). Past the limit, SPF returns a permerror.
• The -all ending only after every sender is listed. Mail from a sender you forgot is rejected once -all is in place.

SPF checks the sender address in the message envelope, not the From field you see in your mail program, so it can pass for a fake From field and is not enough on its own.

Step 2: DKIM at your sending provider

DKIM is a signature added to every message. The public key sits in DNS under a name like selector._domainkey.example.com, and the receiver uses it to check that the message was not altered and that your domain signed it. Your sending provider gives you the records, often CNAME or TXT entries. Copy them into DNS exactly as given, without changing a single character.

This step is easy to skip with outside services. Without DKIM for your domain, the service signs messages with its own domain. SPF then passes for the provider’s domain and DMARC fails, because neither domain matches your From address (Microsoft). If the form sends through a provider’s API or through your mailbox’s SMTP, DKIM lives with that provider or that mailbox. Set it up there, not on the website.

For mail to personal Gmail accounts Google requires a DKIM key of 1024 bits or longer, and it says to set up SPF and DKIM at least 48 hours before DMARC (Google).

Step 3: DMARC, with reports first

DMARC ties the SPF and DKIM results to the From field and tells the receiver what to do with a message that fails. A message passes when SPF or DKIM passes and matches the domain in From. The record is a TXT entry named _dmarc.example.com (Google):

v=DMARC1; p=none; rua=mailto:dmarc@example.com

The p policy has 3 values: none (do nothing, only report), quarantine (send to spam) and reject (refuse). Start with none. Receivers then send aggregate reports to the rua address, usually once a day, as XML attachments listing the sources of your email and their SPF and DKIM results. Point them at a shared mailbox or a group, not at an employee’s mailbox (Microsoft). You read them with a tool, not by hand. There are free options, for example the weekly digest from Postmark.

In the reports look for sources that fail: a sender you forgot, or a service without DKIM for your domain. Fix them one by one. Google advises moving to quarantine only after at least a week of reports with no problems, and notes that with reject, failing messages are never delivered (Google). Tightening the policy too early gets good mail rejected, for example emails sent by an outside provider you forgot (Microsoft).

The current DMARC standard has been RFC 9989 since May 2026. It removed the pct tag, which still appears in older guides. The record name and the v=DMARC1 syntax did not change.

How long does it take?

The SPF and DKIM entries take a day if you have access to DNS. If you do not, sort out access to the domain first. Then wait at least 48 hours before DMARC, and after publishing p=none leave time to collect reports. Google’s rollout plan allows a week of reports before quarantine. RFC 9989 says that for a domain with infrequent sending, reaching full enforcement can take many months.

Is deliverability only about DNS?

No. Correct SPF, DKIM and DMARC are necessary, but not enough. Gmail requires SPF or DKIM from all senders and a spam rate below 0.3%, and from 5,000 messages a day it also requires DMARC. Sending providers have their own limits: with too many bounced messages, meaning mail to addresses that do not exist, they may pause your account. At our provider the limit is a bounce rate of 4%.

So when someone signs up for your emails, check that the domain of the address accepts mail. An address with a typo in the domain then adds no bounce to the account statistics.

Questions and answers

Is SPF alone enough to keep emails out of spam?

No. SPF checks the technical sender address, not the From field your recipient sees, so it can pass even when the visible sender is fake. For DMARC to pass you need SPF or DKIM aligned with the domain in the From field. Set up both.

Does a small business need DMARC?

Gmail requires SPF or DKIM from every sender and DMARC from 5,000 messages a day to Gmail accounts, as Google's sender guidelines say. A small business is below that line, but a p=none record costs nothing and gives you reports, so publish one anyway.

Which DMARC policy should I start with?

Start with p=none and an address for reports in the rua tag. That policy blocks nothing and shows you who sends email from your domain. Move to quarantine or reject only when the reports confirm that all your own sending passes.

How can I check that DKIM works?

Send a test message from the form to your own Gmail address and open 'Show original'. Next to dkim look for pass and the signing domain. A test tool such as learndmarc.com does the same when you email it a message.

Terms used in this article

• DMARC
• API