SPF DKIM DMARC Setup for Small Business: 2026 Guide

Your staff email may come from Microsoft 365 or Google Workspace. Your invoices may come from accounting software. Your website may send contact-form confirmations. Your CRM or newsletter tool may send from the same business domain.

That is why a safe SPF DKIM DMARC setup starts with a sender list, not with copying three DNS records from a tutorial.

This guide shows you how to set up email authentication for a small business, test every real sending system, and avoid common mistakes that can break legitimate mail. It also explains an important 2026 change: the current DMARC standard is now RFC 9989, not the older RFC 7489.

This is not just theory. In early October 2026, attackers were actively exploiting a critical FortiMail flaw (CVE-2026-104286) with no login required. Email systems are live targets, which is why getting authentication right matters.

SPF DKIM DMARC Setup: The Safe Order

Use this order:

1. List every service that sends email using your domain.
2. Save your current DNS records before changing anything.
3. Build one valid SPF policy for each sending domain.
4. Enable DKIM in each service that supports it.
5. Send real test messages and confirm SPF/DKIM results.
6. Understand DMARC alignment before publishing DMARC.
7. Start with monitoring where that fits your active business domain and risk.
8. Verify each real message flow, not just staff email.
9. Review DMARC reports before changing enforcement.

Do not assume Microsoft 365 or Google Workspace is your only sender. A forgotten invoicing tool, website form, CRM, scanner, or marketing platform can be the reason legitimate mail fails after a DNS change.

SPF vs. DKIM vs. DMARC in Plain English

A message can pass SPF and DKIM and still fail DMARC if the authenticated domains do not align with the domain the recipient sees in the From address.

Before You Touch DNS: List Every System That Sends Email

Start with an inventory.

Common business senders include:

• Microsoft 365 or Google Workspace
• accounting and invoicing software
• CRM
• newsletter or marketing platforms
• help-desk software
• payroll systems
• website contact forms
• WordPress notifications
• booking systems
• e-commerce platforms
• scanners and multifunction printers
• monitoring and alert services
• customer portals
• transactional email providers

Do not add a service to SPF only because a scanner says it is missing. First confirm that the service actually sends mail using your domain.

Sender inventory worksheet

Do not store passwords, API keys, DKIM private keys, recovery codes, or other secrets in this worksheet.

Step 1: Save Your Current DNS Configuration

Before changing DNS, save what is already there.

Record:

• current SPF TXT record;
• current DKIM selectors and records;
• current DMARC TXT record;
• TTL values;
• DNS provider;
• current email provider;
• date and time of the snapshot.

This gives you a reference point if something stops working.

DNS change log

Do not delete an existing record just because a setup guide shows a different value. First work out what the current record is doing.

Step 2: Set Up SPF Without Creating Multiple SPF Records

SPF is checked against the domain used in the SMTP envelope sender, often called the MAIL FROM or Return-Path domain.

If you use SPF for a domain, publish one SPF policy, not one SPF record for every service.

Multiple SPF records for the same domain cause an SPF permanent error (permerror) under the SPF standard.

Google Workspace example

If Google Workspace is the only system sending mail for the domain, Google currently documents:

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

Do not copy that record unchanged if other services also send mail for the same domain.

Microsoft 365 example

For a standard commercial Microsoft 365 domain where Microsoft 365 is the only sender, Microsoft currently documents:

v=spf1 include:spf.protection.outlook.com -all

Microsoft uses different values for some government and regional cloud environments, so use the record shown in the official documentation for your tenant.

If several services send mail

The answer is usually not to publish a second SPF record.

You need to build one policy that represents the authorized sources for that specific envelope-sender domain. Some services use their own bounce or Return-Path domain, so they may not need to appear in the SPF record for your main domain at all.

This is why sender inventory comes first.

The SPF 10-DNS-lookup limit

RFC 7208 limits SPF evaluation to 10 DNS-query-causing terms.

These include:

• include
• a
• mx
• ptr
• exists
• redirect

The count can include lookups triggered through nested include or redirect processing. If the limit is exceeded during evaluation, SPF returns permerror.

That does not mean every recipient will handle the message in exactly the same way, but it means SPF is no longer producing a normal pass/fail result for that evaluation.

Do not keep adding SaaS include values without checking the total lookup path.

Should you flatten SPF?

Do not treat SPF flattening as an automatic fix.

Manually replacing provider includes with IP addresses can create maintenance problems because the provider may change its sending infrastructure later.

If your SPF design is approaching the lookup limit, first ask:

• Does every listed service still send mail?
• Can a third-party service use its own aligned subdomain?
• Can DKIM alignment handle that service instead?
• Can unused includes be removed?
• Does the provider offer a supported design that reduces lookups?

