The problem DMARC solves
Every day, billions of emails are sent with forged sender addresses. The email protocol has no built-in way to verify that an email actually came from the address it claims. If someone sends you an email from "partner@yourfirm.com," your email client shows that address — even if the email came from a server in another country.
DMARC exists to fix this. It is a standard published in your domain's DNS records that tells receiving email servers how to handle messages that fail authentication checks. Without DMARC, anyone can send email pretending to be from your domain and it will be delivered normally.
How email authentication works
Think of email authentication as a three-layer system. Each layer adds a check, and DMARC ties them together.
Layer 1: SPF (Sender Policy Framework)
SPF answers a simple question: "Is this server allowed to send email for this domain?"
You publish a DNS record listing every server authorized to send email on behalf of your domain — your email provider (Google Workspace, Microsoft 365), your CRM, your marketing platform. When a receiving server gets an email from your domain, it checks your SPF record to see if the sending server is on the list.
If the server is not listed, the email fails SPF.
A typical SPF record looks like this:
v=spf1 include:_spf.google.com include:sendgrid.net -all
The -all at the end means "reject anything not explicitly listed." If you see ~all (with a tilde), that is a soft fail — it flags suspicious emails but still delivers them.
Layer 2: DKIM (DomainKeys Identified Mail)
DKIM answers a different question: "Was this email altered in transit?"
Your email server adds a cryptographic signature to every outgoing email. The receiving server looks up your public key in DNS and verifies the signature. If the email was modified after being sent — or if it was never signed by your server in the first place — it fails DKIM.
DKIM is configured through your email provider. Google Workspace, Microsoft 365, and most modern email platforms support it, but it often needs to be manually enabled and a DNS record published.
Layer 3: DMARC (Domain-based Message Authentication, Reporting & Conformance)
DMARC ties SPF and DKIM together and adds one critical piece: a policy that tells receiving servers what to do when authentication fails.
Without DMARC, even if an email fails SPF and DKIM, the receiving server makes its own judgment call. It might deliver the email anyway. DMARC removes that ambiguity.
The three DMARC policies
Your DMARC record includes a policy tag (p=) that tells the world how to handle emails that fail authentication:
p=none — "Do nothing"
This is monitor-only mode. Emails that fail authentication are still delivered normally. You get reports about failures, but nothing is blocked.
This is almost as bad as having no DMARC at all. The spoofed emails still land in your clients' inboxes. The only benefit is that you receive reports showing who is spoofing your domain — but most firms never read those reports.
We see p=none on roughly half the firms that have DMARC configured at all. It creates a false sense of security.
p=quarantine — "Send to spam"
Emails that fail authentication are sent to the recipient's spam or junk folder. This is significantly better than p=none because most recipients will never see the spoofed email.
However, some recipients do check their spam folders, and mobile email clients sometimes surface spam messages in notifications. Quarantine is a good intermediate step, not a final destination.
p=reject — "Block it"
Emails that fail authentication are rejected outright. They never reach the recipient at all. The sending server gets a bounce-back, and the recipient has no idea the spoofed email was ever attempted.
This is the only policy that actually prevents email spoofing. If your DMARC policy is not set to reject, your domain can still be spoofed with some chance of success.
How to check if your firm has DMARC
Option 1: Use a free scanner
The fastest way is to run your domain through a scanner. Go to kasperashield.com/security-assessment, enter your domain, and you will see your DMARC status in under 30 seconds — along with SPF, DKIM, and other security checks.
Option 2: Check manually
If you are comfortable with the command line, you can check your DMARC record directly:
dig txt _dmarc.yourfirm.com
On Windows, use:
nslookup -type=txt _dmarc.yourfirm.com
If you get no results, you have no DMARC record. If you see a result, look for the p= tag to see your policy.
Option 3: Use MXToolbox
Go to mxtoolbox.com/dmarc.aspx and enter your domain. It will show you your DMARC record and explain what each part means.
What a properly configured DMARC record looks like
Here is an example of a strong DMARC record:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourfirm.com; pct=100
Breaking this down:
v=DMARC1— This is a DMARC record (required)p=reject— Reject all emails that fail authenticationrua=mailto:...— Send aggregate reports to this addresspct=100— Apply the policy to 100% of emails
Compare this to what we commonly see on law firm domains:
v=DMARC1; p=none
This record exists but does nothing to prevent spoofing. It is the equivalent of installing a security camera that records but never alerts anyone.
Common objections and why they are wrong
"We use Google Workspace / Microsoft 365, so we're protected"
Google and Microsoft authenticate emails sent through their servers. They do not prevent someone from spoofing your domain from a different server. Without DMARC set to reject, an attacker can send email claiming to be from your domain using any server they control.
"We're too small to be a target"
Small firms are preferred targets because they lack security infrastructure. Attackers know a two-attorney firm is unlikely to have email authentication, security monitoring, or phishing awareness training.
"Setting up DMARC is too complicated"
Adding a DMARC record is a single DNS entry. It takes less than five minutes if you have access to your domain registrar. The tricky part is making sure all legitimate email sources are covered by SPF before setting the policy to reject — which is why starting with p=quarantine and monitoring for a few weeks is the recommended approach.
"Our IT person handles this"
Ask them. Specifically ask: "What is our DMARC policy set to?" If the answer is "none," "I'm not sure," or silence, you have a problem.
The path from no DMARC to full protection
Week 1: Add a DMARC record with p=none and an rua address to start receiving reports. This changes nothing about email delivery but starts collecting data.
Weeks 2-3: Review the DMARC reports. Identify all legitimate services sending email on behalf of your domain. Update your SPF record to include all of them. Enable DKIM on all email platforms.
Week 4: Move your DMARC policy to p=quarantine. Monitor for any legitimate emails being flagged.
Week 6: If no legitimate emails are being quarantined, move to p=reject. Your domain is now protected from spoofing.
The entire process takes about six weeks and costs nothing beyond the time to configure DNS records.
What to do next
Run a free security assessment of your domain at kasperashield.com/security-assessment. You will see exactly where your email authentication stands and what needs to be fixed. No signup required, results in 30 seconds.
