SPF, DKIM, and DMARC Explained: How These Three Email Security Protocols Protect Your Business From Spoofing and Phishing

Introduction: Can Someone Send an Email Using Your Company's Domain?

Imagine receiving an email that appears to come directly from your company's CEO.

The sender's address looks legitimate, the company name is correct, and the message urgently requests a payment to a new bank account.

Would your employees recognize that the email is fraudulent?

One of the fundamental weaknesses of traditional email is that the address displayed to recipients is not, by itself, proof of who sent the message.

Attackers can construct emails that claim to originate from domains they do not control.

This technique, known as email spoofing, is frequently associated with phishing, financial fraud, credential theft, and Business Email Compromise (BEC).

To combat this problem, the email industry developed three complementary authentication technologies:

• SPF (Sender Policy Framework): Identifies which servers are authorized to send email using a domain.

• DKIM (DomainKeys Identified Mail): Uses cryptographic signatures to verify that a domain signed an email and that protected message content has not been improperly modified.

• DMARC (Domain-based Message Authentication, Reporting, and Conformance): Connects SPF and DKIM to the domain recipients see and allows domain owners to publish policies for handling authentication failures.

Individually, these technologies provide important protection. Together, they create a stronger defense against direct domain impersonation.

However, configuring them incorrectly can leave organizations exposed or cause legitimate messages to be rejected.

Let's examine how each protocol works.

1. SPF: Controlling Which Mail Servers Can Send Email for Your Domain

Sender Policy Framework, commonly called SPF, is an email authentication mechanism that uses DNS records to identify authorized sending servers.

DNS, or the Domain Name System, is the technology used to translate domain names into network information.

Organizations can publish an SPF policy in DNS to specify which IP addresses and services are permitted to send email using a particular domain in the SMTP envelope.

How SPF Works

Consider a company using the domain example.com.

Its legitimate outgoing mail server has the IP address 192.0.2.10.

The company publishes an SPF TXT record:

v=spf1 ip4:192.0.2.10 -all

This record essentially communicates:

"Mail servers checking SPF for this domain should recognize 192.0.2.10 as an authorized sender and treat other addresses as unauthorized."

When a receiving mail server processes an incoming message, it can:

1. Identify the IP address of the connecting mail server.

2. Determine the relevant SMTP envelope domain.

3. Retrieve the SPF record from DNS.

4. Evaluate the IP address against the published policy.

5. Produce an SPF authentication result.

If the sender is authorized, the SPF check passes.

If the sending IP does not match an authorized source and the policy specifies a hard failure, the SPF check fails.

Understanding an SPF Record

Let's break down this example:

v=spf1 ip4:192.0.2.10 -all

A domain may also authorize external services, such as email marketing platforms, helpdesk systems, or cloud email providers.

Those services often provide SPF instructions using the include: mechanism.

However, administrators must authorize only the services they actually use.

What Is the Difference Between ~all and -all?

These two SPF mechanisms are commonly misunderstood.

~all — Softfail

Indicates that the domain owner believes unmatched sources are probably unauthorized, without asserting the stronger SPF fail result.

-all — Fail

Indicates that unmatched sources are not authorized under the published policy.

Neither value independently guarantees that an email will be rejected. Receiving systems make their own delivery decisions, taking other authentication results and policies into account.

A strict SPF configuration should be deployed only after all legitimate sending services have been identified.

The Important Weakness in SPF

SPF does not directly authenticate the visible From: address that most email users see.

Instead, it normally validates the domain associated with the SMTP envelope sender, often reflected in the message's Return-Path.

An attacker can control a different domain, configure its SPF correctly, and send an email that displays your company's address in the visible From field.

The attacker's own domain may pass SPF while the displayed business domain remains impersonated.

Expert security insight: SPF answers whether a server is authorized for a particular SMTP identity. It does not independently prove that the visible sender address belongs to that identity.

This limitation is one of the reasons DMARC is necessary.

2. DKIM: Protecting Email Authenticity With Cryptographic Signatures

DomainKeys Identified Mail, or DKIM, takes a different approach.

Instead of checking the sending server's IP address, DKIM uses public-key cryptography to verify a digital signature attached to an email.

The technology allows a receiving server to determine whether a particular domain signed the message and whether the signed portions remain intact.

How DKIM Works

DKIM uses two related cryptographic keys.

Private key: Held securely by the sending system and used to generate email signatures.

Public key: Published in DNS and used by receiving systems to verify signatures.