Fix the architecture before adding more complexity.

Step 3: Enable DKIM — Then Prove It Is Actually Signing

A DKIM record in DNS does not prove your mail is being signed correctly.

There are two parts:

1. Publish the public key, or provider CNAME, in DNS.
2. Enable DKIM signing in the sending service.

Then send a real message and check the headers.

Look for:

• DKIM=pass
• the DKIM signing domain (d=)
• the selector (s=)

The d= domain matters for DMARC alignment.

Microsoft 365

Microsoft 365 automatically DKIM-signs mail sent from its initial onmicrosoft.com domain. For a custom domain, Microsoft says you must configure DKIM signing for that custom domain if you want the custom domain to be used for the DKIM signature.

Current Microsoft 365 DKIM setup uses two CNAME selectors. Microsoft changed the CNAME target format for newer custom domains in 2025, so do not build the target values yourself.

Get the exact values from:

Microsoft Defender portal → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM

Microsoft also exposes the selector values through Exchange Online PowerShell.

After the CNAME records are detected, enable signing and send a test message. Confirm the custom domain appears in the DKIM d= value.

Official guide:
https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure

Google Workspace

Google Workspace uses a different process:

1. Open Admin console → Apps → Google Workspace → Gmail → Authenticate email.
2. Generate a DKIM key if one has not already been provisioned.
3. Publish the TXT record Google gives you.
4. Return to the Admin console.
5. Start authentication.
6. Send a real test message and verify the DKIM result.

Google notes that after Gmail is first turned on for an organization, you may need to wait 24–72 hours before a DKIM key can be generated in the Admin console. That is not the same thing as saying every DKIM DNS change takes 24–72 hours.

For DNS changes themselves, wait according to your DNS TTL and Google's verification message if the key is not found yet.

Official guide:
https://support.google.com/a/answer/174124

Step 4: Understand DMARC Alignment Before Publishing DMARC

DMARC does not ask only:

“Did SPF pass?”
or
“Did DKIM pass?”

It asks whether at least one passing method is also aligned with the domain in the visible From address.

Simple example

A customer sees:

From: [email protected]

But the third-party invoicing service authenticates:

SPF domain: vendor-mail.example.net
DKIM d=: vendor-mail.example.net

SPF can pass. DKIM can pass.

DMARC can still fail because neither authenticated domain aligns with example.com.

What alignment means

With DMARC's default relaxed alignment, the authenticated domain and visible From domain can be different subdomains as long as they share the same Organizational Domain.

For example:

From: [email protected]
DKIM d=mail.example.com

can align in relaxed mode.

With strict alignment, the domains must match exactly.

For most small businesses, you do not need to change alignment modes just to complete a normal setup. You do need to understand why a third-party provider passing SPF or DKIM on its own unrelated domain may still fail DMARC for your business domain.

How third-party services usually solve alignment

Look for settings such as:

• domain authentication;
• custom DKIM;
• custom signing domain;
• custom Return-Path;
• custom bounce domain.

Do not assume adding the provider to SPF will always fix DMARC. If the provider uses its own Return-Path domain, SPF may still not align with your visible From domain. Custom DKIM is often the cleaner path.

Step 5: Publish DMARC Monitoring Carefully

For an active business domain where you are still discovering senders, a monitoring policy can be a practical starting point.

An illustrative record is:

v=DMARC1; p=none; rua=mailto:[email protected]

Do not paste this unchanged.

Replace the reporting address with a real mailbox or DMARC reporting service that you control.

The rua tag asks participating receivers to send aggregate DMARC reports. RFC 9990 is the current aggregate-reporting specification. These reports are machine-readable XML, so many small businesses use a reporting service or parser rather than reading raw XML files by hand.

If the reporting address is on a different domain, external-reporting authorization may be required. Follow your reporting provider's current setup instructions.

Is p=none always the right starting policy?

No universal policy fits every domain.

For an established, general-purpose business domain with several sending systems and incomplete visibility, p=none is often a low-risk way to collect evidence before enforcement.

A parked domain that should never send mail is a different case. A tightly controlled dedicated sending domain can also have a different path.

The right policy depends on the purpose of the domain and its legitimate mail flows.

Once monitoring is working, use BizRiskGuide's guide:
DMARC p=none: What Should Your Small Business Do Next?

That article covers report review and the decision about what policy should come next.

A 2026 DMARC Change You Should Know About

In May 2026, the IETF published RFC 9989, the current DMARC specification. It obsoletes RFC 7489 and RFC 9091.

Two changes matter when you read older setup guides.

