What is the difference between SPF, DKIM and DMARC?

SPF declares which servers are authorized to send email from your domain. DKIM cryptographically signs outgoing messages so the recipient can verify the message has not been altered and was authorized by the signing domain. DMARC ties SPF and DKIM together with a policy that tells receiving servers what to do when authentication fails (none, quarantine, reject) and reports failures back to the domain owner. The three are complementary; deploying only one leaves measurable gaps.

Does DMARC stop phishing entirely?

No. DMARC at p=reject prevents direct domain spoofing of your registered sending domain. It does not stop lookalike domain attacks (typosquatting, homograph), display-name spoofing (where the visible sender name is yours but the email address is attacker-controlled), compromised mailbox attacks (where the attacker sends from a legitimate but compromised account) or third-party impersonation lures. DMARC is one layer; phishing simulation training, MFA and user reporting are the other layers.

What DMARC policy should we deploy?

The recommended progression is p=none for the first 30-60 days (collect telemetry, identify all legitimate senders, fix false positives), then p=quarantine for 30-60 days (failing email moves to spam folder rather than being rejected outright), then p=reject for ongoing operation. Skip p=quarantine only at your peril; jumping directly from none to reject is the most common DMARC deployment failure and produces email-delivery outages for legitimate marketing or transactional senders that were not yet aligned.

How long does it take to deploy DMARC?

A correct deployment to p=reject takes 60-120 days for most organizations. The technical record changes are minutes; the time goes into telemetry collection, identifying all legitimate sending sources (marketing platforms, ticketing systems, payment processors, HR tools, billing platforms), aligning each with SPF and DKIM and waiting through enforcement-staging windows. Rushing to p=reject before this work is the largest single cause of DMARC-related email outages.

Do cyber insurers ask about DMARC?

Yes, increasingly so. Major cyber-insurance carriers in 2026 ask explicitly about DMARC policy enforcement, MFA coverage and phishing simulation programs in renewal questionnaires. Documented DMARC at p=reject is treated as a meaningful underwriting signal alongside the program-level controls. The trio of DMARC enforcement, MFA on all email and a continuous phishing simulation program now appears on most major-carrier checklists.

Does DMARC interact with phishing simulation programs?

Yes. Phishing simulation platforms send legitimate test emails from an authorized sending domain. The simulation sender domain must be added to your SPF allowlist, DKIM-signed and DMARC-aligned for the test emails to pass authentication and reach inboxes. Most platforms (including Bait & Phish) provide explicit DNS values for SPF and DKIM during onboarding; failure to apply them is the most common reason simulation emails are quarantined and produce inflated 'no-click' rates that misrepresent the actual program.

DMARC, DKIM, SPF: Email Authentication for Phishing Defense

Email authentication is the boring control that quietly does most of the work. SPF, DKIM and DMARC together form the technical foundation that prevents direct domain spoofing in phishing attacks. They do not stop every kind of phishing - lookalike domains and compromised mailboxes route around them entirely - but for the high-volume direct-spoof attacks that have been a workhorse of phishing for two decades, correctly deployed email authentication is what stops them at the gateway. Most organizations get one or two of the three protocols wrong; the smaller share that get all three right collect a meaningful underwriting credit at cyber-insurance renewal and a measurable reduction in the volume of phishing email that lands in user inboxes.

This post is for the IT director, the security engineer and the deliverability owner who has been told that email authentication is in place but is not certain it actually works. It walks through what each of the three protocols does, where they sit in the email path, the policy levels DMARC supports, the deployment progression that does not break legitimate email and the common mistakes that produce a "deployed but not enforced" state.

The big picture

SPF, DKIM and DMARC are three layered protocols that solve different parts of the same problem: how does a receiving mail server decide whether an email claiming to be from your domain was actually sent by you?

SPF answers the question "is the sending IP authorized to send for this domain?" by publishing the authorized senders in DNS.
DKIM answers "was this message actually authorized by the domain owner?" using a cryptographic signature.
DMARC answers "what should the receiver do if SPF or DKIM fails?" with a policy and gives the domain owner reporting on what happened.

None of the three is sufficient alone. SPF can be bypassed by message forwarding. DKIM can be deployed without enforcement. DMARC at p=none is informational only. The three together, deployed correctly, are what produces enforceable anti-spoofing.

SPF (Sender Policy Framework)

SPF is a TXT record at the apex of your domain that names the IP addresses or sending services authorized to send email from that domain. A receiving server compares the IP that delivered the message against the list and either passes, soft-fails or hard-fails based on the SPF record's terminator (-all, ~all, ?all).

Example: v=spf1 include:_spf.google.com include:sendgrid.net -all declares that Google Workspace and SendGrid are authorized to send mail for this domain, and any other source should be rejected. The -all terminator is a hard fail; ~all is a soft fail (delivery proceeds but the message is marked); ?all is neutral (do nothing). Modern guidance is -all once SPF inventory is complete.

SPF's main limitation is that it breaks on message forwarding. When a user auto-forwards a message, the forwarding server becomes the sending IP and SPF will fail unless the forwarder uses Sender Rewriting Scheme (SRS). For this reason, SPF alone is insufficient and DKIM provides the durability layer.

