Most web design and digital agencies don't run their clients' email. But they often run the DNS, and DNS decides where every client email goes. A nameserver move or a tidy-up of "old records" during a site launch can quietly break mail or open a route around a client's spam filter. This page covers how to make email changes safely and how to introduce filtering to a client without becoming their email provider.
Why do web agencies need to think about email security?
Because the records that control email sit in the same DNS zone as the website. MX records decide where mail is delivered, SPF and DMARC decide whether receivers trust mail sent as the domain, and an agency with DNS access can change all of them in a few clicks, sometimes without meaning to.
An agency is different from an IT provider. A managed service provider usually looks after the mailboxes, devices and support desk. A web host runs the servers. An agency builds and maintains websites, and often ends up holding the registrar and DNS logins because it set up the domain. That makes you the first person a client blames when mail stops, even when the platform is someone else's.
Which DNS changes put a client's email at risk?
Most email outages after website work come from a small set of changes. Know them before you touch a client zone.
| Change | What can go wrong | Safer approach |
|---|---|---|
| Moving nameservers to a new DNS host | MX, SPF, DKIM and DMARC records aren't copied, so mail stops or fails authentication | Export the whole zone first and compare it record by record after the move |
| Deleting "unused" records during launch | A DKIM key or verification record the mail platform needs disappears | Ask who uses each record before deleting it; check the platform's admin console |
| Adding a second SPF record for a new tool | Two SPF records cause a permanent error (permerror), so SPF can't pass for any mail | Merge the new include into the one existing record |
| Adding includes to SPF | SPF allows at most 10 DNS lookups, and going over returns a permanent error | Count lookups after each change |
| Pointing MX at the old host "as a backup" | Senders may use any listed MX, so spam can skip the filter | Keep only the MX hosts the client's filter or platform specifies |
| Retiring a subdomain but leaving its records | A dangling record can let someone else take over the name | Remove records when the service behind them goes |
The SPF rules come from RFC 7208: section 3.2 says a domain must not publish more than one SPF record, and section 4.6.4 sets the limit of 10 lookups. The MX behavior is in RFC 5321, section 5.1. Our guides explain each problem in depth: multiple SPF records, too many SPF lookups, changing MX records without losing email and subdomain takeover through dangling DNS.
Website forms and plugins
The website itself often sends mail as the client's domain: contact forms, order confirmations, password resets. If that mail isn't covered by the domain's SPF and DKIM, receivers may junk it or reject it once the client's DMARC policy is enforcing. Our guide to website form emails going to spam shows how to fix it. DMARC (RFC 9989) only passes when SPF or DKIM passes for a domain aligned with the visible From address.
How do you make an email DNS change without breaking anything?
Treat every email record change as a small migration with a written rollback. This checklist works for any client and any mail platform.
- Record the current zone. Export it, or save the output of the Email Health Check for the domain.
- Find out who runs the mailboxes. Microsoft 365, Google Workspace, a cPanel host or something else. You'll need someone with admin rights there.
- Lower the TTL on the records you'll change, at least one full old-TTL period ahead.
- Make one change at a time, and check it with the MX Lookup or SPF Checker straight away.
- Send real test messages in and out, and read the headers.
- Keep the rollback ready: the old values, and the order to restore them.
- Tell the client what changed and when, in writing.
How do you introduce email filtering to a client?
Start with evidence, not a sales pitch. Run the free Email Health Check on the client's domain and share what it shows: where mail goes, whether SPF and DMARC are in place, and anything broken. Many clients have never seen their own email setup explained.
If the client wants inbound filtering, iBlockSpam works at the MX level in front of the platform they already use. The domain's MX records point to our filtering servers, and clean mail is delivered to their existing mailboxes. The mail platform needs its own step so it accepts mail from the filtering service: an inbound Partner connector on Microsoft 365, the inbound gateway setting on Google Workspace, or the right routing on cPanel/WHM. That step usually needs the client's mail admin, which keeps responsibilities clear.
What the client gets for each domain:
- Spam, virus, malware, phishing and spoofing filtering before mail reaches their mailboxes.
- A personal quarantine for every user, with digest emails on a schedule, and a shared quarantine for their admin.
- Mail held for up to 5 days if their mail server is down, and 30 days of message history.
- DMARC monitoring, Lookalike Domain Watch, and alerts when MX, SPF or DMARC records change: weekly on Protect, daily on Protect Plus.
The client signs up, chooses a plan and pays for its own domains. Pricing is per domain with unlimited mailboxes (mailbox count, not message volume); see pricing. There's no free trial. A first annual subscription for a domain has a 30-day money-back guarantee.
Can an agency manage clients' filtering from one place?
Yes, if you're an approved partner and the client grants access. The partner program is aimed at MSPs and web hosts. Agencies that look after many client domains can apply, and every application is reviewed by a person; see partners.
Approved partner staff, who must use two-factor authentication, see every client account that has granted access, with per-domain status, search, filters and CSV export. Clients grant full or read-only access by accepting your invitation or entering your partner code, and can remove it at any time (immediately in iBlockSpam; an open filtering-panel session lasts until it times out). Partners can't change a client's billing, plan, payment, security settings or partner access, and can't delete the account. Everything you do shows in the client's activity log.
Each client pays for its own domains. There's no consolidated partner invoice, partner API or bulk import. Partner terms, including pricing, are agreed individually.
What if a client changes DNS without telling you?
Domain monitoring catches it. For each protected domain, iBlockSpam alerts when the MX, SPF or DMARC records change, weekly on Protect and daily on Protect Plus. That covers the common case where someone else edits the zone and mail quietly stops being filtered. See domain monitoring.
Honest limits
- An MX lookup can't prove mail is filtered. Header checks on real messages are the evidence.
- iBlockSpam filters inbound mail. It doesn't secure your registrar or DNS host logins, so protect those with two-factor authentication; our guide to registrar security explains registry lock.
- Each domain includes 100,000 inbound messages a month and 500 outbound relay messages a month.
- Mail is processed in the United States.
Check a client domain with the free Email Health Check, or apply to become a partner if you look after many client domains.
Frequently asked questions
Can a web agency set up email filtering without managing the client's mailboxes?
Yes. The change happens in DNS and on the client's mail platform. You update the MX records you already manage, and someone with admin rights on the platform adds the inbound connector or gateway setting. The client's mailboxes, passwords and mail apps stay where they are. The setup wizard shows the exact records and the rollback steps.
Who pays when an agency adds filtering for a client?
The client does. Each client chooses its plan and pays for its own domains from its own sign-in, so the subscription belongs to them, not to you. iBlockSpam has no consolidated partner invoice. Protect is $12 per domain per month billed annually, or $15 month-to-month, beta pricing.
Why does website form email break after a DNS change?
Usually because SPF was rewritten or duplicated. A domain must have only one SPF record, and adding a second one, or dropping the include for the service that sends your forms, makes the form's mail fail authentication. Check SPF before and after any change with a checker, and keep a copy of the old records.
Can our agency see all our clients' domains in one place?
If you're approved as a partner and each client grants you access. The partner console lists every client account that has accepted your invitation or entered your partner code, with per-domain status, search, filters and CSV export. Clients can switch you to read-only or remove you at any time. There's no partner API or bulk import.
Related guides
What does zero-hour auto purge (ZAP) do in Microsoft 365?
How Microsoft 365 zero-hour auto purge pulls spam, phishing and malware from inboxes after delivery, its 48-hour window, where mail goes and when ZAP won't act.
9 min read Choosing a filterHow should an MSP price managed spam filtering?
How an MSP can price managed spam filtering: work out cost to serve per client domain, add setup and quarantine support time, test margins and design packages.
9 min read Setup guidesHow do you protect the domain your email depends on?
Protect the domain your email depends on: registrar MFA, transfer lock vs registry lock, auto-renew, contact addresses and DNS host security, plus a checklist.
10 min readLast updated: