SPF DKIM DMARC setup is the essential DNS work that proves which services may send mail for your domain and tells receiving inboxes what to do with impersonated messages. Done carefully, it protects your brand from spoofing while helping legitimate campaigns, invoices, support replies, and transactional mail reach the inbox.

Email authentication is not a one-record task. SPF authorizes sending infrastructure, DKIM cryptographically signs messages, and DMARC checks whether either result aligns with the visible From address recipients see. The safe sequence is: inventory senders, publish or repair SPF, enable DKIM everywhere, publish a monitoring DMARC record, analyze reports, then move DMARC to enforcement.

What SPF, DKIM, and DMARC each do

These standards solve related but different problems. A passing result in one does not automatically mean your visible brand identity is protected.

SPF: which servers may send mail

Sender Policy Framework (SPF) is a DNS TXT record that lists the IP addresses and third-party services authorized to send mail using an envelope sender domain. The envelope sender is also called the Return-Path or MAIL FROM domain. It is used for bounces and is often not the same as the From address displayed in a mail client.

A simplified SPF record looks like this:

example.com. TXT "v=spf1 ip4:198.51.100.24 include:_spf.google.com -all"

It says that the listed IPv4 address and Google-authorized infrastructure may send mail using example.com as the envelope domain. -all is a hard fail for everything else.

SPF is useful but fragile when mail is forwarded. A forwarding server can change the connecting IP address without changing the envelope sender, causing SPF evaluation to fail at the final destination. SPF also has a strict limit of 10 DNS-query-causing mechanisms and modifiers during evaluation, including include, a, mx, redirect, and exists.

DKIM: prove the message was signed

DomainKeys Identified Mail (DKIM) adds a digital signature to the message headers. The sending system signs selected content with a private key. The receiving system retrieves the matching public key from DNS and verifies that the signed content was not changed after signing.

A DKIM-Signature header includes a signing domain (d=) and selector (s=), for example:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2026; ...

The receiver looks up this DNS name:

mail2026._domainkey.example.com

DKIM often survives ordinary forwarding because the message itself is still intact. It can fail when a mailing list, security gateway, or forwarding service rewrites the body or headers that were signed.

DMARC: connect authentication to the visible From domain

Domain-based Message Authentication, Reporting, and Conformance (DMARC) evaluates SPF and DKIM results and, crucially, whether a passing identifier aligns with the domain in the visible From header.

For a message from billing@example.com, DMARC can pass if either:

SPF passes and the SPF envelope domain aligns with example.com; or
DKIM passes and the DKIM d= domain aligns with example.com.

That “either” is important. DMARC does not require both SPF and DKIM to pass, although deploying both is strongly recommended. DMARC also lets a domain owner request none, quarantine, or reject treatment for messages that fail DMARC, and it can send aggregate authentication reports.

Before your SPF DKIM DMARC setup: inventory every sender

The most common reason a new DMARC policy blocks real mail is an incomplete sender inventory. Your main mailbox provider is only one source of mail. List every platform that can send a message with your domain in the From address or uses your domain for its return path.

Include at least the following:

Google Workspace, Microsoft 365, Zoho Mail, or your hosted mailbox provider.
Marketing platforms such as HubSpot, Mailchimp, Klaviyo, Customer.io, Braze, or Salesforce Marketing Cloud.
Transactional providers such as Amazon SES, Postmark, SendGrid, Mailgun, Resend, or Brevo.
Help desk and CRM products, including Zendesk, Intercom, Freshdesk, Salesforce, and ticketing integrations.
Website forms, ecommerce platforms, WordPress plugins, scanners, printers, ERP systems, and application servers.
Agencies, affiliates, franchise locations, and separate business units sending branded mail.
Subdomains, such as news.example.com, support.example.com, or mail.example.com.

For each sender, capture the service owner, From domain, envelope/return-path domain, DKIM signing domain, DKIM selector, required DNS records, and whether the service is still active. Ask vendors whether they support custom DKIM signing for your domain. A vendor that signs only with its own domain can be functional for delivery yet fail DMARC alignment for your brand.

