In short and in plain language
Sometimes an enquiry from your form does not arrive. It ends up in spam. That is the folder for junk mail.
The thank you page only says that the website got the enquiry. It does not say if the email arrived.
The customer's address does not go in the sender field. It goes in the reply-to field.
Some entries for your domain show that the email is real. Your domain is the address of your website.
Test the form now and then with an outside address. This is part of upkeep. We can help you with this.
After a contact form is submitted, it says “Thank you for your enquiry”. That message confirms one thing only: the website accepted the input. It says nothing about where the message went. Every trade business surveyed reports using email (Bitkom) - the channel is in use everywhere, and it is precisely this channel that the quietest defect of a website hits. For a sense of how sharply the receiving side sorts: Germany's federal government networks recently received an average of around 712,000 emails per day, and the monthly average of daily spam rates was 51 percent (BSI). Roughly half of the volume is filtered out before a person ever sees it. If you want your own form email to land on the right side of that split, it has to be recognisably genuine.
Key takeaways
- The thank-you page only proves that the website accepted the form. Whether the email was delivered is recorded in the message headers and in the mail server log - not on the page.
- The customer address belongs in the Reply-To field, not in the sender field. If the website sends under someone else's domain, the checks fail by design, because they then apply that other domain's rules (RFC 5322, RFC 9989).
- SPF, DKIM and DMARC are three records in your domain DNS: at most 10 terms in an SPF record may trigger a DNS lookup (RFC 7208), DKIM keys need at least 1024 bits and should have 2048 bits (RFC 8301), and DMARC requires alignment with the visible sender domain (RFC 9989).
- The self-test takes ten minutes: send a test enquiry to an address outside the business, open the headers, read the Authentication-Results line, check the spam folders of both mailboxes. A test to your own address proves little.
- The BSI technical guideline on email authentication expects a policy of quarantine or reject and provides for DKIM keys to be renewed every six months (BSI TR-03182). Both belong in a maintenance rhythm, not in a one-off setup.
The Thank-You Page Is No Proof of Delivery
A form consists of two processes that have little to do with one another technically. The first: the browser sends the input to the website, the website accepts it and replies with a confirmation page. The second: a program on the web server hands an email to a mail server so that the enquiry arrives in the business mailbox. The first process succeeds largely regardless of how the second turns out. That is why a website can say “Thank you” for months while nothing arrives in the office.
The second process has several points where it can fail without anyone noticing. The program on the web server may not even attempt the handover, because a credential is missing. The mail server may accept the message and reject it later - the error notice then goes to a sender address that nobody in the business reads. The receiving server may accept the message and file it in the spam folder. And the spam folder of a shared mailbox is opened less often, in many businesses, than the fuse box in the cellar.
The difference between the two processes is why a form is so hard to assess. Anyone designing the fields of an enquiry form thinks about length, mandatory entries and clarity - we have written up how many fields an enquiry form in the trades can carry. The path the message takes afterwards is a separate job, and experience shows it is only examined once someone from outside says: I wrote to you twice.
| Stage | What can go wrong there | How you spot it |
|---|---|---|
| Website accepts | The form stores the enquiry but does not send it | The form log holds entries, the mailbox does not |
| Web server hands over | The handover to the mail server fails, the notice ends up in the server log | The web server error log names rejected delivery attempts |
| Sender check | The sending server is not authorised for the sender domain | The Authentication-Results header of the test mail shows spf=fail or dmarc=fail |
| Receiving server evaluates | The message is accepted and filed into the spam folder | The test mail sits in the spam folder, not in the inbox |
| Mailbox in the business | A rule moves the message into a folder nobody opens | A search across all folders finds the mail, the inbox does not |
The third and fourth rows are the core of this article. They depend on whether a receiving system can verify that the message really comes from your domain. That is what the three DNS records are for - and the three addresses inside the message that are regularly confused with one another.
Three Addresses That Are Not the Same
An email carries more than one address. Three of them matter for the form. The envelope sender is negotiated between the servers during delivery; non-delivery notices go to it. The sender field is what the recipient sees in the mail program. The Reply-To field decides which address is used when someone clicks reply. Many form extensions set all three to the address the customer entered - well meant, because replying is then convenient, and that is exactly the defect.
In all cases, the "From:" field SHOULD NOT contain any mailbox that does not belong to the author(s) of the message.
If the customer address sits in the sender field, your website is claiming to send on behalf of a foreign domain. The receiving server then checks that foreign domain's rules - and your server is not listed there as an authorised sender. The result is a failure by design, not a coincidence and not a filter error. The stricter the foreign domain has set its policy, the harsher the assessment.
The way out is one line of configuration. The sender is a fixed address on your own domain, for example form@sampletrade.invalid. The customer address moves into the Reply-To field, which the standard provides for exactly this purpose: it names the address to which the author suggests replies be sent (RFC 5322). The business still clicks reply and writes to the enquirer, and the sender domain check can succeed all the same, because it now refers to your own domain.
The rule of thumb for the form
SPF, DKIM and DMARC: the Three Proofs
The three procedures answer three different questions, and they do so through records in your domain DNS - the same place that states where the website is hosted. SPF answers the first question: which servers may deliver on behalf of this domain? The record is essentially a list, and it is published as a TXT record (RFC 7208).
Two limits of the procedure show up in everyday use. First, a domain may carry only a single record of this kind; several records that would be available for selection are not permitted (RFC 7208). Anyone who adds a second record when switching providers and leaves the old one in place invalidates the check. Second, at most 10 terms in a record may trigger a DNS lookup: “SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS” (RFC 7208). What is counted is not each individual DNS lookup but each query-triggering mechanism and modifier in the record; every service included consumes at least one of them. A record that has grown over years eventually breaks that limit, and from then on the check fails with permerror - including for messages that used to pass.
DKIM answers the second question: has the message remained unchanged in transit, and does it come from a system that holds this domain's key? To that end the sending server signs every message, and the public part of the key sits in the DNS. There is a lower bound on the length: signers must use RSA keys of at least 1024 bits for all keys and should use at least 2048 bits (RFC 8301, which updates the requirement from RFC 6376). The BSI technical guideline on email authentication explicitly includes messages generated by a contact form on a website: every message in the name of the sending domain is to be signed, regardless of whether a mail program or indeed a form produced it (BSI TR-03182).
DMARC answers the third question: what should happen when the first two checks do not match the visible sender domain? The technical term is alignment. The current standard RFC 9989, which superseded RFC 7489 in May 2026, requires it between the domain in the visible sender field (Author Domain) and the domain confirmed by SPF or DKIM (Authenticated Identifier).
DMARC describes the concept of alignment between the Author Domain (Section 3.2.2) and an Authenticated Identifier (Section 3.2.1) and requires such Identifier Alignment between the two for a message to achieve a DMARC pass. DMARC defines two states for alignment.
That closes the circle back to the form: as long as the customer address sits in the sender field, alignment cannot succeed, even when SPF and DKIM are set up cleanly for your domain. The policy has three levels - observe, quarantine, reject. The BSI expects quarantine or rejection in its technical guideline, because only those two protect the recipients (BSI TR-03182). Anyone starting out begins at the observation level and evaluates the reports; a reporting period typically covers a single UTC day, so the report usually arrives once a day (RFC 9990).
- SPF shows that a particular server may deliver on behalf of the domain. It says nothing about the content of the message and nothing about the sender field.
- DKIM shows that the message has been unchanged since it was signed and comes from a system holding the matching key.
- DMARC ties both to the visible sender domain, defines what should happen on a mismatch, and supplies reports on who is sending in your name.
- None of the three records forces delivery: per RFC 9989, a DMARC pass on its own says nothing about whether delivery to the inbox is desirable. They take away the receiving server's reason to treat your message as forged - no more than that, but no less either.
Three records, one place - and it is often somewhere else
The Self-Test in Ten Minutes
The test needs no tool you have to buy. It needs two mailboxes, one of which does not belong to your domain, and a willingness to look at the headers of a message once. The order matters: send first, then search, then read. Anyone who starts by adjusting settings loses the reference value.
Send a test enquiry
Fill in your own form using an address that does not belong to your domain; a private mailbox will do. Write the date and time into the message field so the message can be identified unambiguously later.
Search both paths
Look in the business mailbox and in the test mailbox, in the inbox and the spam folder each time. Search across all folders as well, because rules can move messages without marking them as spam.
Open the headers
Almost every mail program can display the source of a message, usually via a menu entry such as show original or message source. What you are looking for is the Authentication-Results line written by the receiving server.
Note the result
Write down what it says for spf, dkim and dmarc, along with the date and the mailbox. Those four details are the difference between a hunch and a finding, and at the next test they are the reference value.
Fill in your own form using an address that does not belong to your domain; a private mailbox will do. Write the date and time into the message field so the message can be identified unambiguously later.
Look in the business mailbox and in the test mailbox, in the inbox and the spam folder each time. Search across all folders as well, because rules can move messages without marking them as spam.
Almost every mail program can display the source of a message, usually via a menu entry such as show original or message source. What you are looking for is the Authentication-Results line written by the receiving server.
Write down what it says for spf, dkim and dmarc, along with the date and the mailbox. Those four details are the difference between a hunch and a finding, and at the next test they are the reference value.
The line that matters looks roughly like the extract below. It is written by the receiving server, not by your own system, and is therefore more reliable than any self-report from your own setup.
Authentication-Results: mx.receiver-example.invalid;
spf=pass (sender IP is 203.0.113.24)
smtp.mailfrom=sampletrade.invalid;
dkim=pass header.d=sampletrade.invalid;
dmarc=pass (p=quarantine sp=quarantine dis=none)
header.from=sampletrade.invalid
From: Website enquiry <form@sampletrade.invalid>
Reply-To: Enquiring person <customer@example.invalid>
To: office@sampletrade.invalid
Subject: Enquiry 2026-0418 via the formThree words decide the matter. A pass at spf means the sending server was authorised for the domain in the envelope sender. A pass at dkim means the signature is valid and the stated domain matches it. A pass at dmarc means the visible sender domain matches at least one of the two checked domains. A fail at dmarc combined with a pass at spf is the classic picture of a form sending under the customer address.
A test to your own address proves little
The Confirmation Email to the Customer
Many forms send two messages: one to the business and a confirmation to the person who made the enquiry. The same rules apply to the second one, but the damage is of a different kind. If the enquiry arrives at the business while the confirmation does not reach the customer, the impression is that the form did not work. Experience shows this leads to the same enquiry being submitted a second time - or to the next business.
The confirmation goes to an address you do not know, through filters you cannot see. That makes its delivery depend all the more on the three proofs. On top of that come a few craft details that avoid the impression of an automatically generated bulk message.
- The sender is an address on your domain with a recognisable name, such as the business name, not a string like noreply-2 or mailer-daemon.
- The subject line names the business and the occasion, so the message can be found again in a full archive.
- The body contains the details from the form in plain text, plus a phone number and when you can be reached. A confirmation without content reads like an empty receipt.
- A reply to the confirmation should reach you: the Reply-To field points at a mailbox that is actually read.
- Leave attachments and embedded tracking pixels out of the confirmation; both raise the likelihood that filters take a closer look.
If the confirmation is being reworked anyway, it pays to think one step ahead: anyone who wants to turn the enquiry into an appointment will find the workflow in the article on organising appointment requests via the website. And if the form or the confirmation involves services that require consent, the article on the cookie banner in a trade business explains when a prompt is required.
Who Notices That No Enquiry Arrived
The most expensive part of this topic is not the technology but the attention. A form that no longer delivers mail behaves quietly: no error message, no red line, no phone call. In the trades there is the added fact that enquiries fluctuate anyway - three quiet weeks in summer are explainable, and that very explainability covers up the defect. Clearly defined procedures for the event of a cyber attack are in place at 15 percent of the businesses surveyed (Bitkom); for the quieter case that simply nothing arrives any more, experience suggests a rule is even rarer.
The way out is not a monitoring product but a counter and a date. The form assigns a sequential number to every enquiry and writes it into the subject line and into a list on the server. Anyone who wants to know whether something is missing compares two figures: how many numbers were issued, how many mails are in the mailbox? The difference is the finding. Without that number the question of whether something has been lost cannot be answered, because the reference value is missing.
A sequential number per enquiry
Every enquiry gets a number that appears in the subject line and is logged on the server. That makes it possible to check later whether a message is missing between two numbers; without the number, that comparison is not possible.
A mailbox somebody opens
Enquiries arrive in a mailbox for which one person is responsible, with a named deputy. Shared addresses without a responsible owner are the most common place where messages are left lying.
A fixed test date
Once a month, one test enquiry from outside, with date and result in the same list. The effort amounts to a few minutes and replaces the assumption that everything is working with a written note.
An alert on silence
If no enquiry arrives over a defined period, a reminder goes to the responsible person. The period is based on the usual volume of the business, not on a general benchmark.
Anyone who puts these four points in place has turned a silent failure into a visible one. The same pattern applies to the second channel through which jobs are lost: the article on why trade businesses lose calls before the phone even rings describes the same blind spot on the telephone. For trades with a pronounced season it is also worth reading the article on the indoor season for painters and decorators: if you depend on enquiries from the form over winter, check the delivery path before the season rather than in the middle of it.
Relaunch and Migration: Records First
The moment at which a working form path most often breaks is a change of hosting. The new website sits on a different server, so a different server delivers the form emails - and as a rule that server is not yet listed in the domain's SPF record. As long as the old site was running, this did not show, because the old server was listed there.
The order is therefore the reverse of intuition: first the new server is added to the SPF record and the DKIM key is published, then the switch happens, and only after that is the old server removed - with a few days in between, because DNS answers are cached. How a relaunch of a trade website runs overall is something we have described; the article on how a relaunch succeeds without losing visibility covers the search engine side of the same move.
- Before the switch: note the current SPF record, add the new server, generate and publish a DKIM key for the new environment.
- On switching day: test enquiry through the new form, read the headers, note the result. Only then is the migration complete.
- After the switch: remove the old server only once no delivery has run through it for several days.
- Check mailboxes and forwarding separately - they hang off the same domain but do not move with the website automatically.
- Read the DMARC reports for two to four weeks; they show which servers are actually sending in your name.
One point is regularly overlooked: keys age. The BSI technical guideline provides for DKIM key material to be renewed every six months, or for the deviation to be documented (BSI TR-03182). For a trade business that does not mean swapping keys yourself, but knowing who does it and when it last happened. That detail belongs in the same list as the access rights to domain and hosting.
What Belongs in Maintenance
A delivery path is not a component you fit once. It depends on records others can change, on software that gets updated, and on receiving servers whose evaluation rules shift. That is why the check belongs in a rhythm. In our maintenance and support for trade websites the delivery test is therefore a fixed item and not an extra on request.
| Check | Rhythm | What a finding means |
|---|---|---|
| Test enquiry from outside | monthly | If the mail is missing or sits in spam, the path is broken - read the headers first, change things afterwards |
| Headers for spf, dkim, dmarc | at every test | A fail names the layer the problem sits in and saves you the guesswork |
| SPF record, count and length | every six months | A second record or more than 10 query-triggering terms invalidate the check (RFC 7208) |
| DKIM key and its age | every six months | Renewal of the key material every six months is what the guideline provides for (BSI TR-03182) |
| Review DMARC reports | monthly | Unknown sending servers in the report point to misuse or to a forgotten service |
| Mailbox and rules | yearly | Rules that move messages are the most common reason for arrived, but not seen |
The effort involved is modest; the benefit is not. 85 percent of the businesses surveyed see a clear expectation of constant availability among their customers (Bitkom). An enquiry sitting in the spam folder is, from the enquirer's point of view, an unanswered enquiry - and in perception worse than no form at all, because an expectation was raised.
Two further articles fit the same work step. Anyone revising content right now should take in the tax relief for trade services on the website as well, because invoice details and contact routes have to match for it. And anyone wanting to settle who is responsible for such checks after handover will find the answer in the article on who maintains the site after handover. What gets set up from the start with a new website for trade businesses is thereby outlined: domain, mailbox, form path and the three records that make the path verifiable.
Sources for this article
Related Articles
Domain and hosting: who owns your trade website
Domain, DNS, hosting, website and email are five contracts with five logins. Who the domain holder is, which deadlines apply to a transfer, and what belongs on.
Refrigerants from 2027: update your heat pump page in time
New refrigerant deadlines apply to heat pumps up to 12 kW from 1 January 2027. What heating firms should change on service pages, FAQs and funding notes.
One website for several trades: structure and legal notice
Electrical, plumbing and painting firms on one site: a page per trade, requests routed to the right firm, the legal notice under § 5 DDG and GDPR roles.