Landing page emails landing in spam: what SPF, DKIM and DMARC actually change

A visitor fills out a landing page's form, clicks "submit", sees a thank-you message appear — and walks away assuming everything went through. Behind the scenes, two emails are supposed to fire at that exact moment: a notification for the sales team, and a confirmation for the visitor. The problem shows up in neither the form nor the sending tool's logs, which proudly display a "sent" status: the email did leave the server, but it never reached the intended inbox. It's sitting in a spam folder, or was flatly rejected by the receiving server. The lead thinks they were ignored. The sales team has no idea a lead exists. Nobody finds out there's a problem until an unhappy customer mentions it — or, more often, never.

Two emails, two invisible points of failure

A landing page that captures leads rests a good part of its value on two automatic emails nobody reviews before they're sent. The first is the internal notification: "new lead received", sent to the sales inbox or the CRM. If it lands in spam, the consequence ties directly into what our guide on the ideal delay for calling back a lead covers: the clock is running, but nobody knows it. The second is the confirmation email sent to the visitor — a meeting reminder, a lead magnet download link, access to a free trial. If that one lands in spam, the prospect who just actively took action often concludes the business isn't responding, and drops off before the first real exchange happens. Both failures are silent: nothing in the landing page interface or the sending tool's dashboard flags either one.

SPF, DKIM, DMARC: what these three acronyms actually check

Mail servers (Gmail, Outlook, corporate mail servers) no longer just filter on an email's content: before they even open it, they check whether the domain claiming to send it is actually authorized to. SPF (Sender Policy Framework) is a DNS record listing which servers are allowed to send email on behalf of a given domain — without it, any server can claim to write "on behalf of" that domain. DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every email, proving it wasn't altered in transit and genuinely comes from the domain it claims to. DMARC (Domain-based Message Authentication) ties the two together: it tells the receiving server what to do when SPF or DKIM fail — ignore it, quarantine it as spam, or reject it outright — and sends back a report on spoofing attempts. Without all three correctly published in the domain's DNS records, a perfectly legitimate email looks, to a modern spam filter, almost indistinguishable from a spoofing attempt.

A more common problem than it seems

This isn't a theoretical worry reserved for large companies. A large-scale measurement study by Sourena Maroofi, Maciej Korczyński and Andrzej Duda, published in 2021 in IEEE Transactions on Network and Service Management (available on Google Scholar), scanned the SPF and DMARC records of more than 236 million domains worldwide: the authors find that a large share of those domains, including high-profile ones, publish SPF or DMARC records that are missing, incomplete, or misconfigured — leaving the door open both to spoofing and to the silent failure of a perfectly legitimate email. Another study, by Hang Hu and Gang Wang (Virginia Tech), presented in 2018 at the USENIX Security Symposium (available on Google Scholar), tested 35 popular mail providers under real conditions: the authors show how a poorly authenticated email is handled varies sharply from one provider to the next, and that even when a warning is shown to the user, it gets ignored the vast majority of the time. In other words: you can't rely on a trustworthy default configuration, nor on the recipient's vigilance to catch the problem after the fact — the one variable you actually control is how the sending domain is configured, upstream.

Where it actually breaks on a landing page

• A hosted third-party service (Formspree, Zapier, Make) often sends the notification from its own generic domain but shows your address as the "reply-to": some spam filters treat that mismatch as suspicious if the service's domain isn't properly DMARC-aligned.
• An email marketing tool (Brevo, Mailchimp, ActiveCampaign) asks you to verify a dedicated sending subdomain — an optional step in the interface, so it's often skipped, which lets emails go out without DKIM or proper SPF alignment on the brand's own domain.
• A native webhook coded into an API route and connected to a transactional service (Resend, Postmark, SendGrid) is the technically most robust method, but it fails the same way if the DNS records the service provides are never added to the domain's zone — see our guide on connecting a form to a CRM or email tool.
• A brand-new domain bought for the campaign has, by definition, no sending reputation built up yet: even perfectly configured, it takes several weeks to earn the trust of major providers — worth planning for before a launch, not after.

Setting up SPF, DKIM and DMARC without losing a day to it

1. Identify every service that actually sends an email on the domain's behalf — email tool, transactional service, CRM, sometimes several at once — before touching any DNS record.
2. Add the SPF record each service provides into a single TXT record on the domain (a domain can only have one valid SPF record, which must list every authorized sender).
3. Enable DKIM in each service and add the CNAME or TXT records it provides — the step most often skipped, even though it's what proves each individual email's authenticity.
4. Publish a phased DMARC policy: start with p=none to observe the reports without blocking anything, then move to p=quarantine once every legitimate source is identified.
5. Test before going live with a free tool like mail-tester.com or MXToolbox's DMARC checker, sending a real test email from the landing page's own form — not one sent by hand from a regular mail client.
6. Re-check after every new tool added: adding a new email service without updating the SPF record silently breaks authentication for all the others.

The safety net that protects you even when an email is lost

No configuration is 100% foolproof: it's worth building in a safety net rather than depending solely on deliverability. Storing every submission server-side before even attempting to send the email — as covered in our guide on connecting a form to a CRM — guarantees a lead stays retrievable even if its notification vanished en route. On the visitor's side, a clear thank-you page that shows the next steps right on screen, rather than resting everything on the confirmation email, keeps a deliverability hiccup from turning into a lost prospect. And for a newsletter sign-up rather than a plain contact form, our comparison of double opt-in versus single opt-in is a reminder that a confirmation email that never arrives simply blocks the sign-up outright — deliverability becomes a conversion problem there, not just a communication one.

Where this plays out concretely on the LanderKit templates

On the 10 LanderKit templates (€89 each, €229 for the full pack), the form ships deliberately unwired — see our technical go-live checklist — precisely so the buyer chooses the sending service and its domain. On the SaaS waitlist template (demo), the internal notification is the critical one: every sign-up missed in real time delays reading demand ahead of launch. On the restaurant reservation template (demo), it's the opposite: the confirmation sent to the customer matters most, since a booking with no confirmation received often pushes the customer to book elsewhere just to be safe. Either way, the sending domain's DNS setup deserves the same care as the choice of service itself.