When an authorized email server sends a message, it generates a signature using its private key.

The signature is included in the email headers.

The receiving server retrieves the corresponding public key from DNS and verifies the signature against the protected message content.

If the verification succeeds, the receiving server knows that the message was signed using the private key associated with the declared DKIM domain.

A Practical DKIM Example

Suppose a company sends an email from:

support@example.com

Its outgoing mail system signs the message using a DKIM selector named s1.

The public key is published at:

s1._domainkey.example.com

A simplified DNS TXT record could look like:

v=DKIM1; k=rsa; p=PUBLIC_KEY_HERE

The text PUBLIC_KEY_HERE is a placeholder. A real configuration requires an actual public key generated by the sending system.

The email itself includes a DKIM-Signature header containing information such as:

• d=example.com — The signing domain.

• s=s1 — The selector identifying the relevant DNS key.

• a=rsa-sha256 — The signing algorithm.

• bh= — The cryptographic hash of the protected message body.

• b= — The digital signature value.

The receiving server uses these values to locate the public key and verify the signature.

What Happens if Someone Changes the Email?

Suppose an attacker modifies the protected message content after it has been signed.

For example, the original email instructs a customer to make a payment to an approved company bank account.

An attacker attempts to replace those details with another bank account number.

If the modification changes the content covered by the DKIM signature, verification will generally fail.

However, DKIM does not guarantee that every header or every possible modification is protected. The protection depends on how the message was signed.

What DKIM Does Not Do

DKIM is often misunderstood as a complete email encryption system.

It is not.

DKIM does not encrypt email contents or prevent authorized parties along the delivery path from reading messages.

It also does not prove that the person identified in the visible From address personally wrote the message.

A malicious sender can sign fraudulent email using a domain the attacker controls.

Therefore, a valid DKIM signature alone is not proof that an email claiming to come from another business is legitimate.

Expert security insight: DKIM establishes a verifiable relationship between an email and its signing domain. DMARC is needed to determine whether that domain corresponds to the identity being presented to the recipient.

3. DMARC: Connecting Authentication to the Sender's Identity

DMARC is the technology that brings SPF and DKIM together.

Its primary objective is to help prevent attackers from impersonating a domain in an email's visible From address.

DMARC does this through a concept called domain alignment.

Why Domain Alignment Matters

Consider the following situation.

An attacker controls the domain:

malicious.example

The attacker publishes valid SPF and DKIM records for that domain.

Then the attacker sends an email containing these identities:

Visible From: ceo@example.com

SMTP Envelope Sender: attacker@malicious.example

DKIM Signing Domain: malicious.example

The email may pass SPF and DKIM because the attacker legitimately controls the infrastructure and cryptographic keys for malicious.example.

But it should not be considered an authenticated email from example.com.

DMARC detects this distinction by comparing the authenticated domains with the domain in the visible From address.

In this case:

• SPF authentication may pass, but the authenticated domain is not aligned with example.com.

• DKIM authentication may pass, but the signing domain is not aligned with example.com.

• DMARC fails because neither authenticated identity aligns with the claimed sender domain.

This is a critical security improvement.

Does DMARC Require Both SPF and DKIM to Pass?

No.

For a message to pass DMARC, it needs at least one of the following:

• A passing SPF result with an aligned domain.

• A valid DKIM signature with an aligned domain.

Both methods can pass, and organizations should configure both correctly for greater resilience.

However, the DMARC protocol does not require both to pass simultaneously.

Relaxed vs. Strict Alignment

DMARC supports two alignment modes.

Relaxed alignment allows domains within the same organizational domain to align.

For example, mail.example.com and example.com can align under relaxed rules.

Strict alignment requires the authenticated domain to match the visible From domain exactly.

These settings are controlled by:

• aspf=r or aspf=s for SPF alignment.

• adkim=r or adkim=s for DKIM alignment.

Relaxed alignment is the default and is appropriate for many organizations.

Strict alignment may be useful where tightly controlled identity boundaries are needed, but it requires careful testing.

4. DMARC Policies: None, Quarantine, and Reject

Domain owners publish DMARC policies as DNS TXT records.

For example.com, the record is located at:

_dmarc.example.com

Three main policy values define the domain owner's requested handling of messages that fail DMARC.

Policy 1: p=none

This is monitoring mode.

Example:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

This policy requests reports without asking receivers to quarantine or reject messages solely because they fail DMARC.

It is useful during initial deployment when administrators are identifying legitimate sending sources and authentication problems.

