Why do the emails from my contact form land in spam?

In most cases it is not the wording of the message but the fact that the receiving server cannot confirm the origin. The most common cause is a form that enters the address of the enquiring person as the visible sender: the From header then carries a foreign domain that your server is not allowed to send for. The second most common cause is an SPF record that does not know the server actually sending, for example after a hosting change. Both can be fixed with a fixed sender address, a correct SPF record and a DKIM signature.

Is it enough to set up SPF only?

SPF alone covers only part of the picture. It states which server may send, but it refers to the transport address rather than the address the recipient sees. Without DKIM the check also breaks at every forwarding step, and without DMARC the recipient does not learn how to handle a failure. M3AAWG therefore recommends using all three mechanisms and tightening the DMARC policy step by step up to p=reject where that is operationally possible (M3AAWG).

What do p=none, p=quarantine and p=reject mean?

These are the three stages of the DMARC policy. With p=none nothing changes about delivery; you only receive aggregate reports and gain an overview. With p=quarantine receiving systems should treat failing messages as suspicious, in practice usually by delivering them to the spam folder. With p=reject they should be refused (IETF RFC 7489). The sensible path leads from none via quarantine to reject, accompanied by an evaluation of the reports so that no legitimate messages are lost.

How many DNS records do I need for one domain?

As a rule three kinds: exactly one SPF record for the domain, one DKIM record per sending system under its own selector and one DMARC record for the domain. It is important that there really is only one SPF record, because several lead to a permanent error (IETF RFC 7208), and that the evaluation triggers at most ten DNS queries (IETF RFC 7208). If subdomains send independently, additional records or a separate subdomain rule are needed there.

Why does forwarding break authentication?

With a forward, a second server hands the message on to the destination. To the SPF check this looks as if an unauthorised server had sent it, so the check fails. A valid DKIM signature usually survives this path as long as the content stays unchanged, which is why DKIM is the more stable anchor. M3AAWG calls on forwarding systems to keep changes to messages small and additionally recommends the ARC mechanism to them (M3AAWG).

What do I have to check after a hosting change?

After a change, different servers often send than before. Check whether the SPF record covers the new sending path, whether a DKIM key has been generated for the new system and stored in DNS, and whether the DMARC record is still reachable unchanged. Then send a test enquiry through every form and check in the headers of the received message whether all three checks passed. Such a test belongs in every migration checklist, because in our projects moves are the most frequent trigger for delivery problems (project experience).

Emails in Spam? Set Up SPF, DKIM and DMARC

The contact form on the website says: thank you, your message has been sent. Yet nothing arrives in the company inbox, or the message sits unnoticed in the spam folder. This gap between a technical success message and actual delivery is one of the most expensive blind spots on company websites, because nobody complains about a message they have not seen. The cause is rarely the form itself but email authentication: receiving mail servers now check very carefully whether a message really comes from the domain shown in the sender field. Three mechanisms decide the outcome: SPF, DKIM and DMARC. How much these checks now matter is shown by a figure from the largest mailbox provider: after binding sender rules were introduced, the number of unauthenticated messages reaching user inboxes fell by 75 percent (Google). This article explains how a form email is technically created, what the three mechanisms do, which mistakes most often cost delivery in practice and in which order small and medium-sized companies should set this up.

Key takeaways

When a form is submitted the web server itself sends an email — and it is precisely this sender that mailbox providers check.
SPF, DKIM and DMARC are open IETF standards; each solves a different part, and only together do they give a reliable picture.
Since February 2024 major mailbox providers have required authentication from senders — for form mails this is no longer optional.
The most common mistake is starting in the middle: adding an SPF record somewhere and hoping, instead of first mapping all sending paths.
DMARC is no blanket protection against fraud: it checks the sending domain, not the content — deceptively similar domains slip through.
Configured is not verified: evaluating reports, sending test messages and checking regularly stops a working setup from quietly decaying.

How a Contact Form Email Comes About

