Service status
Free Email Security Check
Check SPF, DKIM and DMARC for your email domain
Check an email domain
Check which settings your domain publishes for sending email and protecting transport. The domain check examines SPF, discoverable DKIM keys, DMARC and selected reachable mail-server signals. It explains noteworthy findings and identifies unresolved measurements.
You enter a domain. The check does not read a mailbox or real messages, examine attachments or need a mailbox password. A good result does not guarantee delivery.
Domain configuration and an individual message answer different questions
On narrow screens, scroll the table sideways.
| Your question | Check required | What it cannot establish |
|---|---|---|
| What does my domain publish? | The domain check available here reads public DNS records and selected mail-server signals. | It does not show an actual sent message or mailbox content. |
| Does a particular message pass SPF, DKIM and DMARC? | This requires examining the message, its sending identities and the check results determined on receipt. An optional private testmail extension is not currently offered through this page. | A single testmail shows only the observed message and receiving path, not a general inbox or delivery guarantee. It changes neither the domain findings nor their grade. |
Two questions, different evidence
The first question is what an email domain publishes. The public domain check receives the domain and, if needed, actual DKIM selectors. Among other things, it reads SPF rules, discoverable public DKIM keys and the DMARC policy, as well as selected reachable mail-server signals. Its STARTTLS probe connects to no more than three distinct MX hosts with the lowest numerical preference and sends no email; additional hosts at the same preference and MX hosts at other preference levels remain unmeasured. Read DNS and transport findings together with their measurement coverage; a failed connection does not prove that encrypted transport is absent in general. A discoverable DKIM key does not confirm a valid signature on a particular message. The domain check reads neither messages nor mailboxes.
The second question is different: does a particular message pass SPF, DKIM and DMARC? This requires examining the specific message, its sending identities and the results observed on receipt. An optional private testmail extension is not currently offered through this page; the domain check provides no access to it. A single testmail documents only the observed message and receiving path. It is neither a general delivery or inbox guarantee nor proof of a person’s identity, and it does not change the public domain findings or their grade. The offered domain-result-link email is a separate process and is not a testmail check. Domain results and report files are available in German and English.
A DNS key shows that a public key can be reached at a particular name. That alone does not establish whether your sending service signs the message with the matching private key or whether the signature is valid. Likewise, a published DMARC policy is not yet a passed DMARC result for a message.
What the domain check examines
On narrow screens, scroll the table sideways.
| Area | Observation and limit |
|---|---|
| SPF | Published sending rules and selected configuration characteristics, including the DNS queries evaluated within the limited scope. No SPF proof for every actual sending IP. |
| DKIM | Discoverable public keys through known selectors and those additionally supplied. The search is limited and does not verify a message signature. |
| DMARC | The published domain policy and its configuration. Message-specific SPF/DKIM alignment is not validated in the domain check. |
| MX and SMTP-TLS | Selected mail-server and transport characteristics. The STARTTLS probe connects from the test location to no more than three distinct MX hosts with the lowest numerical preference; it sends no email. MX hosts at other preference levels remain unmeasured. |
| MTA-STS and TLS-RPT | Published transport-policy and reporting information. No proof that every sender adopts it, and no analysis of TLS reports actually received. |
| DNSSEC, DANE and other domain characteristics | The DNS signals included in the relevant profile. A DANE/TLSA signal alone does not establish a verified match with the mail-server certificate actually used. |
The scope depends on domain use, reachability and measurability. Where no assessable response is available, the measurement remains unresolved. A failed connection does not prove that your mail server generally lacks support for encrypted connections.
The protocols behind the findings
SPF and DKIM authenticate different sending identities; DMARC links matching results to the visible From domain. Transport mechanisms serve a different purpose. The following explanation describes the protocols, not additional measurements by this domain check.
On narrow screens, scroll the table sideways.
| Protocol | Context and a typical next question |
|---|---|
| SPF – Sender Policy Framework | The recipient checks the sending IP against rules for the SMTP sender domain or HELO identity. The visible From address is not automatically that identity. Check forgotten sending services and DNS lookups; forwarding may cause SPF to fail if the forwarding IP is not authorised. |
| DKIM – DomainKeys Identified Mail | A signature covers selected headers and the message body. The signing domain and selector lead to the public key. Changes to signed content, an incorrect selector or uncoordinated key rotation can affect verification. The domain check does not verify this message signature. |
| DMARC – Domain-Based Message Authentication, Reporting, and Conformance | A message passes DMARC when at least one successful SPF or DKIM check is aligned with the visible From domain. The policy may request none, quarantine or reject; recipients apply additional rules of their own. Before tightening the policy, check actual senders, alignment and available reports. Missing reports do not provide a complete view of sending activity. |
| BIMI – Brand Indicators for Message Identification | Points to a brand logo for supporting services. The logo format, DMARC and service-specific certificate and display conditions must fit. A DNS record does not guarantee a displayed logo or verification mark. BIMI information is optional and unweighted in this check. |
| MTA-STS – Mail Transfer Agent Strict Transport Security | DNS under _mta-sts signals the policy version; the HTTPS file /.well-known/mta-sts.txt specifies the mode and MX names. Supporting senders implement the relevant requirements for inbound transport. Incorrect MX patterns or an unreachable policy are specific points to investigate. Enable enforce only when the necessary conditions are met; it does not force non-supporting senders to enforce the policy. No end-to-end encryption. |
| TLS-RPT – TLS Reporting | DNS under _smtp._tls specifies report destinations. Supporting senders may provide aggregate JSON reports about transport outcomes. Check the destination and the coverage actually received; the number and scope of reports depend on the participating senders. Wolf checks publication but does not collect or analyse these reports. |
The assessment belongs to the relevant domain profile
A+ is the highest grade. For sending domains, the email check uses grades A+, A, A-, B+, B, C, D and F, with its own weights and caps. This grade is not a deliverability percentage and cannot be compared directly with the web or API grade.
For A+ in the sending-domain profile, the DNSSEC evidence required by the model for MX and TXT must also be available. Without this evidence, A+ is not awarded; an unknown DNSSEC state is not a measured configuration defect. Other conditions in the assessment model may cap the grade.
Domains not intended to send email receive a separate assessment with its own scope. It considers, among other things, SPF -all, DMARC and Null MX. Public information does not prove that no message is ever actually sent under this domain. DNSSEC is not measured in this profile. If the result could be stored, PDF, DOCX and CSV are also available for this profile.
Read measurement coverage independently of the grade. Where the measurement basis is insufficient or basic checks remain unresolved, the overall grade may be omitted from the report. Unmeasured points are not passed checks. Even A+ does not rule out phishing, later misconfiguration or delivery problems.
Check specific points after a migration or change
- Check a domain you are authorised to examine. Enter known DKIM selectors if needed.
- Relate SPF, DKIM and DMARC findings to your actual sending services. Read DNS and transport findings together with their measurement limits.
- Pass specific questions to your IT team or provider. An additional sending service may need different settings from your normal mailbox.
- After making a change, start a new domain check if needed. Record message checks and their times separately.
The check does not change DNS records or configure a mail server. For further work, explanations of SPF, DKIM, DMARC, SMTP-TLS and MTA-STS are available. The DKIM setup guide complements these foundations.
Save the domain state for further work
The report files offered on the results page document the stored domain check. PDF is for reading and filing, DOCX for your own additions and CSV for working with the findings table. DOCX is editable; make your own additions recognisable.
Browser findings remain free. Order new report files separately; price, tax and scope appear before you place a binding order. Contract delivery requires an email address. Purchased originals remain in the archive for three calendar years from first delivery. Downloading does not start a new measurement; existing free-file promises retain their original validity.
The optional result-link email is a separate process from submitting a testmail. It unlocks no additional content and checks no message. The report page explains the contents, formats and use as a working document.
Frequently asked questions
Does the check examine suspicious emails or attachments?
No. The domain check is not a virus, attachment or mailbox scan. Do not submit message content or login details.
Why does the check not find my DKIM key?
The actual selector may fall outside the limited search. A missing DNS record or a restricted query may also be the cause. Find out which selector your sending service uses and enter it in the advanced options if needed. The presence of a _domainkey namespace alone establishes neither a public key nor a valid message signature.
Can a good result confirm my deliverability?
No. Content, reputation, sending practices and recipient rules also affect delivery. The domain check establishes neither inbox placement nor freedom from spam, nor the identity of a person.
Is the Wolf report a DMARC aggregate report?
No. DMARC aggregate reports come from receiving systems and describe observed messages. The Wolf report documents a domain check at a particular measurement time. Wolf-Agents does not thereby collect or analyse your DMARC aggregate reports.
Can I share the report as audit evidence?
You can use it as a technical working document for the stated scope. It is not a recognised audit, compliance or insurance certificate and contains no personal expert assessment of your domain. Review recommendations in the context of your environment; automatic assessments can be wrong.
Technical foundations
SPF: RFC 7208 · DKIM: RFC 6376 · DMARC: RFC 9989 · How we use AI
The standards describe the protocols. They do not extend the scope actually offered here.