Table of Contents
- Why do Strato emails go to spam only sometimes (SPF, DKIM, DMARC DNS timeouts)?
- SPF check fails or “temp-errors”
- DKIM verification fails intermittently
- DMARC alignment breaks
- Mixed sending reputation inside Strato
- How to verify the cause (fast, practical checks)
- Inspect a failed message header from the recipient side and look for:
- Test DNS reliability for SPF and DKIM records:
- Check if different outbound IPs are used:
- Run a mail-tester style diagnostic (internal or third-party) to confirm:
- Remediation that typically works
- Stabilize DNS for authentication records
- Make DMARC explicit
- Confirm alignment
- Ask Strato for the concrete sending details
- If reputation is the issue
- What to request from Strato support (so the ticket doesn’t stall)
Why do Strato emails go to spam only sometimes (SPF, DKIM, DMARC DNS timeouts)?
When a receiving mail server evaluates a message, it usually checks three things quickly: identity, integrity, and reputation.
SPF check fails or “temp-errors”
SPF requires a DNS lookup of the sender domain’s SPF record. If Strato DNS is slow, inconsistent, or intermittently unreachable, the receiver may log a “temperror” or treat it as a fail. Some providers convert repeated temp-errors into spam placement.
DKIM verification fails intermittently
DKIM requires fetching a DKIM public key from DNS (the selector record). If that DNS query times out or returns inconsistent answers, the signature can’t be validated, and spam scoring rises sharply.
DMARC alignment breaks
DMARC depends on SPF and/or DKIM passing and aligning with the visible From domain. If SPF passes for Strato infrastructure but the “From” domain doesn’t align, or DKIM is missing/invalid, DMARC can fail and trigger spam/quarantine behavior.
Mixed sending reputation inside Strato
Large providers use multiple outbound IPs. If some IPs have weaker reputation (complaints, past abuse, shared hosting spillover), only certain messages—depending on which server/IP sends them—get filtered.
How to verify the cause (fast, practical checks)
Inspect a failed message header from the recipient side and look for:
Authentication-Results: lines showing spf=fail/temperror, dkim=fail/temperror, dmarc=fail
Any mention of dns timeout, no key, body hash did not verify, or policy=quarantine/reject
Test DNS reliability for SPF and DKIM records:
Query the SPF TXT record for the sending domain repeatedly from multiple resolvers (local ISP, Google 8.8.8.8, Cloudflare 1.1.1.1).
Query the DKIM selector TXT record repeatedly the same way.
Look for intermittent SERVFAIL, timeouts, or inconsistent answers.
Check if different outbound IPs are used:
Compare “Received:” headers across messages that arrive vs. messages that spam.
If the sending IP changes, reputation variance becomes a prime suspect.
Run a mail-tester style diagnostic (internal or third-party) to confirm:
SPF syntax and lookup count (SPF can fail if it exceeds 10 DNS lookups).
DKIM selector correctness and key length (weak keys can trigger negative scoring).
DMARC presence and policy.
Remediation that typically works
Stabilize DNS for authentication records
Ensure authoritative DNS answers are consistent across name servers.
Reduce TTL extremes that cause propagation churn.
Avoid frequent record changes during troubleshooting.
Make DMARC explicit
Publish DMARC with a monitoring policy first, e.g. p=none, then tighten later once pass rates stabilize.
Confirm alignment
Use the same organizational domain in visible From and DKIM d= domain.
Ensure SPF includes the exact Strato sending sources used for that domain.
Ask Strato for the concrete sending details
Outbound SMTP hostnames and the full list of sending IP ranges for the product tier.
Whether DKIM is enabled per mailbox/domain and which selector is used.
Whether traffic is routed through different clusters or shared IP pools.
If reputation is the issue
Move to a dedicated IP (if available) or a higher-tier sending pool.
Reduce complaint triggers: double opt-in lists, remove inactive addresses, consistent volumes.
What to request from Strato support (so the ticket doesn’t stall)
Provide 3–5 examples with timestamps, sender address, recipient domain, and full headers from a spammed message. Ask them to confirm:
- Whether there were DNS issues affecting SPF/DKIM lookups at the cited times
- Which outbound IP sent each message and whether that IP is on any internal suppression/poor-reputation lists
- Whether DKIM signing was active and successful on the outbound server for those messages
If the recipients are major providers (Google, Microsoft, GMX/Web.de), the header evidence usually pinpoints whether the problem is DNS/authentication instability or sending-IP reputation.