SPF / DKIM / DMARC Setup

The three DNS records that let a receiving provider tell your mail from a forgery, published for one sending domain and proved by test sends rather than by eye. This is implementation work: we inventory everything that legitimately sends as you — the mail platform, the CRM, the invoicing tool, the server that emails alerts at 3am — fit them all into one SPF record that stays inside the ten-lookup limit, publish DKIM keys, and set a DMARC policy you can live with.

What you get

  • An inventory, built with you, of every system that sends as your domain
  • One SPF record covering all of them, inside the ten-lookup limit DNS imposes
  • DKIM signing enabled, keys published, and a documented rotation
  • A DMARC record starting at p=none with reporting on, and a written plan for moving to quarantine and then reject
  • Test sends to the major providers, with the authentication headers read back to show each one passing

What this does not cover

  • A second domain, or a subdomain that sends independently. This is one sending domain; another one is another setup.
  • Reading the reports month after month afterward, which is DMARC Report Monitoring — the enforcement plan we hand you only works if somebody watches the reports while you follow it
  • Investigating mail that authenticates and still lands in spam. That is reputation, content and list behavior rather than records, and the Email Deliverability Audit is the service for it.
  • Configuring your CRM, helpdesk or invoicing tool beyond the records and keys each one needs

Who it fits

A domain with no authentication records, broken ones, or years of accumulated SPF includes nobody can account for. If the records already pass and the complaint is about where the mail lands, skip this and buy the Email Deliverability Audit.

Also in email infrastructure