Do not guess from old DNS records alone. Check campaign tools, SMTP credentials, website code, mailbox rules, and recent message headers. A good operational test is to send a message from every identified platform to a test Gmail or Outlook mailbox and inspect its authentication results.

Set up SPF correctly without breaking existing mail

SPF is published as a TXT record at the envelope sender domain. Most organizations publish their primary SPF record at the root domain, but a provider may ask you to use a dedicated subdomain such as bounce.example.com or mail.example.com.

Start by finding the existing SPF record

Query DNS before adding anything:

dig TXT example.com +short

Look for a TXT value beginning exactly with v=spf1. Your domain can have many TXT records for verification tokens, Google site verification, or other purposes. It must not have multiple independent SPF policy records. SPF receivers can return a PermError when more than one v=spf1 record exists.

If SPF already exists, merge required mechanisms into that one record. Do not publish a second SPF TXT record because a vendor’s setup screen tells you to “add this SPF record.” Their value may need to be incorporated into your existing policy instead.

Build a single record

Suppose Example Co uses Google Workspace, a web application at 198.51.100.24, and one sending service whose documented include is spf.transactionalvendor.net. Its record could be:

Host/Name: @
Type: TXT
Value: v=spf1 include:_spf.google.com ip4:198.51.100.24 include:spf.transactionalvendor.net -all

In a DNS interface, @ commonly means the zone apex, example.com. Some interfaces want an empty host field or the full domain instead. Check the provider’s DNS UI conventions; do not literally add example.com.example.com by entering a full name into a field that appends the zone automatically.

Mechanisms are evaluated left to right. -all says all unlisted sources should fail. ~all is a soft fail and may be used temporarily while auditing a legacy domain, but it is not a substitute for discovering senders. Avoid +all; it effectively authorizes every host on the internet and defeats SPF.

Stay under the SPF lookup limit

The 10-lookup limit is a major hidden failure. One include can expand into several nested includes, and adding many SaaS products can exceed the limit even if your visible record looks short. SPF then produces a PermError, which can undermine authentication at receivers.

Use an SPF lookup checker after every change. If the count is too high, practical fixes include:

remove inactive providers and duplicate includes;
ask vendors whether a dedicated custom bounce subdomain can isolate their SPF policy;
use a provider-supported SPF flattening or managed DNS approach, while understanding it must be maintained as vendor IP ranges change;
move systems to DKIM-aligned custom domains where possible, reducing reliance on root-domain SPF alignment.

Do not use a or mx merely because they seem convenient. They authorize the IP addresses resolved by those records, which may not be your outbound mail servers. Use explicit IP mechanisms only for stable infrastructure you control.

Enable DKIM for every service that sends as you

DKIM configuration is vendor-specific because each sender generates keys and chooses selectors differently. The principle is consistent: generate or request a key in the sending platform, publish its public key in DNS, verify it in the platform, and turn signing on.

DKIM record anatomy

A direct RSA DKIM TXT record commonly resembles this:

Host/Name: mail2026._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

The p= value is a public key, not a password. Never publish a private key. A long key may be displayed by DNS tools as several quoted strings; DNS combines adjacent quoted TXT strings. Follow your DNS provider’s input format rather than inserting extra quotation marks or line breaks yourself.

Use a current, strong key length supported by your sender and DNS provider. Many major providers support 2048-bit RSA DKIM keys, which are generally preferable to 1024-bit keys. Some services use CNAME records instead of a raw TXT key. That is normal: the CNAME points your selector to vendor-managed DKIM material and lets the vendor rotate keys.

Configure Google Workspace and Microsoft 365 carefully

For Google Workspace, DKIM is generated and enabled in the Admin console for the relevant domain. Google provides the DNS value and selector; publish it first, wait for DNS visibility, then start authentication in the Admin console. The exact interface and selector are controlled by Google Workspace, so copy its generated record rather than reusing a generic example.

For Microsoft 365 with a custom domain, DKIM commonly uses two Microsoft-provided CNAME records, typically for selectors such as selector1._domainkey and selector2._domainkey. Microsoft provides tenant-specific destinations in the Defender or Microsoft 365 administration experience. Publish exactly the targets Microsoft gives your tenant, then enable DKIM for the domain.

