Guide - updated November 2026

Email authentication for form notifications

SPF, DKIM and DMARC are DNS records that let a receiving mail server check whether the email your website form sends is allowed to use your domain. Set up SPF first, add DKIM second, and turn on DMARC in monitoring mode last, after both are passing.

This guide is for the notification email a form sends to you or your team, not for marketing campaigns. It covers what each record does, a safe setup order, the alignment mistakes that cause failures, and how to verify the published records with the free SPF checker, DKIM checker and DMARC checker. For a side-by-side view of what each check can and cannot verify, use the email authentication checker hub for form notifications.

Short answer. Publish an SPF record that includes the server sending your form notifications, sign those messages with DKIM on the same domain, and add a DMARC record that starts at p=none with reporting. Then check alignment, read the reports, and tighten the policy. Authentication helps receivers trust the message, but it does not guarantee inbox placement.

What SPF, DKIM and DMARC each do

The three records work together, but each answers a different question. SPF asks which servers may send for the domain. DKIM asks whether the message was signed by a key the domain publishes. DMARC asks whether either check matched the From domain, and what the receiver should do when it did not.

Record	What it does	Where it lives	What it checks for form email
SPF	Lists the servers and services allowed to send mail for your domain.	A TXT record on the domain root.	Whether the sending server for your form notification is on the allowed list.
DKIM	Adds a cryptographic signature that receivers verify against a public key.	A TXT record at selector._domainkey.yourdomain.com.	Whether the message was signed by your provider and not altered in transit.
DMARC	Ties SPF and DKIM to the From domain and sets a policy plus reporting address.	A TXT record at _dmarc.yourdomain.com.	Whether an authenticated domain aligns with the From domain, and what to do if not.

For form notifications, the From address is usually on your own domain, for example forms@yourdomain.com. The visitor's address belongs in Reply-To, not From. That keeps the authenticated domain under your control and lets you reply to the visitor without spoofing their domain.

A safe setup sequence

Change one layer at a time and verify it before moving on. Doing all three at once makes it hard to tell which record caused a new failure.

Confirm the sending domain and server. Read the From address on a real form notification and note the domain after the @ sign. Then find which service sends it: your form backend, your email provider, or your own SMTP server.
Publish or update SPF. Add the sending service to the domain's SPF record. Keep one SPF record per domain, stay within the 10 DNS lookup limit, and use ~all while you test before moving to -all.
Turn on DKIM at the sender. Enable signing in your email provider or form backend, then publish the selector record it gives you. Use a key length of at least 2048 bits where the provider supports it.
Add DMARC in monitoring mode. Start with p=none and a reporting address you actually read. This shows which senders pass alignment without blocking legitimate form mail.
Verify each record. Run the SPF checker, DKIM checker and DMARC checker against the From domain. For DKIM, use the selector from the message header.
Send a real test notification. Submit your form and inspect the received message headers. Confirm SPF, DKIM and DMARC all pass and that the authenticated domain matches the From domain.
Tighten DMARC slowly. After the reports show your legitimate senders passing, move to p=quarantine, then p=reject. Keep monitoring so a new sending service does not get blocked silently.

Common alignment mistakes

Most "SPF and DKIM pass but DMARC fails" cases come down to alignment, not a broken record. These are the mistakes worth checking first.

From domain does not match the authenticated domain. A form backend may send From your domain while signing or authorizing a shared sending domain. DMARC compares the two, so the domains must align.
Two SPF records on one domain. SPF allows only one TXT record starting with v=spf1. A second record makes the result ambiguous, so merge the mechanisms into one record.
Too many DNS lookups. SPF has a 10-lookup limit. Nested include: mechanisms can push a record over the limit and produce a permerror even though the record looks valid.
Wrong DKIM selector. The selector in DNS must match the s= value in the message signature. A missing or renamed selector makes DKIM fail while the key itself is fine.
Forwarding breaks SPF. A forwarded message can fail SPF because the forwarding server is not in your record. DKIM usually survives forwarding, which is why both matter.
DMARC enforced too early. Jumping straight to p=reject before reports confirm every legitimate sender can block real form notifications.

How to verify the records

The checkers read public DNS, so they show what is published, not what is in a recipient's inbox. Use them to confirm the records exist and are well formed, then confirm delivery with a real test message.

SPF checker - shows the TXT record, explains each mechanism, and estimates the DNS lookup count against the 10-lookup limit.
DKIM checker - takes a domain and selector, shows the published key, and flags revoked or short keys.
DMARC checker - shows the policy and tags, and flags p=none, partial pct or missing reporting.

If a form submits but the notification never arrives, work through the contact form deliverability diagnostic in order: recipient address, spam or quarantine folder, sender configuration, then the form backend log. To connect a form to an email destination in the first place, see HTML form to email, and for endpoint and payload details read the splitforms docs.

What the checks cannot tell you. A passing SPF, DKIM and DMARC result does not guarantee inbox placement. Sender reputation, content, complaint rates, recipient filters and sending volume all affect where a message lands. Authentication removes one common reason for rejection; it is not a delivery promise.

Frequently asked questions

What is email authentication for form notifications?

Email authentication is the set of DNS records that let a receiving mail server check whether a message really came from your domain. For form notifications, the relevant records are SPF, DKIM and DMARC. They are published on the domain in the From address, which is usually your own domain rather than the visitor's address.

Which record should I set up first: SPF, DKIM or DMARC?

Start with SPF, then DKIM, then DMARC. SPF lists the servers allowed to send mail for your domain. DKIM adds a cryptographic signature that survives forwarding better than SPF. DMARC ties both to the From domain and tells receivers what to do when they fail, so it belongs last, after the other two are working.

Does passing SPF, DKIM and DMARC guarantee inbox placement?

No. Authentication proves the message is allowed to use your domain and has not been altered in transit. Inbox placement also depends on sender reputation, message content, recipient filters, complaint rates and sending volume. Treat the DNS checks as evidence that the sender configuration is correct, not as a promise that every message lands in the inbox.

Why does DMARC fail when SPF and DKIM both pass?

DMARC requires alignment, not just a pass. The domain that passes SPF or DKIM must match the domain in the From address. A common cause is a form backend that sends From your domain but authenticates a shared sending domain, or a DKIM selector that signs a different domain. Check the From domain and the authenticated domain side by side.

How do I find the DKIM selector for my form email?

Open a test notification and look at its DKIM-Signature header. The selector is the value after s=, for example s=selector1. Your email provider or form backend usually documents the selector it uses. Enter the domain and that selector in the DKIM checker to see the published public key.

Should I start DMARC with p=none?

Yes, for most sites. A p=none policy asks receivers to report on messages that fail without blocking them, so you can see which senders are misaligned before you enforce. Move to p=quarantine and then p=reject only after the reports show that your legitimate form notifications pass alignment.

Next: run the contact form deliverability diagnostic, set up form to email, or read the docs.