When a visitor clicks send, more happens technically than the success message suggests. The form passes the entries to a script on the web server. That script builds an email from them and hands it to a mail server, which delivers it to the company inbox. One detail decides the outcome, and hardly anyone sees it in daily business: the domain in the sender field and the server that actually sends the message are two different things. The domain belongs to you, the sending server often belongs to the website host, while the mailboxes sit with a third provider. For the receiving mail server the question is therefore not whether the message looks genuine, but whether this particular server is allowed to send for this particular domain.

To make things harder, every email carries two sender details. During transport the sending server states an address in the so-called envelope from, technically RFC5321.MailFrom; non-delivery reports go back to it. What is visible in the mailbox, however, is the From header, technically RFC5322.From, and only this one is read by the recipient. The two can contain completely different domains without anyone noticing. SPF checks the transport address, DKIM checks the signing domain, and only DMARC requires that at least one of them matches the visible sender domain (IETF RFC 7489). This is exactly the point where authentication fails most often with website forms.

Briefly explained: two senders in every email

The envelope from is the return address for transport and usually appears in the mailbox as the Return-Path. The From header is the address the recipient sees in the inbox. Both are set separately and checked separately. If your form enters the address of the enquiring person as the sender, the visible From suddenly carries a foreign domain that your server is not allowed to send for. To the recipient, the message then looks like a forgery.

In addition, a website is rarely the only system that sends messages under your domain. Newsletters, invoices from accounting, appointment confirmations from a booking flow and the ordinary mailbox often send via completely different servers. Anyone who thinks only of the website and forgets the remaining systems will lock out their own messages once the rules are tightened. How much depends on such automated notifications becomes particularly clear with online appointment booking on the website, where every confirmation and every reminder is an email of its own.

Contact form, callback request and application form on the website
Order and shipping confirmations from an online shop
Appointment and reminder emails from a booking flow
Invoices, reminders and receipts from accounting
Newsletters and regular customer information
The daily mailbox used by your staff

Where the website is hosted therefore also determines which server appears in the name of your domain. Moving to another server or switching the form backend changes this sender chain without anything changing on the visible form. Why operations and mail sending belong together is also shown in our article on the benefits of web hosting in Germany.

SPF, DKIM and DMARC: The Three Building Blocks

All three mechanisms are open internet standards from the Internet Engineering Task Force. Each solves a different part of the problem, and only together do they produce a reliable picture. Anyone who sets up just one of them has covered half the distance but rarely achieves the result they hoped for.

SPF: who may send

The Sender Policy Framework, standardised in RFC 7208 from 2014, is a DNS record in which you define which servers may send email in the name of your domain (IETF RFC 7208). The receiving server looks up the record and compares it with the IP address the message came from. There may be only one SPF record per domain; if the check finds several, it ends with a permanent error (IETF RFC 7208).

DKIM: cryptographic signature

DomainKeys Identified Mail, standardised in RFC 6376 from 2011, adds a signature over selected header fields and the message body to every outgoing message (IETF RFC 6376). The matching public key sits in DNS under a selector. For long-lived keys the standard requires at least 1024 bits (IETF RFC 6376); in practice longer keys are common. Unlike SPF, a DKIM signature survives a forwarding step as long as the message stays unchanged.

DMARC: rule and feedback

DMARC, described in RFC 7489 from 2015, ties both mechanisms together with two ideas: alignment and policy (IETF RFC 7489). Alignment requires the domain confirmed by SPF or DKIM to match the visible sender domain. The policy tells the recipient what should happen to failing messages: none, quarantine or reject. The rua tag additionally brings back daily aggregate reports.

Alignment comes in two levels of strictness. In relaxed mode it is enough for both domains to belong to the same organisational domain, so a subdomain matches the main domain. In strict mode the names have to match exactly (IETF RFC 7489). For a start, relaxed mode is more practical because many systems work with subdomains. The order also matters: DMARC already passes when one of the two checks succeeds and is aligned. A correct DKIM signature is therefore the more stable anchor, while SPF can break at every forwarding step.

Why one mechanism alone rarely suffices

