The problem they solve
Email was designed in the 1970s without authentication. Anyone can send an email that claims to be from any address. Without additional controls, an attacker can send an email that appears to come from your domain — your clients receive it, it looks legitimate, and they have no technical way to know it is fake.
SPF, DKIM, and DMARC are three DNS-based standards that, together, allow receiving mail servers to verify that email claiming to come from your domain actually came from your authorized infrastructure.
SPF — Sender Policy Framework
SPF is a DNS record that lists the mail servers authorized to send email on behalf of your domain. When someone receives an email claiming to be from yourfirm.com, their mail server checks the SPF record for yourfirm.com and asks: did this email come from a server on the approved list?
What an SPF record looks like
v=spf1 include:_spf.google.com include:sendgrid.net -all
This record says: email from yourfirm.com is legitimate if it comes from Google's mail servers or SendGrid. The -all at the end means any other source should be rejected.
The limitation of SPF
SPF checks the technical "envelope from" address — not the "From" header that you actually see in your email client. A sophisticated attacker can pass SPF while still displaying a spoofed from address to the recipient. This is why SPF alone is not enough.
DKIM — DomainKeys Identified Mail
DKIM adds a cryptographic signature to every outgoing email. Your mail server signs the message with a private key. The corresponding public key is published in your DNS. When a receiving mail server gets the message, it can verify the signature and confirm that the message came from your infrastructure and was not modified in transit.
What DKIM proves
If DKIM verification passes, it means two things: the email was sent by someone with access to your private signing key, and the content of the email was not altered between sending and receiving. This makes DKIM more robust than SPF against certain spoofing techniques.
What DKIM does not prevent
DKIM does not tell the receiving server what to do if verification fails. A failed DKIM check might result in the email being delivered anyway, landing in spam, or being rejected — depending entirely on the receiving server's configuration. This is where DMARC comes in.
DMARC — Domain-based Message Authentication, Reporting and Conformance
DMARC ties SPF and DKIM together and adds a policy: what should happen to email that fails both checks? DMARC also adds reporting — domain owners receive aggregate reports showing who is sending email using their domain, which helps identify both legitimate sources you may have missed and active spoofing attempts.
DMARC policies
DMARC has three policy levels:
p=none— monitor only. Collect reports but take no action on failing email. This is where most organizations start.p=quarantine— send failing email to the spam folder. Reduces the impact of spoofing without risking legitimate mail.p=reject— reject failing email outright. The most protective setting, but requires confidence that all legitimate email sources pass SPF and DKIM.
What a DMARC record looks like
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourfirm.com; pct=100
This record says: apply quarantine policy to 100% of emails that fail DMARC checks, and send aggregate reports to dmarc@yourfirm.com.
Why all three matter together
SPF alone can be bypassed. DKIM alone provides no policy enforcement. DMARC alone has nothing to enforce without SPF and DKIM in place.
The three standards work as a system. SPF establishes which servers can send on your behalf. DKIM proves that specific messages came from your infrastructure unchanged. DMARC defines what to do with messages that fail either check, and provides visibility into how your domain is being used.
The insurance and compliance angle
DMARC enforcement is increasingly a checkbox on cyber insurance applications and vendor security questionnaires. A p=none policy — which takes no action on spoofed email — satisfies the technical requirement of "having DMARC" but provides no actual protection. Insurers are beginning to distinguish between organizations that have DMARC configured at p=reject versus those sitting at p=none indefinitely.
Common mistakes
Staying at p=none forever
Many organizations set up DMARC at p=none to collect data and then never move to enforcement. The reporting phase is valuable — it reveals legitimate email sources you need to authorize. But leaving the policy at p=none means your domain can still be freely spoofed.
Missing email sources
Moving to p=reject too quickly causes legitimate email to be rejected. Marketing platforms, ticketing systems, invoice tools, and any third-party service that sends email on your behalf needs to be authorized in your SPF record and configured with DKIM before you enforce DMARC.
Weak SPF endings
Using ~all (softfail) instead of -all (hardfail) in your SPF record means unauthorized senders get a softfail rather than a rejection. Many receiving servers treat softfail the same as pass.
How to check your current configuration
From any terminal:
dig TXT yourdomain.com # SPF record
dig TXT _dmarc.yourdomain.com # DMARC record
Or run a free email security check at kasperashield.com/security-assessment to see your current SPF, DKIM, and DMARC configuration and what needs to change.
