DMARC for accounting and CPA firms

DMARC for accounting firms: stop fake portal emails sent as your firm

By Adam W., founder of DMARCit · Last updated 2026-10

Every January your clients start expecting email from you with links in it: a portal notice, an e-signature request for the return, an invoice. That expectation is what a forged email from your firm's domain borrows.

DMARC is the DNS record that tells Gmail, Microsoft and Yahoo what to do with mail that claims to be your firm and can't prove it. Neither the Safeguards Rule nor Publication 4557 names it. For a tax practice the hard part is timing: find every system that sends as you over the summer, so an e-file authorization request doesn't land in spam in April.

Check your domain free Several domains? Check them together

The email your clients are already expecting

IRS Publication 4557 describes the spear-phishing version aimed at your staff: the thief may pose as your tax software provider, your data storage provider, the IRS or even a prospective client [IRS Pub 4557, p. 9]. The other direction gets less attention. Mail aimed at your clients, from your domain, saying their documents are ready and linking to a login page that isn't yours.

DMARC handles that second direction when the forgery uses your exact domain. It does nothing for the first, because those emails use the IRS's domain, a software company's, or a stranger's webmail. And it does nothing for the payroll-change request that appears to come from a client's owner: that one is forged on the client's domain, so the client's DMARC record is the one that matters. If you run payroll for clients, the free checker works on their domains too.

What the FTC and the IRS actually require

The FTC Safeguards Rule treats an accountant or other tax preparation service in the business of completing income tax returns as a financial institution [16 CFR 314.2, (h)(2)(viii)]. It requires a written information security program [16 CFR 314.3], built on a risk assessment that identifies reasonably foreseeable internal and external risks to customer information [16 CFR 314.4, (b)]. The listed elements include multi-factor authentication, security awareness training and a written incident response plan [16 CFR 314.4, (c)(5), (e), (h)]. If unencrypted customer information on at least 500 consumers is acquired without authorization, the FTC has to be notified no later than 30 days after you discover it [16 CFR 314.4, (j)] [16 CFR 314.2, (m)].

Publication 4557 is the IRS's plain-language companion. It says the Safeguards Rule's definition of a financial institution includes professional tax preparers, and that the rule requires a written information security plan [IRS Pub 4557, p. 13].

Neither the rule nor the publication mentions SPF, DKIM or DMARC. Where DMARC fits is the risk assessment: someone emailing your clients as your firm is a reasonably foreseeable external risk, DMARC is the control for the exact-domain version of it, and the aggregate reports are the record that you are watching. A firm holding customer information on fewer than 5,000 consumers is exempt from four paragraphs: writing the risk assessment down, continuous monitoring or annual penetration testing, the written incident response plan, and the annual report to the board. The written program itself still applies [16 CFR Part 314, §314.6].

If the firm takes card payments for its fees, PCI DSS may apply as well. Requirement 5.4.1 has been required since 31 March 2025 and reads: “Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks” [PCI DSS SAQ D, p. 36]. Whether it lands in your self-assessment depends on which questionnaire your card setup puts you in. Our PCI DSS and DMARC page covers where DMARC sits in it.

How DMARC decides what happens to a forgery

Every email carries two sender addresses: the From line your client reads, and an envelope address servers use for bounces. SPF lets a domain list the servers allowed to use it in the envelope (the MAIL FROM and HELO identities) and says nothing about the From line [RFC 7208, §1]. DKIM signs the message with a domain's key. DMARC ties both to what the reader sees: a message passes when SPF or DKIM passes for a domain that aligns with the From domain [RFC 9989, §3.2.10] [Microsoft DMARC guide].

The policy you publish at _dmarc.yourfirm.com tells receivers what to do with mail that fails. p=none expresses no preference. p=quarantine says failing mail is suspicious, which at most receivers means the spam or junk folder. p=reject says a failure is a clear sign the use of your domain isn't valid [RFC 9989, §4.7] [Microsoft DMARC guide]. Only the last two change what happens to a forgery. A record stuck at p=none gets you reports and nothing else.

Three details catch small offices. Microsoft's own documentation says no DKIM signing occurs for outbound mail from custom domains until you configure it [Microsoft DKIM guide], so a Microsoft 365 tenant that never turned it on is relying on SPF alone, and SPF alignment breaks when mail is forwarded [Microsoft DMARC guide]. SPF allows at most ten DNS-querying terms, and every service added with an include: spends some of that budget [RFC 7208, §4.6.4]. And ~all at the end of an SPF record is a softfail, which receivers should not reject on by itself [RFC 7208, §8.5]. It was never the enforcement step. DMARC is.

What sends email as your firm

