SPF, DKIM, DMARC, BIMI, and MTA-STS: What Every CPA Firm Needs to Know About Domain Security in 2026

Every February through April, CPA firms become one of the most impersonated professions in email. Client trust runs high, wire transfer requests are routine, and a spoofed email from “your firm” asking a client to reroute a refund or update banking details doesn’t look out of place — it looks like Tuesday. Business email compromise (BEC) accounted for $2.77 billion in reported losses across 21,442 incidents in 2024, and climbed further to roughly $3.05 billion in 2025, according to the FBI’s Internet Crime Complaint Center (IC3) annual reports (IC3 2024 Annual Report; IC3 2025 Annual Report). Since 2013, cumulative BEC losses reported to the FBI have topped $55.5 billion (FBI IC3 Public Service Announcement).

SPF, DKIM, DMARC, BIMI, and MTA-STS are the five DNS-based controls that determine whether your firm’s domain can be spoofed — and whether spoofed mail impersonating your firm ever reaches an inbox. This guide explains what each one does, how they work together, and the order to implement them in.

Why This Matters More for CPA Firms Than Almost Any Other Business

Two structural facts make accounting firms a preferred BEC target:

• Wire transfers are a normal part of the relationship. Clients expect to receive banking instructions, refund notifications, and payment requests from their CPA. A spoofed “please update the routing number for this quarter’s payment” email doesn’t trigger the same suspicion it would coming from an unfamiliar sender.
• Tax season creates urgency and volume. The IRS’s 2026 Dirty Dozen list of tax scams specifically flags email and text-based IRS impersonation as the top scam category, noting a sharp rise in fake IRS-branded communications directing taxpayers to fraudulent sites (IRS Dirty Dozen 2026). During filing season, staff are processing high volumes of client email fast — exactly the condition under which phishing succeeds.

The human factor compounds both problems. Verizon’s 2024 Data Breach Investigations Report found that 68% of breaches involve a non-malicious human element — someone clicking, replying, or approving something they shouldn’t have — and that the median time for a user to fall for a phishing email is less than 60 seconds (Verizon 2024 DBIR). Phishing remains the single most common initial attack vector across all breaches, at 16%, with an average breach cost of $4.8 million once one succeeds, according to IBM’s 2025 Cost of a Data Breach Report (IBM Cost of a Data Breach Report 2025).

Domain authentication doesn’t stop a human from clicking a bad link inside a real email. What it does stop is someone else sending mail that looks like it came from your firm’s domain in the first place — which is the exact mechanism behind the majority of BEC and client-impersonation scams.

SPF: Sender Policy Framework

What it does: SPF is a DNS TXT record that lists every mail server authorized to send email on behalf of your domain. When a receiving mail server gets a message claiming to be from yourfirm.com, it checks the SPF record to see if the sending server is on the approved list.

What it doesn’t do: SPF only validates the sending server, not the actual “From” address a recipient sees. It’s also broken by email forwarding, which is one of the most common reasons SPF checks fail on legitimate mail.

Common misconfiguration: Firms using multiple email tools — a practice management platform, a document e-signature tool, a marketing email service, and their primary email provider — often forget to add all of them to the SPF record. Each omitted service either fails authentication (hurting deliverability) or, more dangerously, gets discovered and exploited by a spoofer who notices the gap.

DKIM: DomainKeys Identified Mail

What it does: DKIM adds a cryptographic signature to outgoing email, generated using a private key controlled by the sending domain. The receiving server checks that signature against a public key published in DNS. If the message was altered in transit, or wasn’t actually sent by an authorized system, the signature fails.

Why it matters more than SPF alone: Unlike SPF, DKIM survives most forwarding scenarios because the signature travels with the message content rather than depending on the originating server’s IP address.

Common misconfiguration: Firms that switch email or marketing platforms often leave old DKIM keys active or fail to publish new ones for the replacement service — leaving legitimate mail unsigned and vulnerable to being flagged as suspicious.

DMARC: Domain-based Message Authentication, Reporting & Conformance

What it does: DMARC ties SPF and DKIM together and tells receiving mail servers what to do when a message fails both checks. A DMARC policy has three levels:

Policy	What Happens to Failing Mail	Use Case
p=none	Nothing — message is delivered, but a report is generated	Monitoring phase; visibility without disruption
p=quarantine	Message is routed to spam/junk	Mid-rollout, once you’ve confirmed legitimate senders pass
p=reject	Message is blocked entirely	Full enforcement; the goal state for every domain

Why enforcement matters: DMARC’s real power only shows up at p=quarantine or p=reject. A domain at p=none gets visibility into who’s sending mail as them, but does nothing to actually stop spoofed mail from reaching an inbox. According to the EasyDMARC 2026 DMARC Adoption & Enforcement Report, global DMARC adoption across the top 1.8 million domains reached 52.1% in 2026, up from 27.2% in 2023 — but more than half of domains with a DMARC record are still stuck at p=none, meaning they have monitoring but zero actual spoofing protection (EasyDMARC 2026 DMARC Adoption Report). Fortune 500 adoption is far ahead at 95%, with 62.7% already at full enforcement — small and mid-size firms are the ones lagging.