The pct tag was removed

Older guides often show records such as:

pct=10
pct=25
pct=50

RFC 9989 removed the pct tag because real-world implementation was inconsistent.

The new standard adds a t testing tag, but it does not provide percentage-based rollout. t=y asks receivers not to apply the stated policy fully and, for a failing message, effectively requests treatment one level below the published policy.

For a small-business setup, you do not need to add t=y just because it exists. Receiver support and provider guidance may vary, so use it only when you understand why you need it.

Do not assume every domain should end at p=reject

RFC 9989 explicitly says that domains used for general-purpose email should not automatically deploy p=reject, because indirect mail flows such as mailing lists can create interoperability problems.

This is an important change in how the standard explains deployment.

Do not follow a rigid:

p=none → p=quarantine → p=reject

ladder without looking at your real mail.

Provider documentation may still show older examples

At the time of this 2026 review, Google's Workspace DMARC rollout page still shows pct= examples even though RFC 9989 has removed that tag from the current standard.

That is a documentation transition issue. Do not add pct= merely because an older or not-yet-updated provider article still shows it.

Current RFC:
https://www.rfc-editor.org/rfc/rfc9989.html

Current aggregate reporting RFC:
https://www.rfc-editor.org/rfc/rfc9990.html

Microsoft 365 Setup Path

Use this as a checklist, not as a substitute for Microsoft's live DNS values.

1. Confirm the custom domain is verified in Microsoft 365.
2. Review the existing SPF record.
3. If Microsoft 365 sends mail for that domain, make sure Microsoft 365 is represented in the one SPF policy.
4. Open Microsoft Defender's Email authentication settings.
5. Select the custom domain under DKIM.
6. Copy the exact two CNAME values Microsoft gives you.
7. Publish them in DNS.
8. Enable DKIM for the custom domain after Microsoft detects the records.
9. Send a real message and verify DKIM.
10. Publish DMARC only after you understand the real senders and alignment.

Microsoft's current email-authentication overview recommends SPF, DKIM, and DMARC working together for custom domains.

Official references:

• SPF: https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure
• DKIM: https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure
• DMARC: https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure

Google Workspace Setup Path

1. List all services that send mail for the domain.
2. Review the existing SPF policy.
3. If Google Workspace sends mail, make sure Google's authorized source is represented in the one SPF policy.
4. Open Admin console → Apps → Google Workspace → Gmail → Authenticate email.
5. Generate the DKIM key when available.
6. Publish the TXT record Google gives you.
7. Start authentication in the Admin console.
8. Send a real message and confirm DKIM passes.
9. Publish DMARC monitoring when appropriate.
10. Test every other sender separately.

Google's SPF guide explicitly tells administrators to identify all senders first, including web servers, contact forms, outbound gateways, and third-party providers.

Official references:

• SPF: https://support.google.com/a/answer/33786
• DKIM: https://support.google.com/a/answer/174124
• DMARC: https://support.google.com/a/answer/2466580

What About CRM, Invoicing, Marketing, and SaaS Email?

Third-party services are where small-business email authentication often gets complicated.

For each provider:

1. Open its domain authentication or sender authentication settings.
2. Use the DNS values generated for your account.
3. Enable custom DKIM if supported.
4. Configure a custom Return-Path or bounce domain if the provider supports it and you need SPF alignment.
5. Send a real message.
6. Inspect the final authentication results.
7. Record the result in your worksheet.

Do not copy Mailchimp, Brevo, Salesforce, HubSpot, or another vendor's record from an unrelated blog post. Use the current values shown inside your own account or the provider's current official documentation.

What About WordPress and Website Contact Forms?

A website form can be one of the senders you forget.

First find out how the site actually sends mail:

• local web-server/PHP mail;
• authenticated SMTP;
• Microsoft 365;
• Google Workspace;
• a transactional mail provider;
• a WordPress mail plugin connected to one of those services.

For reliable authentication, use a supported mail route that can authenticate your domain.

Where the form lets you choose headers, a safer design is usually:

From: [email protected]
Reply-To: [email protected]

rather than pretending the message was sent directly from the visitor's external address.

Then test both:

• the internal notification your staff receives; and
• the confirmation message the customer receives, if your form sends one.

Do not assume a form works correctly just because the message arrived in your own inbox once.

Step 6: Test Every Real Sending System

One successful Microsoft 365 or Google Workspace message does not prove your invoices, newsletters, website email, and CRM notifications are authenticated.

Test each message type.

Verification matrix

For every important sender:

