SPF DKIM and DMARC: The Complete Email Authentication Setup Guide

SPF, DKIM, and DMARC are the core DNS-based controls that tell receiving mail systems which services may send as your domain, whether a message was altered, and how to handle impersonation attempts. Setting them up is not just a deliverability task: it is an inventory project, a DNS project, and an ongoing monitoring process.

What SPF, DKIM, and DMARC do

Email was designed so that the visible sender in the From: header could be easy to forge. That flexibility is useful for mailing lists, forwarding, and delegated sending services, but it also enables phishing and business-email-compromise attacks.

SPF, DKIM, and DMARC solve different parts of that problem:

• SPF (Sender Policy Framework) authorizes specific sending infrastructure for a domain used in the SMTP envelope sender (MAIL FROM) or, in some cases, the HELO/EHLO identity.
• DKIM (DomainKeys Identified Mail) adds a cryptographic signature to a message. A receiver obtains the corresponding public key from DNS and verifies that signed parts of the message have not changed.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance) checks whether SPF or DKIM passed and whether the authenticated domain aligns with the domain people see in the visible From: address. It also publishes a requested disposition for failures and can request reports.

SPF is an authorization list, not a signature. DKIM is a signature, not a rule that the signer must match the visible sender. DMARC is the policy layer that ties authentication to the visible author domain. A message can pass SPF and still fail DMARC; it can pass DKIM and still fail DMARC; and it can pass DMARC when either aligned SPF or aligned DKIM passes. (datatracker.ietf.org)

Why SPF DKIM and DMARC matter for senders

The immediate benefit is domain-impersonation protection. Once a domain has a properly enforced DMARC policy, a receiver has a published instruction for messages that claim to be from that domain but fail aligned authentication. That makes direct spoofing materially harder at receivers that honor the policy.

The practical benefit for marketers, founders, and operations teams is just as important: authentication makes your sending setup legible. You can identify every platform sending invoices, password resets, support replies, product alerts, newsletters, and internal mail. That visibility prevents an unknown SaaS tool or abandoned SMTP server from becoming the reason a future DMARC rollout breaks legitimate mail.

Authentication is also an operational baseline at major inbox providers. Gmail requires all senders to personal Gmail accounts to set up SPF or DKIM, and it requires senders of more than 5,000 messages per day to Gmail accounts to use SPF, DKIM, and DMARC. Yahoo similarly requires SPF or DKIM for all senders, while its bulk-sender guidance calls for both SPF and DKIM, a valid DMARC policy, and alignment. These requirements do not mean authentication guarantees inbox placement: content, recipient engagement, complaint rates, sending behavior, IP reputation, and list quality still matter. (support.google.com)

The email identities you must understand first

Most configuration mistakes come from treating every “From” address as the same thing. They are not.

Visible From domain

This is the address recipients see in their mailbox, such as:

From: Acme Updates <news@acme.example>

For DMARC, the domain here is the Author Domain. In this example, it is acme.example.

Envelope sender or MAIL FROM domain

This is used in SMTP delivery and bounce processing. It is commonly exposed in a message as Return-Path. A marketing platform might use:

Return-Path: <bounce@mailer.acme.example>

SPF evaluates the envelope-sender domain, not necessarily the visible From: domain. To satisfy DMARC via SPF, that SPF-authenticated domain must align with the visible From domain.

DKIM signing domain

DKIM adds a DKIM-Signature header containing, among other fields, a signing domain (d=) and selector (s=):

DKIM-Signature: v=1; a=rsa-sha256; d=acme.example; s=mktg2026; ...

For DMARC to pass through DKIM, the d= signing domain must align with acme.example. A platform may sign mail with its own domain, such as d=provider.example; that can produce a valid DKIM signature, but it does not satisfy DMARC alignment for acme.example.

Relaxed versus strict alignment

DMARC alignment can be relaxed or strict:

• Under relaxed alignment, an organizational-domain relationship can align. For example, mailer.acme.example can align with acme.example.
• Under strict alignment, the domains must match exactly.

Relaxed alignment is the practical default for most organizations because it allows purpose-specific subdomains for bounces and mail streams. Use strict alignment only when you understand every sending path and intentionally require exact-domain matching. Microsoft’s DMARC documentation describes the two identities and confirms that a message passes when one or both of aligned SPF and aligned DKIM pass. (learn.microsoft.com)

Before changing DNS: build a sender inventory

Do not begin by publishing p=reject. First identify every system that sends email using your domain in either the visible From address, envelope sender, or DKIM signing domain.

Your inventory should include more than your primary mailbox provider. Check the people, teams, and systems that send external mail:

