How to Set Up SPF, DKIM, and DMARC for Email Authentication

Email spoofing is one of the simplest ways for an attacker to make a fraudulent message appear to come from a legitimate business.

An attacker does not necessarily need access to your mailbox. They can forge the sender information in an email and make a message appear to come from billing@yourcompany.com, your CEO, or another trusted address.

Three email authentication standards work together to reduce this risk:

• SPF (Sender Policy Framework) identifies which systems are authorized to send mail for your domain.
• DKIM (DomainKeys Identified Mail) adds a cryptographic signature to messages.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance) connects those authentication results to the domain users see in the From: address and tells receiving systems what to do when DMARC fails.

The key is not simply publishing three DNS records. You need to make sure your legitimate email streams authenticate correctly, align with your visible From: domain, and are monitored before you move to enforcement

The Three Pillars of Email Authentication

Think of these three technologies as different layers of protection. While SPF and DKIM can work independently, DMARC is what turns them into a true domain-level anti-spoofing policy.

SPF

SPF is published as a TXT record in DNS. It tells receiving mail systems which hosts are authorized to send mail for a domain.

A simple example is:

v=spf1 include:_spf.google.com -all

This example authorizes Google’s infrastructure.

However, do not copy this record unless Google is actually an authorized sender for your domain. Your SPF policy must account for all legitimate systems that send email using your domain, such as your mail provider, CRM, marketing platform, ticketing system, transactional email service, or other SaaS products.

There must normally be one SPF policy for a domain. Publishing multiple independent v=spf1 records does not create a combined policy; SPF evaluation can return a permanent error instead.

SPF also has an important limitation: it authenticates the SMTP envelope identity, not the visible From: address that users see in their mail client. That is one reason SPF alone is not enough to prevent spoofing.

DKIM

DKIM uses public-key cryptography to sign outbound email.

Your email provider generates a private key and signs messages with it. You publish the corresponding public key in DNS, usually at a hostname such as:

selector1._domainkey.example.com

The receiving mail system uses that public key to verify the signature.

A DKIM signature helps prove that:

1. the message was signed by a system controlling the signing domain, and
2. the signed portions of the message were not modified in a way that breaks the signature.

DKIM uses selectors so a domain can have multiple active keys and rotate them without replacing every key at once.

In practice, your email provider will tell you exactly which selector and DNS record to publish. Do not assume that every provider uses the same selector name.

For new deployments, a 2048-bit DKIM key is a sensible default where supported. Google currently recommends 2048-bit keys, while its minimum for mail sent to personal Gmail accounts is 1024 bits.

DMARC

DMARC is the policy layer that ties SPF and DKIM to the domain in the visible From: address.

A basic monitoring policy might look like:

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

The important tags are:

• v=DMARC1 — specifies DMARC.
• p=none — monitor failures without asking receivers to quarantine or reject them.
• rua=mailto:... — requests aggregate reports about authentication activity.

DMARC does not require both SPF and DKIM to pass. A message passes DMARC when at least one of the underlying authentication mechanisms passes and is aligned with the From: domain.

That alignment concept is crucial.

What is DMARC alignment?

Suppose a message contains:

From: invoices@example.com

The message could pass SPF using an SMTP envelope domain such as:

bounce@mail.example.com

Under relaxed alignment, those domains can be considered aligned because they share the same organizational domain.

Likewise, a DKIM signature might contain:

d=example.com

That would align with:

From: invoices@example.com

If the message instead passes DKIM with:

d=some-email-provider.com

the DKIM authentication may be valid, but it is not necessarily aligned with example.com.

That distinction explains why simply checking whether SPF or DKIM “passes” is not enough. DMARC is specifically concerned with whether the authenticated identity corresponds to the domain presented to the recipient.

Why you should configure all three

Think of the three technologies as different layers:

SPF and DKIM can work independently, but DMARC is what turns them into a domain-level anti-spoofing policy.

For example, a fraudulent attacker might send:

From: ceo@example.com

from infrastructure that is not authorized by your SPF policy and does not possess a valid DKIM key for your domain.

Without DMARC enforcement, the receiving system may still accept the message depending on its own filtering policies.

With an appropriate DMARC policy, you are explicitly telling receivers what to do with messages that fail DMARC.

Step 1: Inventory every system that sends email

Before changing DNS, make a list of every service that can send mail using your domain.

Typical examples include:

• Microsoft 365 or Google Workspace
• CRM and marketing platforms
• Help-desk software
• Website forms
• Transactional email services
• Monitoring and alerting systems
• Accounting or invoicing platforms
• Cloud applications
• SMTP relays
• Legacy applications