A mailbox provider’s DKIM configuration does not sign mail sent through your marketing or help desk provider. Each independent sending platform needs its own DKIM setup.

Use domains that align

A passing DKIM signature with d=vendor-mail.example.net will not relaxed-align with From: sales@example.com. Configure the vendor’s authenticated sending domain or branded domain feature so it signs with example.com or an aligned subdomain such as mail.example.com.

Relaxed alignment treats a subdomain as aligned when it shares the organizational domain. Strict alignment requires an exact match. Therefore, a DKIM signature using d=mail.example.com can align with From: example.com under relaxed alignment, but not under strict alignment.

Publish a DMARC monitoring record first

DMARC is a TXT record at _dmarc.yourdomain. Start with reporting and no requested enforcement:

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100

This says: evaluate DMARC, request no special treatment for failures, send aggregate reports to the specified address, use relaxed DKIM and SPF alignment, and apply the stated policy to all messages. p=none does not stop spoofing by itself; it gives you visibility needed to avoid disrupting legitimate traffic.

Use a dedicated mailbox or, preferably, a DMARC reporting service. Aggregate reports arrive as compressed XML files and are difficult to interpret manually at scale. Tools such as dmarcian, Valimail, EasyDMARC, Red Sift OnDMARC, Proofpoint, and Cloudflare’s DMARC tooling can parse reports, group sources, and surface alignment failures. Product capabilities and pricing differ, so assess retention, alerting, user access, and support for your organization.

Important DMARC tags

The minimum valid DMARC record is v=DMARC1 and p=. Useful operational tags include:

rua=mailto:... for aggregate report destinations.
ruf=mailto:... for failure/forensic reports. Support is inconsistent, and privacy controls may limit what receivers send.
adkim=r or s for relaxed or strict DKIM alignment.
aspf=r or s for relaxed or strict SPF alignment.
pct=25 through pct=100 to request policy application to a percentage of failing messages.
sp=quarantine or sp=reject to set policy for subdomains when they do not publish their own DMARC record.

If rua points to another domain, DMARC requires external reporting authorization: the report-receiver domain publishes a TXT record at example.com._report._dmarc.receiver-domain.com authorizing reports for example.com. Many commercial reporting providers document the required authorization record.

Read DMARC reports and fix alignment failures

Give reports enough time to expose normal business cycles before enforcing policy. The exact duration depends on your sending patterns: a company that sends monthly invoices, quarterly newsletters, or seasonal campaigns must observe those sources before declaring its inventory complete.

Focus on identifiers, not only pass percentages. For each meaningful source IP or sending service, ask whether it is legitimate, whether SPF passes, whether DKIM passes, and whether at least one passing result aligns with the From domain.

Common report outcomes

SPF pass, DMARC fail: The envelope sender may be a vendor domain that does not align with the visible From domain. Configure a custom return-path or rely on an aligned DKIM signature.

DKIM pass, DMARC fail: The sender may sign with its own domain instead of yours. Authenticate your domain in that vendor and enable custom DKIM.

SPF fail, DKIM pass, DMARC pass: Usually acceptable. This is common with forwarding, provided DKIM remains intact and aligned.

Both fail: The mail might be spoofed, an unconfigured legitimate tool, or a system that is altering mail after it is signed. Investigate before changing the policy.

Unknown IP with your From domain: Treat it as potential spoofing, but verify internally first. Look at reverse DNS, provider identifiers, message samples where available, and whether an employee deployed an unapproved tool.

Do not automatically add every source IP appearing in a report to SPF. SPF authorizes the use of your envelope domain; blindly adding IPs expands the attack surface and can approve a malicious source. Add a sender only after establishing business ownership and configuring it for aligned authentication.

Move DMARC from monitoring to quarantine and reject

Once all legitimate streams either pass aligned SPF or aligned DKIM, increase enforcement deliberately. A common progression is:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

Then increase pct as monitoring confirms expected results. Finally, request full rejection:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100

quarantine asks receivers to treat failing mail suspiciously, often by placing it in spam. reject asks them to reject it during delivery. Receiving systems retain discretion: DMARC expresses the domain owner’s requested disposition, not an absolute guarantee of identical handling by every mailbox provider.