1. Google Workspace, Microsoft 365, or a self-hosted mail server.
2. Marketing platforms and newsletter tools.
3. Transactional email providers for receipts, password resets, and alerts.
4. CRM and sales-engagement platforms.
5. Help desks, customer-support platforms, and chat systems that email transcripts.
6. Billing, accounting, payroll, recruiting, and e-signature services.
7. Website forms, WordPress plugins, ecommerce systems, and application servers.
8. Monitoring, status-page, security-alert, and backup services.
9. Agencies or contractors with delegated sending access.
10. Subdomains such as news.example.com, notify.example.com, and support.example.com.

For each sender, record the following in a spreadsheet or password-protected configuration document:

A platform that uses its own shared sending domain can still deliver email, but it complicates DMARC alignment and gives you less brand control. Prefer a provider’s custom-domain authentication feature when available. That feature typically asks you to publish DKIM CNAME or TXT records and may also ask you to configure a custom bounce or return-path domain.

How to create a correct SPF record

SPF is a DNS TXT record published at the domain used by the envelope sender. It begins with v=spf1, contains mechanisms that authorize senders, and ends with an all mechanism that defines the default result.

SPF record anatomy

A simplified record might look like this:

v=spf1 ip4:198.51.100.24 include:spf.email-provider.example -all

This syntax means:

• v=spf1 — this TXT value is an SPF version 1 record.
• ip4:198.51.100.24 — authorize that IPv4 address.
• include:spf.email-provider.example — evaluate the provider’s SPF policy; if it passes, treat the include as a match.
• -all — fail every sender not matched earlier in the record.

The address and provider domain above are illustrative documentation values, not a record you should copy into production. Replace them only with the exact IP address or include: value supplied by the service you actually use.

Use one SPF record per domain

A domain must have one SPF policy record. Adding a separate SPF TXT record for every vendor is a common failure mode. Multiple SPF records can produce an SPF permanent error instead of authorizing all vendors.

If your existing record is:

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

and a second provider instructs you to add include:spf.vendor.example, you merge the mechanisms into one policy before the final all mechanism:

v=spf1 include:_spf.google.com include:spf.vendor.example ~all

Whether you use ~all (soft fail) or -all (fail) should be a deliberate operational decision. Neither setting fixes an incomplete sender inventory. A strict ending is only correct when every legitimate source is covered.

The SPF 10-DNS-lookup limit

SPF is powerful but fragile at scale. RFC 7208 limits SPF evaluation to 10 DNS-querying terms across the full evaluation chain. include, a, mx, exists, ptr, and redirect can trigger lookups; nested vendor includes count too. Exceeding the limit can yield permerror, causing SPF to fail as an authentication signal. (datatracker.ietf.org)

This means you cannot safely keep adding email vendors forever. Remove retired services, avoid unnecessary a and mx mechanisms, and test the expanded lookup tree rather than merely counting visible include: statements.

SPF setup checklist

Before publishing or changing SPF, verify that:

• The TXT record starts exactly with v=spf1.
• There is no second SPF TXT value at the same domain.
• Every include: belongs to a currently active service.
• Your mail provider’s authorized servers are included.
• Your website or application server is included only if it truly sends mail directly.
• The number of evaluated DNS lookups remains at or below 10.
• The final ~all or -all appears last.

SPF is especially vulnerable to forwarding. A forwarder sends the message from its own infrastructure, which normally is not authorized in the original sender’s SPF record. That is expected behavior, not proof that the original sender was fraudulent. DKIM is therefore often the more durable DMARC path for forwarded mail, provided the message remains intact enough for the signature to verify. (learn.microsoft.com)

How to configure DKIM signing

DKIM works with a private key held by the sending system and a public key published in DNS. The sender signs selected headers and body content. The receiver reads the d= signing domain and s= selector, retrieves the public key from DNS, and verifies the signature.

DKIM DNS record format

A DKIM public key is commonly published at:

selector._domainkey.example.com

For a selector named mktg2026 and a domain named acme.example, the DNS host is:

mktg2026._domainkey.acme.example

A generic TXT value resembles this:

v=DKIM1; k=rsa; p=BASE64_ENCODED_PUBLIC_KEY

Do not manually invent the p= value. Generate it with your mail server or copy the complete value supplied by your email provider. A missing character, accidental space inside the key, wrong host name, or incorrect selector will make verification fail.

Some services use CNAME delegation instead of asking you to publish the public key directly. In that model, you create CNAME records at the provider-specified selector hostnames, and the provider hosts the final DKIM key. Follow that vendor-specific record type and target exactly; substituting a TXT record for a required CNAME will not work.