This is one of the most important steps in the entire process.

If you forget a legitimate sender, you can create authentication failures or accidentally disrupt legitimate email.

Step 2: Publish SPF

Create or update the SPF TXT record at the root of the domain.

A simplified example is:

v=spf1 include:provider.example -all

Your real record should contain the authorization mechanisms required by your actual senders.

For example, a company using two different email platforms might have something conceptually like:

v=spf1 include:provider-a.example include:provider-b.example -all

Do not automatically add every possible email service to your SPF record. Every additional mechanism increases complexity, and SPF has a limit of 10 DNS-triggering lookups during evaluation. Exceeding that limit can cause SPF to return PermError.

This is why large SPF records often become difficult to maintain.

~all vs. -all

You will commonly see:

~all

and:

-all

~all produces a SoftFail result for sources not otherwise authorized.

-all produces a Fail result.

The correct choice depends on your deployment and the behavior of your legitimate senders. Do not change to -all simply because it “sounds more secure” before you have identified all authorized sending systems.

Remember that SPF is only one part of the authentication chain. A strong SPF record does not replace DKIM or DMARC.

Once you’ve published or updated your SPF record, use the free SPF Checker to confirm that the record is publicly visible and identify common configuration issues such as multiple SPF records or excessive DNS lookups.

Step 3: Enable DKIM

Enable DKIM in every email platform that sends mail using your domain.

Your provider will normally give you:

• a selector name,
• the DNS hostname,
• the public key,
• and instructions for enabling signing.

For example, the DNS name may look like:

selector1._domainkey.example.com

and the value may contain a public key:

v=DKIM1; k=rsa; p=PUBLIC_KEY_HERE

Do not use the example above as a literal key. The key must be generated by your email provider.

After publishing the DNS record, enable DKIM signing in the provider’s administration interface.

Then send a real message and inspect its headers. Look for a result similar to:

dkim=pass

Do not assume that publishing a DKIM key proves that your outbound messages are actually being signed.

Once the DKIM record is published, use the free DKIM Checker to confirm that the public key can be retrieved from DNS for your domain and selector. You should still send a real test message afterward to verify that your mail provider is actually signing outgoing messages.

Step 4: Publish DMARC in monitoring mode

Start with a monitoring policy:

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

This lets you collect aggregate reports without immediately asking receivers to quarantine or reject messages that fail DMARC.

This is an important correction to a common misconception: p=none is not an invalid DMARC configuration.

Google explicitly allows p=none for its bulk-sender requirement, and Yahoo’s current sender requirements specify a valid DMARC policy with at least p=none for bulk senders.

The purpose of starting with p=none is visibility.

You want to answer questions such as:

• Which systems are sending mail for my domain?
• Which sources pass SPF?
• Which sources pass DKIM?
• Which sources fail DMARC?
• Which third-party platforms are not aligned?
• Are there unauthorized senders attempting to use my domain?

After publishing your DMARC record, use the free DMARC Checker to verify that the policy is publicly accessible and correctly configured before you begin analyzing reports.

Step 5: Analyze DMARC reports

DMARC aggregate reports can reveal both legitimate and malicious activity.

You may discover legitimate services you forgot about, such as:

newsletter.example.com
crm-provider.example
ticketing-provider.example
legacy-app.example

At this stage, fix legitimate authentication problems.

For example:

SPF: PASS
DKIM: PASS
DMARC: FAIL

often points to an alignment problem rather than a simple authentication failure.

A message might be authenticated by a third-party platform but still fail DMARC because the authenticated domain does not align with the domain in the visible From: address.

A monitoring or DMARC-analysis service can make the aggregate XML reports much easier to interpret, especially for organizations with many sending services.

Step 6: Move from monitoring to enforcement

Once legitimate email consistently passes DMARC, begin enforcing the policy.

A typical progression is:

p=none

then:

p=quarantine

and eventually:

p=reject

The exact rollout should depend on the amount and complexity of legitimate email traffic.

A mature policy might look like:

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

When you reach p=reject, you are asking receiving systems to reject messages that fail DMARC.

This is the point at which DMARC moves from monitoring toward active anti-spoofing enforcement.

Yahoo specifically advises organizations with spoofing problems to consider an enforcement policy such as p=quarantine or p=reject.

Step 7: Verify the final result from a real message

DNS checks are useful, but the best test is an actual delivered message.

Send mail through every legitimate sending platform and inspect the authentication results.

