Password resets and receipts from my own domain keep landing in spam: what actually fixes deliverability?

Two practical things for your immediate problem.

Test properly rather than by sending to yourself. There are free services where you send one message to a generated address and get back a report: whether each of the three records passed, what your content scored, and whether the sending address is on any blocklist. That takes five minutes and it will tell you exactly which of your two configured records is wrong, which is the question you actually have.

Sending to your own account tells you very little, because your provider knows you.

Then check the reports. Once DMARC is set, you receive summaries of who is sending as your domain and whether it authenticated. That is the only place you will discover that the receipts go through a service you configured properly and the password resets go out through the application server directly, unsigned: which is an extremely common split and produces exactly your symptom of some mail arriving and some not.

On volume: a dozen a day is small, and small senders are held to a stricter standard because there is not enough traffic to build much reputation. That is a reason to get the records exactly right rather than a reason to despair: with all three correct and a separate transactional subdomain, low volume is not a problem.

The three records answer three different questions, and understanding which is which makes the whole thing straightforward.

SPF, who is allowed to send for this domain. A DNS record listing the servers permitted to send mail claiming to be from you. A receiver checks whether the sending server is on the list.

The common mistakes: having two SPF records, which is invalid and fails everything, and exceeding the lookup limit by including too many services.

DKIM, was this message actually sent by them and unmodified. Your sending service signs each message with a private key; the matching public key sits in your DNS. This is the strongest of the three because it survives forwarding.

The common mistake: setting it up for one service and later adding another that signs with a different key that was never published.

DMARC - what should a receiver do when SPF and DKIM disagree with the From address, and where should reports go. This is the one people skip, and it is the one that turns the other two from decoration into policy.

Set all three. Start DMARC in the mode that only reports, read the reports for a couple of weeks to find anything sending as you that you forgot about, then tighten it.

Without DMARC, receivers are guessing. With it, you are telling them.

Beyond the records, the things that actually move deliverability, roughly in order:

Reputation of the sending domain and address. Built over time by people opening your mail and not marking it as spam. This is why a brand new domain has a hard first month regardless of configuration.

Separate your streams. Send transactional mail from one subdomain and anything marketing from another. Then a newsletter that collects complaints cannot damage the reputation of your password resets. This is the single most valuable structural decision and almost nobody does it early.

Do not send to addresses that bounce. Repeated hard bounces are read as a sign you are not maintaining your list. Remove them immediately and automatically.

Make unsubscribing trivial for anything non-transactional. People who cannot unsubscribe mark as spam instead, and that is far more damaging.

Content matters less than people think, and it is not zero. Link shorteners, a single large image, mismatched display names and lots of exclamation marks all contribute.

Also check you are not on a blocklist, there are free lookup tools, and check whether your sending service puts you on a shared pool with other senders, since on a small volume you inherit their behaviour.