Choose aligned signing

The key goal is not merely dkim=pass. Inspect a delivered message and confirm that the signature contains your domain or an aligned subdomain:

dkim=pass header.d=acme.example

This is DMARC-capable alignment. By contrast:

dkim=pass header.d=mailer-provider.example

may be a valid signature but does not align with From: ...@acme.example.

DKIM key size and rotation

For RSA DKIM, RFC 8301 requires verifiers to support keys from 1024 through 4096 bits and says signers must use keys of at least 1024 bits; it also updates DKIM algorithm guidance around rsa-sha256. In practice, use a 2048-bit RSA key when your sending provider and DNS tooling support it, because it provides a stronger long-term default and is widely supported. (rfc-editor.org)

Rotate selectors rather than replacing a live key in place:

1. Create a new selector and publish its DNS key or CNAME.
2. Configure the sender to sign with the new selector.
3. Send and verify test messages from every mail stream.
4. Keep the old key published long enough for mail signed shortly before the change to be verified.
5. Remove the retired selector only after your retention period and vendor documentation allow it.

Use separate selectors for different services when practical. They simplify troubleshooting and let you revoke or rotate one vendor without changing every sender.

How to publish a DMARC record

DMARC is a DNS TXT record located at _dmarc below the domain being protected.

For acme.example, the record host is:

_dmarc.acme.example

A sensible monitoring-mode starting record is:

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

The components are:

• v=DMARC1 — identifies the record as DMARC.
• p=none — requests monitoring rather than a quarantine or rejection action for failures.
• rua=mailto:dmarc-reports@acme.example — requests aggregate reports at that address.

A more explicit record that sets relaxed alignment and a separate policy for subdomains is:

v=DMARC1; p=none; rua=mailto:dmarc-reports@acme.example; aspf=r; adkim=r; sp=none

The current DMARC specification is RFC 9989, which obsoletes RFC 7489. Aggregate-reporting behavior is specified separately in RFC 9990. Aggregate reports are XML reports sent by participating receivers; they help reveal source IPs, message counts, SPF and DKIM outcomes, alignment results, and the receiver’s applied disposition. (rfc-editor.org)

DMARC policy values

DMARC has three familiar policy values:

A receiver ultimately makes its own delivery decision. DMARC publishes the domain owner’s requested handling, but it does not force identical behavior at every recipient system.

Reports are data, not a green checkmark

rua reports are valuable only if someone reads them. They are typically compressed XML files and can be difficult to interpret manually. You can use a dedicated DMARC reporting platform, an internal parser, or a mailbox and workflow that regularly classifies sources.

Review reports for:

• Sending IPs and hostnames you recognize.
• Platforms you forgot were using your visible From domain.
• SPF passes that are not aligned.
• DKIM passes from provider domains rather than your domain.
• Legitimate sources failing both mechanisms.
• Spoofed sources that should fail and will be covered by enforcement.

Treat a new sending source as a configuration change. Verify it before it starts sending campaigns or critical transactional mail.

A safe DMARC rollout from none to reject

The safest rollout sequence is gradual because DMARC enforcement can affect password resets, invoices, and support replies if you missed a sender.

Phase 1: Authenticate known senders

Publish SPF, enable aligned DKIM, and configure custom return-path or bounce domains where the vendor supports them. Publish a monitoring record:

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

Do not confuse “record exists” with “deployment is complete.” At this stage, your job is to discover sources and correct alignment.

Phase 2: Investigate failures

Classify every meaningful report source as one of these:

• Legitimate and correctly authenticated — keep monitoring.
• Legitimate but not aligned — configure custom DKIM, custom MAIL FROM, or a suitable subdomain.
• Legitimate but obsolete — disable the integration or migrate it.
• Unauthorized — no configuration change is needed; it is evidence that enforcement will provide value.
• Unclear — identify the owner before changing SPF or adding exceptions.

Avoid authorizing unknown IP addresses just because they appear in a report. SPF entries are permissions; every addition expands who may send mail using that envelope domain.

Phase 3: Move to quarantine

After legitimate sources consistently pass DMARC, change the policy:

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

Continue checking reports and support channels. This phase exposes edge cases, especially legacy systems, forwarding behavior, and third-party services that were configured with a visible From address but not custom domain authentication.

Phase 4: Move to reject

When you can account for your legitimate mail streams and failures are primarily unauthorized, publish:

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

Keep monitoring after enforcement. New tools, mergers, rebrands, application releases, and departmental purchases can introduce new senders later.