However, p=none is not an active anti-spoofing enforcement policy.

Policy 2: p=quarantine

Example:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com

This requests that receiving systems treat DMARC-failing messages as suspicious.

Many receivers may send such messages to spam or junk folders.

Quarantine can provide stronger protection while reducing some of the delivery risks associated with immediate rejection.

Policy 3: p=reject

Example:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

This requests rejection of messages that fail DMARC validation.

It offers a strong anti-spoofing signal, particularly for tightly managed domains with predictable mail flows.

However, it is not appropriate to apply p=reject blindly to every domain.

Legitimate messages passing through mailing lists and forwarding services may fail authentication after being modified.

The updated DMARC standard specifically cautions against using p=reject on general-purpose email domains where such indirect mail flows are common, unless the risks have been carefully evaluated.

Receiving mail systems also retain responsibility for their final delivery decisions.

Expert security recommendation: Begin with monitoring, correct authentication problems, evaluate indirect mail traffic, and select an enforcement policy appropriate to the domain's actual email usage.

5. How SPF, DKIM, and DMARC Work Together

Let's follow a legitimate business email traveling from sender to recipient.

Step 1: The employee sends an email.

An employee sends an invoice from billing@example.com.

Step 2: The authorized outgoing server processes it.

The mail server is included in the relevant SPF policy.

Step 3: The message is digitally signed.

The outgoing mail infrastructure adds a DKIM signature using a private signing key.

Step 4: The receiving server checks SPF.

It verifies the sending IP against the SPF record for the SMTP envelope domain.

Step 5: The receiving server verifies DKIM.

It retrieves the signing domain's public key and checks the digital signature.

Step 6: DMARC evaluates alignment.

The receiver compares the authenticated SPF and DKIM domains against the visible From domain.

Step 7: The receiver evaluates the message.

If DMARC passes, the message has a positive domain-authentication result.

If DMARC fails, the recipient's provider considers the domain's DMARC policy and other security signals.

SPF vs. DKIM vs. DMARC

The three controls are complementary rather than interchangeable.

A correctly configured authentication system strengthens confidence in domain identity, but it does not automatically prove that an email is harmless.

6. How Hackers Exploit Missing SPF, DKIM, and DMARC Protection

Consider a hypothetical manufacturing company called Example Industries.

The company's official domain is example.com.

Its finance department regularly receives invoices and payment instructions by email.

A cybercriminal identifies a supplier relationship and attempts to impersonate the supplier's finance department.

The attacker constructs an email with the supplier's legitimate domain in the From field and requests payment to a fraudulent bank account.

If the impersonated supplier has not implemented an effective DMARC policy, receiving systems may have fewer domain-specific instructions for detecting and handling this impersonation.

A sufficiently convincing email could reach the recipient's inbox, depending on the receiving provider's other security controls.

The employee might then act on the fraudulent payment instructions.

This illustrates why email authentication matters in financial fraud prevention.

However, attackers can also register lookalike domains or compromise legitimate mailboxes.

For example, a fraudulent message sent from examp1e.com rather than example.com may pass SPF, DKIM, and DMARC for the attacker's own domain.

Therefore, DMARC should be combined with user education, domain monitoring, account security, and independent verification of sensitive business requests.

The key limitation: Email authentication can help establish whether a domain is being legitimately used. It cannot determine whether the authenticated sender is trustworthy or whether the requested action is safe.

7. How to Configure SPF, DKIM, and DMARC Correctly

Businesses should approach email authentication as an organized infrastructure project.

Step 1: Identify Every Legitimate Email Sender

Before changing DNS records, identify all systems that send mail using your domains.

These might include:

• Microsoft 365 or Google Workspace.

• Website contact forms.

• Customer relationship management (CRM) systems.

• Accounting and invoicing applications.

• Marketing and newsletter platforms.

• Helpdesk and ticketing systems.

• Automated monitoring systems.

• Internal mail servers.

An overlooked service may begin failing authentication after restrictive policies are introduced.

Step 2: Configure SPF

Publish a single valid SPF TXT policy for each relevant domain.

Include the authorized sending IP addresses and approved provider mechanisms.

Avoid blindly copying SPF records from online examples.

SPF has a limit of 10 DNS-lookup-triggering terms during evaluation, including mechanisms such as include, a, and mx, and the redirect modifier.

Nested includes can contribute to this limit.

Exceeding the limit can cause SPF permanent errors and disrupt legitimate email delivery.

Step 3: Enable DKIM Signing