Keep monitoring after reaching p=reject. New SaaS tools, acquisitions, agency changes, new subdomains, and abandoned DNS records can create failures later. Make authentication review part of vendor procurement and campaign-launch checklists.

A worked SPF DKIM DMARC setup example

Assume example.com uses Google Workspace for employee mail, Postmark for receipts, and HubSpot for marketing. It also has a legacy application server at 198.51.100.24 that sends internal alerts.

Step 1: map the intended identities

The team decides:

Employee mail uses From: person@example.com.
Receipts use From: receipts@example.com and a branded return-path subdomain supplied by Postmark.
Marketing uses From: updates@example.com and HubSpot custom DKIM.
Alert mail uses From: alerts@example.com and sends directly from the application server.

Step 2: publish the consolidated SPF policy

After checking vendor documentation, the administrator merges the Google include, the application IP, and only the includes specifically required for root-domain envelope sending. If Postmark and HubSpot use dedicated branded return-path subdomains, their SPF records can live at those subdomains rather than bloating the root record.

example.com TXT "v=spf1 include:_spf.google.com ip4:198.51.100.24 -all"

The team then publishes vendor-provided SPF records at the dedicated bounce subdomains, if the vendor requires them. The precise hostnames and values must come from each provider’s domain-authentication screen.

Step 3: enable three DKIM paths

Google Workspace receives the selector and key generated in Google Admin. Postmark and HubSpot each provide their own DNS records, often CNAME records, for custom DKIM. The administrator publishes all records, verifies each domain inside the relevant platform, and sends a test from each source.

Step 4: publish DMARC monitoring

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100"

Step 5: validate mail headers

A Gmail test message should show results similar to:

SPF: PASS with IP 198.51.100.24
DKIM: PASS with domain example.com
DMARC: PASS

The exact wording varies by recipient. In Gmail, open the message menu and choose “Show original.” In other mail clients, find “view source,” “view message details,” or “view headers.” Look for Authentication-Results, Return-Path, From, and DKIM-Signature headers.

Step 6: enforce only after reports confirm the picture

If aggregate reports show the Google, HubSpot, Postmark, and application sources passing with alignment—and unknown sources are confirmed as spoofing—the team changes to p=quarantine, monitors again, then uses p=reject. If a legitimate source fails, fix its domain authentication rather than weakening the entire policy.

Test DNS and message authentication after every change

DNS publication and vendor verification are separate checks. A record can exist in your DNS zone but be malformed, placed at the wrong hostname, unavailable due to propagation, or not yet activated in the sending platform.

Use command-line checks where practical:

dig TXT example.com +short
dig TXT _dmarc.example.com +short
dig TXT mail2026._domainkey.example.com +short

For CNAME-based DKIM, query CNAME instead:

dig CNAME selector1._domainkey.example.com +short

Then send real messages to at least two major mailbox ecosystems and inspect headers. Online validators can help identify syntax errors and SPF lookup counts, but do not paste sensitive full headers, private data, or unredacted customer messages into an untrusted public service.

A setup has worked when DNS queries return the intended records, each approved sender has a passing aligned SPF or DKIM result, DMARC returns pass for normal mail, aggregate reports identify no unexplained legitimate traffic, and messages sent with your From domain from unauthorized sources fail DMARC. The final test is not simply “DKIM passed”; it is “DMARC passed with the From domain our recipients see.”

Common SPF, DKIM, and DMARC mistakes

The most damaging errors are usually configuration shortcuts rather than obscure DNS problems.

Publishing multiple SPF records

Only one SPF policy record should exist for a domain. Merge mechanisms into one v=spf1 string. Multiple values beginning with v=spf1 can cause a permanent SPF error.

Copying records with the domain duplicated

DNS dashboards vary. If a dashboard automatically appends example.com, entering _dmarc.example.com may create _dmarc.example.com.example.com. Query the final DNS name externally to confirm what was actually published.

Leaving a vendor on its default DKIM domain

A vendor signature can be valid yet not aligned. Set up the vendor’s custom domain authentication, including DKIM, before relying on it for DMARC.

Turning on reject immediately