1. Send a real message to an inbox you control.
2. Open the message's authentication details or full headers.
3. Record SPF.
4. Record DKIM.
5. Record DMARC.
6. Record the SPF domain / Return-Path.
7. Record the DKIM d= domain.
8. Confirm alignment with the visible From domain.
9. Repeat after major provider or DNS changes.

Testing the actual mail flow is more useful than checking only whether a DNS record exists.

Gmail, Yahoo, and Microsoft Sender Requirements in 2026

Email authentication is also a deliverability requirement for major mailbox providers.

Gmail

Google's current sender requirements say:

• All senders to personal Gmail accounts: SPF or DKIM.
• Senders sending more than 5,000 messages per day to Gmail accounts: SPF and DKIM and DMARC, plus other bulk-sender requirements.

Google recommends setting up SPF, DKIM, and DMARC even when you are below the bulk-sender threshold. Since late 2025, Gmail has been ramping up enforcement — non-compliant bulk mail now faces temporary or permanent rejection, not just the spam folder.

Official guidance:
https://support.google.com/mail/answer/81126

Yahoo

Yahoo's current Sender Hub says:

• All senders: SPF or DKIM at minimum.
• Bulk senders: both SPF and DKIM, plus a valid DMARC policy with at least p=none, and DMARC must pass.

Yahoo also has separate requirements for DNS, spam rates, and unsubscribe handling.

Official guidance:
https://senders.yahooinc.com/best-practices/

Microsoft

Since May 5, 2025, Microsoft rejects mail from domains sending more than 5,000 messages a day to Outlook.com, Hotmail, and Live.com addresses unless SPF and DKIM both pass and a DMARC record exists with at least p=none, aligned to one of them.

The original plan was to send failing mail to junk. Microsoft changed course before launch: failing messages are rejected outright with "550 5.7.515 Access denied." For a small business this usually matters when a newsletter or CRM crosses the volume line. One big campaign can put you in the stricter tier.

Official guidance:
https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure

These provider requirements do not mean every small business is a bulk sender. They do show why email authentication is now part of normal outbound-mail hygiene.

Step 7: Review DMARC Reports Before Changing Policy

Once aggregate reports are arriving, use them to answer:

• Which services are sending mail using your domain?
• Which ones pass SPF?
• Which ones pass DKIM?
• Which ones pass DMARC?
• Which legitimate senders fail alignment?
• Are any unknown sources appearing?
• Are there old services you no longer use?

Do not "fix" every unknown source by authorizing it.

First decide whether it is legitimate.

This is where the setup-from-scratch guide ends. The next job is report interpretation and policy choice:

DMARC p=none: What Should Your Small Business Do Next?

How to Know Your Setup Is Working

Use this checklist:

• [ ] Every real sending system is listed.
• [ ] Current DNS settings were saved before changes.
• [ ] Each SPF-using domain has one SPF policy.
• [ ] SPF stays within the RFC lookup limit.
• [ ] Microsoft/Google/vendor senders are represented correctly where needed.
• [ ] DKIM is enabled, not just published.
• [ ] Real messages show the expected DKIM d= domain.
• [ ] DMARC is published at the correct _dmarc name.
• [ ] Aggregate reports are arriving at a monitored destination.
• [ ] Staff email has been tested.
• [ ] Invoice/accounting mail has been tested.
• [ ] Website mail has been tested.
• [ ] CRM/help-desk/marketing mail has been tested.
• [ ] DMARC alignment has been checked for each important flow.
• [ ] Unknown or failing senders are documented for review.

A green DNS checker is useful, but it is not the same as proving every important mail flow works.

You can also run BizRiskGuide's free Business Email Security Checker against your domain for a quick outside-in view of SPF, DKIM, and DMARC.

What SPF, DKIM, and DMARC Will Not Protect You From

Email authentication helps reduce direct spoofing of your domain.

It does not stop every email attack.

It does not automatically prevent:

• a real mailbox being compromised;
• a lookalike domain;
• display-name impersonation;
• phishing from another properly authenticated domain;
• a fraudulent message sent from an authorized compromised account;
• malware;
• malicious OAuth/app access;
• every form of Business Email Compromise.

For those risks, see:

• Business Email Compromise: What Small Businesses Need to Know
• How to Secure Your Business Email From Account Takeover
• How to Recognize a Phishing Email: 10 Signs for Small Businesses

For broader security basics, use the Small Business Cybersecurity Guide 2026.

Common SPF, DKIM, and DMARC Setup Mistakes

Avoid these:

