New Domain, No SPF: Why Clients Ask for Exceptions and How MSPs Should Respond

Why new domains go live without email authentication

Most domain registration processes don't include email authentication setup as a default step. A client registers a domain at a registrar, points it at a hosting provider, and either hands it to a developer or starts using it themselves. The developer's job is to get the website working. The registrar doesn't prompt for SPF record creation. Nobody in the chain is specifically accountable for email authentication until something breaks or someone complains.

The result is predictable: new domains regularly enter production with no v=spf1 record, no DKIM configuration, and no DMARC record. Email gets sent anyway — from whatever platform the client uses — and whether it delivers depends entirely on the receiving server's local policy and how lenient it is toward unauthenticated senders.

This situation generates two types of escalations to MSPs. The first is delivery problems: email from the new domain lands in spam, or gets rejected outright. The second is allowlist requests: a vendor whose system sends on the client's behalf — a form submission service, an e-commerce platform, a ticketing system — asks to be added to a receiving server's exception list because their messages aren't authenticating. Both are symptoms of the same root cause: email authentication was treated as optional configuration rather than a deployment requirement.

Why making the exception is the wrong response

When a vendor requests an exception — "can you whitelist our sending IPs" or "can you disable filtering for this domain temporarily" — the request sounds reasonable. The email is legitimate. The vendor is known. The urgency is real. Granting the exception resolves the immediate ticket quickly.

The problem is what the exception represents in terms of email security posture. An allowlist exception for unauthenticated mail from a specific domain or IP range is an explicit bypass of email authentication enforcement. Any message that spoofs that vendor's sending address, or any message that originates from a compromised account at that vendor, now bypasses the filtering controls that would otherwise catch it — because the MSP has told the receiving server to trust it unconditionally.

The exception accumulation problem:

Each individual exception request looks low-risk in isolation. Over months and years, a client accumulates a list of sending domains and IP ranges that bypass authentication filtering entirely. That list was built by granting reasonable exceptions one at a time, without anyone tracking the aggregate effect on the client's overall email security posture. The exceptions themselves become attack surface: a threat actor who wants to deliver email to that client can research the exception list and craft delivery paths that bypass the controls that were supposed to protect against exactly this kind of thing.

There's also the audit problem. When a client undergoes an IT security audit or insurance assessment, the auditor reviewing the exception list will ask why each entry exists and what the authentication status of that sender is today. Exceptions granted under time pressure two years ago — without documentation, without review dates, without remediation commitments — become audit findings. The MSP ends up defending configuration decisions that were made in five minutes to close a ticket.

What domain onboarding should look like instead

The solution to the exception cycle is removing its root cause — new domains going live without email authentication configured. An onboarding checklist that treats email authentication as a deployment requirement (not a later addition) eliminates most of the exception requests before they happen.

A practical onboarding standard for new domains:

check_circle
SPF record published before the domain is used for email. Even a minimal v=spf1 -all record — which explicitly states "this domain sends no email" — prevents the domain from being exploited for spoofing while it's not yet actively sending. When sending services are known, the record gets updated to include them. The important thing is that the record exists and is intentional from day one.
check_circle
DKIM configured for every sending platform before mail is sent. Every platform the client uses to send email from the new domain — Microsoft 365, Google Workspace, a marketing platform, a transactional mail service — needs its DKIM selector published in DNS and verified as working before the first message is sent. This isn't optional or "something to do when there's time." It's a deployment gate.
check_circle
DMARC record at p=none with reporting from day one. A p=none DMARC record starts the data collection immediately. Aggregate reports begin arriving within 24 hours, showing exactly what is sending in the domain's name, what is passing, and what is failing. This data makes the path to enforcement explicit and removes the ambiguity that keeps domains at p=none indefinitely.
check_circle
A target date for p=reject in the onboarding scope of work. Setting an expectation at the start — "we'll move to full enforcement within 90 days" — creates a project rather than a perpetual state. It gives the MSP leverage to revisit the sending posture at defined intervals rather than only when something breaks.

Handling the exception requests that still arrive

Even with a strong onboarding standard, exception requests will arrive — for existing clients whose domains predate the new process, for vendors that resist implementing DKIM, and for edge cases where a system genuinely can't be made to authenticate. The issue isn't whether to handle exceptions, it's whether the exception process is intentional.

A defensible exception process looks like this: document every exception with the reason it was granted, the affected sender, the review date, and the remediation plan. Set a review date — 90 days is a reasonable default — and enforce it. When the review date arrives, check whether authentication has been implemented. If yes, remove the exception. If no, re-evaluate whether the exception should remain or whether the client needs to replace the sending platform with one that supports authentication.

"We'll look at it later" and "the vendor says they're working on it" are not remediation plans. If a vendor genuinely cannot implement DKIM and SPF alignment, the MSP should document that limitation factually and advise the client on whether the risk is acceptable or whether the vendor should be replaced. That's a harder conversation than making the exception, but it's the one that protects the MSP if the exception is later abused.

The MSP's leverage point: domain registration and management

MSPs that manage domain registration and DNS hosting for their clients are in the strongest position to enforce this standard — because new domain setup goes through the MSP's workflow, and email authentication records can be deployed as part of that workflow before the domain is handed to the client.

When the MSP registers the domain, creates the DNS zone, and configures the initial record set, adding a v=spf1 -all SPF record, a placeholder DMARC record, and whatever DKIM selectors can be pre-configured takes minutes. The domain never has a window where it's registered and active but lacking basic email authentication protection.

For clients who manage their own domain registration independently, consolidating domain and DNS management under the MSP is worth raising as part of a security and operational efficiency conversation. It reduces the surface area for the exception cycle — and it gives the MSP visibility into every new domain before it starts sending email in ways that might need remediation later.

Monitoring as the safety net:

Even with a strong domain onboarding process, clients will occasionally register domains independently and start using them without notifying the MSP. Domain portfolio monitoring that alerts when a known client domain appears in DMARC reports without valid email authentication configuration provides a catch mechanism for the cases that don't go through the standard process. The goal is to find out before the first exception request arrives — not after three deliverability complaints have already been fielded.