Domain, DNS and email deliverability

What this actually solves

There are two versions of this problem and they arrive from opposite directions.

The first is a business whose ordinary mail has started disappearing. Quotes, invoices and password resets land in junk folders or vanish entirely, customers say they never received anything, and the sales team has begun ringing people to ask whether an email arrived. This rarely has anything to do with the content of the messages. Email was designed at a time when anyone could write anyone's name in the From field, so mailbox providers built verification on top of it, and mail from a domain that cannot prove who it is gets treated with suspicion no matter how legitimate it is.

The second is a team about to send at volume — outreach, a campaign, a product launch — who has been told they need SPF, DKIM and DMARC and does not know whether what exists is correct. That deadline is now real rather than advisory: since February 2024, Google and Yahoo require all three from senders posting more than five thousand messages a day to their users.

Underneath both sits the domain itself, which is a single point of failure that attracts no attention at all while it is working. Every one of these records lives in DNS, alongside the records that decide whether your website resolves at all. A domain that lapses, a nameserver change that drops records nobody documented, or a migration done without lowering the TTL first, will take out mail and web together — and the symptom is total rather than partial, which makes it alarming out of proportion to how simple the fix is.

How the work runs

1. Audit what is actually published, and who is actually sending. The current SPF record, every DKIM selector, any DMARC record, the MX records and the TTL on each. Then the part that takes the time — listing every system that sends mail using your domain. Billing, CRM, helpdesk, booking, marketing, and the old server nobody decommissioned. Each one is either authorised or removed; there is no third option. Half a day to a day.
2. Publish authentication correctly. One SPF record, kept within the ten DNS lookups the specification allows. DKIM signing enabled at every legitimate sender with its keys published. DMARC published in monitoring mode with a reporting address that someone actually receives, so the next step has data to work from. One to two days.
3. Collect and read the reports before enforcing anything. This is the step that gets skipped, and skipping it is what breaks businesses. The reports tell you which sources pass, which fail, which are forwarders behaving normally, and which are forgeries. Only once every legitimate sender is accounted for is it safe to move. Three to seven days of collection, half a day to interpret.
4. Raise the policy in stages. Monitoring first, then quarantine, then rejection, with enough days of reports between each move to see the effect. If a legitimate sender was missed, it shows up at quarantine as mail diverted rather than at rejection as mail destroyed. Half a day per move.
5. Handle the DNS and cutover work around it. If mail routing or nameservers are moving as part of this, TTLs are dropped to a few minutes the day before so the change takes effect in minutes instead of the day a long TTL would impose, then restored afterwards. Records are verified from outside your own network, because a resolver that already has the answer cached will happily tell you everything is fine. Half a day to a day.

What moves the price

The range is $200–$2,000 across 2–7 days, and it is decided almost entirely by three things.

How many systems send as your domain. A single mailbox provider is a short job. Six tools, a transactional sending API and a legacy application on an old server is a longer one, because each has its own place to enable signing and its own quirks, and the discovery of the forgotten one is often the entire value of the engagement.

How many domains are in scope. Outreach programmes typically run several sending domains by design, and every one needs its own complete set of records, its own reporting and its own staged enforcement. The work multiplies fairly directly with the count.

The state of the DNS you are starting from. A clean zone at a single provider is straightforward. A registrar pointing at one nameserver set, records duplicated across two control panels, and entries pointing at services shut down years ago, is an untangling job - and it has to happen before authentication can be trusted, because you cannot authorise senders in a zone you do not fully control.

What usually goes wrong

A second SPF record is published, or the existing one has quietly exceeded ten lookups. Adding a new sending tool usually means adding an include, and every include costs DNS lookups against a hard limit of ten. Cross it and the whole record returns a permanent error, which fails everything at once rather than degrading gracefully. Worse, publishing a second SPF record instead of merging into the existing one invalidates both. Both faults look like tidy configuration in a DNS panel and both silently disable your authentication.

The policy is set straight to rejection. It feels like the thorough choice and it is the expensive one. Enforcing before the reports have been read means every sender nobody remembered — the accounting package, the appointment reminders, the form on the old site - stops being delivered, permanently and invisibly, because rejected mail does not bounce back to you in any way you will notice. Monitoring first exists precisely to find those.

Mail passes SPF and still fails, because of alignment. A vendor sends on your behalf, the message passes SPF against the vendor's own domain, and everyone assumes the setup is correct. DMARC requires that the domain your recipient sees in the From field is the one that authenticated, so a technically passing SPF check can sit alongside a failing DMARC evaluation. This is the single most common reason a business that "already set this up" is still filtered, and it is only visible in the reports.