DMARC for insurance agencies

DMARC for insurance agencies: stop fake premium notices sent as your agency

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

A policyholder gets an email from your agency's address: the premium is past due, coverage lapses Friday, pay here. Or: confirm your details so we can process the policy change. Your clients are used to hearing from you about money and deadlines, which is exactly what makes your domain worth forging.

Publish DMARC at enforcement and the policyholder's mail provider is told to refuse mail that forges your exact domain. The harder part is everything that already sends as the agency (the management system, the carrier portals, the payment links) and getting it aligned before a renewal notice bounces. The NAIC's data security model law doesn't name DMARC, but two of its items describe what the record does.

Check your domain free Several domains? Check them together

The email that looks like a renewal

Premium reminders, renewal notices, ID cards, certificates: an agency sends a steady stream of routine mail that clients act on without much thought. A forged version from your exact domain inherits that trust. Without an enforced DMARC policy, the receiving server has no instruction from you about what to do with it.

Carrier impersonation is a separate problem. A fake email from a carrier uses the carrier's domain, and only the carrier's DMARC record speaks to it. Your record protects your name, which is the one your clients see most.

What the NAIC model law asks for

The NAIC Insurance Data Security Model Law (#668), adopted in late 2017, applies to licensees: any person licensed, authorized to operate or registered under a state's insurance laws [NAIC Model 668, §3]. It requires a written information security program [NAIC Model 668, §4A] based on a risk assessment that identifies reasonably foreseeable internal or external threats [NAIC Model 668, §4C]. Its risk management measures include controls to authenticate and permit access only to authorized individuals, and regular testing and monitoring of systems to detect actual and attempted attacks [NAIC Model 668, §4D(2)(a), (h)]. When the model's criteria are met, a licensee must notify the commissioner as promptly as possible and no later than 72 hours after determining a cybersecurity event occurred [NAIC Model 668, §6A].

A model law is a template until a state enacts it. NAIC's August 2025 brief counted 28 jurisdictions that had implemented it [NAIC brief, Aug 2025]. Alabama's version, for example, is Ala. Code §§ 27-62-1 to 27-62-12, from 2019 [NAIC state chart]. Your state's enacted text is the one that applies, and it can differ from the model.

The model doesn't mention email authentication. DMARC fits two of its items: the risk assessment, because someone emailing your clients as your agency is a foreseeable external threat, and the monitoring item, because aggregate reports show attempts to send as your domain, including the ones that failed. The model exempts licensees with fewer than ten employees, including independent contractors, from Section 4 [NAIC Model 668, §9A]. That is the program requirement, not the notification section.

Taking premium by card brings in PCI DSS. Its Requirement 5.4.1, a best practice until 31 March 2025 and required after, asks for processes and automated mechanisms to detect and protect personnel against phishing attacks [PCI DSS SAQ D, p. 36]. Which self-assessment questionnaire your card setup puts you in decides whether you answer it. Our PCI DSS and DMARC page covers 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.youragency.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 agency

Agencies tend to have more systems sending as them than staff realize, because a carrier or a software provider set several of them up:

  • Microsoft 365 or Google Workspace. Producer and CSR mailboxes. Microsoft 365 leaves custom-domain DKIM off until it is configured [Microsoft DKIM guide].
  • Agency management system. Renewal notices, ID cards and policy documents emailed from the management system.
  • Carrier and rating portals. Quotes and documents sent through a portal. If it sends from the carrier's own domain with your address as reply-to, your policy does not apply to it. If it puts your address in the From line, it has to align.
  • Payment links and receipts. Premium payment requests and receipts from a payment processor.
  • Certificates of insurance. Certificate requests and deliveries, often from a separate tool.
  • E-signature and newsletters. Application signatures and the client 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 agency'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 agency: 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 youragency.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.

Agencies that grew by buying books of business often still own the acquired agency's domain. If it forwards to you, it still needs a DMARC record. If it sends nothing, give it the parked-domain record above. And avoid moving to quarantine in the middle of a heavy renewal month.

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. youragency-ins.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 anything involving payment, tell clients how you actually ask for money (the portal, the phone or the carrier bill) and that it won't change by email. For requests that come to you, such as a “client” asking to change a payee or bank account, confirm by phone at the number in the file before acting.

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 NAIC Insurance Data Security Model Law require DMARC?

No. Model Law #668 does not mention email authentication. What it asks for is a written program grounded in a risk assessment, plus access controls and monitoring for actual and attempted attacks. An enforced DMARC record answers one foreseeable threat in that assessment: someone emailing your clients as the agency. Your state's enacted version is the text that applies.

We have fewer than ten employees. Does the model law apply to us?

Under the model, a licensee with fewer than ten employees, including independent contractors, is exempt from Section 4, the information security program. The model does not exempt small licensees from the rest of the act. States can change the details when they enact it, so check your state's text or ask your compliance adviser.

Our carrier portal sends quotes for us. Will DMARC block them?

That depends on whose domain is in the From line. Many portals send from the carrier's own domain with your address as the reply-to, and your policy never sees those. If the portal puts your agency's domain in the From line, it needs aligned SPF or DKIM before you enforce. Your p=none reports show which kind you have.

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.

  • [NAIC Model 668] Insurance Data Security Model Law (#668), National Association of Insurance Commissioners. Cited for: Adopted 4th quarter 2017. Licensee definition (§3); written information security program (§4A) based on a risk assessment of reasonably foreseeable internal or external threats (§4C); controls to authenticate and permit access only to authorized individuals (§4D(2)(a)) and regular testing and monitoring to detect actual and attempted attacks (§4D(2)(h)); notice to the commissioner as promptly as possible and no later than 72 hours after determining a cybersecurity event occurred, when the section's criteria are met (§6A); licensees with fewer than ten employees, including independent contractors, exempt from Section 4 (§9A). No mention of email authentication.
  • [NAIC brief, Aug 2025] The NAIC Insurance Data Security Model Law (August 2025 brief), National Association of Insurance Commissioners. Cited for: 28 jurisdictions had implemented Model Law #668 as of the August 2025 update.
  • [NAIC state chart] NAIC Model Laws, Regulations, Guidelines and Other Resources, Summer 2026: Model #668 state page, National Association of Insurance Commissioners. Cited for: Alabama: Ala. Code §§ 27-62-1 to 27-62-12 (2019).
  • [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.