Most small practices find some version of this list in their first weeks of reports:

  • Microsoft 365 or Google Workspace. Staff mailboxes. If the firm is on Microsoft 365 and nobody configured DKIM for the custom domain, that mail isn't DKIM-signed as you at all [Microsoft DKIM guide].
  • Tax software signature requests. E-file authorization forms sent for signature by the software, with your firm name and often your address.
  • Client portal notices. "Your documents are ready" messages. The exact message an attacker copies.
  • Practice management and invoicing. Engagement letters, invoices and payment reminders.
  • Payment receipts. Card and ACH receipts from the payment processor, if they carry your domain in the From line.
  • Scanners, copiers and the newsletter. Scan-to-email from the office copier, and the deadline-reminder newsletter, each through its own sending service.

Each one has to pass SPF or DKIM for your domain, aligned, before you enforce. The ones that don't are not attacks. They are the reason the rollout starts in monitoring mode.

What Gmail, Yahoo and Microsoft check now

Since February 1, 2024, Google has required every sender to Gmail to set up SPF or DKIM, and senders of more than 5,000 messages a day to also publish DMARC (a policy of none is enough) with the From domain aligned [Google sender guidelines]. Yahoo asks all senders for SPF or DKIM, and bulk senders for both, plus a passing DMARC policy of at least p=none and an aligned From domain [Yahoo sender best practices]. Yahoo won't say what volume makes you a bulk sender [Yahoo sender FAQ]. Microsoft rejects mail with 550 5.7.515 when a domain that has sent 5,000 or more messages to Outlook.com, Hotmail and Live.com doesn't pass both SPF and DKIM, publish a DMARC record, and align at least one of them [Microsoft 550 5.7.515].

A small firm's own mailboxes rarely get near those numbers, and none of these is a regulation. They matter for two narrower reasons. The receivers holding your clients' inboxes now check authentication on everyone. And Microsoft counts volume by the From domain [Microsoft 550 5.7.515], so a newsletter or billing platform sending as you adds to your count, not its own.

Getting to p=reject without losing real mail

Microsoft's guidance for its own customers is the right shape for any firm: start at p=none, monitor, step up to p=quarantine, then p=reject, and begin with a low-volume domain if you have one [Microsoft DMARC guide].

  1. Publish p=none with a reporting address. Delivery doesn't change. Receivers start sending aggregate reports, typically once a day [Microsoft DMARC guide].
  2. Read two to four weeks of reports. Every source sending as yourfirm.com shows up with its SPF and DKIM results. Mark the ones that are yours. Anything you don't recognize is either a forgotten tool or someone else.
  3. Fix alignment one sender at a time. For each service, turn on its custom-domain DKIM setting (it gives you a DNS record to publish) or an aligned return-path, then check the next day's reports.
  4. Move to p=quarantine. Failing mail goes to spam instead of the inbox. Watch for a legitimate sender you missed.
  5. Move to p=reject once every legitimate source aligns. A forgery of your exact domain now fails at receivers that enforce DMARC.

Domains you own but never send from get v=DMARC1; p=reject; [Microsoft DMARC guide] and an SPF record that authorizes nothing, v=spf1 -all [RFC 7208]. The test-flag mechanics for each step (t=y, and pct=0 for receivers that predate RFC 9989) are on our staged rollout page.

Timing matters more for a tax practice than for most offices. Run the p=none phase in the summer or fall, fix senders before January, and avoid moving a policy step between late January and the April deadline, when a misaligned signature request costs the most. Merged practices often keep the acquired firm's domain for forwarding; it still needs its own record.

What DMARC won't stop

DMARC protects one thing: your exact domain in the From line. RFC 9989 says so plainly. DMARC can only combat specific forms of exact-domain spoofing directly, and it does not address visually similar domain names or abuse of the From display name [RFC 9989, §2.2].

  • Lookalike domains. yourfirm-cpa.com, registered last week, can pass its own SPF, DKIM and DMARC. Your record has no say over it.
  • Display names. A colleague's name in front of a free webmail address passes, because the domain really is the webmail provider's.
  • A real mailbox with a stolen password. Mail sent from inside your own tenant is your mail. It passes everything, because your systems sent it.
  • Everyone else's domains. Your record covers your domain. Your clients, and anyone else copied on the thread, each have their own.

For your own staff, Publication 4557's advice still applies: never open attachments from unknown senders, including potential clients [IRS Pub 4557, p. 10]. For anything that changes where money or a refund goes, confirm by phone at a number you already had, not one in the email.

What DMARCit does on this job

You publish one DNS record with a reporting address. The aggregate reports from Gmail, Microsoft, Yahoo and the rest route to DMARCit and become a list of named senders, each with its SPF and DKIM alignment. You approve the senders that are yours and deny the rest. Alerts tell you when your pass rate drops, when receivers start quarantining or rejecting mail under your policy, and when reports stop arriving. DMARCit never writes your DNS: every record on your domain is one you placed. The details are on the product page.

What it doesn't do: read your mailboxes or filter the mail coming in to your staff. It won't catch a lookalike domain either. Those belong to your mail filter and your verification procedure, and if you want one tool that does them, this isn't it.

Questions that come up

Does the FTC Safeguards Rule require DMARC?

