Why email ends up in spam
Since February 2024 Gmail and Yahoo are strict: anyone writing to their users needs SPF or DKIM, both plus DMARC above 5,000 messages a day, plus matching reverse DNS and TLS. Other providers such as Microsoft follow suit. If anything is missing, messages land in spam or are rejected outright, even a perfectly harmless invoice or the website's contact form.
What the mail check covers
- MX: which servers accept email for the domain, with provider, IP addresses and reverse DNS. The tool also detects null MX (domain deliberately accepts no email) and missing MX records.
- SPF: the TXT record defining which servers may send for the domain. The tool resolves all
includeandredirectchains and counts the DNS lookups. More than 10 is a hard error many people miss. - DKIM: the public key receivers use to verify a message's signature. The mail check tries about 50 common selectors (Plesk, Microsoft 365, Mailchimp and others) and shows the key length.
- DMARC: the policy for messages that fail SPF and DKIM, and where reports go.
- SMTP and STARTTLS: the mail server is contacted on port 25. The tool reads the greeting, checks STARTTLS, the TLS version and the certificate, and says goodbye. No email is delivered.
- MTA-STS, TLS-RPT, BIMI: newer standards for enforced encryption, reports about it and the brand logo in the inbox.
SPF, DKIM and DMARC in one sentence each
SPF says which servers may send. DKIM signs every message so that changes in transit are detected. DMARC ties both to the visible sender address and defines what happens to forgeries: nothing (p=none), spam folder (quarantine) or rejection (reject). Without DMARC anyone can send email with your domain as the sender, and many receivers still deliver it.
A safe order: set up SPF and DKIM first, then DMARC with p=none and a report address. After two to four weeks look at the reports: if only your own servers appear, raise to quarantine and later reject. Starting with reject right away easily locks out your own newsletter service.
Enabling DKIM in Plesk
In Plesk under Websites & Domains, Mail, tab Mail Settings, enable "Use DKIM spam protection system to sign outgoing email messages". Plesk creates the key under the selector default. If the domain's DNS is not managed by Plesk (for example at Cloudflare), the TXT record default._domainkey shown there must be added manually. This is often forgotten: the server then signs, but nobody can verify the signature.
Reverse DNS and the 10-lookup limit
A mail server needs a PTR record pointing to its name, and that name must resolve back to the same IP (forward-confirmed reverse DNS). The PTR is not set by the domain owner but by the operator of the IP network, usually the hosting provider in the customer panel.
In SPF every include, a, mx, exists and redirect counts as a DNS lookup, including nested records. More than 10 lead to a permerror, and SPF is then treated as missing. Typical cause: Microsoft 365, a newsletter service, a CRM and your own server, each with its own includes.
One-liners for mail and DNS
- Show the SPF record of a domain
- Check a domain's DKIM key in DNS
- Show the DMARC policy of a domain
- Test an SMTP connection with STARTTLS and certificate
- Verify reverse DNS of a mail server IP (FCrDNS)
- Check if a server IP is on the Spamhaus blacklist
- Find permanently rejected emails in the mail log
Privacy
The check runs on the myline.de server. It queries the domain's DNS records and connects to the most important mail server on port 25, just as any mail server does before delivering. No email is sent and no address is verified: for an email address only the part after the @ matters, the part before it is neither used nor stored. The shareable link only contains the domain. To prevent abuse there is a limit of 20 checks per hour, for which only an encrypted check value is kept briefly, never an IP address.