Small-Business Email Authentication Checklist: SPF, DKIM, and DMARC

Your business may send mail through more systems than you expect: employee inboxes, website forms, estimates, invoices, newsletters, scheduling tools, support software, payment platforms, and automated alerts. Each system can affect whether recipients trust or reject messages using your domain.

SPF, DKIM, and DMARC are DNS-based email authentication controls. Configured together, they help receiving systems determine whether a message is authorized and whether the authenticated domain aligns with the address a person sees. This checklist helps a small business organize the work without cutting off legitimate senders.

What matters most

Do not start by copying a strict DMARC record from a generic tutorial. Start by finding every legitimate sender. A policy that rejects unauthenticated mail is useful only after the systems your company relies on can authenticate correctly.

• SPF publishes which sending infrastructure may send for a domain. SPF evaluation has technical limits, including a limit on DNS-querying mechanisms, so repeatedly appending vendor fragments can create an invalid or fragile record.
• DKIM adds a cryptographic signature that a receiver can verify using a public key published in DNS. Each sending provider normally supplies its own selector and setup instructions.
• DMARC checks whether a message passes SPF or DKIM in alignment with the visible From domain. It also publishes a handling policy and can request aggregate reports.

Passing SPF alone does not necessarily mean DMARC passes. For example, a vendor can authenticate its own return-path domain while showing your domain in the From address. DKIM can provide the aligned path if the vendor signs with your domain, or the vendor may support aligned SPF. Confirm the provider's documented configuration instead of guessing.

How to build an email authentication plan

1. Inventory domains and every source of outbound mail

Create a row for the main domain and each subdomain used in email. Then list every system that sends or forwards messages.

Sender	Questions to answer
Employee email	Which provider hosts mail? Are aliases, groups, scanners, or shared mailboxes used?
Website forms	Does the site send directly, use an API provider, or pass through the mailbox provider? What appears in From and Reply-To?
Sales and marketing	Which CRM, newsletter, review, proposal, or outreach tools send as the business?
Operations	Which scheduling, invoicing, payroll, ticketing, monitoring, or payment tools send mail?
Infrastructure	Which hosting, domain, backup, security, or status systems send alerts using the domain?
Forwarding	Are messages forwarded through personal accounts, groups, or help desks that may affect authentication?

For each sender, record the owner, purpose, visible From domain, return-path domain, DKIM signing domain, setup documentation, renewal date, and a real test recipient. Remove obsolete systems from the plan before adding more DNS entries.

2. Protect DNS changes and capture the baseline

Identify who controls the registrar and authoritative DNS. Confirm that the business can recover both accounts and that multifactor authentication is enabled. Export or record the current DNS zone before editing it.

Use DNS lookups and message headers from real test emails to capture the current SPF, DKIM, and DMARC results. Do not rely only on a vendor dashboard saying “verified.” A receiver's Authentication-Results header shows how that message was evaluated at delivery.

Plan changes during a period when the responsible people can monitor important mail. DNS caching means old and new answers can coexist for a time, so avoid stacking several uncertain changes at once.

3. Consolidate and validate SPF

A domain should publish one SPF policy, not several separate TXT records beginning with v=spf1. Combine authorized sources into one intentional record using the instructions from the mailbox and sending providers.

Before publishing:

• remove services that no longer send mail;
• count mechanisms that cause DNS lookups and stay within the SPF specification's limits;
• decide whether subdomains send mail and configure them deliberately;
• avoid broad authorization of infrastructure you do not control;
• choose the ending qualifier only after understanding its operational effect;
• recheck the record after vendors change their sending instructions.

SPF authenticates the envelope sender used during mail transport, not automatically the address visible in the From field. That distinction matters when evaluating DMARC alignment.

4. Enable DKIM for each legitimate provider

Follow each provider's current instructions to generate or assign the DKIM key and publish the required DNS record. The record name usually includes a selector supplied by the provider. Do not reuse a private key between unrelated services.

