Email Deliverability for Agencies and Developers

You manage multiple domains. Each one has its own SPF, DKIM, DMARC, and IP reputation. One misconfigured record and your client's invoices land in spam. This guide covers the exact checklist to keep every domain in the inbox.

Why deliverability is harder when you manage many domains

When you run one domain, you can memorize the DNS records. When you manage ten client domains across five different email providers, you need a system. The most common failure modes for agencies and developers:

• Stale SPF records. A client switches from Mailchimp to Brevo but the SPF record still includes the old provider. Now you're over the 10-DNS-lookup limit and SPF fails entirely.
• Missing DKIM signatures. The email provider signs with DKIM, but the CNAME record was never added to the client's DNS. Receivers see unsigned mail and flag it.
• DMARC policy at none. The client has a DMARC record but it's set to p=none. That means no enforcement, no reporting, and no protection against spoofing.
• Shared IP reputation. The client uses a shared sending IP that another user burned. The client's mail now lands in spam even though their own records are perfect.
• No monitoring. Someone changes a DNS record, a provider rotates their DKIM key, or an IP gets blacklisted. The client finds out three days later when their customer says "I never got your email."

The 7-check deliverability audit

Every domain needs these seven checks, run against live DNS and mail servers:

1. MX records. Does the domain have valid MX records pointing to a reachable mail server? No MX means no mail delivery at all.
2. SPF. Does the SPF record include every sending provider? Is it under the 10-DNS-lookup limit? Does it end with -all or ~all?
3. DKIM. Is DKIM enabled at the provider? Is the CNAME record published in DNS? Is the key length at least 1024 bits?
4. DMARC. Is there a DMARC record? Is the policy p=reject or p=quarantine? Are reports being sent to a monitored address?
5. TLS/STARTTLS. Does the mail server support TLS? Is it using a valid certificate? Is the certificate not expired?
6. PTR / reverse DNS. Does the sending IP have a PTR record that matches the hostname? Does the hostname resolve back to the IP (forward-confirmed reverse DNS)?
7. IP reputation. Is the sending IP on any major blacklist (Spamhaus, Barracuda, SpamCop)? What's its reputation score?

Each check has a weight. DMARC and MX carry the most because they decide delivery first. A domain can't score well by fixing only the easy checks.

The agency workflow

Here's the workflow that keeps every client domain in the inbox:

1. Onboard every domain

When a new client comes in, run a full audit on their domain. This takes 30 seconds. You get a 0-100 score and a list of exact records to fix. No account needed, no DNS changes required.

2. Fix the records

Each failure comes with the exact TXT record to paste into the client's DNS. Copy, paste, verify. Most clients need 2-4 records added or updated.

3. Monitor continuously

DNS records change. Providers rotate DKIM keys. IPs get blacklisted. You need daily monitoring to catch regressions the day they happen, not three days later when the client calls.

4. Report to the client

Every audit is stored with a public link. You can share the report with the client, show them the score, and track the fix over time.

The developer workflow

If you're a developer building an email-sending product, deliverability is part of your API surface. Your users will blame your product when their mail lands in spam.

1. Verify the sending domain

Before your user sends their first email, verify their domain. Check SPF, DKIM, and DMARC. If any check fails, tell them exactly what to fix before they send.

2. Check IP reputation before sending

If you're using a shared IP pool, check the IP reputation before each send. If the IP is on a blacklist, route to a different IP or hold the send.

3. Expose deliverability in your dashboard

Your users should see their deliverability score in your dashboard. If the score drops, alert them. This turns a silent failure into a visible, fixable problem.

4. Use the API

Inboxproof has a REST API. Run an audit on any domain, get the score and checks as JSON, and build it into your product. No account needed for the free tier.

Common mistakes that burn agencies and developers

• Forgetting to update SPF after a provider switch. The client moves from SendGrid to Resend. The SPF record still includes include:sendgrid.net. Now you're one DNS lookup over the limit.
• Using p=none for DMARC. You added the record but left the policy at none. That means no enforcement. Set it to p=quarantine at minimum.
• Not monitoring after the fix. You fixed the records, the score went to 95, and you moved on. Two weeks later the provider rotated their DKIM key and the score dropped to 60. You didn't know until the client complained.
• Assuming one domain's config works for all. Each domain has its own DNS zone. You can't copy-paste records between domains without checking that the values are correct for each one.
• Ignoring shared IP reputation. Your client uses a shared IP pool. Another user on the same IP sent spam. Now your client's mail lands in spam. You need to check IP reputation and route around bad IPs.

How to keep every domain in the inbox

The system is simple:

1. Run a 30-second audit on every domain you manage.
2. Fix the records the audit tells you to fix.
3. Monitor daily so you catch regressions the day they happen.
4. Share the report with your client so they can see the score.

That's it. No XML forwarding. No sales call. No setup.