DKIM (DomainKeys Identified Mail)

DKIM is a public-key cryptographic signature applied to outgoing messages by the sending mail server. The public key is published as a TXT record at selector._domainkey.yourdomain.com; the private key signs the message body and selected headers. The receiving server validates the signature using the public key and confirms the signed parts have not been modified in transit and were authorized by the signing domain.

DKIM survives forwarding because the signature travels with the message body. It is also resistant to small modifications by intermediate relays as long as the signed headers are not rewritten. DKIM is the protocol that produces durable authentication across the modern email ecosystem of forwarders, mailing lists and gateway services.

DKIM has its own gotchas. Each sending platform requires its own selector and key. Key rotation is a real operational task; expired or revoked keys produce silent authentication failures that surface only in DMARC reports. Subdomain DKIM signing (mail.yourdomain.com) is a separate setup from apex (yourdomain.com) and the two do not share keys.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

DMARC sits on top of SPF and DKIM and provides two things: a policy directive to the receiving server about what to do when authentication fails, and an aggregate reporting feedback loop that tells the domain owner what is happening to mail claiming to be from their domain.

The DMARC record at _dmarc.yourdomain.com looks like: v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-failures@yourdomain.com; pct=100; sp=reject; aspf=s; adkim=s

p=none: monitor only. Receiver applies SPF/DKIM, reports back, but does not act on failures. Used during initial deployment.
p=quarantine: receiver delivers failing email to spam/junk. Used as a stepping-stone before reject.
p=reject: receiver bounces failing email outright. The endpoint of correct DMARC deployment.

The reporting addresses (rua for aggregate, ruf for individual failure samples) are critical. Without an active reporting subscription, you cannot see what your DMARC policy is doing in production. Dmarcian, Valimail and Postmark are the most-used reporting services; major email providers (Microsoft, Google) include DMARC reporting interfaces in their admin consoles for managed-tenant cases.

Why all three together

The combined setup defends against direct domain spoofing - email claiming to be from yourdomain.com - far better than any single protocol alone. SPF restricts the sources, DKIM proves authorization through cryptography, DMARC enforces policy and produces visibility. Together, they make the cost of spoofing your domain higher than the cost of attacking via a different vector.

This is why direct-spoof phishing has declined sharply for organizations with DMARC at p=reject. Attackers shift to lookalike domains (typosquatting, homograph), display-name spoofing (where the sender shows your name but a different address) or compromised mailbox attacks. None of those are stopped by email authentication; they require phishing simulation training, user reporting and human-layer detection.

Common deployment mistakes

Skipping p=quarantine. Jumping from p=none directly to p=reject is the most common mistake. Legitimate senders that were not yet DKIM-aligned will produce delivery outages.
Forgetting subdomains. The DMARC sp= tag controls subdomain policy. Without it, attackers can spoof marketing.yourdomain.com while you have yourdomain.com locked down.
Ignoring the SPF 10-lookup limit. SPF allows at most 10 DNS lookups per evaluation. Stacking many include directives breaks the record and produces silent SPF failures. Flatten or remove unused includes.
Not subscribing to DMARC reports. Deploying DMARC without a reporting destination is "open-loop" enforcement. You will not see legitimate senders failing alignment until users complain about missing email.
Forgetting transactional and marketing platforms. Inventory must include every system that sends mail from your domain. The most common forgotten senders are HR notifications, billing platforms and the phishing simulation platform itself.

How phishing simulation tests interact with email authentication

Phishing simulation programs need a sending domain that passes authentication for inboxes to receive the test emails. Simulation platforms typically provide an explicit allowlist value to add to SPF and a DKIM key to publish. Failure to apply these produces simulation emails that are blocked or quarantined, which inflates "no-click" results and gives the program a misleadingly clean appearance. The DMARC report will show the simulation sender failing alignment until the records are correctly updated.

If you are running a continuous program and your reports look unexpectedly clean, the first thing to check is whether the simulation platform's domain has been correctly aligned. The second is whether the user population received the test mail at all (gateway logs, mailbox-rule sweeps).

What to ask your insurance carrier

Cyber-insurance underwriting teams in 2026 weight DMARC enforcement, MFA coverage and continuous phishing-simulation programs as the three principal email-security signals. The questions you can expect on a renewal questionnaire: "Do you publish a DMARC record? At what policy?", "Are all sending sources DKIM-aligned?", "What share of your mail traffic passes DMARC at p=reject?". Documented evidence that the answer is "yes, p=reject, 95%+, here is the report" produces a measurable underwriting outcome.

Pulling it together

Email authentication is not glamorous and it is not the entire phishing defense. But it is the substrate that makes the rest of the program possible. Without DMARC at p=reject, your domain is spoofable and the rest of the controls live downstream of that gap. With it, direct-spoof phishing becomes a meaningfully harder attack against your organization, and the residual phishing volume your users see is the harder-to-detect kind that security awareness training and continuous simulation are designed to address.

If you want to see how a phishing simulation platform interacts with DMARC in practice, start a free trial covering up to 25 users - the platform documentation includes the SPF and DKIM values for your tenant. For deployment scoping, see pricing or contact us.

Related definitions

9may