SPF says something about the transport path, not about the visible sender address. DKIM proves the origin but does not tell the recipient how to handle a missing signature. Only DMARC connects both checks with the visible address and gives an instruction. Anyone who sets up SPF alone therefore does little to protect their domain from misuse. How technical foundations and website operations can be secured overall is summarised in our article on the basics of website security.

Why This Is No Longer Optional in 2026

For a long time email authentication was considered a topic for large senders. That has changed. Since February 2024 the largest mailbox provider has required SPF and DKIM, a published DMARC policy and alignment between the visible sender domain and the checked domain from senders who send more than 5,000 messages (Google) per day to its users. At the same time an upper limit of 0.30 percent (Google) applies to reported spam complaints, with a value below 0.10 percent (Google) recommended. Another large provider has published comparable requirements for high-volume senders to its consumer mailboxes (Microsoft).

The effect of these rules can be quantified: according to the provider, the number of unauthenticated messages in inboxes fell by 75 percent (Google), and by the same account its filters block roughly 15 billion unwanted messages every day (Google). For small companies this means the threshold of 5,000 messages may look far away, yet the same filters also assess individual messages. A domain without authentication stands out negatively in this environment, regardless of volume.

At national level, too, the topic has left its niche. The German Federal Office for Information Security has published verifiable requirements for email service providers in its Technical Guideline TR-03182 Email Authentication and justifies them by stating that email authentication protects against attacks in which the identity of trustworthy senders is faked, for example spoofing and phishing (BSI, Technical Guideline TR-03182). It is complemented by the guideline on secure email transport (BSI, Technical Guideline TR-03108). For a mid-sized business these guidelines are not an immediate obligation, but they clearly show the direction in which expectations are moving.

Mailbox providers regularly speak of a possible email authentication future with the catchphrase: no auth, no entry.

M3AAWG, Email Authentication Recommended Best Practices (September 2020)

Authentication counts below the 5,000 threshold too

The volume threshold governs when a provider formally enforces requirements. The assessment of individual messages runs independently of it: filters take reputation, authentication result and complaint rate into account. A trades business with twenty form enquiries a week therefore benefits from the same records as a mail-order retailer, only with considerably less effort.

Step by Step to a Clean Setup

The most common mistake during setup is starting in the middle: publishing an SPF record somewhere and hoping for improvement. The reverse order makes more sense, because every later step builds on a complete inventory. For a small company this is a manageable task once it is worked through in an orderly way.

Take inventory: record every system that sends under the domain. Website, online shop, booking flow, newsletter, accounting, ticket system and the classic mailbox. In our experience, this exercise regularly turns up two to three forgotten senders in small businesses (project experience).
Publish SPF: exactly one record per domain that authorises only the servers or network blocks actually needed. M3AAWG recommends ending SPF records with a soft fail and not authorising more addresses than necessary (M3AAWG).
Set up DKIM per system: a separate key pair with its own selector for every sending system. That makes it possible to trace later which system signed which message, and a key change affects only one system.
Start DMARC with p=none: observe first and request aggregate reports via the rua tag. Without the ability to receive and process reports, a domain owner cannot know whether a stricter policy is safe (M3AAWG).
Evaluate and follow up: review reports over several weeks, clarify unknown senders, add missing signatures. Only then move to p=quarantine.
Tighten to p=reject: M3AAWG recommends p=reject where operationally possible, otherwise p=quarantine; p=none, sp=none and a pct value below 100 should be seen only as transitional states (M3AAWG).
Secure non-sending domains: for domains and spelling variants that send no email at all, M3AAWG recommends an SPF record that rules out any sending (M3AAWG).

Two traps lurk in the SPF record that repeatedly cost delivery in practice. The first is the duplicate record: if a second SPF record is simply created for a new service instead of extending the existing one, the check ends with a permanent error, and it does so for all systems at once (IETF RFC 7208). The second is the lookup limit: the standard requires that an SPF evaluation triggers at most 10 DNS queries (IETF RFC 7208) in order to limit the load on DNS. Every reference to a service provider uses up at least one of them. In addition, queries that return no result, called void lookups in the standard, should be limited to two (IETF RFC 7208). Anyone integrating four or five services hits this limit faster than expected.

