Email Spam Tester Test ausführen · Für Agenten · API · Blog

So funktioniert der Test

Senden Sie eine Nachricht an eine temporäre Adresse, und 42 Prüfungen werden darauf ausgeführt. Diese Seite enthält sie alle: was jede einzelne prüft, wie viele Punkte sie kostet, wenn sie fehlschlägt, und aus welchem Abschnitt des Standards sie stammt.

Nichts hier ist unsere Meinung, die als Regel dargestellt wird. Wenn eine Prüfung etwas durchsetzt, das in einem Standard festgelegt ist, wird der entsprechende Satz aus diesem Standard darunter zitiert. Wenn sie stattdessen etwas durchsetzt, das Google oder Yahoo verlangt, wird deren Seite verlinkt. Wenn es sich um unsere eigene Einschätzung handelt, wird dies angegeben.

Aktualisiert:

PrüfungGruppeUnsere BewertungKlassische Bewertung
ARC-KetteAuthentifizierung−20
DKIM-SignaturAuthentifizierung−18−1
DKIM-AbgleichAuthentifizierung−10−1
DMARC-ErgebnisAuthentifizierung−140
Sender IDAuthentifizierung−5−0.5
SPFAuthentifizierung−18−1
SPF-AbgleichAuthentifizierung−5−0.5
Sendender Hostname wird aufgelöstInfrastruktur und Reputation−5−3
SperrlistenInfrastruktur und Reputation−25−3
HELO-NameInfrastruktur und Reputation−50
MX-RecordInfrastruktur und Reputation−5−3
Reverse DNSInfrastruktur und Reputation−12−1.5
TransportverschlüsselungInfrastruktur und Reputation−50
KI-BewertungSpam-Engines
GesamturteilSpam-Engines−250
Postmark SpamCheckSpam-Engines
RspamdSpam-Engines
SpamAssassinSpam-Engines0−3
Alternativtext für BilderInhalt−4−0.5
Link-VerfügbarkeitInhalt−5−1
Script und iframeInhalt−10−1
Verhältnis von Text zu HTMLInhalt−3−0.3
Text- und HTML-TeileInhalt−50
HTML-GrößeInhalt−3−0.3
BildgrößeInhalt−3−0.3
Sichtbare LinkzieleInhalt−30
Link-ReputationInhalt−400
AnhangprüfungInhalt−600
PreheaderInhalt−20
BetreffzeileInhalt−30
Verkürzte LinksInhalt−5−0.5
DMARC-Richtlinie veröffentlichtRegeln für Massenversender−60
List-UnsubscribeRegeln für Massenversender−10−1
Abmeldung mit einem KlickRegeln für Massenversender−80
TLS für Massen-E-MailsRegeln für Massenversender−50
BIMIEmpfehlungen00
Alter und Länge des DKIM-SchlüsselsEmpfehlungen00
DMARC-BerichtszustellungEmpfehlungen00
DNSSECEmpfehlungen00
MTA-STSEmpfehlungen00
Länge der RücksendeadresseEmpfehlungen00
TLS-BerichterstattungEmpfehlungen00

Authentifizierung

Ob der empfangende Server nachweisen kann, dass die Nachricht von dort kam, woher sie zu kommen behauptet. Dies ist die Hälfte der Zustellbarkeit, die ausschließlich von DNS abhängt, und die Hälfte, die Gmail und Yahoo 2024 für Massenversender verpflichtend gemacht haben.

ARC-Kette auth.arc

ARC bewahrt das Authentifizierungsergebnis über eine Weiterleitung hinweg. Ohne ARC beschädigt eine Mailingliste, die eine Fußzeile anhängt, Ihre DKIM-Signatur, und die weitergeleitete Kopie besteht am anderen Ende die DMARC-Prüfung nicht.

Bei einem Fehlschlag: Als Absender müssen Sie nichts tun. Dies ist relevant, wenn Sie eine Liste oder eine Weiterleitung betreiben, und erklärt, warum einige Ihrer E-Mails DMARC nicht bestehen, nachdem sie jemand weitergeleitet hat.

Kostet bis zu 2 von 100 Punkten in unserer Bewertung.

RFC 7960 §1 — Introduction

DMARC with restrictive policies causes problems for many Mailing Lists.

RFC 8617 §2.1 — Evidence

In ARC's situation, the "evidence" is a message's authentication assessment at any point along the delivery path between origination and final delivery.

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

DKIM-Signatur auth.dkim

DKIM signiert Teile der Nachricht mit einem privaten Schlüssel und veröffentlicht den öffentlichen Schlüssel in DNS. Wir überprüfen jede Signatur, die die Nachricht enthält, und melden die signierende Domain, den Selektor und die Schlüssellänge.

