Understand sending configuration
See which rules and keys your domain publishes and which settings need a closer technical review.
Free email security check
Check your domain’s SPF, DKIM and DMARC
See what your domain publishes about email sending and transport protection. Wolf-Agents checks features including SPF, discoverable DKIM keys, DMARC and signals from reachable mail servers. The results explain potential issues and measurement gaps.
The tool checks domain configuration. It does not read mailboxes, scan attachments or guarantee message delivery. Results, report files and optional result emails are currently in German.
Free report beta: no Wolf-Agents account and no email address required.
Check an email domain
A+
A
B
C
D
F
Best grade within the check scope High risk
What you can do with the result
Review transport signals
Check selected DNS and reachable mail-server signals. Incomplete measurements remain clearly identified.
Work with the people responsible
Discuss specific findings with your internal IT team or provider. The report records the scan results for that discussion.
What the email check covers
| Area | What the check says |
|---|---|
| SPF | Published email-sending rules and selected configuration features |
| DKIM | Discoverable DNS keys using a limited selector search; not proof that every message is correctly signed |
| DMARC | The published domain policy and its configuration |
| Mail servers and transport | Selected MX, SMTP/TLS and transport-protection signals, where reachable and measurable |
| Further DNS security features | Domain features within the relevant scope, depending on domain use and available measurements |
SPF, DKIM and DMARC work together but serve different purposes. A DNS record alone does not prove that every sending service is configured correctly or every message passes its expected checks.
What this check leaves open
The domain check does not read real messages or examine mailboxes, login credentials, attachments, spam filters or the reputation of every sending IP address. It does not prove general protection against phishing or guarantee deliverability.
The DKIM selector search is limited. A key that is not found does not prove the domain never uses DKIM. The signature and alignment of a particular message need to be assessed using that message.
Understanding email security
The key email security protocols
Modern email security rests on several protocols that work together. Here you can read what each protocol does, how it works and which problems typically come up.
Outbound email (authentication)
Inbound email (transport protection)
SPF Sender Policy Framework
What it does
SPF publishes rules for which systems may use a domain as an SMTP sender. This means the envelope sender domain or the HELO identity, not automatically the visible From address.
How it works
The receiving server evaluates the SPF rules of that domain against the IP address of the sending server. Rules can also point to further DNS lookups. DMARC additionally considers alignment with the visible sender domain.
Typical problems
- 10-lookup limit exceeded by too many include statements
- Third-party services (newsletter, CRM) left out of the SPF record
- SPF fails when email is forwarded, because the IP address of the forwarding server is not authorised
DKIM DomainKeys Identified Mail
What it does
DKIM lets a sending service digitally sign selected message headers and the message body. The recipient checks the signature against a published DNS key.
How it works
The DKIM signature names the signing domain and a selector. That is how the recipient finds the public key in DNS. The domain check looks for those keys; it does not verify the signature of a real message.
Typical problems
- Content changes made by forwarding servers invalidate the signature
- Key rotation not coordinated with DNS publication and with messages still in transit
- Selector configured incorrectly for third-party services
DMARC Domain-based Message Authentication
What it does
DMARC ties the visible sender domain to the SPF and DKIM results and publishes a policy for how failures are to be handled.
How it works
DMARC passes when at least one successful SPF or DKIM check is aligned with the visible sender domain. The policy can ask for none, quarantine or reject; receiving systems also apply rules of their own. Reports from participating recipients can help with the analysis.
Typical problems
- Moving to p=reject too quickly, before every sending source has been recorded
- Subdomain alignment (aspf/adkim) not configured correctly
- Reports never analysed - shadow IT sources stay undetected
BIMI Brand Indicators for Message Identification
What it does
BIMI publishes a pointer to a brand logo for email services that support it. An existing DNS record guarantees neither that the logo is shown nor that a verification marker appears.
How it works
Whether the logo is shown depends on the DMARC configuration, the logo format and the rules of the receiving service. Depending on the service, additional certificates are required. The domain check grants no trade mark or certificate approval.
Typical problems
- Logo not in the correct SVG Tiny PS format
- The certificate or display requirements of the receiving service are not met
- If BIMI display is wanted: check the recipient’s DMARC requirements and coordinate policy changes with legitimate sending paths
MTA-STS Mail Transfer Agent Strict Transport Security
What it does
MTA-STS publishes requirements for TLS connections to the receiving mail servers of a domain. They are enforced by sending systems that support the standard.
How it works
A DNS record under _mta-sts points to the current policy version; an HTTPS file under /.well-known/mta-sts.txt describes the mode and the permitted MX hosts. In enforce mode, supporting senders are meant to use only matching encrypted connections. This is not end-to-end encryption.
Typical problems
- Policy file not reachable over HTTPS, or published under the wrong path
- MX entries in the policy do not match DNS
- Switching to enforce too quickly - older servers cannot establish a TLS connection
TLS-RPT TLS Reporting
What it does
TLS-RPT lets supporting senders deliver reports about successful or failed TLS connections to your domain.
How it works
A DNS record under _smtp._tls sets the report destinations by email or HTTPS. Supporting senders can send aggregated JSON reports. The Wolf-Agents domain check examines the published configuration; it does not collect or analyse those reports.
Typical problems
- No report address configured - no visibility into TLS problems
- Report volume can be considerable where email volume is high
- Reports are missing or cover only some of the sending systems
Setup and troubleshooting: Email security guides (German). How the parts fit together: DMARC and identifier alignment.
Turn the email results into a report
The email report documents the checked domain configuration, findings, explanations and coverage notes. Save the PDF, add your own notes in DOCX or continue working with the findings table in CSV.
The available report files are free during the beta, with no email address required. Domains that do not send email also receive PDF, DOCX and CSV reports when the result could be stored for download; the report then uses the separate scope for non-sending domains.
Sending a report by email is optional and unlocks no further content. Save the files you need locally: you can only download them again while the corresponding result is still available.
How to proceed
- Enter a domain you are authorised to assess and start the check.
- Review the findings about domain use, DNS and reachable mail-server signals. Pay attention to limited or missing measurements.
- Use the available files for your next steps. After making changes, run another check yourself if needed.
Questions about the email security check
Do you scan my mailbox or suspicious attachments?
No. You enter a domain. The tool examines its public configuration and selected signals from reachable mail servers. It is not an antivirus, attachment or mailbox scanner.
Can I check SPF, DKIM and DMARC together?
Yes, within the scope described here. SPF and DMARC are assessed using published domain information. DKIM keys must be reachable through a discoverable selector. The limited search may not find every key in use.
Why was my DKIM key not found?
The selector may fall outside the search, a DNS record may be missing or the lookup may be limited. Check the actual selector used by your sending service; you can enter custom names in the advanced options. A missing result alone does not prove that your messages lack DKIM signatures. Conversely, an existing _domainkey namespace alone proves neither a public key nor a verified message signature.
Does a good result prove my emails will be delivered?
No. Delivery also depends on factors this check does not assess, including message content, reputation, sending practices and recipient rules. The result evaluates selected configuration features of your domain.
Does the tool validate DMARC alignment for my messages?
It checks domain information, not real sent messages. Whether SPF or DKIM aligns with the visible sender domain for a particular message must be assessed using that message and its authentication results.
Can I check a domain that does not send email?
Yes. It has a separate assessment, with a different scope from a sending domain. When the result could be stored for download, PDF, DOCX and CSV are available for it as well. An unmeasured item is not a passed test.
Is a Wolf-Agents report a DMARC aggregate report?
No. DMARC aggregate reports are messages from receiving systems about email they have observed. Our report documents a technical domain check at a particular time. It does not collect or analyse your DMARC aggregate reports.
Where can I find setup guidance?
Our email security guides — German cover specific configuration tasks, including SPF at STRATO — German, DKIM at Netcup — German and SMTP TLS at Hetzner — German.