Distinguish domain configuration, transport and individual messages
Start with what your question concerns. “Secure email” can mean protecting your own sender domain, requiring an encrypted connection or assessing a suspicious message. A single DNS finding does not answer all these questions.
On narrow screens, scroll the table sideways.
| Your question | Relevant evidence | What remains unanswered |
|---|---|---|
| Which rules and keys does my domain publish? | DNS records and published policies, each with its name and observation time | Whether every sending service is configured correctly and actually produces valid message signatures |
| How are reception and transport configured? | Actual MX targets, the relevant transport policy and observations of the specified connection path | Other servers, connections and the complete journey of a message |
| What arrived in this particular message? | Original headers, specific sending identities and verification results from the trusted receiving system | Other sending paths, other messages and subsequent treatment by other recipients |
Checking whether an individual email address exists is another task again. Spam filter tests, attachment checks and a general deliverability analysis are likewise not results of a domain check.
SPF, DKIM and DMARC: choose your starting point
These three mechanisms help assess the use of domains in sending email. They do not encrypt message content or confirm a person’s identity.
The basics according to your specific question.
-
… which servers are allowed to send for a sending domain
- Brief explanation
- SPF checks the sending IP against the published rules for the SMTP sender domain or HELO identity. This is not automatically the visible From domain.
- Further reading
- SPF: understand sending rules and evaluation
-
… whether a message carries a valid domain signature
- Brief explanation
- DKIM checks a signature over the signed parts of a message. The signing domain and selector identify the corresponding public key. Publishing that key alone does not prove a valid message signature.
- Further reading
- DKIM: signing domain, selector and signature
-
… how these results relate to the visible sender domain
- Brief explanation
- For a DMARC pass, at least one successful check must align with the visible From domain: SPF for the
MAIL FROMidentity or DKIM. This relationship is called alignment. The domain owner also publishes a requested treatment for messages that fail DMARC. - Further reading
- DMARC: alignment, policy and reports
When the SMTP reverse path is empty, the MAIL FROM identity for SPF is formed from the local name postmaster and the HELO domain. A standalone HELO pass is not an additional alternative for DMARC. RFC 9989, section 3.2.4.
The mechanisms and their limits are described in RFC 7208, RFC 6376 and the current DMARC standard, RFC 9989. An authentication pass guarantees neither harmless content nor delivery to the inbox. Receiving services apply further rules.
If a scan reports a missing or unclear DKIM finding, first establish your sending service’s actual selector. A limited search for known selectors can miss an existing key. Before tightening a DMARC policy, check legitimate sending paths and their actual alignment. Publishing p=reject does not replace this work.
Who needs to change which setting?
A mailbox provider, a newsletter service and a website can use different sending paths for the same visible sender domain. Domain registration and DNS administration may also be handled by different providers. The MX record for reception therefore does not reliably identify the service that signs outgoing messages.
On narrow screens, scroll the table sideways.
| Role | What it is responsible for | What you need for the next action |
|---|---|---|
| Domain owner or responsible IT team | Intended domain use, legitimate sending services and policy decisions | An inventory of the sending paths actually used, including newsletters and automated messages |
| DNS administrator | The relevant zone and the records required by each service | The complete name, record type and value from the relevant service configuration |
| Sending service or its administrator | Signing domain, key, selector and enabled signing | That service’s configuration for your own domain; example values from another domain are not enough |
| Operator of the receiving system | Authentication checks, acceptance and further filtering decisions | A traceable finding on the actual receiving path |
Follow each additional sending service’s specific instructions. A generic extra SPF record or an arbitrary DKIM key will not complete the setup. Match the SPF rule to the sending paths actually authorised. For DKIM, the DNS value and the signer actually used must correspond. The general DKIM setup guide brings these details together.
Setup guidance for your sending service
Choose guidance for the specific process. A personal Gmail or Outlook.com mailbox does not provide administrative access to your own Google Workspace or Microsoft 365 domain.
Set up DKIM: the general process and two specific service paths.
-
The signer, selector or DNS responsibility is still unclear
- Relevant guide
- Set up DKIM: general guide
- What to focus on
- Establish responsibilities, publish the record, enable signing and check a message separately
-
Gmail sends for your own Workspace domain
- Relevant guide
- Set up DKIM in Google Workspace
- What to focus on
- Publish the value for the selected domain and enable signing in the service
-
Exchange Online sends for your own domain
- Relevant guide
- Set up DKIM in Microsoft 365
- What to focus on
- Use the two CNAME targets actually specified and check the signing status
The vendors describe publication and activation as separate steps: Google Workspace: set up DKIM and Microsoft 365: DKIM for custom domains. Use your environment’s values. A guide is not evidence that your setup succeeded.
Reception and transport: MX, SMTP-TLS and MTA-STS
MX records identify the mail servers that receive email for a domain. TLS can encrypt an SMTP connection. With MTA-STS, the receiving domain additionally publishes a policy with requirements for TLS and matching MX targets. Supporting sending mail servers take these into account when establishing a connection. The DNS indication, the policy served over HTTPS and its application by a sender are separate steps. SMTP: RFC 5321, section 5, STARTTLS: RFC 3207, MTA-STS: RFC 8461.
Transport questions and where to continue.
-
Which mail server accepts messages for my domain?
- Starting point
- MX records and receiving infrastructure
- Next check
- First establish the actual MX targets and who administers them
-
What do STARTTLS and a certificate demonstrate?
- Starting point
- Understand SMTP-TLS and certificates
- Next check
- Establish the connection’s direction, host, port and trust model
-
How do MX records, an HTTPS policy and supporting senders work together?
- Starting point
- Understand MTA-STS and TLS-RPT
- Next check
- Check MX names, policy content and the behaviour of supporting senders separately
A successful connection to one examined MX does not establish the state of every other server or message path. Conversely, a failed connection attempt does not prove that encrypted transport is generally absent. Read the target, observation time and incomplete measurements alongside the finding.
SMTP-TLS does not provide end-to-end encryption of content. TLS-RPT also has a distinct purpose: supporting senders can provide transport reports. Publishing a reporting destination is not the same as receiving a report. TLS-RPT: RFC 8460.
Examine an individual message
To answer “What SPF, DKIM and DMARC results did the receiving system determine for this message?”, you need the specific message and its receiving context. Original headers let you identify the visible From, SMTP identities, DKIM-Signature and Authentication-Results. Trust the results of the responsible receiving system; a header with the same name inserted by the sender is not reliable evidence. The guide to interpreting header findings explains this distinction. RFC 8601 describes the trust boundary.
Through the German email check, Wolf-Agents offers an optional private test email feature as a free beta with a limited scope. It is intended for your own newly sent test message. The public domain check remains usable without selecting this feature. The private evaluation adds to your understanding; it does not automatically change the public domain finding or its grade. One test email covers only the sending and receiving path examined.
Understand the domain check and private test email
An offered email containing the domain result link is a different process from checking a test message. The beta does not provide a collection service for DMARC aggregate reports (RUA) or continuous monitoring. For delivery problems, you also need the specific error, sending logs where relevant and the receiving service’s feedback.
Continue after a finding or a change
- State the open question. Does it concern a published setting, activation in the sending service, receiving transport or a particular message?
- Choose the relevant explanation and instructions. Agree changes with the responsible person and use the values for your own domain and services.
- Review the relevant evidence again. A DNS change requires a new DNS observation. A change to signing additionally requires a message finding from the affected sending path. Record observation time and coverage separately.
To examine the public configuration of your own domain or one you are authorised to check, use the email domain check. It examines published information and selected signals from reachable mail servers. It does not claim to check your entire mail operation.
If you need to pass an observed domain state to your IT team or a service provider, an offered report can document that state and its measurement limits. The report overview explains its purpose. A Wolf report is not a DMARC aggregate report, a compliance certificate or a delivery guarantee.
Further questions covered by the guide
Domain authentication is not enough to assess a suspicious message: correctly authenticated messages can also deceive. The Guide to email threats covers spoofing, phishing, business identity fraud and other message-related topics. The domain check does not examine attachments or mailbox contents.
Other available chapters address further questions:
-
Introduction to email architecture
For an overview of a message’s journey.
-
Introduce a DMARC policy step by step
For planning based on findings from actual sending operations.
-
DNS security
For DNSSEC and DANE; assess the scope of their evidence separately.
-
ARC and email gateways
For indirect mail flows and intermediary systems.
-
BIMI and logo display
For an optional feature of participating receiving services.
-
Email aliases
For organising different addresses.
-
Compliance and documentation
For a separate assessment of organisational requirements. A scan does not confirm legal compliance.
Common questions when getting started
Do I need to set up every mechanism?
The choice depends on whether your domain sends, receives or does not use email at all. Also establish your sending services and the receiving services’ requirements. Authentication, transport protection, content encryption and optional logo display serve different purposes. A complete chapter list is not a universal list of obligations.
Is an existing DKIM record enough to verify the setup?
It answers which public key can be found at the queried name. The correct service must also sign, and the specific message’s signature must pass verification. A DKIM pass only contributes to a DMARC pass if its signing domain aligns appropriately with the visible From domain. Alternatively, an SPF pass for the appropriately aligned MAIL FROM identity can suffice.
Why does an authenticated message still end up in spam?
Authentication is only part of the recipient’s decision. Content, reputation, sending practices and other recipient rules can lead to different treatment. Read the specific service’s feedback; the Gmail sender guidelines are one example of service-specific requirements. A domain check cannot promise inbox placement.
Do I have to submit a message to use the guide or domain check?
No. You can use the guide and the free domain check without sending your own test email. The private test email feature is an optional, separate check of your own message. It is not an upload facility for generally investigating suspicious emails from other people.
Technical sources
The standards explain mechanisms and their limits; they do not confirm an individual configuration or expand the scope of a Wolf check.
- SPF: RFC 7208, particularly sections 2 and 3.
- DKIM: RFC 6376, particularly sections 1, 3 and 6.
- DMARC: RFC 9989, particularly sections 1, 4 and 5.
- SMTP destination selection: RFC 5321, section 5 and STARTTLS: RFC 3207.
- MTA-STS: RFC 8461 and TLS-RPT: RFC 8460.
- Trusting Authentication-Results: RFC 8601.
- Google Workspace: set up DKIM, Microsoft 365: configure DKIM and Gmail sender guidelines.