SPF, DKIM & DMARC Setup: Verify Email Authentication

Affiliate disclosure: We may earn commissions through PlusVibe or Instantly referrals. We only link to these two supported platforms commercially; review our methodology.

Illustrative DNS records (fictional domain, not copy-paste values)

Assume an example client owns agency-example.test (a reserved fictional testing domain). The exact SMTP hosts, SPF include mechanisms and DKIM selector must come from that client's real mail provider.

These records are instructional placeholders and will not authenticate real mail. Use your provider's actual published setup, including the correct key and selector. A DMARC report address must be provisioned, and external report destinations may require explicit authorization by the destination domain.

Pass versus alignment: the difference that causes false confidence

Suppose the visible From: is hello@agency-example.test. An SPF pass for a return-path under an unrelated platform domain does not necessarily satisfy DMARC. Similarly, a DKIM signature with d=another-example.test can be cryptographically valid but fail DMARC alignment with the visible From domain. DMARC needs at least one aligned authentication path to pass.

Read the Google sender guidelines for current provider requirements and provider-specific records. Do not replace a valid SPF policy with a second SPF record: merge legitimate authorized senders into one policy according to the provider's instructions.

Troubleshooting runbook

1. SPF permerror: look for multiple SPF records or excessive DNS lookups. Consolidate carefully; avoid weakening the policy simply to make a check green.
2. DKIM fail: inspect signing enablement, selector, TXT propagation and whether an intermediary modified signed content. Regenerate keys according to provider documentation.
3. DMARC fail with SPF/DKIM pass: examine domain alignment, not just pass results. Compare the RFC5322 From domain with the actual authentication identifiers.
4. Legitimate mail fails after changing p=quarantine/reject: revert according to a documented change plan, identify missing legitimate senders from aggregate reports, and retest before enforcing again.
5. Delivery still poor despite passing authentication: investigate content, recipient appropriateness, complaint levels and list quality in the deliverability diagnostic guide.

For Google Workspace, Microsoft 365 or any outsourced provider, publish only the records issued for that account. DNS is an identity prerequisite, not a guarantee of inbox placement.

Understand the three controls before editing DNS

SPF lets a domain identify permitted sending servers. DKIM signs outgoing messages so a receiving system can validate integrity and a signing domain. DMARC tells receivers how to evaluate alignment between the visible From: domain and SPF/DKIM identity, and where to send some reports. These mechanisms help authenticate mail; they do not authorize an unwanted campaign or guarantee inbox placement.

Google's sender guidelines specify minimum authentication requirements that vary with sending behavior. Follow the current mailbox-host instructions for record values. Do not copy a sample SPF include or DKIM key blindly: those depend on the provider and your exact account.

The implementation sequence

1. Inventory senders. Record every service sending mail as your domain: workspace host, transactional provider, CRM, support desk and any approved marketing service.
2. SPF. Inspect existing TXT records at the domain or specific sending subdomain. Avoid multiple unrelated v=spf1 records at the same owner name; reconcile mechanisms into a valid record using provider documentation.
3. DKIM. Generate selectors and public keys inside each sending provider, publish the requested DNS records and enable signing.
4. DMARC. Publish an organizational-domain or relevant subdomain policy with an appropriate reporting address you control. Begin with an observation policy where suitable and assess authentication before enforcing stricter treatment.
5. Test. Send a legitimate message from every real sender to a mailbox you control; inspect Authentication-Results for SPF, DKIM and DMARC alignment outcomes.
6. Record and monitor. Keep screenshots or exported DNS/headers, date, owner and changes; review DMARC reports with appropriate privacy controls.

How alignment differs from “pass”

DMARC requires a pass from SPF or DKIM in a way that aligns with the visible From domain under the relevant alignment rules. A message can technically pass SPF for one domain while failing DMARC alignment with a different From domain. Forwarding can also change SPF behavior, making DKIM important.

Agencies should change DNS with a rollback plan

Before editing a client domain, obtain authorization and export existing records. Work from provider-generated values, then validate each actual service. Do not weaken a client-wide DMARC policy to fix one misconfigured vendor without a documented assessment. Keep a record of who can update DNS; offboard obsolete senders.

The domain warmup walkthrough begins after these checks. If mail still fails despite authentication, follow Cold Email Deliverability. To choose mailbox and DNS vendors responsibly, use the infrastructure providers guide.