Email was designed in an era when everyone on the network was assumed to be acting in good faith. The protocol lets any server claim to be sending on behalf of any domain, and by default nothing checks that claim. SPF, DKIM and DMARC are the three records bolted on afterwards to fix it.
They are DNS records, which means they are public, which means anyone - including a prospect evaluating you, and including someone considering impersonating you - can check in seconds whether you have bothered.
What each one actually does
SPF: who is allowed to send
A Sender Policy Framework record is a TXT record listing the servers permitted to send mail for your domain. A receiving server looks up the record, compares it against where the message actually came from, and gets a pass or a fail.
v=spf1 include:_spf.google.com include:sendgrid.net -allRead that left to right: this is an SPF record; Google Workspace may send for us; SendGrid may send for us; anyone else is unauthorised.
The ending matters more than most of the record. -all is a hard fail: reject anything from elsewhere. ~all is a soft fail: treat it as suspicious but deliver it anyway. Many domains publish ~all and never revisit it, which means the record exists but declines to assert anything.
SPF has a real limitation: it validates the envelope sender, not the From: address the recipient sees. Those can differ. That is precisely the gap DKIM and DMARC close.
DKIM: proving the message was not tampered with
DomainKeys Identified Mail signs outgoing messages with a private key held by your mail provider. The matching public key is published in DNS. A receiving server fetches the public key, verifies the signature, and learns two things: the message genuinely originated from a system holding your key, and its contents were not altered in transit.
The public key lives at a selector-specific hostname, like google._domainkey.yourdomain.com. The selector is chosen by your provider, which is why automated tools generally cannot confirm DKIM for you - there is no fixed place to look. You turn it on in your mail provider's admin console and publish the record it gives you.
DMARC: the policy that makes the other two count
This is the one that does the work, and the one most often missing. DMARC does three things SPF and DKIM cannot do alone:
- It requires alignment - the domain that passed SPF or DKIM must match the domain in the visible
From:address, closing SPF's envelope gap. - It states a policy for failures, so receiving servers know whether to deliver, quarantine or reject.
- It requests reports, so you find out who is sending as you.
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1Published at _dmarc.yourdomain.com.
Why p=none is a starting line, not a finish line
p=none means: evaluate our mail, send us reports, and deliver everything regardless. It is genuinely the right place to begin, because it shows you every system sending as your domain - including the ones you forgot about, like the invoicing tool, the CRM and the recruiter platform someone signed up for in 2023.
But a domain sitting at p=none indefinitely has monitoring without enforcement. Someone spoofing you will still have their mail delivered. You will simply receive a report about it afterwards.
The progression is straightforward, and the middle step is where the patience is required:
- Publish
p=nonewith a reporting address. Collect for two to four weeks. - Read the reports. Find every legitimate sender that is failing, and fix it - usually by adding them to SPF or turning on DKIM in that tool.
- Move to
p=quarantine, optionally withpct=25to apply it to a fraction of mail first. - Move to
p=rejectonce quarantine is producing no surprises.
Skipping step two is how a DMARC rollout ends with someone's invoices silently disappearing.
The SPF mistakes that quietly break it
SPF has a few sharp edges that produce records which look fine and do not work.
The ten-lookup limit
SPF evaluation is capped at ten DNS lookups. Every include:, a, mx, ptr and redirect counts, and includes are recursive - a single include: for a large provider may consume several on its own.
Exceed the limit and evaluation returns permerror, which many receivers treat as a failure. The record exists, looks reasonable, and fails. Companies that have accumulated marketing tools, ticketing systems and invoicing platforms over a few years hit this regularly.
If you are near the limit, consolidate: remove senders you no longer use, and prefer ip4: entries over include: for services with stable addresses, since a direct address costs no lookup.
More than one SPF record
A domain must publish exactly one. Two TXT records both starting v=spf1 is a permerror - not a merge. This happens when a new tool's setup guide says "add this record" and someone adds it alongside the existing one instead of merging the include: into it.
Using ptr
The ptr mechanism is deprecated and some receivers ignore records that use it. If it is in yours, it is almost certainly a copy-paste from an old guide.
Reading a DMARC report without a tool
Aggregate reports arrive as gzipped XML, usually daily, and they are genuinely readable once you know what you are looking at. Each record block describes one sending source:
<record>
<row>
<source_ip>203.0.113.10</source_ip>
<count>47</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
</record>Read it as: 47 messages from this address; SPF passed, DKIM failed; we delivered them anyway because the policy is none.
What you are hunting for is sources with volume where both checks fail. Those are either a legitimate tool you have not authorised yet - fix before tightening the policy - or someone sending as you, which is the thing the policy exists to stop. Sources with one pass and one fail are usually a legitimate tool with a half-finished setup.
The record that gets forgotten: CAA
Not email authentication, but the same category of one-line DNS policy - and routinely missing. A Certification Authority Authorization record states which certificate authorities may issue certificates for your domain. Without one, any public CA may issue for you; with one, the rest are obliged to refuse.
yourdomain.com. IN CAA 0 issue "letsencrypt.org"
yourdomain.com. IN CAA 0 iodef "mailto:security@yourdomain.com"The second line asks CAs to notify you about requests that violate the policy. Both take about a minute to add, and they close off a category of mis-issuance entirely.
Checking what you have
All three records are public, so you can read your own from any machine:
dig +short TXT yourdomain.com # look for v=spf1
dig +short TXT _dmarc.yourdomain.com # look for v=DMARC1
dig +short CAA yourdomain.comOne thing worth knowing: these records live on your registrable domain, not on each hostname. Looking up SPF on www.yourdomain.com returns nothing, because that is not where it is published. If a tool reports your email authentication as missing, check that it is not querying the www hostname - that is a common enough bug that we fixed it in our own scanner.
Why this one is worth doing first
Most external findings require engineering work. This one requires three DNS records and the patience to read reports for a month. The failure it prevents - someone sending convincing email as your company, to your customers - is among the more damaging things that can happen to a small company's reputation, and among the cheapest to make substantially harder.
It is also, usefully, the finding that most often separates domains where someone has done a deliberate pass from domains where nobody has looked. That is part of your external security posture whether you manage it or not.