Send a real message through each workflow and inspect the delivered headers. Confirm dkim=pass, identify the signing domain, and check whether it aligns with the visible From domain used by the business. Test normal employee mail and automated paths separately; a contact form and a human mailbox may use different sending infrastructure.

Keep an ownership record for selectors and remove obsolete keys after a migration is complete. Rotate keys according to provider capabilities and your security plan.

5. Start DMARC with reporting and a named owner

Publish DMARC at _dmarc.yourdomain using a record based on the official specification and your providers' guidance. Many businesses begin with a monitoring policy while they collect aggregate reports and correct legitimate failures.

The reporting mailbox can receive large machine-readable files. Use an address or DMARC-reporting service prepared to process them, and consider the privacy and vendor-review implications before sending reports to a third party.

Review reports for:

• recognized systems passing aligned SPF or DKIM;
• known systems authenticating with a vendor domain but not aligning;
• forgotten tools that still send legitimate mail;
• unauthorized or unexplained sources using the domain;
• forwarding or mailing-list behavior that changes the authentication path;
• traffic from subdomains that need their own plan.

Assign one person to own the review and a second person who can cover absences. A reporting-only record that nobody reads is not a finished control.

6. Tighten the policy in measured steps

After legitimate senders consistently authenticate and align, consider moving toward quarantine and then reject. The schedule should reflect mail volume, business risk, report quality, and the ability to respond to failures. Use policy percentage options only with a clear testing purpose, and confirm how your receiving partners handle them.

For each change, record the old record, new record, approver, date, expected outcome, monitoring window, rollback plan, and result. Keep a test checklist for employee mail, website leads, invoices, proposals, newsletters, password resets, support messages, and any other business-critical workflow.

Google's current sender guidelines require authentication for mail sent to personal Gmail accounts, with additional requirements for higher-volume senders. Other mailbox providers have their own policies. Authentication improves identity assurance, but it does not guarantee inbox placement; content, reputation, complaints, volume patterns, and recipient behavior also matter.

What this checklist cannot guarantee

SPF, DKIM, and DMARC cannot guarantee that a message reaches the inbox, that every impersonation attempt stops, or that a compromised authorized account sends only legitimate mail. They also do not encrypt message content.

DMARC reports can reveal sending sources, but an unfamiliar source is not automatically malicious and a familiar source is not automatically configured correctly. Investigate before blocking. Email forwarding and mailing lists can create legitimate edge cases, which is one reason DKIM and aligned identities matter.

DNS and mail changes can interrupt important communication. If you do not control all senders or cannot interpret the reports, use a qualified email administrator rather than jumping directly to a reject policy.

Put the checklist into practice

Complete the sender inventory first, then correct one provider at a time. Test from the actual application to an external mailbox and save the relevant authentication results. When the inventory is clean, publish DMARC reporting, monitor it for a representative business cycle, and document every remaining failure.

Review the inventory quarterly and whenever you add a marketing, billing, form, support, or automation vendor. Make removing a sender part of vendor offboarding so old authorizations and DKIM keys do not remain indefinitely.

Mendola.Tech can help map website and business-email senders, coordinate DNS changes, validate delivered messages, and turn DMARC reporting into a controlled rollout plan.

Official references

• Email sender guidelines — Google Gmail Help; accessed 2026-08-13. Lists Gmail's current authentication and sender requirements.
• Set up SPF — Google Workspace Admin Help; accessed 2026-08-13. Explains SPF purpose, record structure, and setup considerations.
• Set up DKIM — Google Workspace Admin Help; accessed 2026-08-13. Describes DKIM signing and DNS setup for Google Workspace.
• Set up DMARC — Google Workspace Admin Help; accessed 2026-08-13. Covers DMARC records, reports, alignment, and rollout.
• Domain-based Message Authentication, Reporting, and Conformance (DMARC) — Cybersecurity and Infrastructure Security Agency; accessed 2026-08-13. Provides an official overview of SPF, DKIM, DMARC, and policy deployment.