Bei einem Fehlschlag: Aktivieren Sie DKIM bei Ihrer Versandplattform und veröffentlichen Sie den Schlüssel, den sie Ihnen bereitstellt. Verwenden Sie 2048 Bit: 1024 wird weiterhin verifiziert, aber ein so kurzer Schlüssel lässt sich knacken und gilt nicht mehr als sicher.

Kostet bis zu 18 von 100 Punkten in unserer Bewertung und bis zu 1 von 10 Punkten in der klassischen Bewertung.

RFC 6376 §3.5 — The DKIM-Signature Header Field

The signature of the email is stored in the DKIM-Signature header field.

RFC 6376 §6.1 — Extract Signatures from the Message

Verifiers MUST NOT attribute ultimate meaning to the order of multiple DKIM-Signature header fields.

RFC 8301 §3.1 — Signing and Verification Algorithms

rsa-sha1 MUST NOT be used for signing or verifying.

RFC 8463 §6 — Transition Considerations

For backward compatibility, signers can add multiple signatures that use old and new signing algorithms.

Google — Set up DKIM

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

DKIM-Abgleich auth.dkim_alignment

Eine gültige Signatur reicht für DMARC nicht aus. Die signierende Domain muss mit der Domain im From-Header übereinstimmen, exakt oder auf Ebene der Organisationsdomain, abhängig von der von Ihnen veröffentlichten Richtlinie.

Bei einem Fehlschlag: Signieren Sie mit Ihrer eigenen Domain statt mit der Ihrer Plattform. Die meisten Plattformen unterstützen dies und bezeichnen es als benutzerdefinierte oder authentifizierte Versanddomain.

Kostet bis zu 10 von 100 Punkten in unserer Bewertung und bis zu 1 von 10 Punkten in der klassischen Bewertung.

RFC 9989 §4.4.1 — DKIM-Authenticated Identifiers

A single email can contain multiple DKIM signatures, and it is considered to produce a DMARC "pass" result if any DKIM-Authenticated Identifier aligns with the Author Domain.

Google — Set up DMARC

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

DMARC-Ergebnis auth.dmarc

DMARC verknüpft SPF und DKIM mit der Domain, die Ihr Leser sieht, und teilt Empfängern mit, was zu tun ist, wenn keines von beiden übereinstimmt. Wir melden die veröffentlichte Richtlinie und ob diese Nachricht sie erfüllt hat.

Bei einem Fehlschlag: Veröffentlichen Sie einen DMARC-Eintrag. Beginnen Sie mit p=none, lesen Sie die Berichte einige Wochen lang und wechseln Sie dann zu quarantine, sobald Sie wissen, was sonst noch in Ihrem Namen sendet.

Kostet bis zu 14 von 100 Punkten in unserer Bewertung.

RFC 9989 §5.3.5 — Determine DMARC "Pass" or "Fail"

If no Authenticated Identifiers exist for the domain, or none of the Authenticated Identifiers align with the Author Domain, the message is considered to fail the DMARC mechanism check.

RFC 9989 §4.7 — DMARC Policy Record Format

DMARC Policy Records follow the extensible "tag-value" syntax for DNS-based key records defined in DKIM [RFC6376].

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Yahoo — Sender requirements and recommendations

Sender ID auth.sender_id

Dieselbe Prüfung wie SPF, ausgeführt für die Domain im From-Header statt für den Envelope. Sie beantwortet eine andere Frage: ob die Domain, die Ihr Leser sieht, den Server autorisiert, der die Nachricht gesendet hat. Eine Nachricht kann SPF für ihren Envelope bestehen, während die sichtbare Domain für niemanden bürgt.

Bei einem Fehlschlag: Veröffentlichen Sie SPF für die Domain in Ihrem From-Header, nicht nur für die Bounce-Domain, die Ihre Plattform Ihnen zugewiesen hat.

Kostet bis zu 5 von 100 Punkten in unserer Bewertung und bis zu 0.5 von 10 Punkten in der klassischen Bewertung.

RFC 4406 §4 — Record Selection

After the above steps, there should be one record remaining and evaluation can proceed.

SPF auth.spf

SPF ist ein DNS-Eintrag, der auflistet, welche Server für Ihre Domain senden dürfen. Der empfangende Server nimmt die Adresse im Envelope, ruft den Eintrag dieser Domain ab und prüft, ob die verbindende IP darin enthalten ist. Wir melden das Ergebnis und die Anzahl der DNS-Abfragen, die der Eintrag benötigte, da die Auswertung nach zehn stoppt und alles darüber hinaus ein dauerhafter Fehler statt eines Erfolgs ist.

