How SPF, DKIM and DMARC work in plain language
Understand what each email authentication record actually proves, what none of them prevent, and why moving straight to a reject policy breaks your own mail.
Your invoices are landing in spam
The symptom is familiar. Customers say they never received the quotation. Invoices arrive in the junk folder. A newsletter goes out and the delivery report shows a large share of addresses untouched. Somebody suggests three acronyms and sends you a screenshot of a DNS panel.
SPF DKIM and DMARC are not deliverability tools in the way they are usually sold. They answer one question. Is this message really from the domain it claims to be from. Every mailbox provider checks that before it considers anything else. A domain that cannot answer the question has a ceiling on its delivery no matter how good the content is.
What these records do not do and what they cost
None of the three stops spam arriving in your own inbox. They protect your domain's outbound reputation rather than your staff's attention. They also do not stop a lookalike domain. Someone registering a domain one character different from yours is unaffected by anything in your DNS. And they do not make a badly written email land in the primary tab. Content engagement and complaint history still decide that.
The direct cost is nothing. These are DNS records and your domain registrar or hosting panel already lets you create them. The real cost is inventory work. Somebody has to list every system that sends mail using your domain. Your mail provider the website contact form the invoicing software the CRM the marketing platform the helpdesk and whatever a former employee set up in 2019 all count. Missing one of them is how businesses break their own mail.
Who needs to do this and who can wait
Every domain that sends mail should publish SPF and DKIM. There is no business case against it. DMARC enforcement is the part that needs judgement. It matters most for businesses that send invoices handle payment instructions or are plausibly worth impersonating. Manufacturers exporters professional firms and anyone whose customers transfer money on the strength of an email sit in that group.
Enforcement should wait for an organisation that cannot yet list its sending systems. A business with marketing handled by one agency invoicing by an accountant and a website built by a freelancer who has since vanished does not know what sends on its behalf. Publishing a reject policy in that position stops legitimate invoices from reaching customers and the failure is silent on your side. A parked domain that sends no mail is a different case and benefits from a policy that tells receivers to reject everything claiming to be from it.
What each record actually checks
SPF is a published list. A TXT record on your domain names the servers permitted to send on your behalf and the receiving server checks the connecting server against that list. It breaks when mail is forwarded because the forwarding server is not on your list. The specification also limits an SPF evaluation to ten DNS lookups so a record that chains through many providers can fail purely on complexity.
DKIM is a signature. Your sending system signs each message with a private key and publishes the matching public key in DNS. The receiver verifies that the signed parts of the message were not altered in transit. Because the signature travels with the message it survives forwarding better than SPF does.
DMARC ties the two to the address your recipient actually sees. It requires that an SPF or DKIM pass belongs to the same domain as the visible From address which is called alignment. A message can pass SPF for some other domain and still fail DMARC. The record then states the policy. None means monitor only. Quarantine means treat suspect mail as spam. Reject means refuse it. DMARC also requests aggregate reports and those reports are the only reliable way to discover what is sending as you.
Judging whether it is set up correctly
The flattering measure is a green tick from an online checker or a single test mail that shows three passes. It tells you the record parses and that one route works. It says nothing about the eleven other systems sending as your domain.
The measure that matters is the share of mail in your DMARC aggregate reports that passes with alignment broken down by sending source. That is the figure to drive upward before changing policy. Watch delivery complaints from customers in parallel because reports lag and a human telling you they stopped receiving invoices is faster than any dashboard.
The mistake that stops your own email
The common mistake is publishing a reject policy on day one. It is one line of DNS and it feels decisive. Every system you forgot now fails authentication and its mail is refused outright. The mail that disappears first is usually transactional. Invoices order confirmations password resets and quotations all vanish and nobody tells you because the rejection happens at the receiving server.
The sequence that avoids this is unglamorous. Publish SPF and DKIM. Publish DMARC with a monitoring policy and collect reports for several weeks. Fix each sending source the reports reveal. Move to quarantine and watch. Only then move to reject. The second common mistake is publishing two SPF records on one domain which invalidates both. One domain carries exactly one SPF record and additional senders are added inside it.
This guide explains how something works. It is not legal, tax or financial advice, and rules change. Confirm anything regulatory with a qualified professional before you act on it.