When mail ends up in the recipient's spam folder or gets rejected, the cause is very often not a “broken” setting but a misunderstanding: SPF, DKIM and DMARC check different senders. Once that is clear, the usual failure patterns are easy to sort out.
The difference in 30 seconds
| Checks | In DNS as | If it is missing | |
|---|---|---|---|
| SPF | May this server send for the domain? | TXT on the domain: v=spf1 … | Others can spoof your domain more easily; mail lands in spam more often. |
| DKIM | Is the mail unchanged and signed by the domain? | TXT at selector._domainkey | Forwarding breaks SPF — without DKIM the mail then passes nothing. |
| DMARC | Does SPF or DKIM match the visible From domain — and what if not? | TXT at _dmarc: v=DMARC1; p=… | No policy, no reports; Gmail and Microsoft require DMARC for bulk senders. |
Check it yourself: mail DNS checker (MX, PTR, SPF, DMARC), SPF lookup limit and the DMARC generator for the right record.
What SPF, DKIM and DMARC actually check
SPF answers exactly one question: is the sending IP address allowed to send mail for the domain in the envelope sender (also MAIL FROM or Return-Path)? Recipients usually never see that address. The visible From: address plays no role for SPF.
DKIM checks whether a domain cryptographically signed the message (the d= tag of the signature) and whether it was altered in transit. The receiver fetches the public key from DNS (selector._domainkey.domain).
DMARC ties both to what the recipient actually sees: the From domain. DMARC requires that SPF or DKIM passes and that the domain that was checked matches the From domain (“alignment”). The policy (none, quarantine, reject) tells the receiver what to do on failure.
The alignment problem
A typical case: a newsletter service sends mail with the visible sender info@example.com but uses its own domain as the return path, for example bounce.newsletter-service.com.
Result: SPF passes – for newsletter-service.com. A DKIM signature with d=newsletter-service.com passes as well. Neither domain matches example.com, so DMARC fails even though the header says “spf=pass”.
Alignment comes in two modes: relaxed (the default, aspf=r/adkim=r) accepts subdomains of the same organisational domain, e.g. mail.example.com for example.com. Strict requires the exact same domain.
Fix: set up DKIM with your own domain at the sending service (usually one or two CNAME or TXT records) and, if possible, configure a custom return-path domain. DMARC then passes via DKIM even when SPF is not aligned.
Reading the headers
Open the message source in your mail client (in Gmail: “Show original”) and look for Authentication-Results:
Authentication-Results: mx.example.net;
spf=pass smtp.mailfrom=bounce.newsletter-service.com;
dkim=pass header.d=newsletter-service.com;
dmarc=fail (p=QUARANTINE) header.from=example.comThe pattern is obvious: SPF and DKIM pass, but for newsletter-service.com instead of example.com. Comparing smtp.mailfrom and header.d with header.from is the most important step of the investigation.
Commands to check
dig +short TXT example.com | grep -i spf
dig +short TXT _dmarc.example.com
dig +short TXT selector1._domainkey.example.comTypical mistakes you will spot:
Multiple SPF records: a domain may have only one TXT record starting with v=spf1. Two records cause a permerror – all senders must be listed in a single record.
Too many DNS lookups: SPF allows at most 10 lookups (include, a, mx, redirect …). Pulling in many services with include exceeds that quickly – again a permerror.
Wrong selector: find the selector in the header (s= in the DKIM signature) instead of guessing.
The order in which to roll everything out
1. Clean up SPF. One record, all legitimate senders included, ending in ~all at first.
2. Enable DKIM at every sending service – each time with your own domain (webmail, newsletter tool, ticket system, CRM, invoicing software …).
3. Start DMARC in monitoring mode:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"Read the aggregate reports (rua) for two to four weeks: who actually sends mail in your name? A long-forgotten service often shows up.
4. Tighten step by step: p=quarantine (start with pct=10 and increase), and only then p=reject.
Other reasons for spam classification
Missing or wrong PTR record (reverse DNS) on your own mail server: the IP should point to a hostname that resolves back to the same IP.
IP address on a blocklist – unfortunately common after a migration or on a shared IP (for migrations see DNS migration without downtime).
A sudden burst of mail from a previously quiet domain.
Bulk mail without an unsubscribe link: since 2024 Google and Yahoo expect senders of larger volumes to have SPF, DKIM, DMARC, one-click unsubscribe via List-Unsubscribe and low spam rates.
Checklist
- Exactly one SPF record, at most 10 lookups?
- DKIM active with your own domain at every sending service?
- DMARC record present and reports being read?
- In the header: does
header.frommatchsmtp.mailfromorheader.d? - PTR record correct, IP not listed?
Most “spam problems” are not delivery problems but identity problems: the receiver cannot verify that the mail really comes from the domain in the sender field. Prove it with clean alignment and you solve the bulk of cases.
Translated from the German original.