Bei einem Fehlschlag: Veröffentlichen Sie einen Eintrag, der Ihre Versandplattform und nichts anderes nennt. Wenn Ihrer nahe an der Grenze von zehn Abfragen liegt, lösen Sie die Includes auf, die Sie nicht verwenden (ein Eintrag, der heute erfolgreich ist, schlägt an dem Tag fehl, an dem ein Anbieter ein eigenes Include hinzufügt).

Kostet bis zu 18 von 100 Punkten in unserer Bewertung und bis zu 1 von 10 Punkten in der klassischen Bewertung.

RFC 7208 §4.6.4 — DNS Lookup Limits

SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return "permerror".

RFC 7208 §2.6 — Results of Evaluation

Section 4 defines check_host(), a model function definition that uses the inputs defined above and the sender's policy published in the DNS to reach a conclusion about client authorization.

Google — Set up SPF

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

SPF-Abgleich auth.spf_alignment

Ob die Bounce-Adresse mit der From-Adresse übereinstimmt, die ein Leser sieht. SPF autorisiert den Envelope, und DMARC berücksichtigt diese Autorisierung nur, wenn beide übereinstimmen.

Bei einem Fehlschlag: Bitten Sie Ihre Versandplattform um eine Bounce-Subdomain Ihrer eigenen Domain. Wenn Ihr DKIM bereits übereinstimmt, ist dies nicht dringend, aber ohne sie haben Sie keine Ausweichmöglichkeit, wenn DKIM während der Übertragung fehlschlägt.

Kostet bis zu 5 von 100 Punkten in unserer Bewertung und bis zu 0.5 von 10 Punkten in der klassischen Bewertung.

RFC 9989 §4.4.2 — SPF-Authenticated Identifiers

Only an SPF-Authenticated Identifier that has Identifier Alignment with the Author Domain is enough to validate the authorized use of the Author Domain.

RFC 9989 §5.3.5 — Determine DMARC "Pass" or "Fail"

If one or more of the Authenticated Identifiers align with the Author Domain, the message is considered to pass the DMARC mechanism check.

Google — Set up DMARC

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Infrastruktur und Reputation

Der Rechner und die Adresse, von denen die Nachricht gesendet wurde, und was der Rest des Internets bereits von ihnen hält.

Sendender Hostname wird aufgelöst infra.a_record

Ob der bei HELO angekündigte Hostname überhaupt einen Adress-Record hat.

Bei einem Fehlschlag: Veröffentlichen Sie einen A-Record für den Namen, den Ihr Server ankündigt.

Kostet bis zu 5 von 100 Punkten in unserer Bewertung und bis zu 3 von 10 Punkten in der klassischen Bewertung.

RFC 5321 §5.1 — Locating the Target Host

If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.

Google — Set up MX records

Sperrlisten infra.dnsbl

Ob die sendende IP auf einer der Sperrlisten steht, die Empfänger tatsächlich abfragen. Unsere Liste wird anhand des dokumentierten Testpunkts jeder Zone geprüft und nicht aus einer Websuche zusammengestellt, weil eine inaktive Zone mit NXDOMAIN antwortet und dies als „sauber“ gilt.

Bei einem Fehlschlag: Befolgen Sie den Prozess zur Entfernung von der Liste auf der Website des Listenbetreibers. Ein Eintrag in einer wichtigen Zone stoppt E-Mails vollständig, behandeln Sie ihn daher vor allem anderen auf der Seite.

Kostet bis zu 25 von 100 Punkten in unserer Bewertung und bis zu 3 von 10 Punkten in der klassischen Bewertung.

RFC 5782 §2.1 — IP Address DNSxL

Each IPv4 address listed in the DNSxL has a corresponding DNS entry.

RFC 5782 §5 — Test and Contact Addresses

IPv4-based DNSxLs MUST contain an entry for 127.0.0.2 for testing purposes.

Google — Postmaster Tools: reputation and delivery errors

Google — Email sender guidelines

HELO-Name infra.helo

Der Name, mit dem sich der sendende Server zu Beginn der SMTP-Kommunikation ankündigt. Es muss eine vollständig qualifizierte Domain sein, die aufgelöst werden kann.

Bei einem Fehlschlag: Setzen Sie den Hostnamen Ihres Mailservers auf einen echten Namen in Ihrer Domain und nicht auf eine Container-ID oder einen internen Namen.

Kostet bis zu 5 von 100 Punkten in unserer Bewertung.

RFC 5321 §4.1.1.1 — Extended HELLO (EHLO) or HELLO (HELO)

The argument clause contains the fully-qualified domain name of the SMTP client, if one is available.

Google — Email sender guidelines

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

MX-Record infra.mx

Ob die Domain in Ihrem From-Header E-Mails empfangen kann. Ohne ihn können Antworten und Unzustellbarkeitsmeldungen nirgendwo zugestellt werden, und Filter werten eine sendende Domain, die keine E-Mails empfangen kann, als negatives Signal.