Google and Yahoo made this non-optional. Starting February 2024, Google and Yahoo began requiring any domain sending 5,000+ messages per day to personal Gmail or Yahoo accounts to have SPF, DKIM, and at minimum a p=none DMARC record in place, or face throttling and rejection (Google’s official bulk sender requirements). Microsoft followed with its own enforcement for outlook.com, hotmail.com, and live.com starting May 2025. While most individual CPA firms send well under the 5,000/day threshold, any firm using a shared practice management or tax software platform to send client communications may be aggregated into that provider’s sending volume — worth confirming with your software vendor.

BIMI: Brand Indicators for Message Identification

What it does: BIMI lets your firm’s verified logo appear directly next to your emails in supporting inboxes (Gmail, Yahoo, Apple Mail) — before the recipient even opens the message. For a CPA firm, this is a visible trust signal during exactly the season when clients are being trained by scammers to distrust “IRS” and “your accountant” emails.

Requirements:

1. DMARC must be at enforcement — p=quarantine or p=reject. A p=none policy is invisible to BIMI; so is a pct tag below 100.
2. A specially formatted logo file (SVG Tiny PS format).
3. A certificate that verifies your organization owns the logo — either a Verified Mark Certificate (VMC), which requires a registered trademark and typically costs $1,000–$1,500 per year through an approved Certificate Authority (DigiCert or Entrust), or a newer Common Mark Certificate (CMC), which Google introduced in 2025 and doesn’t require a trademark — just proof the logo has been in public use on your domain for at least 12 months (Google Workspace official BIMI setup guide).

For most small and mid-size CPA firms without a registered trademark on their logo, the CMC path removed what used to be the single biggest cost barrier to BIMI adoption.

MTA-STS: The Layer Almost Everyone Forgets

SPF, DKIM, and DMARC all answer the same question: is this email really from who it claims to be from? None of them answer a different, equally important question: is this email being encrypted while it travels between mail servers?

That’s what MTA-STS (Mail Transfer Agent Strict Transport Security) does. Defined in RFC 8461, the official internet standard maintained by the IETF, MTA-STS publishes a DNS-and-HTTPS policy telling sending mail servers: “don’t deliver to us unless you can establish an encrypted TLS connection with a valid certificate.” Without it, standard email transmission (SMTP) allows encryption to be silently downgraded or stripped by an attacker positioned on the network path — meaning a client’s tax documents, SSNs, and bank routing numbers could theoretically be intercepted in plaintext between servers, even if SPF/DKIM/DMARC are configured perfectly.

For a CPA firm transmitting W-2s, 1099s, and bank information by email during tax season, this is not a theoretical concern — it’s the exact class of sensitive data MTA-STS is designed to protect in transit.

The 5-Layer Email Security Stack

Layer	Protects Against	Requires
SPF	Unauthorized servers sending as your domain	DNS TXT record listing approved senders
DKIM	Message tampering in transit	Cryptographic signing key + DNS public key record
DMARC	Spoofed “From” addresses reaching the inbox	SPF + DKIM alignment, policy set to quarantine/reject
BIMI	Lack of visible trust signal in the inbox	DMARC at enforcement + VMC/CMC + hosted logo
MTA-STS	Interception/downgrade of email in transit	DNS policy record + HTTPS-hosted policy file + valid TLS certs

The 90-Day Rollout Plan

Jumping straight to p=reject without preparation is the single most common mistake firms make — it risks blocking legitimate mail from staff, software integrations, and third-party services you forgot were sending on your behalf.

Days 1–30 — Monitor:

• Publish SPF and DKIM for every legitimate sending source (email provider, practice management software, e-signature tool, marketing platform)
• Publish a DMARC record at p=none to start collecting aggregate reports without disrupting mail flow
• Review DMARC reports weekly to build a complete inventory of every system sending mail as your domain

Days 31–60 — Quarantine:

• Once reports confirm all legitimate senders are passing SPF/DKIM alignment, move DMARC to p=quarantine at a low percentage (pct=25)
• Gradually increase to pct=100 over several weeks while continuing to monitor for false positives

Days 61–90 — Reject and Expand:

• Move to p=reject once quarantine has run cleanly with no legitimate mail flagged
• Publish an MTA-STS policy in “testing” mode, then move to “enforce” once TLS connectivity is confirmed clean
• Apply for a VMC or CMC and publish your BIMI record now that DMARC is at enforcement

A Real Scenario: Client Impersonation During Tax Season

