SPF, DKIM and DMARC for form senders

Nobody sets out to learn email authentication. You get here because notifications stopped arriving, someone said the words SPF and DMARC, and the documentation you found was written for mail administrators running a mail platform rather than for someone whose site sends nine messages a week.

The useful framing is narrow. Three records exist to answer one question: did this message really come from the domain it claims? Everything else follows from that. You do not need to become a mail administrator, you need to know which of the three your form is failing and why.

SPF is a DNS record listing the servers permitted to send mail using your domain in the envelope sender. A receiver looks up the record and asks whether the connecting server appears in it.

It is a coarse check and it fails in two ordinary situations. If your site sends through a host, a relay, and a newsletter tool, all three must be listed, and people routinely add the newsletter and forget the website. And SPF validates the envelope sender rather than the From header a human sees, which means a message can pass SPF while displaying a completely different From address.

There is also a limit people hit without realising. Evaluating an SPF record is allowed a bounded number of DNS lookups, and every include for another service consumes some of that budget. Add enough tools and the record silently exceeds the limit, at which point it stops evaluating cleanly and everything it was meant to authorise starts failing at once. A record that grew one service at a time over four years is the usual victim.

That gap, and that limit, are why the other two records exist.

DKIM adds a cryptographic signature over parts of the message, using a private key held by the sending system. The public key is published in your DNS, so any receiver can verify the signature independently.

Where SPF asks whether the sending server is allowed, DKIM proves the message was signed by someone holding your key and has not been modified in transit. It survives forwarding better than SPF does, because a forwarded message keeps its signature while its connecting server changes.

For a website sending notifications, DKIM normally comes from whatever service actually transmits the mail. If you use a transactional provider, they issue the keys and you publish the records they give you.

DMARC is where it becomes useful rather than merely technical. It publishes what a receiver should do when a message claiming your domain fails the checks, and it adds the concept that changes everything for forms: alignment.

DMARC does not just want SPF or DKIM to pass. It wants the domain that passed to match the domain in the visible From header. A message can pass SPF for one domain, carry a valid DKIM signature for another, and still fail DMARC because neither lines up with what the reader sees. The specification is RFC 7489 if you want the exact mechanics.

Now the form-specific failure becomes obvious. A handler that sets From to the visitor's address is sending mail with a From domain it has no authority over.

SPF will be evaluated against your infrastructure, DKIM signed with your key if at all, and the visible From says a stranger's domain. Nothing aligns. If that domain publishes a strict DMARC policy, you have asked the receiver to reject or quarantine your own notification, and it will.

The correct shape is to send From your own domain, and set Reply-To to the visitor. You keep one-click replying and stop forging.

It is worth checking your own form before assuming this does not apply to you. Open the last notification it sent and look at the From line: if it shows the visitor's address rather than yours, this is your configuration, and it is one settings field away from being fixed on most contact form setups.

You do not need a specialist tool for the first check. Send a submission to a Gmail account, open the message, and choose Show original.

The header block reports each mechanism by name with a result beside it. Three passes means authentication is fine and any remaining problem is reputation or content. A DKIM failure with an SPF pass usually means a service is sending on your behalf without a signing key installed. A DMARC failure with both others passing is almost always alignment, which is to say a From header pointing somewhere your infrastructure has no claim to.

A DMARC record can name an address to receive aggregate reports. Those reports arrive as compressed XML, which is why an industry of dashboards exists, but the content is simple: for each sending source, how many messages passed and failed.

The value for a small sender is a list of everything sending as your domain, which is usually longer than expected. Website, invoicing tool, help desk, and a marketing platform somebody signed up for in 2023. Start in monitoring mode, read a few weeks of reports, then tighten the policy once the list contains nothing surprising.

Two things in those reports are worth knowing in advance so they do not alarm you. Forwarded mail routinely shows up as an SPF failure, because forwarding changes the connecting server while leaving your domain in place; a valid DKIM signature is what rescues those messages. And a trickle of failures from sources you do not recognise is normal background noise on the internet, not evidence that someone is targeting you. What matters is whether any source you depend on is failing, which is a much shorter list to check.

1. Inventory every service that sends as your domain.
2. Publish SPF covering all of them, and DKIM keys for each service that offers them.
3. Publish DMARC in monitoring mode, which asks for reports and requests no enforcement.
4. Read reports until nothing unexplained appears.
5. Only then move to quarantine, and later to reject.

The common disaster is doing step five first. A strict policy published before the inventory is complete will start discarding your own invoices.

Authentication makes it possible for a receiver to trust you. It does not oblige them to. Reputation, content and volume still decide placement, and a perfectly authenticated message can still land in spam.

This is the honest limit of the whole exercise, and the reason it is worth separating the notification from the record. Sending a form submission to a spreadsheet involves no mail transport, no DNS records and no filter. It either wrote a row or it reported a failure you can see in the delivery log. Getting DNS right makes the email better; not depending on the email makes the pipeline reliable.

The same reasoning applies to how you think about the rest of the submission path. What you want from any link in the chain is that success and failure look different from the outside, which is the standard the rest of the pipeline is held to as well.

Send from your own domain, always. Put the visitor in Reply-To. Publish SPF that lists every sender, DKIM for each service that supports it, and DMARC in monitoring mode until the picture is clear. Test with Show original after any change to hosting, DNS or mail provider, because those three are where working setups silently stop working.

And keep a record of submissions that does not travel by email, so the next time authentication breaks you lose visibility rather than leads. If you want the wider chain, the six links behind one notification covers what sits either side of these three records.

Do I need all three?

Will publishing DMARC break my existing mail?

My host says mail is configured. Is that enough?

What is alignment in one sentence?

Can I keep replying directly to the person who filled in the form?

Does this matter if I only send a handful of messages?

What breaks these records without anyone touching them?

Is there a way to avoid the whole subject?