Bei einem Fehlschlag: Veröffentlichen Sie einen MX-Record für die Domain, von der Sie senden, selbst wenn er nur an ein Postfach weiterleitet, das Sie einmal im Monat lesen.

Kostet bis zu 5 von 100 Punkten in unserer Bewertung und bis zu 3 von 10 Punkten in der klassischen Bewertung.

RFC 5321 §5.1 — Locating the Target Host

The lookup first attempts to locate an MX record associated with the name.

Google — Set up MX records

Reverse DNS infra.rdns

Ob die sendende IP rückwärts zu einem Hostnamen aufgelöst wird und ob dieser Hostname vorwärts wieder zu derselben IP aufgelöst wird. Entscheidend ist die Auflösung in beide Richtungen: Ein PTR, der auf ein beliebiges Ziel verweist, ist leicht einzurichten; ein übereinstimmendes Paar ist ein Beleg dafür, dass die Adresse Ihnen gehört.

Bei einem Fehlschlag: Bitten Sie den Eigentümer der IP, den PTR auf einen von Ihnen kontrollierten Namen zu setzen, und stellen Sie sicher, dass dieser Name einen zurückweisenden A-Record hat.

Kostet bis zu 12 von 100 Punkten in unserer Bewertung und bis zu 1.5 von 10 Punkten in der klassischen Bewertung.

RFC 1912 §2.1 — Inconsistent, Missing, or Bad Data

Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain.

Google — Email sender guidelines

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Transportverschlüsselung infra.tls

Ob die Nachricht über TLS eingegangen ist und mit welcher Cipher-Suite. Alle modernen Systeme handeln TLS aus; wenn eine Nachricht unverschlüsselt eingeht, sagt das etwas über die sendende Konfiguration aus.

Bei einem Fehlschlag: Aktivieren Sie STARTTLS auf dem sendenden Server. Jede gängige Plattform unterstützt dies bereits, daher weist ein Fehler hier normalerweise auf ein selbst gehostetes Relay im Übertragungsweg hin.

Kostet bis zu 5 von 100 Punkten in unserer Bewertung.

RFC 3207 §2 — STARTTLS Extension

The STARTTLS extension to SMTP is laid out as follows:

Google — Send email over a secure TLS connection

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Spam-Engines

Wie unabhängige Inhaltsfilter die Nachricht bewerten. Zwei Engines statt einer, weil die Bewertung einer einzelnen Engine die Meinung dieser Engine ist.

KI-Bewertung spam.ai_judge

Ein Modell schätzt anhand der technischen Ergebnisse und der Inhaltsmessungen, wie ein moderner auf maschinellem Lernen basierender Filter die Nachricht behandeln würde. Es sieht die Fakten, nicht den Nachrichtentext.

Bei einem Fehlschlag: Für sich genommen nur zur Information. Seine Einschätzung fließt in das unten stehende Gesamturteil ein.

Zur Information angezeigt. Wird nie bewertet.

Gesamturteil spam.panel

Eine Kennzahl aus den Engines, die geantwortet haben, so gewichtet, dass die deutlichste Bewertung nicht einfach durch Mittelwertbildung abgeschwächt wird. SpamAssassin und Postmark zählen als eine einzige Stimme, weil sie dieselbe Regelbasis verwenden.

Bei einem Fehlschlag: Arbeiten Sie die einzelnen Ergebnisse durch. Diese Zeile ändert sich, wenn sie sich ändern.

Kostet bis zu 25 von 100 Punkten in unserer Bewertung.

Google — Why Gmail marks messages as spam

How this score is calculated

Postmark SpamCheck spam.postmark

Eine dritte Einschätzung, standardmäßig deaktiviert. Der Endpunkt verarbeitet die gesamte Nachricht, und wir können nichts davon unkenntlich machen, ohne das zu zerstören, was gemessen wird. Das Aktivieren bedeutet daher, zu akzeptieren, dass jede getestete Nachricht an einen Dritten kopiert wird.

Bei einem Fehlschlag: Nichts zu tun. Wenn die Prüfung deaktiviert ist, meldet sie, dass sie deaktiviert ist, was nicht mit einem bestandenen Test gleichzusetzen ist.

Zur Information angezeigt. Wird nie bewertet.

Rspamd spam.rspamd

Ein zweiter, unabhängig entwickelter Filter. Er widerspricht SpamAssassin oft genug, dass sich eine Abfrage lohnt, weshalb er hier enthalten ist.

Bei einem Fehlschlag: Nur zur Information. Die Einschätzung dieser Engine fließt in das Gesamturteil ein, statt separat bewertet zu werden.

Zur Information angezeigt. Wird nie bewertet.

SpamAssassin spam.spamassassin