With the DMARC record the path matters more than the destination. p=none changes nothing about delivery and serves observation only. p=quarantine instructs the recipient to treat failing messages as suspicious, which in practice usually means the spam folder. p=reject calls for rejection (IETF RFC 7489). Two adjusting screws help during the transition: the pct value defines which share of the message stream the policy is applied to, and the sp tag governs subdomains separately from the main domain (IETF RFC 7489).

Setting	What the recipient does	When it fits
p=none	Delivery unchanged, only reports come back	Entry point and inventory, as long as not all senders are known
p=quarantine	Failing messages are treated as suspicious	When all known systems sign cleanly but a residual risk remains
p=reject	Failing messages are rejected	When the reports have been unremarkable for several weeks
sp=	Separate rule for subdomains	When subdomains are used by other systems
pct=	Policy applies to a share of messages only	For a controlled transition between two stages
rua=	Recipients send daily aggregate reports	At every stage, because without reports any tightening stays guesswork

All records live in the DNS of your domain and affect every send, including the ones from accounting. They therefore belong in the same orderly planning as a server move, where order and waiting times are equally decisive. Which mistakes typically happen during such changes is described in our article on a website relaunch without ranking loss. Which tasks around technology and operations we take on is shown in the overview of our services for websites and online shops.

Typical Failure Patterns from Practice

When form emails land in spam or fail to arrive at all, it is usually one of the same six causes. Almost all of them can be fixed without rebuilding the form.

Customer address as sender

The form enters the address of the enquiring person as the sender so that replying works with one click. This puts a foreign domain in the visible From header that your server is not allowed to send for. The correct approach is a fixed sender address on your own domain and the customer address in the reply-to field.

Forwarding breaks SPF

If a message is forwarded to another mailbox, the forwarding server sends it and the SPF check fails at the destination. A valid DKIM signature usually survives this step as long as the content stays unchanged. M3AAWG therefore calls on intermediaries to keep changes to messages as small as possible (M3AAWG).

Subdomain forgotten

The main domain is set up cleanly, but sending runs via a subdomain, for example for a shop or a newsletter. Without its own records or a matching sp rule, this gap stays open and can be used for misuse (IETF RFC 7489).

Sending from an unknown IP

After a hosting or system change a different server suddenly sends the form emails. The SPF record does not know this server, so the messages fail. Such changes are often noticed only when somebody misses an expected enquiry.

Two SPF records

Another service is added and publishes its own SPF record. From that moment the check returns a permanent error for the entire domain (IETF RFC 7208). The correct approach is a single record in which all services are combined.

Mandatory details missing

Business emails count as business letters and need the same mandatory details as the imprint of the website. If they are missing, that is not a delivery problem but a legal one. Which details belong there is explained in our article on the imprint obligation and mandatory details.

The silent failure is the most expensive one

Unlike a visibly broken page, nobody reports lost form emails. The interested person has pressed send, the company has received nothing, and both consider the matter settled. In projects this often surfaces only weeks later, when somebody compares the number of enquiries with the previous year (project experience). How enquiries can be measured and improved reliably is described in our article on conversion optimisation for more enquiries.

What DMARC Delivers and What It Does Not

DMARC is often presented as all-round protection against fraud. It is not, and the distinction matters, because otherwise false expectations arise. First, what the policy actually achieves:

It makes it considerably harder for third parties to send messages carrying exactly your domain in the visible sender field, as far as receiving systems honour the policy.
It reveals which systems send under your domain, including those nobody in the company remembered.
It improves the chance that legitimate messages reach the inbox, because the authentication result feeds into the assessment.
It provides a solid basis via the aggregate reports instead of guessing at delivery problems (M3AAWG).

The limits are equally important to know before anyone feels too safe:

DMARC does not protect against lookalike domains. A message from a confusable spelling of your name is technically authenticated correctly, just for the wrong domain.
DMARC does not check content. An authenticated message can still contain malware or a forged invoice.
DMARC replaces neither transport encryption nor virus protection; other mechanisms are responsible for that (BSI, Technical Guideline TR-03108).
DMARC only takes effect as far as receiving systems evaluate and honour the policy (IETF RFC 7489).

