Email Spoofing Prevention: SPF, DKIM & DMARC Guide

6 Out of 7 Top Swedish Law Firms Can Be Spoofed

Most organizations ignore email spoofing prevention entirely. Earlier this year, we ran our full SVAR security audit across 597 Swedish law firms. The GDPR compliance numbers were bad. The email authentication numbers were worse.

Of the seven largest firms by headcount, six had incomplete or missing DMARC policies. These are the firms handling the biggest M&A deals, IP disputes, and criminal defense cases. Their names carry weight. An email from one of them gets opened, gets trusted, gets acted on. That is exactly what makes spoofing so dangerous.

This is not theoretical. Business email compromise (BEC) cost $2.9 billion in 2023 according to the FBI's IC3. It is the most financially damaging category of cybercrime. Law firms are obvious targets because they move money, settle transactions, and share sensitive information over email every single day.

The fix is free. SPF, DKIM, and DMARC are open standards that have existed for over a decade. They cost nothing. This guide covers what they do, how they fit together, and how to set them up.

How Email Spoofing Works

Email was designed in the 1980s for a small, trusted network of academics. The sending protocol, SMTP, has no built-in way to verify that the person in the "From" field actually sent the message. It works like a postal letter. You can write any return address you want on the envelope.

When you send an email, your mail client connects to an SMTP server and provides two things: the envelope sender (the actual routing address) and the message headers (what the recipient sees, including the "From" line). These two values do not have to match. Nothing in the protocol enforces it.

So an attacker can connect to any SMTP server and send a message with your domain in the From header. The recipient's email client displays it as coming from you. Almost nobody checks raw message headers, so they have no way to spot the fake.

A spoofed email looks something like this:

From: anders.berg@lawfirm.se
To: maria.nilsson@clientcompany.se
Subject: Updated wire transfer instructions — urgent

Hi Maria,

The bank details for the final settlement have changed due to an
internal restructuring. Please use the following account for the
transfer due Friday:

IBAN: DE89 3704 0044 0532 0130 00
BIC: COBADEFFXXX

Please confirm when the transfer is complete.

Best regards,
Anders Berg
Partner, Berg & Associates

Maria sees a message from her lawyer's exact email address. It references a real transaction. The language is professional. She transfers the money. It goes to the attacker's account in another country. By the time anyone notices, the funds are gone.

This happens every day. It works because without SPF, DKIM, and DMARC, Maria's email server has no way to know the message is fake.

SPF: Who Can Send on Your Behalf

SPF tells receiving mail servers which servers are actually allowed to send email from your domain. Think of it as a guest list for your email.

You publish an SPF record as a TXT entry in your domain's DNS. When a receiving server gets a message claiming to be from your domain, it checks this record against the sending server's IP address. If the IP is not on the list, the server knows something is off.

A basic SPF record:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.50 -all

Each part does something specific:

v=spf1 declares this is an SPF record (version 1). Every SPF record starts with this.

include:_spf.google.com authorizes Google Workspace's mail servers. The "include" mechanism tells receivers to also check Google's SPF record for authorized IPs.

include:sendgrid.net authorizes SendGrid for transactional emails. Every third-party service that sends email on your behalf needs its own include.

ip4:203.0.113.50 authorizes a specific IP address, for example your own mail server.

-all is the enforcement mechanism. Most important part. It tells receiving servers to reject any email from servers not listed above.

Common SPF mistakes to avoid:

Too many DNS lookups. SPF has a hard limit of 10 DNS lookups per record. Each "include", "a", and "mx" mechanism costs one lookup, and nested includes count too. Go over 10 and the entire SPF check fails with a "permerror". Your email loses authentication completely. This is the most common SPF error we see in our scans. If you use Google Workspace, Microsoft 365, a CRM, a marketing platform, and a transactional email service, you hit this limit fast. The fix: flatten your SPF record by resolving the includes to their actual IP ranges, or use an SPF flattening service.

Multiple SPF records. A domain must have exactly one SPF TXT record. If you have two (common when different teams add records independently), both are invalid per the RFC. Merge them into a single record.

Forgetting third-party senders. Every service that sends email as your domain needs to be in the SPF record. CRM systems, helpdesk tools, newsletter platforms, transactional email services, even your accounting software if it sends invoices. Audit every service that uses your domain in the From address.

SPF alone is not enough. SPF only checks the envelope sender (the Return-Path header), not the From header that humans actually see. An attacker can pass SPF with their own domain in the envelope sender while spoofing your domain in the visible From header. You need DKIM and DMARC to close that gap.

DKIM: Digital Signatures for Email

DKIM adds a cryptographic signature to every outgoing email. It proves two things: the email actually came from your domain, and nobody tampered with it in transit.