Der klassische regelbasierte Filter, der weiterhin hinter den meisten E-Mail-Testwerkzeugen steckt. Jede ausgelöste Regel wird mit ihrer Gewichtung aufgeführt.

Bei einem Fehlschlag: Prüfen Sie die ausgelösten Regeln statt der Gesamtwertung. Die meisten lassen sich leicht beheben, sobald Sie sehen können, um welche es sich handelt.

Kostet bis zu 3 von 10 Punkten in der klassischen Bewertung.

Google — Why Gmail marks messages as spam

Apache SpamAssassin — rule documentation

Inhalt

Die Nachricht selbst: ihre Struktur, ihre Links, ihre Bilder, die Dinge, die ein Filter liest, bevor er entscheidet.

Alternativtext für Bilder content.alt_attributes

Ob Bilder alt-Attribute enthalten. E-Mail-Clients blockieren externe Bilder standardmäßig, daher ist der Alternativtext in den ersten Sekunden Ihre Nachricht.

Bei einem Fehlschlag: Schreiben Sie einen Alternativtext, der die Bedeutung vermittelt, und lassen Sie das Hauptbild niemals ohne einen solchen Text.

Kostet bis zu 4 von 100 Punkten in unserer Bewertung und bis zu 0.5 von 10 Punkten in der klassischen Bewertung.

Google — Email sender guidelines

Script und iframe content.forbidden_tags

Ob das HTML Tags enthält, die kein E-Mail-Client ausführt. Sie werden bestenfalls entfernt und schlimmstenfalls als Umgehungssignal gewertet.

Bei einem Fehlschlag: Entfernen Sie script, iframe, object und embed. Alles Interaktive gehört hinter einen Link.

Kostet bis zu 10 von 100 Punkten in unserer Bewertung und bis zu 1 von 10 Punkten in der klassischen Bewertung.

Google — Email sender guidelines

Verhältnis von Text zu HTML content.html_text_ratio

Wie viel der Nachricht aus Markup und wie viel aus lesbarem Text besteht. Eine Seite voller Markup um einen einzigen Satz ist eine Struktur, die Filter erkennen.

Bei einem Fehlschlag: Schreiben Sie einen Textteil, der dasselbe aussagt wie das HTML, statt eines Platzhalters.

Kostet bis zu 3 von 100 Punkten in unserer Bewertung und bis zu 0.3 von 10 Punkten in der klassischen Bewertung.

RFC 2046 §5.1.4 — Alternative Subtype

Systems should recognize that the content of the various parts are interchangeable.

Google — Why Gmail marks messages as spam

Text- und HTML-Teile content.html_version

Ob die Nachricht neben dem HTML eine Klartextalternative enthält. Einige Filter gewichten ihr Fehlen, und jeder Screenreader benötigt eine.

Bei einem Fehlschlag: Senden Sie multipart/alternative mit einer echten Textversion, nicht mit einem leeren Teil oder einer Zeile, die dazu auffordert, die Nachricht in einem Browser anzusehen.

Kostet bis zu 5 von 100 Punkten in unserer Bewertung.

RFC 2046 §5.1.4 — Alternative Subtype

The "multipart/alternative" type is syntactically identical to "multipart/mixed", but the semantics are different. In particular, each of the body parts is an "alternative" version of the same information.

Google — Email sender guidelines

HTML-Größe content.html_weight

Wie groß der HTML-Teil ist. Gmail schneidet eine Nachricht ab ungefähr 102 KB ab und verbirgt den Rest hinter einem Link, wodurch auch Ihre Fußzeile zum Abbestellen verborgen wird.

Bei einem Fehlschlag: Kürzen Sie Inline-CSS und wiederholte Stilblöcke (die meisten Vorlagen passen in ein Drittel des Grenzwerts, sobald die ungenutzten Regeln entfernt sind).

Kostet bis zu 3 von 100 Punkten in unserer Bewertung und bis zu 0.3 von 10 Punkten in der klassischen Bewertung.

Google — Email sender guidelines

Bildgröße content.images_weight

Die Gesamtgröße der Bilder, die die Nachricht lädt. Große Bilder machen eine Nachricht auf einem Mobiltelefon langsam, und reine Bildnachrichten sind ein Format, das Filter mit Misstrauen behandeln.

Bei einem Fehlschlag: Komprimieren Sie sie und stellen Sie sicher, dass die Nachricht auch bei deaktivierten Bildern lesbar bleibt.

Kostet bis zu 3 von 100 Punkten in unserer Bewertung und bis zu 0.3 von 10 Punkten in der klassischen Bewertung.

Google — Email sender guidelines

Anhangprüfung content.malware

Ob Anhänge bekannte Schadsoftware enthalten. Bei Installationen, in denen der Scanner deaktiviert ist, wird gemeldet, dass er nicht ausgeführt wurde, statt ein sauberes Ergebnis zu melden.

