mail delivery records
These are DNS records that prove email claiming to come from your domain is genuine, so mailboxes trust it instead of filing it as spam or blocking it outright.
Every domain has a set of DNS records whose only job is proving that email claiming to come from that domain is genuine. Without them, anyone could send a message that looks like it came from yourbusiness.com, and receiving mailboxes would have no way to tell the difference between that and the real thing. Mail delivery records exist to close that gap.
There are three that matter most. SPF lists which servers are allowed to send mail on behalf of your domain. DKIM attaches a digital signature to outgoing mail that proves it was not altered in transit. DMARC tells receiving mailboxes what to do with a message that fails those checks, whether to flag it, quarantine it, or reject it outright. Together, they are the reason a message from your domain lands in an inbox instead of a spam folder, or gets blocked entirely.
These records live alongside every other DNS entry for the domain, which means whoever manages that DNS is responsible for keeping them correct, especially whenever a new service starts sending mail on the domain’s behalf.
Why it matters to you
Get these wrong, or leave them missing, and email genuinely sent by you or your business can end up filtered as spam, or refused entirely by careful mail providers. That includes both your everyday email through a provider like Google Workspace and any automated notifications your website sends, such as a form submission routed through Cloudflare Email Sending.
It also matters because these records need updating any time a new tool starts sending mail on your domain’s behalf. Add a new marketing platform or booking system without updating them, and mail from that new service can start failing checks, sometimes while your existing mail keeps working fine, which makes the problem harder to notice.
How I set it up
Whenever a service is authorised to send email from a client’s domain, whether that is Google Workspace, Cloudflare Email Sending, or another tool, I add or update the SPF, DKIM and DMARC records at the same time as the rest of that domain’s DNS setup, rather than treating them as a separate step to circle back to later.
I keep the DMARC policy set to actually reject or quarantine mail that fails, not just report on it silently, since a policy that only watches without acting leaves the door open exactly where these records are meant to close it.
What it looks like in practice
You never see these records directly. What you see is email that lands where it should, both yours and your website’s automated notifications, without landing in spam or bouncing back unexplained. The only time these come up in conversation is when adding a brand new tool that needs to send mail on the domain’s behalf, at which point updating them is a five-minute part of that tool’s setup.
Questions I get about this
- Why would my own email start getting marked as spam?
- Mailboxes like Gmail and Outlook check whether a message claiming to be from your domain is actually authorised to send from it. Without the right records in place, that check fails, and the receiving mailbox treats the message as suspicious even though you genuinely sent it.
- Do I need to manage these myself?
- No, and you generally should not touch them without knowing exactly what they do, since a wrong entry can break legitimate mail sending. This is one of the DNS details worth leaving to whoever manages your domain's DNS records.
Want this set up properly for your business?
This is the kind of thing I build every week. Grab a time and we will talk through what fits.