Activate DKIM in each legitimate sending platform.

Generate or obtain the required DNS records from the provider.

Publish the designated public keys and verify that messages are being signed with a domain aligned to your visible From address.

Where supported, 2048-bit RSA keys provide a stronger practical configuration than older 1024-bit RSA keys.

Private signing keys must remain protected, and key rotation should be supported by operational procedures.

Step 4: Publish a DMARC Monitoring Policy

Begin with a record such as:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the example address with an actual mailbox or reporting service configured to receive DMARC aggregate reports.

Step 5: Review the Reports

DMARC aggregate reports can identify:

• Sending IP addresses claiming to use your domain.

• SPF authentication results.

• DKIM authentication results.

• Domain alignment failures.

• Unexpected systems using your domain.

• Legitimate services requiring configuration changes.

These reports are particularly useful when an organization uses multiple third-party sending providers.

Step 6: Correct Authentication and Alignment Failures

Not every failed message is malicious.

A legitimate email might fail because a marketing service signs with its own domain, a forwarding service changes the mail path, or a system is configured with an incorrect envelope sender.

Fix these issues before introducing stricter DMARC policies.

Step 7: Select and Test an Enforcement Policy

After sufficient monitoring, consider moving to quarantine where appropriate.

For highly controlled sending domains, rejection may provide stronger protection.

Organizations using public mailing lists, forwarding services, or complex indirect mail flows should assess the possible impact before enforcing rejection.

Continue monitoring reports after policy changes.

8. DMARC Reports: Turning Email Authentication Into Threat Intelligence

One of DMARC's most valuable capabilities is reporting.

Many companies configure SPF and DKIM but never review whether those controls are functioning correctly across all sending services.

DMARC aggregate reports help close that visibility gap.

These reports are generally XML-based and may contain information about sending sources, authentication outcomes, and receiver policy decisions.

A cybersecurity team can use them to investigate suspicious patterns.

For example, reports might reveal that an unfamiliar IP address is repeatedly sending messages claiming to originate from a company domain.

That activity warrants investigation.

However, an unknown source is not necessarily an attacker. It could be a forgotten business application, an external vendor, or a forwarding system.

Building a Useful Monitoring Strategy

Security administrators should look for:

• Sudden increases in DMARC failures.

• New or unexplained sending IP addresses.

• Persistent failures from legitimate business systems.

• Unexpected sending behavior across subdomains.

• Authentication changes following provider migrations.

Reports can also help companies identify obsolete services that still attempt to send mail on their behalf.

Expert security insight: DMARC reporting is not a replacement for endpoint detection, email security gateways, or SIEM monitoring. It is an additional source of domain-authentication telemetry that can strengthen an organization's security investigations.

9. Common Email Authentication Mistakes

Even experienced administrators can make mistakes when configuring these protocols.

Publishing Multiple SPF Records

A domain must not publish multiple independent SPF records.

Combining all authorized sources into one valid policy is essential.

Forgetting Third-Party Email Services

An organization may configure SPF and DKIM for its primary mail platform while overlooking its newsletter provider or helpdesk system.

This can produce authentication failures and delivery problems.

Assuming SPF Pass Means DMARC Pass

SPF can authenticate a domain that is different from the one displayed to recipients.

DMARC requires alignment.

Using p=none Forever

Monitoring is valuable, but it does not request anti-spoofing enforcement.

Organizations should periodically evaluate whether stronger policies are suitable.

Enforcing Reject Without Monitoring

Aggressive policy changes can affect legitimate mail, particularly through mailing lists and forwarding systems.

Ignoring DKIM Key Management

Expired provider configurations, removed DNS keys, and poor key-management procedures can cause authentication failures.

Treating DMARC as a Complete Anti-Phishing Solution

DMARC cannot independently prevent attacks using lookalike domains or compromised legitimate accounts.

Businesses still need multi-factor authentication, secure account management, email filtering, security awareness, and well-designed financial approval procedures.

10. Why Email Forwarding Can Break Authentication

Email forwarding introduces a technical complication that administrators should understand.

Imagine a message sent from Company A to an employee who has configured automatic forwarding to another mailbox.

The forwarding server may deliver the message from a different IP address.

That new IP may not appear in the original sending domain's SPF policy.

As a result, SPF can fail at the final destination.

DKIM may continue passing because its signature is not inherently tied to the sender's IP address.

However, if an intermediate service modifies signed content, such as adding a mailing-list footer, DKIM verification can also fail.