Bei einem Fehlschlag: Wenn dies auslöst, stellen Sie den Versand ein und ermitteln Sie, was sich auf dem Computer befindet, der die Nachricht erstellt hat.

Kostet bis zu 60 von 100 Punkten in unserer Bewertung.

Google — Why Gmail marks messages as spam

ClamAV — how detection works

Preheader content.preheader

Die Vorschauzeile, die ein Client neben dem Betreff anzeigt. Ohne sie zeigt er den Inhalt an, der im Nachrichtentext zuerst kommt, was normalerweise ein Link zur Browseransicht ist.

Bei einem Fehlschlag: Fügen Sie als erstes Element des Nachrichtentexts einen ausgeblendeten Preheader-Block hinzu.

Kostet bis zu 2 von 100 Punkten in unserer Bewertung.

Google — Email sender guidelines

Betreffzeile content.subject

Länge, Groß- und Kleinschreibung und die Muster, die Filter bewerten. Wir messen den dekodierten Betreff, sodass eine kyrillische oder CJK-Zeile als Text und nicht als ihre Kodierung bewertet wird.

Bei einem Fehlschlag: Halten Sie ihn unter etwa 60 Zeichen und verzichten Sie auf Großbuchstaben und Ausrufezeichen.

Kostet bis zu 3 von 100 Punkten in unserer Bewertung.

RFC 5322 §2.2 — Header Fields

Header fields are lines beginning with a field name, followed by a colon (":"), followed by a field body, and terminated by CRLF.

RFC 2047 §2 — Syntax of encoded-words

An 'encoded-word' is defined by the following ABNF grammar.

Google — Why Gmail marks messages as spam

Verkürzte Links content.url_shortener

Ob Links über einen öffentlichen URL-Kürzungsdienst führen. Kürzungsdienste verbergen das Ziel, und genau darauf sind Filter trainiert, mit Misstrauen zu reagieren.

Bei einem Fehlschlag: Verlinken Sie Ihre eigene Domain oder verwenden Sie die Tracking-Domain Ihrer Plattform auf einer Ihrer Subdomains.

Kostet bis zu 5 von 100 Punkten in unserer Bewertung und bis zu 0.5 von 10 Punkten in der klassischen Bewertung.

Google — Why Gmail marks messages as spam

Regeln für Massenversender

Die Anforderungen, die Gmail und Yahoo für alle veröffentlichen, die große Mengen versenden. Diese gelten für Rundsendungen und werden bei Nachrichten übersprungen, die nicht wie eine solche aussehen.

DMARC-Richtlinie veröffentlicht compliance.dmarc_present

Ob die From-Domain überhaupt einen DMARC-Eintrag veröffentlicht, unabhängig davon, ob diese Nachricht die Prüfung bestanden hat. Gmail und Yahoo verlangen einen solchen Eintrag von Massenversendern.

Bei einem Fehlschlag: Veröffentlichen Sie einen Eintrag. p=none reicht aus, um die Anforderung zu erfüllen, und liefert Ihnen Berichte, mit denen Sie arbeiten können.

Kostet bis zu 6 von 100 Punkten in unserer Bewertung.

RFC 9989 §4.7 — DMARC Policy Record Format

If this tag is not present in an otherwise syntactically valid DMARC Policy Record, then the record is treated as if it included "p=none".

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Yahoo — Sender requirements and recommendations

List-Unsubscribe compliance.list_unsubscribe

Ob die Nachricht einen Abmelde-Header enthält, den ein E-Mail-Client verarbeiten kann. Gmail und Yahoo verlangen ihn von Massenversendern, und sein Fehlen wird unabhängig von allem anderen gefiltert. Die Regel gilt für Mailings. Eine Nachricht, in der der Empfänger gebeten wird, ein Abonnement zu bestätigen, oder in der ihm mitgeteilt wird, dass es erfolgreich abgeschlossen wurde, wird an eine Person zu etwas gesendet, das sie gerade getan hat; CAN-SPAM bezeichnet dies als Transaktions- oder Beziehungsnachricht, und weder Gmail noch Yahoo verlangt dafür einen Abmelde-Header. Daher liest diese Prüfung zuerst die Nachricht. Eine Abonnementbestätigung, eine Willkommensnachricht, eine Transaktionsnachricht oder eine Benachrichtigung ohne Listen-Header wird nicht beanstandet, und der Bericht gibt an, als was die Nachricht eingestuft wurde. Eine mit Angeboten angereicherte Willkommensnachricht ist praktisch die erste Ausgabe des Mailings; ohne Listen-Header kann die Prüfung die beiden nicht unterscheiden, und sie beanstandet nichts aufgrund einer Vermutung. Wenn die Nachricht List-Unsubscribe oder List-Id enthält, haben Sie sie selbst als Listenmail deklariert, und die Prüfung wird wie bisher ausgeführt.