Worked example: a small business using Google Workspace and a newsletter tool

Assume northstarcoffee.example uses Google Workspace for employee email and a newsletter service. The team sends from hello@northstarcoffee.example in both systems. This is a fictional domain, but the workflow and record shapes are real.

Step 1: Confirm the mail streams

The team lists:

• Google Workspace: employee replies, invoices, and direct outreach.
• Newsletter platform: weekly campaigns from hello@northstarcoffee.example.
• Ecommerce platform: receipts from orders@northstarcoffee.example.

The first important discovery is that this is three mail streams, not one. Google Workspace configuration alone cannot authenticate the newsletter and ecommerce services.

Step 2: Publish one merged SPF record

Google’s documented SPF include is include:_spf.google.com. The newsletter and ecommerce providers each supply their own authorized include domain or IP range in their authentication instructions.

The final record must be one value, conceptually like this:

Host: @
Type: TXT
Value: v=spf1 include:_spf.google.com include:SPF_VALUE_FROM_NEWSLETTER_VENDOR include:SPF_VALUE_FROM_COMMERCE_VENDOR ~all

Replace the placeholder mechanisms with the providers’ exact values. Then use an SPF lookup checker to ensure the fully expanded policy stays within the 10-lookup evaluation limit.

Step 3: Enable DKIM for all three systems

For Google Workspace, the administrator enables DKIM signing in the Google Admin console and publishes the generated DNS record. For the newsletter and ecommerce tools, the administrator uses each provider’s custom-domain authentication flow, usually creating one or more CNAME or TXT records.

The success criterion is not simply that each platform says “verified.” Send a message from each platform to a test mailbox and inspect the headers. Each should show an aligned DKIM result, such as:

dkim=pass header.d=northstarcoffee.example

An aligned subdomain such as header.d=mail.northstarcoffee.example can also pass under relaxed alignment.

Step 4: Publish monitoring-mode DMARC

Create this record:

Host: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@northstarcoffee.example; aspf=r; adkim=r

Create and monitor the reporting mailbox, or point rua to a DMARC-reporting service you control. Do not forward reports to an outside reporting address unless its authorization requirements are understood and configured.

Step 5: Test three real messages

Send one message from Google Workspace, one newsletter test, and one ecommerce receipt to Gmail, Outlook.com, and a mailbox you control. In each received message, inspect Authentication-Results.

You want a result shaped like this:

spf=pass
 dkim=pass
 dmarc=pass header.from=northstarcoffee.example

The exact formatting differs by recipient. Gmail and Microsoft 365 expose authentication results in received message headers; Microsoft 365 documents that its Authentication-Results header can show SPF, DKIM, and DMARC outcomes. (learn.microsoft.com)

Step 6: Enforce only after report review

If aggregate reports show all three legitimate systems pass DMARC consistently, move from p=none to p=quarantine, then to p=reject. If the newsletter tool shows dkim=pass but header.d=newsletter-vendor.example, configure its custom DKIM domain before enforcement rather than accepting the misalignment.

How to verify SPF, DKIM, and DMARC actually work

DNS publication is only one half of verification. You must test both DNS resolution and a delivered message.

Check the DNS records

Use your DNS provider’s record viewer, a command-line lookup, or a reputable email-authentication checker.

On macOS or Linux, examples include:

dig TXT northstarcoffee.example +short
dig TXT mktg2026._domainkey.northstarcoffee.example +short
dig TXT _dmarc.northstarcoffee.example +short

Look for the expected record at the expected name. Remember that DNS control panels differ: some expect only _dmarc in the Host field because they append the zone name automatically, while others expect the full hostname.

Check a delivered message

Send mail from every platform, not just your main mailbox. Open the raw headers and find Authentication-Results.

A healthy example looks like:

Authentication-Results: mx.receiver.example;
       spf=pass smtp.mailfrom=bounce.northstarcoffee.example;
       dkim=pass header.d=northstarcoffee.example;
       dmarc=pass header.from=northstarcoffee.example

Interpret the results carefully:

• spf=pass alone is not enough; compare smtp.mailfrom with the visible From domain.
• dkim=pass alone is not enough; compare header.d with the visible From domain.
• dmarc=pass confirms that at least one aligned path succeeded.
• dmarc=fail means neither aligned SPF nor aligned DKIM succeeded, even if one unaligned mechanism passed.

Check reports over time

One successful test message does not prove a deployment is complete. Different streams can use different servers, subdomains, regions, or fallback paths. Review aggregate reports over a meaningful normal sending cycle that includes newsletters, receipts, support replies, and application notifications.

