DMARC for financial advisors and RIAs

DMARC for financial advisors: stop forged transfer emails sent as your firm

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

The email asks a client to confirm their account details for a custodian change, or to send a contribution to new wiring details. It comes from your firm's address. With an enforced DMARC policy, a forgery of that exact domain is told to fail at the client's mail provider.

Neither the 2024 Regulation S-P amendments nor the FTC Safeguards Rule names DMARC, and the rules section below quotes what they do require. For most advisory firms the rollout risk is the CRM or marketing platform that sends the quarterly newsletter as you.

Forged money email runs in two directions

Outbound: an attacker emails your clients as you, asking them to log in somewhere, update account details, or send funds. DMARC covers that when the forgery uses your exact domain.

Inbound: an attacker emails you as a client, asking you to move money. That mail uses the client's address, often a personal mailbox at a large provider, and your DMARC record has nothing to say about it. Verbal confirmation on a known number is the control there, and for disbursements it is the one that matters most.

What Regulation S-P and the Safeguards Rule ask for

The SEC adopted amendments to Regulation S-P on May 15, 2024 [SEC fact sheet] [Release 34-100155]. They apply to broker-dealers, investment companies, registered investment advisers and transfer agents, and require an incident response program reasonably designed to detect, respond to, and recover from unauthorized access to or use of customer information [SEC fact sheet]. The program has to include oversight of service providers, including through due diligence and monitoring. Affected individuals must be notified as soon as practicable, and no later than 30 days after the firm becomes aware that unauthorized access to or use of customer information has occurred or is reasonably likely to have occurred [SEC fact sheet].

Larger entities had to comply by December 3, 2025, and smaller entities by June 3, 2026 [SEC compliance guide]. Both dates have passed.

State-registered advisers should look at the FTC's rule too. 16 CFR Part 314 names investment advisors that are not required to register with the SEC among the institutions it covers [16 CFR 314.1, (b)], and it requires a written information security program [16 CFR 314.3].

Neither text mentions DMARC. Where it fits: a forged email from your domain is one of the more direct routes to customer information, because it asks the client to hand it over. An enforced DMARC record makes the exact-domain version fail at receivers that check, and the aggregate reports log attempts against your domain. Which rule applies to your firm, and how, is a question for your compliance counsel.

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

An advisory firm's sender list is mostly client communication tools layered on the mailbox:

  • Microsoft 365 or Google Workspace. Advisor and operations mailboxes. On Microsoft 365, confirm custom-domain DKIM is on; it isn't until someone configures it [Microsoft DKIM guide].
  • CRM and marketing email. Newsletters, market commentary and birthday emails sent with your domain in the From line. Often the biggest single sender after the mailboxes.
  • Client portal and planning software. "Your plan is ready" and document-vault notices.
  • E-signature. Account forms and advisory agreements sent for signature.
  • Scheduling tools. Meeting confirmations and reminders.
  • Custodian notices. Typically sent from the custodian's own domain, which your policy doesn't cover. Worth confirming in the reports.

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.

Run the p=none phase across a full newsletter cycle, so the marketing platform shows up in the reports before you enforce. If the firm changed affiliation and still owns the old branded domain, give it the parked-domain record above.

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-wealth.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 any disbursement or change of banking details requested by email, call the client at the number on file before acting. For your own outbound instructions, tell clients in writing that you will never send new wiring details by email alone, so a convincing one is suspect by default.

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 Regulation S-P require DMARC?

No. The 2024 amendments require an incident response program reasonably designed to detect, respond to, and recover from unauthorized access to or use of customer information, notice to affected individuals within 30 days, and oversight of service providers. Email authentication is not named. A forged email from your domain asking for account details is one route to that information, though, and an enforced DMARC record is a control you can write into the program against it.

We are a state-registered adviser. Do the Regulation S-P amendments apply?

The amendments cover SEC-registered investment advisers, among others. The FTC's Safeguards Rule names investment advisors that are not required to register with the SEC among the institutions it covers. Your compliance counsel can tell you which one you answer to. Neither names DMARC.

Will p=reject block our CRM newsletters?

Not if the platform authenticates as your domain. If it sends as you without an aligned SPF or DKIM result, the p=none reports show it before anything is enforced. The usual fix is the platform's custom-domain authentication setting, which adds DKIM records under your domain.

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.

Sources

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

  • [SEC fact sheet] Fact Sheet, Final Rules: Enhancements to Regulation S-P, U.S. Securities and Exchange Commission. Cited for: Adopted May 15, 2024; covers broker-dealers (including funding portals), investment companies, registered investment advisers and transfer agents; an incident response program reasonably designed to detect, respond to, and recover from unauthorized access to or use of customer information; oversight of service providers, including through due diligence and monitoring; notice to affected individuals as soon as practicable, but not later than 30 days, after becoming aware that unauthorized access to or use of customer information has occurred or is reasonably likely to have occurred.
  • [Release 34-100155] Adopting release for the Regulation S-P amendments (Release Nos. 34-100155; IA-6604; IC-35193), U.S. Securities and Exchange Commission. Cited for: The adopting release and its release numbers. It does not mention DMARC or email authentication.
  • [SEC compliance guide] Enhancements to Regulation S-P: A Small Entity Compliance Guide, U.S. Securities and Exchange Commission. Cited for: Effective August 2, 2024; larger entities comply by December 3, 2025, smaller entities by June 3, 2026.
  • [16 CFR 314.1] 16 CFR 314.1, Purpose and scope, eCFR. Cited for: Lists investment advisors that are not required to register with the Securities and Exchange Commission among the financial institutions the part covers (314.1(b)).
  • [16 CFR 314.3] 16 CFR 314.3, Standards for safeguarding customer information, eCFR. Cited for: An information security program that is written (314.3(a)).
  • [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.