A strict policy before an inventory can block receipts, password resets, and support mail. Monitoring is not procrastination; it is the evidence-gathering phase that makes enforcement safe.

Forgetting subdomains

An apex-domain DMARC record can affect subdomains that lack their own record. Review every active sending subdomain and use explicit sp= policy only when you understand the impact.

Assuming forwarding means DMARC is broken

Forwarding commonly breaks SPF. Proper aligned DKIM often preserves DMARC success. Mailing lists and gateways that modify content can break DKIM, and ARC can communicate prior authentication results, but ARC is not a replacement for publishing SPF, DKIM, and DMARC.

Deliverability and sender requirements

Authentication is a foundation, not a guarantee of inbox placement. Mailbox providers also consider user complaints, list quality, content, engagement, IP and domain reputation, TLS, reverse DNS, and unsubscribe behavior for bulk mail.

Google’s published sender guidelines require all senders to Gmail personal accounts to use either SPF or DKIM. For bulk senders—defined by Google as sending close to 5,000 or more messages per day to Gmail personal accounts—Google requires SPF, DKIM, and DMARC, with DMARC alignment. Google also specifies a DMARC policy of at least p=none for bulk senders, requires one-click unsubscribe for marketing and subscribed messages, and states that spam rates should remain below 0.3%.

Yahoo also publishes sender requirements for bulk mail, including authentication and easy unsubscribe expectations. Requirements can change and depend on traffic type and receiving network, so check the current official documentation for the mailbox providers that matter to your audience.

For marketers, the practical implication is clear: do not treat authentication as a deliverability repair after a campaign fails. Authenticate a sending domain before importing a list or launching automation. Use separate subdomains for clearly separate streams when that helps operations—such as news.example.com for marketing and notify.example.com for product mail—but maintain aligned DKIM and DMARC for each.

Operating model: keep authentication healthy

Assign ownership. DNS may sit with IT, campaign sends with marketing, transactional mail with engineering, and customer communication with support. Without a shared inventory and approval process, new sending tools can quietly bypass your controls.

A lightweight recurring review should include:

checking DMARC report dashboards for new sources and alignment failures;
reviewing SPF lookup count after adding or removing vendors;
confirming DKIM key rotation and vendor domain-verification status;
removing DNS authorizations for retired tools;
testing a sample from each critical sending stream;
documenting who can change DNS and who approves a new From domain.

Preserve DKIM records during key rotation until the sending service has fully stopped using the old selector. Deleting a selector too early makes messages signed with the old key fail verification. Likewise, do not remove an SPF include until you have confirmed the associated system no longer sends with that envelope domain.

Conclusion: enforce identity, not just records

A successful SPF DKIM DMARC setup gives receivers a consistent answer to a simple question: is this message legitimately associated with the domain in the From field? SPF identifies permitted envelope senders, DKIM protects a signed identity, and DMARC makes those results meaningful to your visible brand.

Start with a complete sender inventory, publish one controlled SPF policy, configure aligned DKIM for every approved platform, and use DMARC reports before enforcing quarantine and reject. The result is stronger anti-spoofing protection, clearer control over third-party senders, and a durable base for email deliverability.

FAQ

What is the correct order for SPF, DKIM, and DMARC setup?

Inventory senders first, then create or consolidate SPF, enable DKIM on every sending platform, publish DMARC with p=none, analyze aggregate reports, and only then move to quarantine and reject.

Can DMARC pass if SPF fails?

Yes. DMARC passes when either SPF or DKIM passes and aligns with the visible From domain. This is why aligned DKIM is especially valuable for forwarded mail.

Do I need more than one SPF record for multiple email tools?

No. Publish one SPF record per domain and merge authorized mechanisms into it. Multiple records beginning with v=spf1 can generate an SPF PermError.

What DMARC record should a new domain use?

A practical starting record is v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; adkim=r; aspf=r; pct=100. Replace the report address with one you control and monitor.

How do I know whether DKIM is aligned?

Inspect the message headers. A passing dkim=pass result must use a d= signing domain that matches, or relaxed-aligns with, the domain in the visible From address. A vendor’s own signing domain generally does not align with your brand domain.

SPF, DKIM, and DMARC Setup: A Practical DNS Guide That Works