DKIM uses a pair of cryptographic keys. Your mail server signs every outgoing message with a private key. The matching public key sits in a DNS TXT record. When a receiving server gets your email, it pulls the public key from DNS and checks the signature. Valid signature means authentic email. Invalid means something was tampered with.

The DKIM signature shows up as a header in the email:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=yourdomain.com; s=google;
  h=from:to:subject:date:message-id;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk2yFUGCVEGHFY
   OKYHGOHkgmjfaliLIvKOewNhP3IfEGD...

The important parts:

d=yourdomain.com is the domain that owns the signing key.

s=google is the selector, a label that identifies which key pair to use. A domain can have multiple selectors (e.g., one for Google Workspace, another for SendGrid). The public key lives at google._domainkey.yourdomain.com.

h=from:to:subject:date:message-id lists the headers included in the signature. If any of these change after signing, verification fails.

b= is the actual cryptographic signature.

bh= is a hash of the email body, ensuring the content was not altered.

The DNS record for the public key:

google._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

Setting up DKIM: Most email providers handle signing automatically. Google Workspace: generate the DKIM key in admin console, add the TXT record to DNS. Microsoft 365: enable DKIM signing in Exchange admin center, publish two CNAME records. Third-party senders like SendGrid, Mailchimp, and Postmark each have their own process, usually one or two DNS records.

How to verify DKIM is working: Send a test email to an external address (Gmail works well) and view the original message headers. Look for dkim=pass in the Authentication-Results header. You can also check your DKIM DNS record directly:

dig TXT google._domainkey.yourdomain.com

If this returns a record containing v=DKIM1 and a p= value with your public key, DKIM is published. If it returns empty, the record is missing or the selector is wrong.

Key rotation. Rotate DKIM keys at least once a year. Generate a new key pair, publish the new public key with a new selector, configure your mail server to sign with the new key, then remove the old public key from DNS after a transition period. Most managed email providers handle this automatically.

DMARC: The Policy Layer

SPF and DKIM each solve part of the problem. SPF verifies the sending server. DKIM verifies message integrity. But neither tells the receiving server what to do when verification fails. And neither checks whether the domain in the visible From header matches the authenticated domain.

DMARC fills both gaps. It does three things:

1. Alignment. DMARC checks that the domain in the From header (what the human sees) matches either the SPF-authenticated domain or the DKIM-signing domain. This closes the loophole where an attacker passes SPF with their own domain while spoofing yours in the visible From header.

2. Policy. DMARC lets you tell receiving servers what to do with messages that fail authentication. You have three options:

p=none        →  Do nothing. Deliver the email normally. Just send me reports.
p=quarantine  →  Mark failing emails as suspicious. Send them to spam.
p=reject      →  Block failing emails entirely. Do not deliver them.

3. Reporting. DMARC generates reports that tell you exactly what is happening with email sent from your domain. There are two types:

Aggregate reports (rua) are daily XML summaries from receiving servers. They show how many messages passed or failed SPF, DKIM, and DMARC alignment. You see which IPs are sending as your domain, how many pass, and how many fail.

Forensic reports (ruf) are per-message failure reports with details about individual emails that failed DMARC. Not all providers send these due to privacy concerns, but they are invaluable for debugging when available.

A DMARC record is published as a TXT entry at _dmarc.yourdomain.com. Typical progression:

Starting point, monitor only:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.com; pct=100"

Intermediate, quarantine suspicious emails:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100"

Full enforcement, reject spoofed emails:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; pct=100"

Why most organizations stop at p=none. In our 597-firm scan, most firms that had a DMARC record at all were stuck at p=none. They set it up but never enforced it. A p=none policy tells receiving servers "do whatever you want with failing emails." From a protection standpoint, that is the same as having no DMARC at all. The only benefit is reports. If you have been at p=none for more than a few weeks without actively reviewing reports and moving toward enforcement, DMARC is doing nothing for you.

BEC: The Business Email Compromise Threat

Business Email Compromise is a targeted attack where criminals impersonate someone trusted (CEO, lawyer, accountant, business partner) to trick a person into transferring money or sharing sensitive data. These are not mass phishing blasts. BEC attacks are researched, personalized, and patient.

A BEC attack follows a pattern:

Reconnaissance. The attacker researches the target organization. LinkedIn profiles reveal who works there, what their titles are, and who they report to. Company websites list key personnel. Court filings and press releases reveal ongoing deals and transactions. For law firms, this information is especially easy to find.

Infrastructure setup. The attacker either compromises a legitimate email account (account takeover) or sets up spoofing infrastructure. If the target domain lacks DMARC enforcement, spoofing is trivially easy. No account compromise needed.

The attack. A carefully crafted email arrives at exactly the right moment. It references real people, real deals, real deadlines. It asks for something routine: updated bank details, a wire transfer, a document with personal data. The urgency and specificity make it convincing.