Common SPF DKIM and DMARC failures and fixes

“I added every vendor’s SPF record”

Cause: Multiple SPF TXT records were published, or too many nested includes pushed evaluation over 10 DNS lookups.

Fix: Merge authorized mechanisms into one record, remove retired sources, and test the expanded lookup count. Do not add a second v=spf1 record. (datatracker.ietf.org)

“DKIM passes, but DMARC fails”

Cause: The service signs with its own domain, not yours.

Fix: Enable the vendor’s custom DKIM domain feature and ensure the resulting header.d aligns with the visible From domain.

“SPF passes, but DMARC fails”

Cause: The vendor uses an unaligned shared return-path domain.

Fix: Configure a custom MAIL FROM, return-path, or bounce domain if the provider supports it. Alternatively, make aligned DKIM the passing DMARC path.

“Our DMARC reports are empty”

Cause: The record may be malformed, the report mailbox may reject messages, the receiving systems may not send reports, or DNS has not propagated according to the record’s TTL.

Fix: Validate the _dmarc TXT record, confirm the rua mailbox accepts inbound mail, and inspect delivered-message headers independently. Reports are useful but are not guaranteed from every receiver.

“Marketing messages fail after p=reject”

Cause: A marketing tool was using your visible From domain without aligned SPF or DKIM.

Fix: Temporarily use the provider’s supported custom-domain authentication process, verify delivered headers, then keep the enforcement policy once the stream passes.

“Forwarded mail fails SPF”

Cause: A forwarding server’s IP is not in the original sender’s SPF record.

Fix: This is normal. Preserve aligned DKIM where possible, and understand that indirect-mail flows can alter or break authentication signals. (learn.microsoft.com)

Tools and operating habits that keep the setup healthy

You do not need a large security team to run email authentication well, but you do need an owner and a repeatable process.

Use these habits:

• Keep the sender inventory alongside your DNS documentation.
• Require authentication review before any team connects a new email platform.
• Assign ownership of the DMARC report mailbox or reporting dashboard.
• Test production headers after vendor migrations and application releases.
• Rotate DKIM selectors on a defined schedule or when a key may be exposed.
• Remove SPF mechanisms and DKIM selectors for retired systems.
• Use dedicated subdomains for distinct traffic types when that improves operational separation, such as news.example.com for marketing and notify.example.com for product mail.

Dedicated subdomains can reduce blast radius and make reporting easier, but they are not an excuse to avoid proper alignment. Each sending subdomain needs the appropriate SPF/DKIM/DMARC design for the way it is used.

Conclusion: treat authentication as email infrastructure

SPF, DKIM, and DMARC work best as a system. SPF says which infrastructure may use an envelope domain. DKIM proves that a signing domain authorized a message and that signed content survived transit. DMARC checks whether either authenticated identity aligns with the address recipients see, publishes a policy for failures, and supplies reporting data to find gaps.

The reliable path is straightforward: inventory every sender, publish one controlled SPF record, enable aligned DKIM for each service, start DMARC in monitoring mode, validate actual message headers, analyze reports, and only then progress to p=quarantine and p=reject. Do that work carefully and your domain becomes both harder to impersonate and easier to operate.

FAQ

What is the difference between SPF, DKIM, and DMARC?

SPF authorizes sending servers for the envelope-sender domain. DKIM cryptographically signs mail using a domain’s private key and DNS-published public key. DMARC requires aligned SPF or DKIM to match the visible From domain and publishes a failure-handling policy.

Do I need SPF, DKIM, and DMARC, or is one enough?

Use all three. SPF alone does not protect the visible From domain through alignment, and it can fail during forwarding. DKIM provides a resilient authenticated path when it remains valid. DMARC supplies alignment, policy, and reporting. Gmail and Yahoo bulk-sender guidance calls for both SPF and DKIM plus DMARC. (support.google.com)

Can I have more than one SPF record?

No. Publish one SPF policy record per domain. Combine each active provider’s approved mechanisms into that one value, then test that the fully expanded SPF evaluation stays within the 10-DNS-lookup limit.

Does p=none protect my domain from spoofing?

p=none is primarily a monitoring policy. It helps you collect visibility into authentication outcomes, but it does not ask receivers to quarantine or reject DMARC failures. Protection increases when you move to p=quarantine or p=reject after validating legitimate senders.

How do I know DMARC is passing?

Inspect a real delivered message’s headers. Look for dmarc=pass in Authentication-Results, then confirm that either SPF passed with an aligned envelope domain or DKIM passed with an aligned header.d signing domain. Also review aggregate reports to verify every production mail stream over time.