With the widespread invoice fraud, DMARC helps where attackers misuse the genuine company domain to make a changed bank account look credible. It does not help when somebody registers their own similar-sounding domain and writes from there. A well-considered sender strategy therefore also includes securing obvious spelling variants of your own domain and publishing an SPF record for them that rules out any sending (M3AAWG). The second building block is attention within the team, because a changed bank account should as a rule be confirmed by phone.

A common objection concerns the aggregate reports: do they contain personal data? The reports summarise delivery results statistically by sending IP address and contain no message content (IETF RFC 7489). The Certified Senders Alliance within the eco Association of the Internet Industry has examined the compatibility of DMARC with the General Data Protection Regulation in a dedicated report (eco Association of the Internet Industry, Certified Senders Alliance). With individual failure reports via the ruf tag more restraint is appropriate; M3AAWG explicitly considers their inclusion optional (M3AAWG). How data protection on the website is implemented cleanly overall is summarised in our GDPR checklist for websites.

Control: Reports, Test Sends and Monitoring

Set up is not the same as verified. Five simple routines prevent a working configuration from falling apart unnoticed.

Read the aggregate reports: the daily rua reports show which servers have sent under your domain and whether SPF and DKIM passed. Without this evaluation any tightening remains guesswork (M3AAWG).
Test send after every change: after adjustments to DNS, hosting or the form, send a real enquiry and check the headers in the target mailbox for a pass on SPF, DKIM and DMARC.
Test every sender individually: not just the contact form but also order confirmations, invoice dispatch and newsletters, because every system needs its own signature.
Check again after moves: hosting changes, a new form backend or a change of mailbox provider alter the sending servers. Such changes are the most frequent reason why a previously clean configuration suddenly fails (project experience).
Plan key changes: a DKIM key whose public part is removed from DNS too early makes all messages still in transit unverifiable (IETF RFC 6376).

The effort stays manageable when it is part of ongoing care rather than caught up in a rush once a year. In our projects, the initial setup for a small company with three or four sending systems takes a few hours, while the subsequent observation phase up to the stricter policy takes several weeks (project experience). Why regular care pays off in other respects too is described in our article on website maintenance; the ongoing framework for it is our website care service.

The moment when it breaks most often

After a provider change the website is back, the form reports success, and still nothing arrives. The reason is usually the same: the new server is not authorised in the SPF record, and no DKIM key was stored for it. A deliverability test therefore belongs in every migration checklist, right next to the check of redirects and forms.

What This Means for Your Website

For most small and medium-sized companies, email authentication is a one-off clean-up with lasting effect. It costs no licence fees but care: a complete list of the sending systems, a clean SPF record, one DKIM key per system and a DMARC policy that gets stricter step by step. The benefit shows up twice, in the delivery of your own messages and in protecting your brand from misuse. Anyone who also wants to measure how many enquiries actually arrive will find the right key figures in our article on measuring website success.

We set up website sending, DNS records and the evaluation of aggregate reports as part of our web hosting offer and check delivery again after every move. If you cannot judge how your domain currently stands, a deliverability check of your existing domain is the quickest way in: we look at SPF, DKIM and DMARC, name the open points and classify what is urgent and what can wait. For questions about the concrete approach, you can reach us via the contact form, which on our side is sent with authentication in place.

Sources and studies

This article is based on data from: the German Federal Office for Information Security (BSI), Technical Guideline TR-03182 Email Authentication and TR-03108 Secure Email Transport; IETF RFC 7208 (Sender Policy Framework), IETF RFC 6376 (DomainKeys Identified Mail) and IETF RFC 7489 (DMARC); M3AAWG, Email Authentication Recommended Best Practices (September 2020); Google (sender requirements and reported results after their introduction); Microsoft (requirements for high-volume senders); eco Association of the Internet Industry, Certified Senders Alliance (report on the compatibility of DMARC with the GDPR) and our own projects. Figures marked (project experience) come from our own setup and migration projects and are orders of magnitude. Provider requirements can change, and a specific delivery rate cannot be assured.