Email Deliverability Audit: SPF, DKIM and DMARC
An email deliverability audit checks whether your legitimate messages authenticate correctly, reach the intended mailbox and give recipients a clear way to stop marketing email. Begin with a sender inventory, inspect real message headers, verify SPF, DKIM and DMARC alignment, then test subscriptions, suppression and reporting. A green DNS check is evidence of configuration, not a promise that every campaign will reach the inbox.
Start an email deliverability audit with a sender inventory
List every system that sends on behalf of your business: staff mailboxes, newsletter software, CRM sequences, ecommerce receipts, website forms, helpdesk replies and appointment reminders. Record the visible From address, sending provider, owner, audience and purpose. Include forgotten integrations rather than assuming the newsletter platform is your only sender.
For Pakistani agencies serving international clients, ownership is often split between the domain registrar, hosting company, developer and marketing team. Assign one person to approve DNS changes and another to verify delivery. Keep access scoped to the client account. Export current records before editing, and never replace a working mail configuration with a generic example copied from a tutorial.
| Message stream | Evidence to capture | Acceptance check |
|---|---|---|
| Newsletter | Consent source, sender domain, headers | Authentication and opt-out work |
| Order receipt | Actual test-order email | Customer receives the right receipt |
| Website inquiry | Form submission and notification | Business receives the inquiry securely |
| CRM follow-up | Automation path and suppression state | Unsubscribed contacts stay excluded |
Email deliverability audit: check SPF authorization
SPF checks whether a sending server is authorized for the envelope-sender domain, which may differ from the address a reader sees. The SPF specification defines this authorization process. During the audit, inspect the actual Return-Path and authentication result instead of searching only for your brand domain.
Publish one SPF policy per hostname, not separate competing policies for each provider. Review authorized services and remove obsolete entries only after confirming they no longer send. SPF evaluation has a limit of ten DNS-query-causing terms; nested provider includes can consume that budget. A record that exists but produces a permanent evaluation error is not a successful implementation.
Use the DNS Checker to inspect public TXT records, then compare them with the provider’s exact instructions. DNS inspection alone cannot prove that every message stream uses the expected envelope domain. Send a real test from each application and retain the headers with sensitive addresses redacted.
Email deliverability audit: verify DKIM signing
DKIM attaches a cryptographic signature to selected message headers and content. The public verification key is published under a selector in DNS; the signing service keeps the private key. Read the d= signing domain and s= selector in a received message, then verify that the corresponding record resolves.
The DKIM specification explains how a domain takes responsibility through its signature. Do not assume a provider’s successful generic signature represents your brand domain. Check whether custom-domain signing is enabled for the specific sending account and stream. An existing key in DNS is ineffective if the application never signs with it.
When rotating keys, follow the provider’s overlap procedure so messages already in transit remain verifiable. Do not delete old selectors immediately or expose private keys in tickets, screenshots or repositories. Add the current selectors and operational owner to your audit record so future teams can distinguish active keys from abandoned integrations.
Check DMARC alignment, not just three green labels
DMARC connects authentication to the visible From domain. A message needs an aligned successful SPF or DKIM result to pass DMARC. This distinction explains a common failure: SPF passes for a provider domain, but neither that domain nor the DKIM signing domain aligns with the brand shown to the recipient.
Review the DMARC record at the appropriate _dmarc hostname, its policy and reporting destination. The current DMARC specification, RFC 9989, supersedes RFC 7489. Use current provider guidance and standards when implementing a new policy rather than treating an older checklist as definitive.
If legitimate senders are not yet mapped, begin with visibility and fix alignment before enforcing a stricter policy. Move deliberately toward quarantine or rejection after testing all genuine streams. A monitoring policy is not equivalent to blocking impersonation. Conversely, switching straight to rejection without an inventory can disrupt receipts, support replies or operational alerts.
Authentication proves something about a message’s origin. It does not prove the recipient requested the campaign, or that the content deserves inbox placement.
Test consent and unsubscribe as real customer journeys
Subscribe through the public form using a controlled address. Note what frequency and content were promised, whether confirmation is clear and which lists receive the contact. Then unsubscribe from an actual campaign and confirm that the address remains suppressed when the next automation runs. A confirmation screen without a database change is a broken opt-out.
Google’s sender guidelines for personal Gmail accounts distinguish general senders from bulk senders. General senders need SPF or DKIM; bulk senders need SPF, DKIM and DMARC, with alignment and one-click unsubscribe for marketing and subscribed messages. Check the live guidelines for the applicable volume criteria and other requirements before sending.
A footer link is useful but is not the same as header-based one-click unsubscribe. RFC 8058 describes the one-click mechanism using List-Unsubscribe and List-Unsubscribe-Post headers. Ask your email platform to implement and test it; do not invent a header URL that fails to update subscription state.
Separate delivery errors from weak campaign engagement
Read the exact SMTP response and the provider’s event log. Distinguish a permanent rejection from a temporary deferral, a suppression decision and an accepted message. “Delivered” commonly means the receiving server accepted the message; it does not establish which inbox folder displayed it. Preserve timestamps and error codes so support can investigate the same incident.
Build a small diagnostic matrix by provider, message stream and time window. If receipts fail across every mailbox provider, inspect the application first. If only one provider defers marketing traffic after a sudden volume increase, investigate reputation and sending patterns. Avoid repeatedly retrying permanent failures or uploading the same invalid contacts through another list.
Evaluate campaign usefulness separately through relevant clicks, replies and downstream business outcomes. Open-rate changes alone are not a reliable diagnosis because client privacy and image-loading behavior affect measurement. Use a consistent UTM Builder convention for campaign links and confirm that landing-page tracking works before comparing conversions.
Prioritize repairs without damaging working email
- Immediate: stop unauthorized sends, broken opt-outs and campaigns to contacts without valid permission.
- High: repair authentication or alignment failures affecting legitimate messages.
- Next: resolve application errors, stale suppression rules and unclear subscription expectations.
- Ongoing: review list quality, stream ownership and delivery patterns after provider changes.
Make one controlled change at a time. Save the previous record, expected behavior, rollback step and test result. After DNS updates, check authoritative and public resolver results as appropriate, then send fresh messages. Reusing an old email cannot demonstrate that a new signature or policy is now functioning.
Turn the audit into a repeatable release checklist
Retest whenever you add a CRM, replace a newsletter provider, migrate hosting or change a sending domain. Include marketing, developer and operations sign-off. A launch is complete only when a subscribed test contact receives the intended message, can leave the list and does not re-enter through a second automation.
Keep the evidence lightweight: sender inventory, redacted headers, DNS findings, opt-out results and prioritized fixes. Connect the work with your wider full-stack marketing strategy and CRM nurturing workflow, but do not disguise deliverability problems with more aggressive messaging. Relevant permission-based communication is the long-term foundation.
Email deliverability audit FAQs
Does passing SPF, DKIM and DMARC guarantee inbox placement?
No. Authentication is an important foundation, but inbox placement also depends on sender reputation, recipient expectations, complaints, message quality and mailbox-provider filtering.
What should I check first in an email deliverability audit?
Inventory every system sending for the domain, then inspect real messages from each stream. Compare the visible From domain, envelope sender, DKIM signing domain and authentication results.
Should I change DMARC directly to reject?
Not without verifying legitimate senders and alignment first. Review reporting, repair failures and test operational messages before tightening the policy.
Is a footer unsubscribe link the same as one-click unsubscribe?
No. A visible footer link and the header-based one-click mechanism are separate checks. Test both and confirm that the contact remains suppressed from future marketing sends.