SPF, DKIM and DMARC: why your email lands in spam
Three DNS records decide whether Gmail believes your mail is yours. Getting them right also stops other people sending as you.
Two things bring this up. Either your quotations are landing in customers' junk folders, or somebody has been sending invoices in your company's name and you want it to stop. The same three records are the answer to both, which is the only tidy thing about this subject.
Email was designed without any way to prove who sent a message. The From address is typed by the sender, like the return address on an envelope. SPF, DKIM and DMARC are the retrofit, and they work by publishing statements in your domain's DNS that receiving mail servers can check.
These are the servers allowed to send mail for my domain. A list of sources, nothing more.
This message carries a signature that only my mail system could have produced, and the body has not been altered since.
If a message claiming to be from my domain fails both of the above, here is what I want you to do with it, and here is where to send me a report.
Why deliverability got stricter
Google and Yahoo began requiring authentication for bulk senders in 2024, and the effect spread further than bulk mail. Filters now treat an unauthenticated domain as weak evidence of legitimacy, so ordinary business mail from a domain with no DMARC record sits closer to the junk threshold than it used to.
If your mail is inconsistent, landing in the inbox for some recipients and junk for others, the usual cause is a sending source nobody remembered to authorize. Xero, Mailchimp, a booking system, the accounting package, the website contact form, the multifunction printer that scans to email. Each of these sends as you and each needs to be in the record.
How to do it without breaking your own mail
Start by listing every system that sends email in your name. Most companies find two or three they had forgotten. Then set SPF to include those sources, and enable DKIM signing in the Microsoft 365 admin center, which is a two-record change and a switch.
Publish DMARC at p=none first. That asks receivers to do nothing but send you reports, so you get a picture of what is sending as your domain without any risk of losing legitimate mail. Read those reports for a few weeks. When the only failures you see are things you do not recognize, move to p=quarantine, and later to p=reject if you want it.
Skipping the reporting stage is how people break invoicing. Somebody sets p=reject on a Friday, and on Monday the finance system's statements have been silently discarded by every recipient. The reports are dull, but they are the only way to know what you are about to switch off.
What it does not fix
DMARC at p=reject stops people sending mail that claims to come from your exact domain. It does nothing about a lookalike domain, because that domain is authenticated perfectly well by its owner. It also does nothing about a genuine compromised mailbox, yours or a supplier's, since that mail is authentic by every measure.
So treat this as the hygiene layer. It protects your name and your deliverability, and it is a common question on cyber insurance forms and in the Cyber Essentials assessment. It is not a defense against the invoice fraud that costs people money.