By Ryan Windt | Head of Growth Marketing | Updated April 2026
Most businesses set up email and never think about it again. The domain works. Mail goes out. Replies come back. That is the entire mental model.
It is also why email remains the entry point for the majority of cyber insurance claims filed today.
Business email compromise, phishing, and spoofing attacks do not succeed because attackers are sophisticated. They succeed because the target organization never configured three basic technical controls that have been available for free, for years, on every domain in the world. Those controls are SPF, DKIM, and DMARC.
Understanding what they do, why underwriters care about them, and how to document them correctly before your next renewal is worth your time. This post covers all three.
Why Email Authentication Controls Appear on Cyber Insurance Applications
Underwriters do not ask about SPF, DKIM, and DMARC because they enjoy reading DNS records. They ask because the absence of these controls is a reliable predictor of loss.
When an attacker can spoof your domain, they can send email that appears to come from your CEO, your CFO, your IT team, or your accounting department. Your employees cannot tell the difference by looking at the sender address. Neither can your clients, vendors, or banking partners. That is the foundation of every business email compromise attack.
The FBI’s 2025 Internet Crime Report identified BEC as one of the highest-loss categories in reported cybercrime, with losses exceeding $2.7 billion in a single year. A significant portion of those losses trace back to organizations with no email authentication controls in place.
Carriers have noticed. In the current underwriting environment, the absence of DMARC enforcement is increasingly treated the same way the absence of MFA was treated four or five years ago: as a control gap significant enough to affect pricing, terms, or bindability.
SPF: Who Is Allowed to Send Email on Your Behalf
Sender Policy Framework (SPF) is a DNS record that tells the world which mail servers are authorized to send email from your domain.
When an email arrives claiming to be from your domain, the receiving mail server checks your SPF record to see whether the sending server is on your approved list. If it is not, the receiving server can flag or reject the message.
What a Basic SPF Record Looks Like
SPF records live in your domain’s DNS as a TXT record. A simplified example:
v=spf1 include:_spf.google.com include:mailgun.org ~allBreaking that down:
- v=spf1 tells receiving servers this is an SPF record
- include: statements authorize specific mail providers you use
- ~all is a softfail, meaning mail from unauthorized servers is flagged but not rejected
- -all is a hard fail, meaning unauthorized mail is rejected outright
SPF Limitations
SPF only checks the sending server’s IP address. It does not authenticate the “From” address that email recipients actually see. This is important because attackers learned to exploit this gap years ago. SPF alone does not stop domain spoofing in the way most people assume it does.
That is where DKIM and DMARC fill in.
DKIM: A Digital Signature on Every Email You Send
DomainKeys Identified Mail (DKIM) adds a cryptographic signature to outgoing email. That signature is generated using a private key held by your mail server and verified against a public key published in your DNS.
When a receiving mail server gets your email, it looks up your DKIM public key and checks whether the signature in the email header was generated by the matching private key. If it was, the message has not been tampered with in transit and genuinely came from a server with access to your private key.
Why DKIM Matters for Insurance
DKIM solves a different problem than SPF. SPF verifies the sending server. DKIM verifies the message itself. Together they address two separate attack vectors.
From an underwriting standpoint, DKIM is increasingly expected as a baseline control alongside SPF. The combination tells carriers your email infrastructure is configured with deliberate intent, not defaults.
DKIM in Your DNS
A DKIM record looks like this in DNS:
selector._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."The long string after “p=” is your public key. Your email provider typically generates both keys and walks you through adding the public key to DNS. Most major providers (Google Workspace, Microsoft 365, and others) have step-by-step DKIM setup guides in their admin consoles.
DMARC: The Policy That Ties SPF and DKIM Together
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is the control that underwriters most specifically ask about, and for good reason.
DMARC does two things that SPF and DKIM cannot do on their own.
First, it tells receiving mail servers what to do when an email fails SPF or DKIM checks. Without DMARC, failing those checks has no enforced consequence. The receiving server might flag the message, or it might not. DMARC gives you control over that outcome.
Second, it provides reporting. You can configure DMARC to receive aggregate and forensic reports showing you who is sending email from your domain, legitimate or otherwise. This visibility is operationally valuable beyond insurance compliance.
The Three DMARC Policy Levels
DMARC policies are set in a DNS TXT record and have three enforcement options:
| Policy | What It Tells Receiving Servers |
|---|---|
| p=none | Take no action on failures. Monitor and report only. |
| p=quarantine | Send failing messages to spam or quarantine. |
| p=reject | Reject failing messages outright. Do not deliver them. |
A basic DMARC record looks like this:
_dmarc.yourdomain.com TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"- p=reject is the enforcement level underwriters want to see
- rua= is the address where aggregate reports are sent
Why p=none Does Not Satisfy Underwriters
When carriers ask about DMARC on an application, they are asking whether you have enforcement in place, not whether you have a DMARC record at all.
A DMARC record set to p=none is the monitoring-only mode. It generates reports but takes no action when someone spoofs your domain. Attackers can still successfully send phishing email that appears to come from your organization.
From an underwriting perspective, p=none is better than nothing because it at least demonstrates awareness. But carriers increasingly expect p=quarantine at minimum, with p=reject being the gold standard for organizations serious about reducing BEC exposure.
Moving from p=none to p=reject does require testing. Rushing the transition can cause legitimate email to be rejected if your SPF and DKIM records are incomplete. A staged rollout over 30 to 60 days is standard practice.
How These Controls Appear on Cyber Insurance Applications
Application language varies by carrier, but the questions generally fall into a few patterns.
Some applications ask directly: “Does your organization have DMARC implemented with a policy of quarantine or reject?”
Others ask more broadly about email security controls and follow up with specific questions about enforcement levels.
A growing number of carriers are conducting their own DNS lookups as part of underwriting review. They are not taking your word for it. If your application says you have DMARC enforcement and your DNS record says p=none, that discrepancy will be identified.
This matters beyond the application. Misrepresentation on a cyber insurance application is one of the most common reasons claims are denied. If you report controls you do not actually have, a carrier has grounds to deny a BEC claim on the basis of material misrepresentation. The cyber insurance application and claim denial post covers this in more detail.
Verifying Your Current Email Authentication Configuration
Before your next renewal, confirm where your domain stands on all three controls. Several free tools make this straightforward.
MXToolbox (mxtoolbox.com) has individual lookup tools for SPF, DKIM, and DMARC. You can check each record in seconds without any technical setup.
Google Admin Toolbox includes a “Check MX” tool that will flag configuration issues with your DNS records.
DMARC Analyzer and similar services will parse your DMARC aggregate reports and show you what is actually sending email from your domain.
What you are looking for:
- An SPF record exists with appropriate includes for every mail service you use
- DKIM is configured for every sending domain, including subdomains used for transactional or marketing email
- A DMARC record exists at p=quarantine or p=reject, not p=none
- Your DMARC record includes a reporting address so you are actually receiving the data
A Note on Subdomains and Third-Party Senders
Two areas where organizations frequently have gaps even after setting up the basics.
Subdomains used for transactional email, marketing automation, or client portals may not inherit your root domain’s DMARC policy. If you send from notifications.yourdomain.com or mail.yourdomain.com, those subdomains need their own SPF and DKIM records. Your DMARC record can include a subdomain policy (sp=) to cover them, or each subdomain can have its own record.
Third-party senders like marketing platforms, billing systems, and CRM tools need to be authorized in your SPF record and may require DKIM configuration through your email provider’s portal. A common gap is adding a new tool and not updating SPF to authorize it, which causes legitimate outbound email to fail authentication checks.
Both issues show up in DMARC aggregate reports, which is another reason the reporting function is valuable even after you reach p=reject.
What to Tell Your Underwriter
When email authentication comes up in renewal conversations or applications, be specific and accurate.
The right answer is not “yes, we have email security.” The right answer is: “We have SPF configured for all sending domains, DKIM is enabled through our email provider, and our DMARC policy is set to p=reject with aggregate reporting enabled. We review reports quarterly.”
That level of specificity demonstrates that your team understands what the controls actually do and has implemented them intentionally. Underwriters notice the difference between a checkbox response and one that reflects operational awareness.
If you are not yet at p=reject, be honest about where you are and what the timeline looks like. A credible path to enforcement is better than overstating your current posture.
The Broader Picture
SPF, DKIM, and DMARC are not complex to implement. For most organizations using Google Workspace or Microsoft 365, setup takes a few hours and costs nothing beyond the time involved.
What they protect against, BEC, phishing, and domain spoofing, represents billions of dollars in annual losses and one of the most consistent sources of cyber insurance claims.
Carriers have priced that risk into their underwriting models. Organizations with enforcement in place are meaningfully lower risk than organizations without it. That difference shows up in premiums, coverage terms, and how quickly a carrier is willing to bind.
If your domain is not fully configured, now is the right time to fix it. If you have questions about how your email security posture affects your coverage options, SeedPod Cyber works directly with businesses and through brokers to find the right fit.