A client rings to say their invoices are going to spam. Sometimes it is the mail server. Far more often the mail server is doing exactly what it always did, and the reason the other end stopped believing it is three DNS records nobody owns.
SPF says who may send
A list of the servers allowed to send as your domain. It breaks in one of two ways: something new starts sending and is not on the list — a CRM, a payroll system, the accounting package that mails PDFs — or the list has been added to for years and quietly exceeded the ten-lookup limit, at which point the whole record is treated as invalid rather than as mostly right.
DKIM says the message was not altered
A signature on the way out, a public key in DNS, a check on the way in. It fails when a key is rotated at the provider and not in DNS, when a mailing list rewrites the body, or when a domain moves and the selector record is left behind with everything else that did not seem important.
DMARC says what to do when the first two disagree
This is the one that is usually missing, and it is the one that decides your fate. Without it, every receiving server applies its own judgement. With it, you say plainly what should happen to mail that fails, and you get reports telling you who is sending as you.
Publish it on p=none first and read the reports for a month. Almost everybody discovers a legitimate sender they had forgotten about. Moving to p=quarantine before that is how a company stops its own invoices.
Why this keeps happening
These records live in DNS, DNS usually sits with whoever registered the domain, and that is often not whoever runs the mail. So a change to the mail service is made by one supplier and the DNS half is nobody's job. The failure is slow and partial — some recipients, not all — which is why it is usually noticed weeks late, by a customer.
It is not difficult work. It just has to belong to somebody.