Try two approaches. The notification sent to yourself often stays within your own email system and is treated leniently. The confirmation email sent to the visitor, on the other hand, goes to third-party providers such as Gmail or Outlook.com, where it is strictly screened. Therefore, always test using an external email address as well.
Category: Email & Delivery | Reading time: about 8 minutes | Author: Dietmar Engler
A contact form displays a message to the visitor saying, “Thank you for your message”—but nothing arrives in the company’s inbox. No one receives an error message, and no one notices the missing inquiry until the prospective customer has reached out elsewhere. The cause is usually not a faulty website, but rather missing or incorrectly configured email authentication. This article explains what SPF, DKIM, and DMARC verify, what Google, Yahoo, and Microsoft now require, and how you can get your domain up to standard step by step.
Table of Contents
Why Form-Based Emails Are a Special Case
You compose a normal email in Outlook or a webmail client. It passes through your provider’s mail server, which is set up for that purpose. A form-generated email works differently: The web server generates it itself and sends it on behalf of your domain, for example as website@ihre-domain.de. In other words, a server that has nothing to do with your email account claims to be acting on behalf of your domain.
From the recipient’s perspective, this looks exactly like a spoofed email. That’s why email providers now verify whether the sender is authorized to send the message. If the verification fails, the message ends up in the spam folder or is rejected. The visitor doesn’t notice anything, and the website doesn’t always detect it either.
A common mistake exacerbates the problem: Some forms enter the visitor’s address as the sender so that a direct reply is possible. Then your web server sends the email on behalf of gmail.com or a third-party company domain—which is not acceptable. The correct approach is: The sender should be an address from your own domain, and the visitor’s address should be listed in the “Reply-To” field.
SPF, DKIM, and DMARC: What Each Checks
All three methods are entries in your domain’s DNS—the same place where it’s specified which server your website points to. They complement each other.
SPF is a list: Which servers are authorized to send emails on behalf of this domain? The recipient compares the sending server against this list. The verification checks the technical sender address in the background (Return-Path), not the one you see in your email client.
DKIM is a digital signature. The sending server signs each email with a private key; the corresponding public key is stored in the DNS. The recipient can use this to verify that the email truly originated from an authorized system and was not altered in transit.
DMARC links both of these to the visible sender. The rule is called alignment: The domain the recipient sees in the “From” field must match the domain verified by SPF or DKIM. It is sufficient if one of the two methods passes verification and matches. In addition, with DMARC, you specify what should happen to emails that fail verification: nothing (p=none), the spam folder (p=quarantine), or rejection (p=reject). And you can have reports sent to you showing who is sending emails on your behalf.
| Procedure | Checks | Protects against | Common error |
|---|---|---|---|
| SPF | Is this server allowed to send mail for this domain? | Sending via third-party servers | Two SPF records or more than 10 DNS queries |
| DKIM | Is the signature valid and has the email been altered? | Forgery and tampering in transit | The email is signed with the service provider’s domain instead of your own |
| DMARC | Does the visible sender match SPF or DKIM? | Misuse of your domain as the sender | Stay permanently set to p=none; never read reports |
What Google, Yahoo, and Microsoft require
Since February 1, 2024, Google has enforced guidelines for email senders. These apply to emails sent to personal Gmail accounts (gmail.com and googlemail.com). The following applies to all senders: SPF or DKIM must be set up. Anyone sending more than 5,000 messages per day to such accounts needs SPF and DKIM, a DMARC record, and a sender that matches the SPF or DKIM. For promotional emails, one-click unsubscribe is also required. Yahoo essentially requires the same.
Microsoft followed suit in 2025. The requirements for Outlook.com apply to personal mailboxes at outlook.com, hotmail.com, and live.com and are aimed at domains that send more than 5,000 emails per day to these addresses: SPF and DKIM must be valid, and DMARC must be present with at least p=none and match the requirements. As of May 5, 2025, emails that do not meet these requirements will be rejected.
A contact form does not reach these volumes. Formally, therefore, the strict requirements apply to newsletter senders, not to your ten inquiries per week. There are two key takeaways, however. First, Google’s basic requirement applies to every sender. Second, these rules illustrate the standards that spam filters from all major providers use as a guide. A domain without proper authentication faces greater challenges everywhere, even with corporate email accounts.
How to Check Your Own Domain
The most reliable test is to send an actual email. Fill out your form and have the message sent to an email address outside your company, such as a personal Gmail account. Open the headers there: in Gmail via “View Original,” in Outlook via the message properties. Look for the line “Authentication-Results.” There you’ll find a result for each method:
spf=pass– the server was on the listdkim=passwithheader.d=your-domain.de– signed using your domaindmarc=pass– the visible sender matches
If it says “fail,” “softfail,” “none,” or “permerror,” you have the results in black and white.
The DNS records themselves can be queried using built-in tools. On Windows: `nslookup -type=TXT your-domain.de ` displays the SPF record; `nslookup -type=TXT _dmarc.your-domain.de ` displays the DMARC record. If the second query returns nothing, the domain has no DMARC.
The Recommended Order and Common Mistakes
If you set a strict DMARC policy right away, you might end up blocking your own emails if you’re unlucky. This sequence has proven effective:
- Record all senders: mailboxes, website, online store, newsletter tool, invoicing software, ticketing system, and copiers with “scan-to-email” functionality.
- Set up SPF and include each of these senders.
- Enable DKIM for each service using your own domain.
- PublishDMARC with
p=noneand forward the reports to your own email account. - Analyze the reports. Who is sending what? What passes, and what fails?
- Set
p=quarantineas soon as all legitimate senders pass verification. - Set the target to `
p=reject`.
That’s how we’ve set it up here as well. Our website doesn’t send form emails via the web host’s email function, but rather via SMTP through a transactional email service (Brevo). The emails are DKIM-signed with our domain, and the service is listed in our SPF record. DMARC runs with `p=none`, and the reports go to a dedicated mailbox. We only tighten the policy once the analysis shows that no senders are missing.
These are the errors we see most frequently:
- Two SPF records. Only one is allowed per domain. Two result in an error, and the SPF check fails. New senders should be added to the existing record.
- More than 10 DNS queries. Each
`include`generates a query, even nested ones. If the limit is exceeded, the result is also an error. - A missing sender. Usually the newsletter tool or the website itself.
- Copy errors in the DNS value. It’s happened to us too: A value was pasted along with formatting characters, rendering the record invalid. Quotation marks, backticks, or a line break are enough. Always check the published record directly on the nameserver after saving.
A quick note on BIMI, the process that displays your logo next to the email in the inbox. It’s optional and requires that DMARC is already set to “quarantine” or “reject.” Gmail also requires a certificate (VMC or CMC) for logo display, which incurs ongoing costs. BIMI doesn’t help with the delivery of your emails. It’s just a nice-to-have.
The Second Line of Defense: Save First, Then Send
Even a properly configured domain doesn’t protect against every potential failure. An email service might be down, a password might expire, or a mailbox might be full. That’s why email should never be the only place where a request exists.
We learned this the hard way. We had inquiries that weren’t saved anywhere because the email sending process failed as the first step, causing the form to abort afterward. Since then, saving to the CMS has taken place before the email is sent. Every inquiry is saved before any attempt is even made to send an email. If the email fails to send, the inquiry is still there.
Ask your agency two things: Are form submissions saved in the CMS? And in what order do saving and sending occur? For TYPO3 websites, we set this up as part of our maintenance and support services. Keep data protection in mind: Stored requests require a retention period and must be included in the privacy policy.
Conclusion
Lost form emails are a silent problem. There’s no error message—just fewer inquiries. The solution is straightforward: a complete SPF record, DKIM with your own domain, and DMARC with reports and a plan for tightening security. In addition, use a form that first stores each request and then sends it. With a test email and a quick look at the headers, you’ll know where you stand in ten minutes. If the DNS records are managed by your provider and you’re unsure who’s authorized to make changes, we can also assist with domains and hosting.
Delivery Check
We'll review your website's forms: Are emails being delivered? Do they pass SPF, DKIM, and DMARC validation? And is each request also being logged? You'll receive a brief report with specific steps to take.
Frequently Asked Questions
-
I'm still receiving my form emails—do I need to do anything anyway?
-
Isn't SPF alone enough?
No. SPF is lost as soon as an email is forwarded, because another server then delivers it. The DKIM signature remains intact during a simple forwarding. Furthermore, SPF only verifies the technical sender address, not the visible one. Only DMARC establishes the connection to the sender that the recipient sees.
-
What do the DMARC reports say, and who is supposed to read them?
The reports are sent as XML files by the receiving providers. They list which servers delivered emails with your domain as the sender and whether SPF and DKIM validation was successful. Email content is not included. The files can be read using an analysis tool. It’s important to have a separate mailbox for this, as reports arrive daily.
-
How long should DMARC be set to p=none?
Continue this process until the reports show no legitimate senders failing the check for several weeks. Make sure that even infrequent senders are included in this period, such as the monthly billing cycle. Setting a fixed evaluation date in the calendar prevents
“p=none”from becoming a permanent state. In this state, DMARC does not protect your domain from abuse. -
Why not just send it using the web host's email feature?
This can work if the hosting provider is listed in the SPF record and signs with your domain. On shared servers, however, many customers send emails from the same IP address, and their reputation affects your delivery rates. Sending via SMTP using a corporate email account or a transactional email service is easier to control and provides logs that allow you to track every email sent.
Automatisch übersetzt. Ohne Gewähr für Vollständigkeit und Richtigkeit.