A South Florida CPA firm with a client base of small business owners and high-net-worth individuals had no DMARC enforcement in place. During tax season, a scammer registered a lookalike domain and sent a message that appeared to come from the firm’s managing partner, requesting an urgent wire transfer to “cover a quarterly estimated payment shortfall” to a new account. Because the firm’s domain had SPF and DKIM published but DMARC set to p=none, there was no protection against the lookalike domain — DMARC alignment only protects the exact domain it’s published for, not similar-looking ones. The client caught the request as suspicious only because the wording felt slightly off, not because any technical control flagged it.

This is a critical nuance: DMARC protects your exact domain from being spoofed directly. It does not stop lookalike-domain attacks (yourfirm-cpa.com instead of yourfirm.com). For that risk, firms need a combination of DMARC enforcement, staff training on verifying banking-detail changes by phone, and monitoring for newly registered lookalike domains — a layered defense, not a single control.

Checklist: Domain Security Audit

• Confirm SPF record includes every legitimate sending service (email provider, tax software, e-signature platform, marketing tools)
• Confirm DKIM is configured and signing for every one of those same services
• Check current DMARC policy — if it’s p=none or missing entirely, you have zero enforcement today
• Review DMARC aggregate reports for unrecognized sending sources
• Confirm MTA-STS policy is published and set to “enforce,” not just “testing”
• Confirm TLS-RPT is configured to receive reports on any TLS connection failures
• Evaluate whether BIMI is worth pursuing given your firm’s logo/trademark status (CMC path if no trademark, VMC if you have one)
• Establish a verbal-confirmation policy for any client request to change banking or wire instructions, regardless of how legitimate the email looks

How ITva Helps CPA Firms Lock Down Domain Security

We handle the full SPF/DKIM/DMARC/BIMI/MTA-STS rollout as part of our managed IT service for CPA firms — not as a separate line-item project:

• Full DNS audit and staged 90-day rollout from p=none to p=reject, so you’re never at risk of blocking legitimate client or vendor mail
• Weekly DMARC report review during the transition period to catch unauthorized senders early
• BIMI setup and VMC/CMC guidance so your firm’s logo displays correctly once DMARC reaches enforcement
• MTA-STS and TLS-RPT configuration to protect client tax documents and financial data in transit
• 3.5-minute average ticket response time and 24/7 SOC monitoring if anything looks abnormal in your mail flow
• No long-term contracts and a 90-day satisfaction guarantee — we’re confident enough in the setup that we don’t need a multi-year lock-in to prove it works

Frequently Asked Questions

What’s the difference between SPF, DKIM, and DMARC?

SPF authorizes which servers can send mail for your domain. DKIM cryptographically signs messages to prove they weren’t altered in transit. DMARC ties both together and tells receiving servers what to do — deliver, quarantine, or reject — when a message fails those checks.

Do small CPA firms actually need to worry about Google and Yahoo’s bulk sender rules?

Most individual firms send well under the 5,000-messages-per-day threshold that triggers Google and Yahoo’s mandatory requirements. However, firms using a shared practice management or tax software platform to send client communications may be aggregated into that provider’s total sending volume, so it’s worth confirming with your software vendor.

Does DMARC stop lookalike domain attacks, like “yourfirm-cpa.com” instead of “yourfirm.com”?

No. DMARC only protects the exact domain it’s published for. Lookalike-domain attacks require a separate layer of defense — staff training on verifying wire instruction changes by phone, plus monitoring for newly registered domains that resemble your own.

What does BIMI actually require, and is it worth the cost?

BIMI requires DMARC at enforcement (p=quarantine or p=reject), a properly formatted logo file, and a certificate — either a Verified Mark Certificate (roughly $1,000-$1,500/year, requires a trademark) or a newer, no-trademark-required Common Mark Certificate that Google introduced in 2025. For a CPA firm, the visible trust signal it adds during tax season, when clients are primed to distrust financial emails, often justifies the cost.

What is MTA-STS and why isn’t it as well-known as SPF, DKIM, or DMARC?

MTA-STS encrypts email in transit between mail servers, protecting against interception — a different problem than SPF/DKIM/DMARC, which verify sender identity. It’s less well-known because it’s newer and doesn’t affect whether mail gets delivered to an inbox, only whether it’s protected in transit — but for a firm transmitting client tax documents and bank details by email, it closes a real gap.

How long does a full domain security rollout take?

A properly staged rollout — from initial SPF/DKIM setup through DMARC monitoring, quarantine, and full enforcement, plus MTA-STS and BIMI — typically takes about 90 days done correctly. Rushing straight to enforcement without the monitoring phase risks blocking legitimate mail from staff and software integrations.

Get a Free Domain Security Audit

Not sure where your firm’s domain security actually stands? Book a free assessment and we’ll run a full SPF/DKIM/DMARC/MTA-STS audit and show you exactly what’s exposed. Or call us directly at (305) 629-5925.