Bei einem Fehlschlag: Fügen Sie einen List-Unsubscribe-Header mit einer HTTPS-URI hinzu. Jede Versandplattform kann dies tun.

Kostet bis zu 10 von 100 Punkten in unserer Bewertung und bis zu 1 von 10 Punkten in der klassischen Bewertung.

RFC 2369 §3.2 — List-Unsubscribe

The List-Unsubscribe field describes the command (preferably using mail) to directly unsubscribe the user (removing them from the list).

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Yahoo — Sender requirements and recommendations

Abmeldung mit einem Klick compliance.one_click_unsubscribe

Die strengere Form: eine HTTPS-URI, ein „List-Unsubscribe-Post“-Header und eine einzelne gültige DKIM-Signatur, die beide Header abdeckt. Alle drei müssen vorhanden sein, sonst zeigt der Empfänger die Schaltfläche nicht an. Wie die List-Unsubscribe-Prüfung gilt sie für Mailings, nicht für eine Bestätigung oder eine Willkommensnachricht.

Bei einem Fehlschlag: Meist fehlt die Signatur: Plattformen signieren „List-Unsubscribe“ und vergessen „List-Unsubscribe-Post“. Beide Header-Namen müssen im h=-Tag derselben Signatur erscheinen.

Kostet bis zu 8 von 100 Punkten in unserer Bewertung.

RFC 8058 §4 — Additional Requirements

The List-Unsubscribe and List-Unsubscribe-Post headers MUST be covered by the signature and included in the "h=" tag of a valid DKIM-Signature header field.

RFC 8058 §3.1 — Mail Senders

The List-Unsubscribe header field MUST contain one HTTPS URI.

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Yahoo — Sender requirements and recommendations

Empfehlungen

Sinnvoll und nie bewertet. Nichts in diesem Abschnitt kann Punkte kosten, was eine Produktentscheidung ist, die von den Tests durchgesetzt wird.

BIMI advisory.bimi

Ob die Domain einen BIMI-Eintrag veröffentlicht, der in einigen Clients ein Logo neben Ihren Nachrichten anzeigt. Dafür ist zunächst eine durchsetzende DMARC-Richtlinie sowie ein kostenpflichtiges Zertifikat für eine verifizierte Marke erforderlich.

Bei einem Fehlschlag: Lohnt sich, sobald DMARC auf quarantine oder reject gesetzt ist und das Volumen das Zertifikat rechtfertigt.

Empfehlung. Kostet nichts.

BIMI — draft specification, not yet an RFC

Alter und Länge des DKIM-Schlüssels advisory.dkim_key_rotation

Die Länge des Signierschlüssels und wie lange er bereits verwendet wird. Kurze Schlüssel lassen sich mit jedem Jahr kostengünstiger offline angreifen.

Bei einem Fehlschlag: Wechseln Sie zu 2048 Bit und rotieren Sie nach einem festen Zeitplan. Veröffentlichen Sie den neuen Selektor, stellen Sie die Signierung darauf um und nehmen Sie anschließend den alten außer Betrieb.

Empfehlung. Kostet nichts.

RFC 8301 §3.2 — Key Sizes

Since short RSA keys more easily succumb to off-line attacks, Signers MUST use RSA keys of at least 1024 bits for all keys. Signers SHOULD use RSA keys of at least 2048 bits.

Google — Set up DKIM

DMARC-Berichtszustellung advisory.dmarc_reporting

Ob die Adressen in Ihrem DMARC-Eintrag tatsächlich etwas empfangen werden. Wenn eine Berichtsadresse außerhalb Ihrer eigenen Domain liegt, verlangt RFC 9990, dass diese Domain zuerst ihre eigene Berechtigung veröffentlicht, als TXT-Eintrag unter your-domain._report._dmarc.their-domain. Ohne diesen Eintrag verwirft ein Empfänger die Adresse: keine Unzustellbarkeitsmeldung, kein Fehler, kein Bericht. Dies ist die übliche und keine ungewöhnliche Konfiguration, da die Adresse normalerweise bei einem Monitoring-Anbieter liegt oder bei Ihrer Hauptdomain, während die Richtlinie auf einer sendenden Subdomain liegt. Dieselbe Regel gilt für Fehlerberichte, wobei RFC 9991 für das ruf-Tag auf dasselbe Verfahren verweist. Wir fragen dieselben Einträge ab wie ein Empfänger und zeigen Ihnen die abgefragten Namen.