Extraction. Money is transferred to mule accounts and quickly moved across borders. Sensitive data is exfiltrated. By the time the fraud is discovered, recovery is rarely possible.

Why law firms and financial services are prime targets:

Law firms handle large wire transfers routinely. A request to change payment details for a settlement does not raise immediate suspicion. They also hold privileged information: M&A details, intellectual property, personal data from litigation. All of it exploitable. And clients trust communications from their lawyers without second-guessing them.

The regulatory side matters too. Under GDPR, a BEC-caused data breach triggers Article 33 notification to the supervisory authority within 72 hours, and potentially Article 34 notification to affected individuals. IMY has already fined organizations for inadequate technical safeguards. The NIS2 directive raises the bar further, requiring "appropriate and proportionate technical measures" for entities in scope. That increasingly includes legal and financial services.

In 2024, the European Data Protection Board reported more enforcement actions tied to email security failures. Several national authorities issued fines where missing email authentication contributed to breaches. Regulators now treat email spoofing prevention as a baseline expectation, not a nice-to-have.

How to Check Your Email Security Right Now

You can check your email authentication in under five minutes. Three methods, from simplest to most thorough.

Method 1: Run a SVAR scan. Our free security scan checks SPF, DKIM, and DMARC as part of a 16-dimension security assessment. Enter your domain, wait two minutes, get a breakdown of what is configured, what is missing, and what is wrong. No signup required.

Method 2: Command-line checks. If you prefer to check manually, use dig or nslookup to query your DNS records directly.

Check SPF:

dig TXT yourdomain.com | grep spf

# Good result:
"v=spf1 include:_spf.google.com -all"

# Bad result:
(empty — no SPF record exists)

Check DMARC:

dig TXT _dmarc.yourdomain.com

# Good result:
"v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; pct=100"

# Weak result:
"v=DMARC1; p=none;"

# Bad result:
(empty — no DMARC record exists)

Check DKIM:

dig TXT google._domainkey.yourdomain.com

# Good result:
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA..."

# Bad result:
(empty — DKIM not configured for this selector)

Note: For DKIM, you need to know the selector name. Common selectors include google for Google Workspace, selector1 and selector2 for Microsoft 365, and service-specific selectors for tools like SendGrid (s1, s2) or Mailchimp (k1).

Method 3: Send a test email. Send an email from your domain to a Gmail address. Open it in Gmail, click the three dots, select "Show original." Check the Authentication-Results header:

Authentication-Results: mx.google.com;
  dkim=pass header.d=yourdomain.com;
  spf=pass (google.com: domain of user@yourdomain.com designates 203.0.113.50 as permitted sender);
  dmarc=pass (p=REJECT) header.from=yourdomain.com

You want pass for all three. If any shows fail, softfail, or none, you have a gap to fix.

Setting It Up: Simpler Than You Think

People overcomplicate this. The actual setup is a day of work. You list your email senders, add some DNS records, and start monitoring. See our security configuration essentials guide for the broader picture.

Step 1: List every service that sends email as your domain

This is the step most people skip, and it is the only one that matters. Write down every system that uses your domain in the From address. Your email provider (Google Workspace, Microsoft 365), your CRM, helpdesk, marketing tools, transactional email service, invoicing software. Ask around. Check existing SPF records if you have any. Look at email headers from different services.

Step 2: Add the DNS records

With your list ready, configure all three in one sitting. SPF first, then DKIM for each service, then DMARC.

For SPF, add a TXT record with an include: for each third-party service and ip4: entries for servers you manage. Start with ~all (soft fail) until you have verified nothing is missing. Keep total DNS lookups at 10 or fewer.

# Example SPF record:
v=spf1 include:_spf.google.com include:sendgrid.net include:mail.zendesk.com ~all

# Once verified, switch to hard fail:
v=spf1 include:_spf.google.com include:sendgrid.net include:mail.zendesk.com -all

For DKIM, enable signing in each service's admin panel and publish the DNS records they give you. Most providers make this a toggle plus one DNS entry. Send test emails and check headers for dkim=pass.

For DMARC, publish a TXT record at _dmarc.yourdomain.com starting with p=none to collect reports without blocking anything:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; pct=100"

Set up a free DMARC report parser (DMARC Analyzer, Postmark's tool, or an open-source one) so you can actually read the XML reports that start coming in.

Step 3: Monitor for a few days, then enforce

Check the reports for a few days. You are looking for two things: legitimate services that fail (fix their SPF/DKIM config) and unauthorized senders you can safely block. Once your legitimate email consistently passes, move to quarantine:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100"

If everything looks clean after a couple more days, switch to full reject:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; pct=100"

Done. Your domain cannot be spoofed anymore.