When both authenticated paths fail or lack alignment, DMARC fails.

Can ARC Help?

Authenticated Received Chain (ARC) is another email-related protocol designed to preserve authentication assessments across intermediate mail systems.

ARC can provide useful evidence about a message's earlier authentication results.

However, it does not guarantee delivery or automatically override DMARC.

Receiving systems determine how much trust to place in ARC information.

This matters for businesses that operate mailing lists, email forwarding gateways, and complex mail-routing environments.

11. Why SPF, DKIM, and DMARC Matter More in 2026

Email authentication is no longer merely an optional improvement for organizations that want extra protection.

Major mailbox providers have introduced formal sender-authentication requirements.

Google requires SPF or DKIM for all senders to Gmail accounts and requires SPF, DKIM, and DMARC for senders exceeding its bulk-sender threshold.

Microsoft has also introduced stricter authentication requirements for high-volume senders to its consumer email services.

These requirements have made correct email authentication increasingly important for businesses sending invoices, notifications, newsletters, and customer communications.

The Updated DMARC Standard

In May 2026, the Internet Engineering Task Force published updated DMARC standards:

• RFC 9989: DMARC core protocol.

• RFC 9990: DMARC aggregate reporting.

• RFC 9991: DMARC failure reporting.

These documents replace the older RFC 7489 specification.

Among the changes, RFC 9989 introduces DNS Tree Walk policy discovery and removes several older DMARC tags, including pct, which attempted to control the percentage of failing messages subject to enforcement.

The updated standard also gives additional attention to the problems strict enforcement can create for legitimate indirect email flows.

Administrators should therefore avoid relying exclusively on older DMARC tutorials when designing new deployments.

12. Frequently Asked Questions

Do I need all three: SPF, DKIM, and DMARC?

Using all three is generally recommended. SPF authorizes sending infrastructure, DKIM provides cryptographic domain signing, and DMARC evaluates alignment with the visible sender identity while enabling policy publication and reporting.

Does DMARC prevent all phishing attacks?

No. DMARC helps combat direct spoofing of protected domains. Attackers may still use lookalike domains, compromised email accounts, or other social engineering techniques.

Will SPF and DKIM improve email deliverability?

Correct authentication can support successful delivery and help organizations meet provider requirements. However, deliverability also depends on sender reputation, message quality, user engagement, and other filtering signals.

Should every domain use p=reject?

Not necessarily. Rejection can be effective for controlled mail streams, but domains used for public mailing lists or complex forwarding arrangements may experience legitimate authentication failures. The appropriate policy depends on how the domain is used.

Can I configure these records through Cloudflare?

Yes. SPF, DKIM, and DMARC are commonly published as DNS TXT records and can be managed through a DNS provider such as Cloudflare.

The actual signing configuration must also be enabled in your email service.

How do I check whether SPF, DKIM, and DMARC are working?

Inspect the authentication results in message headers from legitimate test emails.

Look for results such as spf=pass, dkim=pass, and dmarc=pass.

For DNS verification, Windows administrators can use commands such as:

nslookup -type=TXT example.com

nslookup -type=TXT _dmarc.example.com

nslookup -type=TXT s1._domainkey.example.com

Replace the sample domain and DKIM selector with the values used by your organization.

Remember that correct DNS records alone do not prove that your outbound mail is properly authenticated. Real message testing and domain-alignment verification are also necessary.

Conclusion: Protecting Your Business Identity Starts With Email Authentication

Email remains one of the most widely used communication technologies in the business world, and its popularity makes it an attractive target for cybercriminals.

A fraudulent message impersonating a trusted company can expose employees and customers to credential theft, financial fraud, and sensitive information disclosure.

SPF, DKIM, and DMARC were developed to address important weaknesses in traditional email authentication.

SPF helps identify authorized sending infrastructure.

DKIM verifies cryptographic signatures associated with sending domains.

DMARC connects those authentication results to the domain users actually see and allows domain owners to publish policies and receive reports.

Together, they significantly strengthen protection against direct email domain spoofing.

But deploying these controls is not a one-time task.

As organizations introduce new cloud services, marketing platforms, automated systems, and external vendors, their email infrastructure evolves.

Authentication policies must evolve with it.

The strongest approach is to combine correctly configured SPF, DKIM, and DMARC with continuous monitoring, strong account security, effective incident response, and employee awareness.

Your company's domain is more than a website address. It is part of your digital identity and reputation.

Protecting that identity should be a fundamental part of every organization's cybersecurity strategy.