Domain and email: the technology under the website

What this is about

Under every website lies a domain, and on that domain hang records that have nothing to do with the website — but a great deal to do with whether your emails arrive and whether someone can write in your name.

Three DNS records are central here: SPF defines which servers may send mail for your domain. DKIM signs outgoing mail cryptographically. DMARC connects the two and tells recipients what should happen to mail that fails.

On top of that comes the domain itself: when does it expire? Is it locked against transfer? And is more than one name server entered?

Why it matters

Without these records anyone can send an email that looks as if it came from your address. That is the basis of most fraud emails in business — an invoice with a changed account number, supposedly from you. And in the other direction, your own mail lands in spam, because the recipient cannot check whether it is genuine.

The most common finding in practice is a DMARC record with p=none. It looks configured and prevents nothing. It only tells recipients: observe and report. Without someone actually reading the reports, that is pure scenery.

The route there is still right: first p=none, then evaluate the reports for four to twelve weeks, fix every legitimate misconfiguration, then set p=quarantine and finally p=reject. The mistake is not starting at p=none, but getting stuck there.

One error you cannot see in the SPF record: its evaluation may use at most ten DNS lookups — that is what RFC 7208 prescribes. Every include counts, and recursively: include:_spf.google.com alone triggers three further lookups internally. If the limit is exceeded, the check returns a permanent error, and DMARC treats that like a hard fail. That means: a carefully maintained domain is then protected exactly as well as one without a record. The record reads perfectly fine, and the limit is exceeded by adding one more service to an already full record.

Two side remarks for context:

DKIM cannot be checked from outside. The key sits under a name nobody can guess. If a report says nothing about it, that means “not checked” — not “missing”.

And for German and Austrian domains: DENIC and nic.at publish no expiry date. For most client domains the question of expiry cannot be answered from outside at all.

There is also a range of further mechanisms — DANE, MTA-STS, TLS reporting — that like to show up red in checks. They depend on DNSSEC and on records the mail provider has to publish. Those are properties of the hosting, not omissions of the website. Reporting them as errors would have an unpleasant side effect: a category that is red in every report is one the reader learns to skip — and takes the real findings next to it along.

How to check it yourself

The simplest way goes through MXToolbox (mxtoolbox.com). Enter your domain and run the checks for SPF and DMARC one after the other. For SPF the tool directly shows the number of DNS lookups used — exactly the number that has to stay under ten.

For DMARC, look at the p= value: if it says none, the record is there but has no effect.

On the command line the same is quicker:

dig +short txt deinedomain.de
dig +short txt _dmarc.deinedomain.de

For the practical test: send yourself a mail from your business address to a Gmail address. There, open “Show original” in the details. At the very top it says whether SPF, DKIM and DMARC passed.

And for the name servers: if only one is entered there, the domain has no failover.

What to do if it is missing

Start with DKIM, not with SPF. DKIM survives forwarding — SPF does not. When a mail runs through a mailing list or a forward, the sending IP changes, and SPF fails. The DKIM signature stays intact. For a later move to p=reject, DKIM is therefore the more reliable path.

Set a DMARC record with p=none and a reporting address, read the reports, and then work your way up. Do not forget sp= — without it, subdomains inherit the main policy, and an explicit rule closes the gap through which someone could forge rechnung.deinedomain.de.

If your SPF record is close to the limit of ten: throw out the services that do not need to be in it at all. Many marketing providers send through a sender domain of their own and need no record with you — the line is then a wasted lookup. The next step would be to put newsletters and transactional mail on subdomains of their own; each gets its own budget of ten.

For the reports: Postmark offers a free evaluation. If data residency matters, URIports (Netherlands) or dmarcian-EU (Brussels) are the more fitting addresses.

And the domain itself: switch on the transfer lock, automate the renewal, enter at least two name servers. That is three clicks at the registrar and the cheapest failover there is.

Sources

• SPF under RFC 7208 with a hard limit of 10 DNS lookups per evaluation; include, a, mx, ptr, exists and redirect count, ip4, ip6 and all do not; nested includes count recursively, include:_spf.google.com triggers three further lookups internally; exceeding it returns PermError, which DMARC treats like a hard SPF fail; SPF breaks with forwarding, DKIM survives it; remove SaaS entries that are not needed; splitting across subdomains gives each sending stream its own budget; MXToolbox shows the lookup count -- @ctx:atlas-services-email-deliverability-spf@1
• DMARC as a DNS TXT record under _dmarc.; p=none observing only, p=quarantine, p=reject; recommended rollout path p=none for 4 to 12 weeks with evaluation of the aggregate reports, then tightening; p=none without evaluating the rua reports has no effect; sp= is often missing and leaves subdomains open as an impersonation surface; DKIM as the primary path before moving to p=reject because of forwarding; Postmark free, URIports (NL) and dmarcian-EU (Brussels) for data residency; ruf reports are privacy-sensitive -- @ctx:atlas-services-email-deliverability-dmarc@1
• DENIC and nic.at publish no expiry date and run no RDAP, which is why this detail cannot be determined for most German client domains; DKIM sits at a selector that cannot be guessed and is kept as not checked rather than missing; DANE, MTA-STS and TLS reporting depend on DNSSEC and on the mail provider's records and are properties of the hosting; a category that is red in every report is one the reader learns to skip, taking the real findings next to it along; name server redundancy and transfer lock as checks -- @ctx:projects-tools-checky-workbench-docs-tech-specs-probe-catalog-trust@7