A healthy message might contain results conceptually similar to:

SPF: PASS
DKIM: PASS
DMARC: PASS

More importantly, verify that DMARC passes because SPF or DKIM is aligned with the visible From: domain.

You can inspect message headers in Gmail using “Show original” and in other mail clients through their message-header or internet-header views.

Do this for every important sending system, not just your primary mailbox provider.

Common SPF, DKIM, and DMARC problems

Multiple SPF records

Problem: More than one TXT record begins with v=spf1.

Why it matters: SPF does not combine separate policies automatically.

Fix: Maintain a single SPF record containing the authorization mechanisms required by your real senders.

SPF PermError: too many DNS lookups

Problem: The SPF evaluation exceeds the 10-DNS-lookup limit.

Fix: Remove unnecessary mechanisms, simplify nested includes, and redesign the SPF architecture where necessary. Avoid treating “SPF flattening” as a permanent magic fix; flattened records can become stale when providers change their infrastructure.

DKIM published but not signing

Problem: The DKIM key exists in DNS, but messages do not contain valid DKIM signatures.

Fix: Confirm that DKIM is enabled in the sending platform and inspect a real message header.

DKIM passes but DMARC fails

Problem: DKIM is valid, but its signing domain does not align with the visible From: domain.

Fix: Configure the email platform to sign with an aligned domain or configure a custom sending domain.

SPF passes but DMARC fails

Problem: SPF authenticates the envelope sender, but that domain does not align with the visible From: address.

Fix: Check the SMTP MAIL FROM / Return-Path domain and the From: domain.

SPF fails but DMARC passes

Problem: SPF fails, but DMARC reports pass.

Why it happens: DMARC only requires one aligned authentication mechanism to pass. If DKIM passes and its signing domain aligns with the visible From: domain, DMARC can pass even when SPF fails.

Fix: DMARC itself may be working correctly. Investigate the SPF failure separately if SPF is expected to authenticate that sending source.

DMARC passes but mail still goes to spam

DMARC is an authentication and policy mechanism. It is not a guarantee of inbox placement.

Receiving systems also consider factors such as:

• sender reputation,
• complaint rates,
• message content,
• recipient engagement,
• sending patterns,
• infrastructure reputation,
• and other anti-abuse signals.

Google’s current sender guidance, for example, includes spam-rate and infrastructure requirements in addition to authentication.

What SPF, DKIM, and DMARC do not protect against

These technologies primarily protect your domain’s identity.

They do not prevent an attacker from registering a different domain such as:

examp1e.com
example-security.com
example-billing.com

and sending mail from it.

They also do not make a malicious email harmless if it comes from a completely unrelated domain.

You still need other controls, including:

• phishing-resistant authentication,
• secure payment processes,
• user awareness,
• mailbox security,
• malicious-link and attachment filtering,
• and verification procedures for sensitive requests.

Gmail and Yahoo sender requirements

Email authentication is no longer just a best practice for high-volume senders.

Google currently requires senders to personal Gmail accounts to use SPF or DKIM, and senders of more than 5,000 messages per day to Gmail accounts have additional requirements including SPF, DKIM and DMARC, with the From: domain aligned with SPF or DKIM. Google also requires low spam rates and valid DNS/TLS configuration.

Yahoo similarly requires bulk senders to use both SPF and DKIM, publish a valid DMARC policy with at least p=none, pass DMARC, and align the From: domain with either SPF or DKIM. Yahoo also requires easy unsubscribe mechanisms for bulk marketing/subscribed mail and maintains spam-complaint thresholds.

That means SPF, DKIM and DMARC are now part of basic email infrastructure management, not just an optional security improvement.

A practical deployment checklist

Before considering your domain protected, verify all of the following:

Final thoughts

SPF, DKIM and DMARC are most effective when treated as a system rather than three independent DNS records.

SPF identifies authorized sending infrastructure. DKIM provides message-level cryptographic authentication. DMARC connects those authentication results to the identity shown to the recipient and provides a mechanism for monitoring and enforcement.

The safest deployment strategy is therefore:

Inventory senders
      ↓
Configure SPF
      ↓
Enable DKIM
      ↓
Publish DMARC with p=none
      ↓
Analyze reports
      ↓
Fix authentication and alignment problems
      ↓
Move to quarantine/reject

The goal is not simply to make an online checker report “SPF = PASS”.

The goal is to reach a state where legitimate mail authenticates reliably, unauthorized mail cannot easily impersonate your domain, and you have enough visibility to detect changes before they become a deliverability or security incident.