Bei einem Fehlschlag: Bitten Sie den Betreiber der Zieldomain, unter dem im Befund angegebenen Namen einen TXT-Eintrag mit v=DMARC1 zu veröffentlichen. Monitoring-Anbieter erledigen dies normalerweise für Sie, sobald Sie die Domain zu ihrem Konto hinzufügen. Wenn der Eintrag fehlt, wurde die Domain daher wahrscheinlich nie auf deren Seite hinzugefügt. Wenn die Berichte stattdessen an Ihre eigene Domain gehen, ist nichts erforderlich.

Empfehlung. Kostet nichts.

RFC 9990 §4 — Verifying External Destinations

When a Mail Receiver discovers a DMARC Policy Record in the DNS, and the Organizational Domain at which that record was discovered is not identical to the Organizational Domain of the host part of the authority component of a [RFC3986] specified in the "rua" tag, the following verification steps MUST be taken:

RFC 9990 §4 — Verifying External Destinations

Where the above algorithm fails to confirm that the external reporting was authorized by the Report Consumer, the URI MUST be ignored by the Mail Receiver generating the report.

RFC 9991 §5 — Verifying External Destinations

In case of external destinations, a Mail Receiver who generates failure reports MUST use the Verifying External Destinations procedure described in Section 4 of [RFC9990], substituting the "ruf" tag where the "rua" tag appears in that procedure.

Google — Set up DMARC

DNSSEC advisory.dnssec

Ob die Domain signiert ist. SPF, DKIM und DMARC sind alle in DNS hinterlegt, sodass ein Angreifer, der DNS-Antworten fälschen kann, auch alle drei fälschen kann.

Bei einem Fehlschlag: Aktivieren Sie es bei Ihrem Registrar. Normalerweise ist dafür nur ein Schalter erforderlich, und der Registrar erledigt den Rest.

Empfehlung. Kostet nichts.

RFC 4033 §2 — Definitions of Important DNSSEC Terms

Authentication Chain: An alternating sequence of DNS public key (DNSKEY) RRsets and Delegation Signer (DS) RRsets

MTA-STS advisory.mta_sts

Ob die Domain eine Richtlinie veröffentlicht, die andere Server anweist, unverschlüsselte Zustellungen an Sie abzulehnen. Sie schützt an Sie gesendete E-Mails und nicht E-Mails, die Sie senden.

Bei einem Fehlschlag: Veröffentlichen Sie den TXT-Eintrag und die Richtliniendatei über HTTPS (ein Nachmittag Arbeit, und damit wird ein Downgrade-Angriff verhindert).

Empfehlung. Kostet nichts.

RFC 8461 §3 — Policy Discovery

To discover if a recipient domain implements MTA-STS, a sender need only resolve a single TXT record.

Länge der Rücksendeadresse advisory.return_path_length

Wie lang die Bounce-Adresse ist. RFC 5321 verpflichtet einen empfangenden Server, 64 Oktette vor dem @ zu akzeptieren, und besagt im selben Abschnitt, dass keine Implementierung eine vermeidbare Begrenzung auferlegen sollte. Viele tun es trotzdem, und eine Nachricht, die diese Grenze überschreitet, wird bei MAIL FROM abgelehnt, noch bevor der Nachrichtentext gesendet wird. Sendeplattformen stoßen darauf, wenn sie den Empfänger in der Rücksendeadresse codieren, damit Bounces zugeordnet werden können. Dadurch hängt die Länge davon ab, an wen Sie schreiben, und nicht von Ihnen.

Bei einem Fehlschlag: Kürzen Sie den festen Teil, den Ihre Plattform voranstellt, oder wechseln Sie zu einer kürzeren Bounce-Domain. Wenn Sie beides nicht ändern können, sind Ihre Abonnenten mit den längsten Adressen gefährdet. Daher lohnt es sich, statt eines Durchschnitts die längste Adresse in Ihrer Liste zu messen.

Empfehlung. Kostet nichts.

RFC 5321 §4.5.3.1.1 — Local-part

The maximum total length of a user name or other local-part is 64 octets.

RFC 5321 §4.5.3.1 — Size Limits and Minimums

Every implementation MUST be able to receive objects of at least these sizes.

Haraka — the address parser that enforces the 64-octet local-part, and the flag that relaxes it

TLS-Berichterstattung advisory.tls_rpt

Ob die Domain Berichte anfordert, wenn jemand nicht über TLS an sie zustellen kann. Gehört zu MTA-STS: Ohne Berichterstattung können Sie nicht feststellen, ob die Richtlinie funktioniert.

Bei einem Fehlschlag: Fügen Sie den TXT-Eintrag mit einer Adresse hinzu, die die täglichen Berichte empfängt.

Empfehlung. Kostet nichts.

RFC 8460 §3 — Reporting Policy

A domain publishes a record to its DNS indicating that it wishes to receive reports.