Email Deliverability: SPF, DKIM and DMARC Explained

For a small business the contact form is often the most important sales channel on the website. It replaces the phone call, it arrives outside opening hours, and it delivers the enquiry in writing – there is a reason the contact page is one of the five most important pages of a website. That is exactly why it weighs so heavily when the message fails to reach the mailbox. The business waits for enquiries that were made long ago. The prospective customer waits for an answer that cannot come. And because no error message appears on either side, nobody goes looking for the cause.

The technical reason is simple: receiving systems now check whether a message really comes from the domain shown in the sender address. If that check fails, or if it is missing entirely, the mail ends up in the spam folder or is refused during the delivery attempt. The German Federal Office for Information Security translated this expectation into verifiable requirements for email service providers in Technical Guideline TR-03182 on email authentication, published as version 1.0 on 15 February 2024 (BSI). Its stated goal is to make authentic email communication more comparable and more widespread (BSI).

The direction of travel is clear, and it is getting stricter. In May 2026 the original DMARC specification from 2015 was replaced by three new documents on the standards track (IETF RFC 9989) – what used to be an informational proposal is now a proposed internet standard. Anyone sending in the name of a domain without being able to prove it has a hard time with the large mailbox providers. For a medical practice, a law firm or a trades business this means deliverability is not a side issue of IT but part of being reachable.

SPF stands for Sender Policy Framework. In your domain's DNS there is a text record starting with v=spf1 that lists which servers are allowed to send – by IP address, by referencing other records, or via the servers named in the MX record. At the end comes the statement about how everything else should be treated. The receiving server looks up this record and compares it with the address the connection actually comes from.

Two rules from the specification are the most common stumbling blocks. First, a domain must not have more than one SPF record; with two the result is no longer unambiguous and the check fails (IETF RFC 7208). Second, there is a lookup budget: at most 10 DNS lookups may be triggered during an evaluation, and the number of void lookups should be limited to 2 (IETF RFC 7208). Every reference to another service consumes at least one of those lookups. Anyone who adds host, newsletter tool, booking system and invoicing software one after another exhausts the budget faster than expected – and after that the check fails for every message, including the ones from the contact form.

SPF and DKIM each verify one technical relationship, but not what the recipient actually sees: the sender address in the message header. DMARC closes exactly that gap. The record sits in DNS under the name _dmarc in front of your domain and requires at least one of the two checks to pass and to match the visible sender domain. This match is called alignment; by default it is evaluated in relaxed mode, so subdomains of the same organisational domain fit together (IETF RFC 9989). Only then comes the actual decision: what should happen when nothing matches?

The second, often overlooked part of DMARC is the feedback. Via an address in the record you receive aggregate reports showing, per sending source, how many messages were processed with which outcome – including SPF and DKIM results, alignment and the disposition actually applied (IETF RFC 9990). In addition there are failure reports about individual messages (IETF RFC 9991). These reports are the one reliable way to notice that part of your mail is getting lost before customers start complaining.

Working on existing websites, the same patterns keep appearing. They have nothing to do with carelessness and everything to do with the fact that website, mailbox and DNS often come from different sources and nobody looks at the chain as a whole.

The first point is the most important and at the same time the easiest to fix. A contact form should send the notification from an address on your own domain, for example form@yourcompany.com, and put the visitor's address into the Reply-To field. The message then passes every check, and replying still goes to the enquirer with one click. This is not a comfort detail but the difference between an enquiry in the inbox and an enquiry that does not make it into the mailbox at all. How form data should be handled in a privacy-compliant way is covered in our article on the GDPR basics for small websites.

For a small business the effort is manageable. The following list describes what should be in place after setup – regardless of who looks after the website.

For clarity: this article is exclusively about deliverability and the technical records behind it – not about choosing your preferred address or the legal duties attached to the domain itself. Which address suits your business and why an own domain shapes the first impression is covered in the article on your own domain and a business email address. If you are also interested in the duties around registrant data, you will find that context in the piece on the obligations attached to .de domains and registrant data.