No. 16 CFR Part 314 does not mention email, let alone email authentication. It requires a written information security program built on a risk assessment of reasonably foreseeable internal and external risks. Mail sent as your firm by someone else is one of those risks, and an enforced DMARC record with its reports is evidence that you assessed it and put a control on it.

Does IRS Publication 4557 mention DMARC?

No. Publication 4557 (Rev. 6-2024) covers phishing and spear phishing, including thieves posing as the IRS, tax software providers and prospective clients, and it points tax preparers to the FTC Safeguards Rule. It does not name SPF, DKIM or DMARC.

Will DMARC enforcement block our tax software's signature emails?

Only if the software sends as your domain and fails alignment on both SPF and DKIM. The p=none reports settle which case you are in. A failing one is usually fixed in the software's custom sending-domain or DKIM setting, and one that sends from its own domain is outside your policy entirely.

Start with what your domain publishes today

The checker reads your SPF, DKIM and DMARC records and names the next fix. No account. If you want the reports read for you after that, the plans are on the pricing page.

Run the free DMARC checkerCheck up to 25 domains at once

Sources

Every claim above links to one of these. None of them is a DMARCit page.

  • [IRS Pub 4557] Publication 4557, Safeguarding Taxpayer Data: A Guide for Your Business (Rev. 6-2024), Internal Revenue Service. Cited for: Spear phishing where the thief poses as your tax software provider, your data storage provider, the IRS or a prospective client (p. 9); never opening attachments from unknown senders, including potential clients (p. 10); the Safeguards Rule definition of financial institutions including professional tax preparers, and its written information security plan (p. 13). No mention of SPF, DKIM or DMARC.
  • [16 CFR 314.2] 16 CFR 314.2, Definitions, eCFR. Cited for: An accountant or other tax preparation service in the business of completing income tax returns is a financial institution (314.2(h)(2)(viii)); a notification event is acquisition of unencrypted customer information without authorization (314.2(m)).
  • [16 CFR 314.3] 16 CFR 314.3, Standards for safeguarding customer information, eCFR. Cited for: An information security program that is written and appropriate to your size and complexity (314.3(a)).
  • [16 CFR 314.4] 16 CFR 314.4, Elements, eCFR. Cited for: Risk assessment of reasonably foreseeable internal and external risks (314.4(b)); multi-factor authentication (314.4(c)(5)); security awareness training (314.4(e)(1)); written incident response plan (314.4(h)); FTC notice no later than 30 days after discovery of a notification event involving at least 500 consumers (314.4(j)(1)). No mention of email or phishing.
  • [16 CFR Part 314] 16 CFR Part 314, Standards for Safeguarding Customer Information, eCFR. Cited for: Section 314.6: paragraphs 314.4(b)(1), (d)(2), (h) and (i) do not apply to financial institutions that maintain customer information concerning fewer than five thousand consumers.
  • [PCI DSS SAQ D] PCI DSS v4.0 Self-Assessment Questionnaire D for Merchants, PCI Security Standards Council. Cited for: Requirement 5.4.1 text, and its applicability note: a best practice until 31 March 2025, required after (printed p. 36).
  • [RFC 7208] RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1, IETF, via the RFC Editor. Cited for: SPF authorizes the MAIL FROM and HELO identities (§1), the limit of ten DNS-querying terms (§4.6.4), and that receivers should not reject on a softfail alone (§8.5).
  • [RFC 9989] RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), IETF. Cited for: Identifier alignment (§3.2.10), what p=none, p=quarantine and p=reject mean (§4.7), and that DMARC only combats exact-domain spoofing and does not address lookalike domains or display names (§2.2).
  • [Microsoft DMARC guide] Set up DMARC to validate the From address domain for cloud senders, Microsoft Learn. Cited for: A message passes DMARC when SPF or DKIM passes and aligns; how receivers treat quarantine; forwarding breaking SPF alignment; the gradual p=none to p=reject rollout; the parked-domain record.
  • [Microsoft DKIM guide] Set up DKIM to sign mail from your cloud domain, Microsoft Learn. Cited for: No DKIM signing occurs for outbound mail from custom domains in Microsoft 365 until you configure it.
  • [Google sender guidelines] Email sender guidelines, Google. Cited for: From February 1, 2024: SPF or DKIM for all senders to Gmail; SPF, DKIM and DMARC (policy can be none) with From alignment for senders of more than 5,000 messages a day.
  • [Yahoo sender best practices] Sender Best Practices, Yahoo. Cited for: SPF or DKIM for all senders; for bulk senders, both SPF and DKIM, a DMARC policy of at least p=none that passes, and an aligned From domain.
  • [Yahoo sender FAQ] FAQs, Yahoo. Cited for: Yahoo does not specify a bulk-sender volume threshold.
  • [Microsoft 550 5.7.515] Fix NDR error "550 5.7.515" in Outlook.com, Microsoft Support. Cited for: Senders of 5,000 or more messages using the same From domain to Outlook.com, Hotmail and Live.com must pass both SPF and DKIM, publish a DMARC record, and align at least one of them, or get 550 5.7.515. No time period is stated.