You send a message to one client and it arrives; to another and it disappears, with no error and no notice. That is not a mail fault but a decision made by the receiving server based on three records in your domain. When they are missing or wrong, your mail is suspicious by default, and a carefully written subject line will not save it.
How a message is judged
The receiving server asks three questions. Is the sender actually allowed to send on behalf of this domain? Was the message altered in transit? Does the domain publish a clear policy for suspicious mail? The answers map to SPF, DKIM and DMARC. Absence means "unknown", and "unknown" is not a good answer.
SPF: who may send
A TXT record lists the servers allowed to send for your domain. A simplified example: v=spf1 include:_spf.provider.com -all. The ending matters: -all rejects everything outside the list, while ~all marks it suspicious but often accepts. A common mistake is publishing more than one SPF record; the standard allows one, and two invalidate each other. Another is exceeding the ten-lookup limit, which happens silently on domains that add many services.
DKIM: the signature that proves integrity
DKIM signs every message with a key published as a DNS record. Your provider gives you the key and record; you paste it unchanged. What breaks here is rewriting the message after signing: some tools add headers and invalidate the signature. Recheck after any new service touches your sending path.
DMARC: what to do with suspicious mail
DMARC combines the SPF and DKIM results and tells receivers what to do when checks fail, and where to send reports. Always start with p=none plus a report address, watch for two weeks, then move to quarantine. Jumping straight to reject can cut off your own legitimate mail because of a forgotten SPF entry.
Check your domain now
Read TXT and MX records from outside, confirm exactly one SPF record, that a DKIM key exists, and that DMARC states a policy. The DNS checker on this site shows records as the world sees them: the DNS records checker. Then send a test to an outside inbox and read the headers: SPF=pass and DKIM=pass must appear.
Three recurring mistakes
First: copying an SPF record with an include you do not recognise, leaving it meaningless. Second: forgetting to update DKIM after switching providers, so messages silently stop being signed. Third: using a From address outside the authenticated domain, the most common reason a message is treated as forgery.
Reading a DMARC report
A week after enabling reports, XML files arrive that look complex, but you need three facts from them: which IPs sent mail, whether SPF or DKIM passed, and whether the mail claimed your domain. Unknown addresses mean either a service you use without knowing, or an impersonation attempt. Add the legitimate services to SPF first, then watch for two more weeks before tightening the policy. Never tighten on the day the first report lands.
Shared services and hidden limits
When a third party sends on your behalf, it adds lookups to SPF and needs its own DKIM key. Every new service can silently break if you forget to add it, and the worst case is exceeding the lookup limit, which invalidates SPF for everyone at once. Document each service separately, and recheck the record after every addition rather than after complaints begin.
What not to do
Do not treat "the message arrived once" as proof. Do not run a newsletter from a personal mailbox. And do not keep resending tests into spam and blame the receiver. Start with the record, then the signature, then the policy, in that order. How the record types fit together is in DNS records explained, and mailbox setup itself is in the business email guide.