My email goes to spam
Content filtering is the smallest part of a modern spam verdict. The larger part is authentication: can the receiver establish that this message is authorised by the domain in RFC5322.From? If not, the message is filtered or rejected before anyone reads a word of it.
What the receiver evaluates
On delivery a receiver runs three checks, in this order. SPF (RFC 7208) compares the connecting IP against the v=spf1 record of the RFC5321.MailFrom domain. DKIM (RFC 6376) verifies the DKIM-Signature header against the public key at <selector>._domainkey.<d= domain>. DMARC (RFC 7489) then asks whether either of those passed and aligned with the domain in the visible From header.
Alignment is the part that surprises people. An SPF pass for bounces.provider.net does nothing for a message whose From reads you@yourdomain.com — under relaxed alignment the organisational domains have to match, under strict (aspf=s, adkim=s) the full domains do. A pass that does not align is a DMARC fail.
The three records involved
All three live in the DNS of your domain, not in your mail client, and all three are TXT records except MX.
v=spf1 …on the apex: which hosts may send for this domain, terminated by~allor-all. A sending service that is not included fails SPF.<selector>._domainkey.<domain>: the public key your sending service signs with. Absent or with an emptyp=, every signature it produces fails verification._dmarc.<domain>:v=DMARC1; p=…, the policy a receiver applies when neither check aligns, plusrua=for the daily aggregate reports.
What to measure first
Run the scan at the bottom of this page: it resolves all three over DNS-over-HTTPS, counts the SPF lookups, probes the selectors of every sending service it recognises from your MX and includes, and shows each record it read.
One failure mode outranks the rest: an SPF record over the ten-DNS-lookup limit of RFC 7208 §4.6.4. That is a permerror, not a warning, and receivers treat it as a fail — so part of your mail is already being rejected while the record looks perfectly reasonable.
If authentication is already clean
Then look at transport and reputation: the PTR of your sending IP and whether it forward-confirms, listing on Spamhaus or Spamcop, TLS on the connection, and the message itself — an HTML-only body, a mismatched Return-Path, or a missing List-Unsubscribe on bulk. A send test measures those on a real message; DNS alone cannot.
Frequently asked questions
Does rewording the message help?
Marginally. Content scoring still exists but is weighted far below authentication. A domain with an aligned DKIM pass and p=reject is delivered; an unauthenticated one is filtered whatever it says.
Do I have to change mail provider?
No. SPF, DKIM and DMARC are DNS records on your domain, independent of where the mailboxes run. You publish them at your DNS operator and keep the provider you have.