Kurz und einfach erklärt
Manchmal kommt eine Anfrage aus dem Formular nicht an. Sie landet im Spam. Das ist der Ordner für Werbemüll.
Die Dankeseite sagt nur, dass die Website die Anfrage hat. Ob die Mail ankommt, sagt sie nicht.
Die Adresse des Kunden gehört ins Feld für die Antwort. Ins Feld für den Absender gehört sie nicht.
Einige Einträge bei Ihrer Domain zeigen, dass die Mail echt ist. Die Domain ist die Adresse Ihrer Website.
Testen Sie das Formular ab und zu mit einer fremden Adresse. Das gehört in die Wartung. Wir helfen Ihnen dabei.
Ein Kontaktformular meldet nach dem Absenden „Vielen Dank für Ihre Anfrage“. Diese Meldung besagt, dass die Website die Eingaben entgegengenommen hat. Über den Verbleib der Nachricht sagt sie nichts. Alle befragten Handwerksbetriebe geben an, E-Mail zu nutzen (Bitkom) - der Kanal ist also überall im Einsatz, und ausgerechnet ihn trifft der stillste Defekt einer Website. Zur Einordnung, wie scharf auf der Empfangsseite sortiert wird: In den Regierungsnetzen des Bundes gingen zuletzt durchschnittlich rund 712.000 E-Mails täglich ein, das Monatsmittel der täglichen Spam-Quoten lag bei 51 Prozent (BSI). Rund die Hälfte des Aufkommens wird also aussortiert, bevor ein Mensch sie sieht. Wer möchte, dass die eigene Formularmail auf der richtigen Seite dieser Trennung landet, muss ihr ansehen können, dass sie echt ist.
Das Wichtigste in Kürze
- Die Dankeseite beweist nur, dass die Website das Formular angenommen hat. Ob die Mail zugestellt wurde, steht in den Kopfzeilen der Nachricht und im Protokoll des Mailservers - nicht auf der Seite.
- Die Kundenadresse gehört in das Feld „Antwort an“, nicht in das Absenderfeld. Sendet die Website unter fremder Domain, scheitern die Prüfungen planmäßig, weil sie dann die Regeln der fremden Domain heranziehen (RFC 5322, RFC 9989).
- SPF, DKIM und DMARC sind drei DNS-Einträge Ihrer Domain: Ein SPF-Eintrag darf höchstens 10 DNS-Abfragen auslösen (RFC 7208), DKIM-Schlüssel brauchen mindestens 1024 Bit und sollen 2048 Bit haben (RFC 8301), DMARC verlangt Ausrichtung auf die sichtbare Absenderdomain (RFC 9989).
- Der Selbsttest dauert zehn Minuten: Testanfrage an eine betriebsfremde Adresse, Kopfzeilen öffnen, die Zeile Authentication-Results lesen, Spamordner beider Postfächer prüfen. Ein Test an die eigene Adresse beweist wenig.
- Die Technische Richtlinie des BSI zur E-Mail-Authentifizierung erwartet als Richtlinie quarantine oder reject und sieht vor, DKIM-Schlüssel alle sechs Monate zu erneuern (BSI TR-03182). Beides gehört in einen Wartungsrhythmus, nicht in eine einmalige Einrichtung.
Die Dankeseite ist kein Zustellnachweis
Ein Formular besteht aus zwei Vorgängen, die technisch wenig miteinander zu tun haben. Der erste: Der Browser schickt die Eingaben an die Website, die Website nimmt sie an und antwortet mit einer Bestätigungsseite. Der zweite: Ein Programm auf dem Webserver übergibt eine E-Mail an einen Mailserver, damit die Anfrage im Postfach des Betriebs ankommt. Der erste Vorgang gelingt weitgehend unabhängig davon, wie der zweite ausgeht. Deshalb kann eine Website monatelang „Vielen Dank“ sagen, während im Büro nichts eingeht.
Der zweite Vorgang hat mehrere Stellen, an denen er scheitern kann, ohne dass es jemandem auffällt. Das Programm auf dem Webserver kann die Übergabe gar nicht erst versuchen, weil eine Zugangsangabe fehlt. Der Mailserver kann die Nachricht annehmen und später zurückweisen - die Fehlermeldung geht dann an eine Absenderadresse, die im Betrieb keiner liest. Der Empfangsserver kann die Nachricht annehmen und in den Spamordner legen. Und der Spamordner eines Sammelpostfachs wird in vielen Betrieben seltener geöffnet als der Sicherungskasten im Keller.
Der Unterschied zwischen beiden Vorgängen ist der Grund, warum ein Formular so schwer zu beurteilen ist. Wer die Felder eines Anfrageformulars gestaltet, denkt an Länge, Pflichtangaben und Verständlichkeit - dazu haben wir aufgeschrieben, wie viele Felder ein Anfrageformular im Handwerk verträgt. Der Weg der Nachricht danach ist eine eigene Baustelle, und sie wird erfahrungsgemäß erst dann angesehen, wenn jemand von außen sagt: Ich habe Ihnen zweimal geschrieben.
| Station | Was dort schiefgehen kann | Woran Sie es erkennen |
|---|---|---|
| Website nimmt an | Das Formular speichert die Anfrage, versendet sie aber nicht | Im Formularprotokoll stehen Einträge, im Postfach fehlen sie |
| Webserver übergibt | Die Übergabe an den Mailserver scheitert, die Meldung landet im Serverprotokoll | Das Fehlerprotokoll des Webservers nennt abgelehnte Zustellversuche |
| Absenderprüfung | Der versendende Server ist für die Absenderdomain nicht autorisiert | Die Kopfzeile Authentication-Results der Testmail zeigt spf=fail oder dmarc=fail |
| Empfangsserver bewertet | Die Nachricht wird angenommen und in den Spamordner einsortiert | Die Testmail liegt im Spamordner, nicht im Posteingang |
| Postfach im Betrieb | Eine Regel verschiebt die Nachricht in einen Ordner, den keiner öffnet | Die Suche über alle Ordner findet die Mail, der Posteingang nicht |
Die dritte und die vierte Zeile sind der Kern dieses Beitrags. Sie hängen daran, ob eine empfangende Stelle nachvollziehen kann, dass die Nachricht wirklich von Ihrer Domain stammt. Genau dafür gibt es drei Einträge im DNS - und drei Adressen in der Nachricht, die regelmäßig verwechselt werden.
Drei Adressen, die nicht dasselbe sind
Eine E-Mail trägt mehr als eine Adresse. Für das Formular sind drei davon wichtig. Der Umschlagabsender wird beim Einliefern zwischen den Servern ausgehandelt; an ihn gehen Unzustellbarkeitsmeldungen. Das Feld „Von“ ist das, was der Empfänger in seinem Programm sieht. Das Feld „Antwort an“ bestimmt, welche Adresse eingesetzt wird, wenn jemand auf Antworten klickt. Viele Formularerweiterungen setzen alle drei auf die Adresse, die der Kunde eingetragen hat - gut gemeint, weil sich dann bequem antworten lässt, und genau das ist der Defekt.
In all cases, the "From:" field SHOULD NOT contain any mailbox that does not belong to the author(s) of the message.
Steht die Adresse des Kunden im Feld „Von“, dann behauptet Ihre Website, im Namen einer fremden Domain zu senden. Der Empfangsserver prüft daraufhin die Regeln jener fremden Domain - und Ihr Server steht dort nicht als berechtigter Absender. Das Ergebnis ist ein planmäßiges Scheitern der Prüfung, kein Zufall und kein Filterfehler. Je strenger die fremde Domain ihre Richtlinie gesetzt hat, desto härter fällt die Bewertung aus.
Der Ausweg ist eine Zeile Konfiguration. Als Absender steht eine feste Adresse Ihrer eigenen Domain, etwa formular@musterbetrieb.invalid. Die Adresse des Kunden wandert in das Feld „Antwort an“, das im Standard genau dafür vorgesehen ist: Es benennt die Adresse, an die der Verfasser Antworten erbeten hat (RFC 5322). Der Betrieb klickt weiterhin auf Antworten und schreibt der anfragenden Person, die Prüfung der Absenderdomain kann trotzdem gelingen, weil sie sich auf Ihre eigene Domain bezieht.
Die Faustregel für das Formular
SPF, DKIM und DMARC: die drei Nachweise
Die drei Verfahren beantworten drei verschiedene Fragen, und sie tun das über Einträge im DNS Ihrer Domain - an derselben Stelle also, an der auch steht, wo die Website liegt. SPF beantwortet die erste Frage: Welche Server dürfen im Namen dieser Domain einliefern? Der Eintrag ist im Kern eine Liste, und er wird als TXT-Eintrag veröffentlicht (RFC 7208).
Zwei Grenzen des Verfahrens fallen im Alltag auf. Erstens darf eine Domain nur einen einzigen Eintrag dieser Art führen; mehrere Einträge, die zur Auswahl stünden, sind unzulässig (RFC 7208). Wer beim Anbieterwechsel einen zweiten Eintrag anlegt und den alten stehen lässt, macht die Prüfung damit ungültig. Zweitens dürfen in einem Eintrag höchstens 10 Angaben eine DNS-Abfrage auslösen: „SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS“ (RFC 7208). Gezählt wird dabei nicht jede einzelne DNS-Abfrage, sondern jeder abfrageauslösende Mechanismus und Modifikator im Eintrag; jeder eingebundene Dienst verbraucht davon mindestens einen. Ein über Jahre gewachsener Eintrag reißt diese Grenze irgendwann, und ab dann scheitert die Prüfung mit permerror - auch für Nachrichten, die vorher durchgingen.
DKIM beantwortet die zweite Frage: Ist die Nachricht unterwegs unverändert geblieben, und stammt sie aus einem System, das den Schlüssel dieser Domain besitzt? Dazu unterschreibt der sendende Server jede Nachricht, der öffentliche Teil des Schlüssels liegt im DNS. Für die Länge gilt eine Untergrenze: Unterzeichner müssen für alle Schlüssel RSA mit mindestens 1024 Bit verwenden und sollen mindestens 2048 Bit einsetzen (RFC 8301, der die Vorgabe aus RFC 6376 aktualisiert). Die Technische Richtlinie des BSI zur E-Mail-Authentifizierung bezieht dabei ausdrücklich Nachrichten ein, die ein Kontaktformular auf einer Website erzeugt: Signiert werden soll jede Nachricht im Namen der sendenden Domain, unabhängig davon, ob ein Mailprogramm oder eben ein Formular sie erzeugt hat (BSI TR-03182).
DMARC beantwortet die dritte Frage: Was soll geschehen, wenn die ersten beiden Prüfungen nicht zur sichtbaren Absenderdomain passen? Der Fachbegriff dafür ist die Ausrichtung. Der geltende Standard RFC 9989, der RFC 7489 im Mai 2026 abgelöst hat, verlangt sie zwischen der Domain im sichtbaren Absenderfeld (Author Domain) und der Domain, die SPF oder DKIM bestätigt hat (Authenticated Identifier).
DMARC describes the concept of alignment between the Author Domain (Section 3.2.2) and an Authenticated Identifier (Section 3.2.1) and requires such Identifier Alignment between the two for a message to achieve a DMARC pass. DMARC defines two states for alignment.
Damit schließt sich der Kreis zum Formular: Solange im Feld „Von“ die Adresse des Kunden steht, kann die Ausrichtung nicht gelingen, selbst wenn SPF und DKIM für Ihre Domain sauber eingerichtet sind. Die Richtlinie kennt drei Stufen - beobachten, in Quarantäne stellen, ablehnen. Das BSI erwartet in seiner Technischen Richtlinie Quarantäne oder Ablehnung, weil nur diese beiden die Empfänger schützen (BSI TR-03182). Wer anfängt, beginnt in der Beobachtungsstufe und wertet die Berichte aus; ein Berichtszeitraum umfasst in der Regel einen UTC-Tag, der Bericht kommt also üblicherweise täglich (RFC 9990).
- SPF belegt, dass ein bestimmter Server im Namen der Domain einliefern darf. Über den Inhalt der Nachricht und über das Feld „Von“ sagt es nichts.
- DKIM belegt, dass die Nachricht seit dem Unterschreiben unverändert ist und aus einem System mit dem passenden Schlüssel stammt.
- DMARC verbindet beides mit der sichtbaren Absenderdomain, legt fest, was bei Abweichung geschehen soll, und liefert Berichte darüber, wer in Ihrem Namen sendet.
- Keiner der drei Einträge erzwingt die Zustellung: Ein bestandener DMARC-Abgleich sagt laut RFC 9989 für sich genommen nichts darüber aus, ob die Zustellung in den Posteingang erwünscht ist. Sie nehmen dem Empfangsserver den Grund, Ihre Nachricht für gefälscht zu halten - mehr nicht, aber auch nicht weniger.
Drei Einträge, ein Ort - und der liegt oft woanders
Der Selbsttest in zehn Minuten
Der Test braucht kein Werkzeug, das Sie kaufen müssen. Er braucht zwei Postfächer, von denen eines nicht zu Ihrer Domain gehört, und die Bereitschaft, einmal in die Kopfzeilen einer Nachricht zu sehen. Wichtig ist die Reihenfolge: erst senden, dann suchen, dann lesen. Wer zuerst an den Einstellungen dreht, verliert den Vergleichswert.
Testanfrage stellen
Füllen Sie das eigene Formular mit einer Adresse aus, die nicht zu Ihrer Domain gehört; ein privates Postfach genügt. Schreiben Sie Datum und Uhrzeit in das Nachrichtenfeld, damit sich die Nachricht später eindeutig zuordnen lässt.
Beide Wege absuchen
Sehen Sie in das Betriebspostfach und in das Testpostfach, jeweils in Posteingang und Spamordner. Suchen Sie zusätzlich über alle Ordner, weil Regeln Nachrichten verschieben können, ohne sie als Spam zu kennzeichnen.
Kopfzeilen öffnen
Fast jedes Mailprogramm zeigt den Quelltext einer Nachricht an, meist über einen Menüpunkt wie Original anzeigen oder Nachrichtenquelle. Gesucht wird die Zeile Authentication-Results, die der empfangende Server geschrieben hat.
Ergebnis notieren
Schreiben Sie auf, was dort für spf, dkim und dmarc steht, dazu Datum und Postfach. Diese vier Angaben sind der Unterschied zwischen einer Vermutung und einem Befund, und beim nächsten Test sind sie der Vergleichswert.
Füllen Sie das eigene Formular mit einer Adresse aus, die nicht zu Ihrer Domain gehört; ein privates Postfach genügt. Schreiben Sie Datum und Uhrzeit in das Nachrichtenfeld, damit sich die Nachricht später eindeutig zuordnen lässt.
Sehen Sie in das Betriebspostfach und in das Testpostfach, jeweils in Posteingang und Spamordner. Suchen Sie zusätzlich über alle Ordner, weil Regeln Nachrichten verschieben können, ohne sie als Spam zu kennzeichnen.
Fast jedes Mailprogramm zeigt den Quelltext einer Nachricht an, meist über einen Menüpunkt wie Original anzeigen oder Nachrichtenquelle. Gesucht wird die Zeile Authentication-Results, die der empfangende Server geschrieben hat.
Schreiben Sie auf, was dort für spf, dkim und dmarc steht, dazu Datum und Postfach. Diese vier Angaben sind der Unterschied zwischen einer Vermutung und einem Befund, und beim nächsten Test sind sie der Vergleichswert.
Die Zeile, auf die es ankommt, sieht in etwa so aus wie im folgenden Auszug. Sie wird vom empfangenden Server geschrieben, nicht von Ihrem eigenen System, und ist deshalb belastbarer als jede Selbstauskunft der eigenen Technik.
Authentication-Results: mx.beispiel-empfaenger.invalid;
spf=pass (sender IP is 203.0.113.24)
smtp.mailfrom=musterbetrieb.invalid;
dkim=pass header.d=musterbetrieb.invalid;
dmarc=pass (p=quarantine sp=quarantine dis=none)
header.from=musterbetrieb.invalid
From: Anfrage Website <formular@musterbetrieb.invalid>
Reply-To: Anfragende Person <kunde@beispiel.invalid>
To: buero@musterbetrieb.invalid
Subject: Anfrage 2026-0418 aus dem FormularDrei Wörter entscheiden. Steht bei spf ein pass, war der sendende Server für die Domain im Umschlagabsender autorisiert. Steht bei dkim ein pass, ist die Unterschrift gültig und die angegebene Domain passt dazu. Steht bei dmarc ein pass, stimmt die sichtbare Absenderdomain mit mindestens einer der beiden geprüften Domains überein. Ein fail bei dmarc bei gleichzeitigem pass bei spf ist das typische Bild für ein Formular, das unter der Kundenadresse sendet.
Der Test an die eigene Adresse beweist wenig
Die Bestätigungsmail an den Kunden
Viele Formulare schicken zwei Nachrichten: eine an den Betrieb und eine Bestätigung an die Person, die angefragt hat. Für die zweite gelten dieselben Regeln, nur ist der Schaden anders gelagert. Kommt die Anfrage im Betrieb an, die Bestätigung beim Kunden aber nicht, entsteht der Eindruck, das Formular habe nicht funktioniert. Erfahrungsgemäß führt das dazu, dass dieselbe Anfrage ein zweites Mal gestellt wird - oder beim nächsten Betrieb.
Die Bestätigung geht an eine Adresse, die Sie nicht kennen, und durch Filter, die Sie nicht sehen. Umso mehr hängt ihre Zustellung an den drei Nachweisen. Dazu kommen einige handwerkliche Punkte, die den Eindruck einer automatisch erzeugten Massennachricht vermeiden.
- Absender ist eine Adresse Ihrer Domain mit erkennbarem Namen, etwa dem Betriebsnamen, nicht eine Zeichenfolge wie noreply-2 oder mailer-daemon.
- Der Betreff nennt Betrieb und Anlass, damit die Nachricht in einer vollen Ablage wiederzufinden ist.
- Der Text enthält die Angaben aus dem Formular im Klartext, dazu Telefonnummer und Erreichbarkeit. Eine Bestätigung ohne Inhalt wirkt wie eine leere Empfangsquittung.
- Eine Antwort auf die Bestätigung soll bei Ihnen ankommen: Das Feld „Antwort an“ zeigt auf ein Postfach, das gelesen wird.
- Verzichten Sie in der Bestätigung auf Anhänge und auf eingebundene Zählpixel; beides erhöht die Wahrscheinlichkeit, dass Filter genauer hinsehen.
Wenn die Bestätigung ohnehin überarbeitet wird, lohnt es sich, den nächsten Schritt gleich mitzudenken: Wer aus der Anfrage einen Termin machen möchte, findet die Abläufe im Beitrag zu Terminanfragen über die Website. Und wenn im Formular oder in der Bestätigung Dienste eingebunden sind, die eine Einwilligung brauchen, klärt der Beitrag zum Cookie-Banner im Handwerksbetrieb, wann eine Abfrage nötig ist.
Wer merkt, dass keine Anfrage kam
Der teuerste Teil dieses Themas ist nicht die Technik, sondern die Aufmerksamkeit. Ein Formular, das keine Mails mehr zustellt, verhält sich still: keine Fehlermeldung, keine rote Zeile, kein Anruf. Im Handwerk kommt hinzu, dass Anfragen ohnehin schwanken - drei ruhige Wochen im Sommer sind erklärbar, und genau diese Erklärbarkeit deckt den Defekt zu. Über klar geregelte Abläufe für den Fall eines Cyberangriffs verfügen 15 Prozent der befragten Betriebe (Bitkom); für den leiseren Fall, dass schlicht nichts mehr eingeht, gibt es erfahrungsgemäß noch seltener eine Regelung.
Der Ausweg ist kein Überwachungsprogramm, sondern ein Zählwerk und ein Termin. Das Formular vergibt je Anfrage eine fortlaufende Nummer und schreibt sie in den Betreff und in eine Liste auf dem Server. Wer wissen will, ob etwas fehlt, vergleicht zwei Zahlen: Wie viele Nummern wurden vergeben, wie viele Mails liegen im Postfach? Die Differenz ist der Befund. Ohne diese Nummer bleibt die Frage, ob etwas verloren gegangen ist, unbeantwortbar, weil der Bezugswert fehlt.
Fortlaufende Nummer je Anfrage
Jede Anfrage bekommt eine Nummer, die im Betreff steht und auf dem Server protokolliert wird. Damit lässt sich später prüfen, ob zwischen zwei Nummern eine Nachricht fehlt; ohne Nummer ist dieser Vergleich nicht möglich.
Ein Postfach, das jemand öffnet
Die Anfragen laufen in ein Postfach, für das eine Person zuständig ist, mit benannter Vertretung. Sammeladressen ohne Zuständigkeit sind der häufigste Ort, an dem Nachrichten liegen bleiben.
Ein fester Testtermin
Einmal im Monat eine Testanfrage von außen, mit Datum und Ergebnis in derselben Liste. Der Aufwand liegt bei wenigen Minuten und ersetzt die Vermutung, dass alles läuft, durch eine Notiz.
Meldung bei Stille
Kommt über einen festgelegten Zeitraum keine Anfrage, geht eine Erinnerung an die zuständige Person. Der Zeitraum richtet sich nach dem üblichen Aufkommen des Betriebs, nicht nach einem allgemeinen Richtwert.
Wer diese vier Punkte umsetzt, hat den stillen Ausfall in einen sichtbaren verwandelt. Dasselbe Muster gilt für den zweiten Kanal, über den Aufträge verloren gehen: Der Beitrag dazu, warum Betriebe Anrufe verlieren, bevor das Telefon klingelt, beschreibt die gleiche Blindstelle am Telefon. Für Gewerke mit ausgeprägter Saison lohnt außerdem der Blick in den Beitrag zur Innensaison für Maler und Lackierer: Wer im Winter auf Anfragen aus dem Formular angewiesen ist, prüft den Zustellweg besser vor der Saison als mittendrin.
Relaunch und Umzug: zuerst die Einträge
Der Moment, in dem ein funktionierender Formularweg am häufigsten kaputtgeht, ist der Wechsel des Hostings. Die neue Website liegt auf einem anderen Server, also liefert ein anderer Server die Formularmails ein - und dieser Server steht im SPF-Eintrag der Domain in der Regel noch nicht. Solange die alte Seite lief, fiel das nicht auf, weil der alte Server dort eingetragen war.
Die Reihenfolge ist deshalb umgekehrt zur Intuition: Erst wird der neue Server in den SPF-Eintrag aufgenommen und der DKIM-Schlüssel hinterlegt, dann wird umgeschaltet, und erst danach wird der alte Server entfernt - mit einigen Tagen Abstand, weil DNS-Antworten zwischengespeichert werden. Wie ein Relaunch der Handwerker-Website insgesamt abläuft, haben wir beschrieben; der Beitrag dazu, wie ein Relaunch ohne Sichtbarkeitsverlust gelingt, nimmt die Suchmaschinenseite desselben Umzugs auf.
- Vor dem Umschalten: aktuellen SPF-Eintrag notieren, neuen Server ergänzen, DKIM-Schlüssel für die neue Umgebung erzeugen und veröffentlichen.
- Am Umschalttag: Testanfrage über das neue Formular, Kopfzeilen lesen, Ergebnis notieren. Erst dann gilt der Umzug als vollzogen.
- Nach dem Umschalten: den alten Server erst entfernen, wenn über mehrere Tage keine Zustellung mehr über ihn läuft.
- Postfächer und Weiterleitungen getrennt prüfen - sie hängen an derselben Domain, ziehen aber nicht automatisch mit der Website um.
- DMARC-Berichte zwei bis vier Wochen mitlesen; darin steht, welche Server tatsächlich in Ihrem Namen senden.
Ein Punkt wird dabei regelmäßig übersehen: Schlüssel altern. Die Technische Richtlinie des BSI sieht vor, DKIM-Schlüsselmaterial alle sechs Monate zu erneuern oder die Abweichung zu begründen (BSI TR-03182). Für einen Handwerksbetrieb heißt das nicht, selbst Schlüssel zu tauschen, sondern zu wissen, wer das tut und wann es zuletzt geschehen ist. Diese Angabe gehört in dieselbe Liste wie die Zugänge zu Domain und Hosting.
Was in die Wartung gehört
Ein Zustellweg ist kein Bauteil, das man einmal montiert. Er hängt an Einträgen, die andere ändern können, an Software, die aktualisiert wird, und an Empfangsservern, deren Bewertungsregeln sich verschieben. Deshalb gehört die Prüfung in einen Rhythmus. In unserer Wartung und Pflege für Handwerker-Websites ist der Zustelltest darum ein fester Punkt und keine Zusatzleistung auf Zuruf.
| Prüfung | Rhythmus | Was ein Befund bedeutet |
|---|---|---|
| Testanfrage von außen | monatlich | Fehlt die Mail oder liegt sie im Spam, ist der Weg unterbrochen - erst Kopfzeilen lesen, dann ändern |
| Kopfzeilen auf spf, dkim, dmarc | bei jedem Test | Ein fail benennt die Schicht, an der es hängt, und erspart das Raten |
| SPF-Eintrag auf Anzahl und Länge | halbjährlich | Ein zweiter Eintrag oder mehr als 10 abfrageauslösende Angaben machen die Prüfung ungültig (RFC 7208) |
| DKIM-Schlüssel und sein Alter | halbjährlich | Vorgesehen ist eine Erneuerung des Schlüsselmaterials alle sechs Monate (BSI TR-03182) |
| DMARC-Berichte sichten | monatlich | Unbekannte sendende Server im Bericht deuten auf Missbrauch oder auf einen vergessenen Dienst |
| Postfach und Regeln | jährlich | Regeln, die Nachrichten verschieben, sind der häufigste Grund für angekommen, aber nicht gesehen |
Der Aufwand dafür ist überschaubar, der Nutzen ist es nicht. 85 Prozent der befragten Betriebe sehen bei ihrer Kundschaft einen klaren Wunsch nach ständiger Verfügbarkeit (Bitkom). Eine Anfrage, die im Spamordner liegt, ist aus Sicht der anfragenden Person eine unbeantwortete Anfrage - und in der Wahrnehmung schlechter als gar kein Formular, weil eine Erwartung geweckt wurde.
Zwei weitere Beiträge passen zum selben Arbeitsschritt. Wer gerade Inhalte überarbeitet, nimmt den Steuerbonus für Handwerkerleistungen auf der Website gleich mit, weil dafür Rechnungsangaben und Kontaktwege zusammenpassen müssen. Und wer klären möchte, wer nach der Übergabe für solche Prüfungen zuständig ist, findet die Antwort im Beitrag dazu, wer die Website nach der Übergabe pflegt. Was bei einer neuen Website für Handwerksbetriebe von Anfang an eingerichtet wird, ist damit umrissen: Domain, Postfach, Formularweg und die drei Einträge, die den Weg belegbar machen.
Quellen dieses Beitrags
Verwandte Artikel
Domain und Hosting: wem die Handwerker-Website gehört
Domain, DNS, Hosting, Website und E-Mail sind fünf Verträge mit fünf Zugängen. Wer Domaininhaber ist, welche Fristen bei einem Wechsel gelten und was in die.
Kältemittel ab 2027: Wärmepumpen-Seite rechtzeitig ändern
Ab 1. Januar 2027 gelten neue Kältemittel-Fristen für Wärmepumpen bis 12 kW. Was SHK-Betriebe auf Leistungsseite, FAQ und Förderhinweis jetzt anpassen.
Eine Website für mehrere Gewerke: Aufbau und Impressum
Elektro, Sanitär und Maler auf einer Website: Seite je Gewerk, Anfragen an den richtigen Betrieb, Impressum nach § 5 DDG und Datenschutzrollen je Betrieb.