SPF, DKIM and DMARC: A Practical Email Authentication Audit

Start with the systems that send your email. An email authentication audit should identify every sender, record what SPF, DKIM and DMARC show on real messages, and assign someone to fix each gap. Use the worksheet below before changing DNS or tightening a DMARC policy. A green check for your everyday mailbox does not tell you whether invoices, booking reminders or website notifications are configured correctly.

This guide is for an owner or operations lead whose business uses several tools to email customers. The deliverable is a sender inventory with evidence and next actions. If the immediate problem is a missing WordPress notification, start with our guide to WordPress form emails going to spam, then use this audit to review the wider business.

Understand the three checks before interpreting a result

Matching domains align in these examples. Related subdomains may also align, depending on the policy’s mode. Record the actual domains and receiver results instead of relying on a provider’s “verified” badge. Microsoft explains these identity and alignment checks.

Copy this sender-audit worksheet

Duplicate the following record for each sending system. Begin with staff mailboxes, the website, CRM, scheduling, invoicing, newsletters, review requests and help-desk tools. Separate two workflows from the same platform if they use different sending identities. Ask the person who operates each workflow to help complete it.

Keep credentials out of the worksheet. Record an approved account or evidence location, not passwords, API keys or customer message bodies. “Unknown” is a useful finding: assign an owner and a next step rather than filling a gap with an assumption.

Test messages from the actual workflow

Ask each system to send a controlled test to a mailbox your team can inspect. Test the invoice from the invoicing platform, the booking reminder from the scheduler, and the website’s own notification. Sending a message manually from your everyday inbox exercises a different path.

1. Record the context. Note the system, trigger, time, intended recipient and From address. Use synthetic test details instead of a real customer’s information.
2. Open the received message’s full headers. In Gmail on a computer, open the message, use the More menu beside Reply, and choose Show original. Google documents how to view full headers in Gmail and other clients.
3. Capture results and domains together. Record SPF, DKIM and DMARC results supplied by the receiving service, along with the envelope-sender and signing domains. A bare “SPF pass” leaves out the identity that passed.
4. Investigate missing mail at the sender. If nothing arrives, inspect the platform’s delivery or bounce log. Record the error and the responsible provider; absence from an inbox does not establish a particular SPF or DMARC failure.

For business-critical flows, our suggested audit scope is more than one receiving provider and any forwarding route your team actually relies on. Keep successful and unsuccessful tests. Later changes to the sending platform or domain should trigger a retest.

A worked example: the invoice tool passes SPF but fails DMARC

Illustrative scenario: a service company uses example.com for its business domain and an invoice provider using example.net. These are example domains, not a customer case or settings to copy. The office manager owns the invoice workflow; the DNS administrator owns domain changes.

The decision: keep the invoice workflow in the repair queue until its identity is configured and retested. Adding another SPF record at the business’s root would not change a provider-controlled envelope domain. First ask the provider how its custom sender and DKIM options work. Some providers use an aligned subdomain, and an individual message can pass DMARC through one aligned method; record the actual supported setup rather than expecting every platform to look identical.

A completed worksheet action: “Invoicing / customer invoices / office manager plus operations backup. Both methods passed for the provider domain; DMARC failed. Office manager obtains current custom-domain instructions; DNS administrator reviews the required changes. Retest an invoice and reminder after setup, save the receiver results, and close the item only when the agreed checks pass.”

Review SPF without breaking another sender

Give your DNS administrator the complete inventory before asking for changes. For each domain being checked, confirm that there is only one applicable SPF policy. Multiple independent SPF records at the same name cause an error; unrelated TXT records may coexist. SPF also limits DNS-querying terms during evaluation, including nested includes, so counting the visible platform names is not enough. These constraints come from the SPF record rules and its DNS lookup limits.

• Collect the current instructions for each verified sender and its actual envelope domain.
• Ask the administrator to check the complete evaluated SPF policy and lookup budget.
• Confirm DKIM is enabled in the sending platform as well as configured in DNS.
• Record the previous configuration and the person responsible for recovery.
• Retest every affected business workflow after a change.

Do not add every tool to the root SPF record by default, delete an unfamiliar entry before identifying its owner, or paste a stranger’s DNS values. The right record depends on where and how the system sends.

Choose the next DMARC action from the evidence

• Unknown senders or missing tests: finish the inventory and investigate. Our recommendation is to leave stronger enforcement pending while legitimate sources remain unexplained.
• A known sender fails: assign a concrete correction and retest it. Do not assume every authentication failure is an attacker or blindly authorize an unknown source.
• Known senders work and report coverage is representative: review stricter handling with the domain administrator. Include low-frequency invoices, seasonal campaigns and indirect mail paths in that decision.

A useful observation period covers your actual business cycles; there is no universal number of quiet days that proves readiness. Configure aligned SPF and DKIM where supported, and resolve provider limitations before tightening policy. The current DMARC standard specifically says domains using p=reject must not rely solely on SPF for a DMARC pass. Forwarding and mailing-list behavior also deserve review.

Finish with an owner and a retest plan

The audit is useful when every system has a named owner, recorded evidence and a decision. Keep an exception list with the affected workflow, business consequence, action and next review date. Add one operating rule: a new email platform does not become business-critical until someone has completed its sender record and tested the real messages.

An owner can usually assemble the inventory; domain and platform administrators should handle changes that affect multiple senders. If the website and follow-up tools have different owners, bring the worksheet to a website maintenance or marketing automation conversation. Talk with QC Webworks about the website and customer-workflow pieces, with your email provider involved where necessary.

Frequently asked questions

Does a small business need SPF, DKIM and DMARC?

Google recommends all three for sending domains. Its requirements for personal Gmail recipients distinguish all senders, who need SPF or DKIM, from bulk senders, who need SPF, DKIM and DMARC alongside other requirements. Check the current sender guidelines for the traffic you send; a low-volume business can still benefit from documenting every sender.

Why can SPF and DKIM pass while DMARC fails?

The successful checks may authenticate a domain that does not align with the visible From domain. Compare the domain attached to each result, as in the invoice example. A valid signature from a provider is not automatically a valid connection to your business identity.

Should each email platform get a separate SPF record?

Not at the same DNS name. A domain must not return multiple applicable SPF records. Different sending domains or subdomains can have their own policies; the provider’s actual envelope-sender setup determines what belongs where. Have the DNS administrator review the complete configuration.

Does a DMARC pass guarantee inbox placement or stop phishing?

No. It validates the use of a domain for that message, not whether its content is safe or wanted. It does not eliminate display-name impersonation or messages from compromised authorized accounts. Keep account protection and payment-verification practices separate from this authentication audit.

How often should we repeat the audit?

Use changes as the trigger: a new CRM, invoice system, newsletter platform, sending subdomain, provider migration or DNS change. Review reports between changes and revisit low-frequency workflows before their next campaign or billing cycle. Assign this responsibility to a person rather than relying on an annual reminder alone.

Sources and technical references

Technical guidance checked September 8, 2026. Recheck provider instructions before configuration changes.

• RFC 7208: SPF — policy records and lookup limits.
• RFC 9989: DMARC — authentication, alignment and policy.
• Microsoft: Configure DMARC — sender identity and alignment.
• Google: Sender guidelines — requirements for personal Gmail.
• Google: View full headers — finding message evidence.