• publishing two SPF records for the same domain;
• copying another company's SPF record;
• authorizing a vendor you do not actually use;
• forgetting website, invoicing, CRM, or newsletter senders;
• exceeding the SPF lookup limit;
• manually flattening SPF without a maintenance plan;
• publishing DKIM DNS records but never enabling signing;
• seeing SPF=pass or DKIM=pass and assuming DMARC must pass;
• ignoring the authenticated domains used for alignment;
• using a third-party sender without custom-domain authentication when it is available;
• publishing DMARC enforcement before testing real mail flows;
• using pct= as if it were still part of the current RFC;
• assuming every domain should automatically end at p=reject;
• adding rua= but never confirming reports arrive;
• changing DNS without saving the old values;
• testing only staff email.

Free Small-Business Email Authentication Worksheet

Sender inventory and test results

DNS change log

Unresolved-sender log

Keep this worksheet free of passwords, API secrets, DKIM private keys, recovery codes, and other credentials.

Frequently Asked Questions

Do I need SPF, DKIM, and DMARC if I only use Microsoft 365?

Microsoft recommends using SPF, DKIM, and DMARC together for custom domains. First confirm that Microsoft 365 really is your only sender. Your website, invoicing platform, CRM, or newsletter service may also send as the same domain.

Do I need all three if I use Google Workspace?

Google requires at least SPF or DKIM for all senders to Gmail and stronger authentication for bulk senders. Google recommends setting up SPF, DKIM, and DMARC for your sending domains. You should also account for third-party senders.

Can I have more than one SPF record?

No. If SPF is used for a domain, publish one SPF policy for that domain. Multiple SPF records cause a permanent SPF error.

What happens if SPF exceeds 10 DNS-query-causing terms?

SPF evaluation returns permerror. The exact delivery treatment depends on the receiver and other authentication results, but you should treat it as a configuration problem and fix the SPF design.

Does a DKIM DNS record mean DKIM is working?

No. The public record can exist while the sending service is not using it. Send a real message and check for DKIM=pass and the expected d= domain.

Should a small business start DMARC at p=none?

For an established business domain where you are still discovering senders, p=none is often a practical monitoring starting point. It is not a universal rule for every domain.

Should I move DMARC to p=reject?

Not automatically. RFC 9989 specifically cautions against automatic p=reject deployment for general-purpose email domains because of indirect mail-flow issues. Review your real senders and reports before choosing a policy.

Is the DMARC pct tag still current in 2026?

No. RFC 9989 removed pct. Some provider documentation still shows older pct examples, so check the publication date and the current RFC before copying a record.

What is the new DMARC t tag?

RFC 9989 adds a t testing tag. t=y requests test-mode handling instead of fully applying a quarantine or reject policy. It is not a percentage rollout tool. Small businesses do not need it for a basic p=none monitoring setup.

How long do DNS changes take?

It depends on the DNS provider, TTL, and receiving resolver cache. A change may appear quickly but older cached answers can remain until their TTL expires. Check the public DNS result instead of relying only on the "Saved" message in your DNS dashboard.

Can SPF, DKIM, and DMARC stop Business Email Compromise?

No. They reduce some forms of domain spoofing. They cannot stop fraud sent from a genuinely compromised mailbox or a lookalike domain that has its own valid authentication.

Do website contact forms need email authentication?

If the form sends mail using your domain, include that mail flow in your inventory and authenticate it through the service that actually sends the message. Test both staff notifications and customer-facing confirmations.

Final Recommendation

A good SPF DKIM DMARC setup is not three DNS records copied from a tutorial.

Start by finding every real sender. Save your current DNS. Build SPF carefully. Enable DKIM and prove that messages are signed. Then use DMARC to check whether the authenticated domains align with the address your customers actually see.

Most important, test the mail your business really sends: staff messages, invoices, website notifications, CRM alerts, and newsletters.

Once monitoring is working, use the DMARC reports to decide what should change next instead of guessing.

Sources and References

• RFC 7208 — Sender Policy Framework (SPF)
• RFC 6376 — DomainKeys Identified Mail (DKIM)
• RFC 9989 — Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 9990 — DMARC Aggregate Reporting
• Microsoft — Set up SPF for custom cloud domains
• Microsoft — Configure DKIM for custom domains
• Microsoft — Configure DMARC
• Google Workspace — Set up SPF
• Google Workspace — Set up DKIM
• Google Workspace — Set up DMARC
• Google — Email sender guidelines
• Yahoo Sender Hub — Sender Best Practices

Editorial fact-check note: Reviewed against current IETF, Microsoft, Google, Yahoo, and live BizRiskGuide pages on October 5, 2026. Additions this round: FortiMail CVE-2026-104286 timeliness note, Microsoft May 2025 sender-requirement enforcement (550 5.7.515 rejection), Gmail late-2025 enforcement ramp-up, Business Email Security Checker tool link.