Five Email Deliverability Mistakes That Cost You Money

If your invoices, password resets and product updates keep landing in spam, the fix is rarely the email copy. It is usually one of three DNS records — SPF, DKIM and DMARC — configured just well enough to pass a checklist. Indian B2B teams feel this hardest, because most run business mail on Google Workspace or Zoho Mail while campaigns go out through a separate platform, so two systems sign the same domain and nobody owns the result.

Mistake 1: an SPF record that breaks at 10 DNS lookups

SPF is a single TXT record, v=spf1 ... -all, and every mechanism that triggers a DNS query counts toward a hard limit of 10 lookups. That covers include:, a, mx, ptr, exists and redirect. Cross the limit and receivers return permerror, which most treat as having no SPF at all. Your mail fails authentication outright and you spend a week rewriting subject lines.

Records bloat one vendor at a time: include:_spf.google.com for Workspace, include:zoho.in for the CRM, include:sendgrid.net for the app, a helpdesk, a survey tool, an old campaign include nobody removed. Add an mx mechanism and you are at 11 lookups without anyone ever deciding to get there.

• Audit before you add another sender. A quick pass through MXToolbox or dmarcian shows the lookup count and whether the record is already failing.
• Delete what you no longer use. A dormant include still spends a lookup.
• Split sending across subdomains: mail.yourdomain.com for transactional, news.yourdomain.com for campaigns. Each gets its own record and its own budget of 10.
• Consider flattening services only when you genuinely cannot cut further. A flattened record breaks silently the day a provider changes its IP ranges.

Mistake 2: DKIM that was configured once and never checked

DKIM signs each message with a private key, and the matching public key sits at selector._domainkey.yourdomain.com. Three things go wrong. Keys stay at 1024 bits because that was the default years ago, while Google and Yahoo bulk-sender rules now expect 2048. A provider migration leaves the old selector published and the new one missing, so DKIM fails quietly while mail still flows. And when a third-party tool signs with its own d= domain, DKIM passes for them but not for you, leaving DMARC alignment to SPF.

Verifying takes two minutes. Send a test to a Gmail address, open Show original, and look for dkim=pass next to your own domain. If the d= field shows your ESP's name, you have a problem no dashboard will surface.

Mistake 3: going to p=reject before you have any data

DMARC tells receivers what to do when neither SPF nor DKIM aligns with the From domain. Teams publish p=reject on day one because it feels like the finish line, then find a legitimate sender they forgot: a payment gateway, a support desk, an internal app relay, an ATS a recruiter signed up for.

Move in stages. Start at p=none with a rua= reporting address, watch for two to four weeks, then quarantine, then reject. Read the aggregate reports or route them to a monitoring service, because raw XML stops being readable past a few hundred messages. Note that some receivers ignore pct= for gradual rollout, so phase the change by subdomain rather than by percentage.

While you are in there, publish a DMARC record on parked and unused domains too, at p=reject. A spoofed invoice sent from a domain you own but never mail from is one of the cheapest frauds going.

Mistakes 4 and 5: root-domain sending, and the ignored sp= flag

Two related mistakes. The first is sending campaigns from your root domain. One over-eager batch or a bought list drops root reputation, and now your password resets and tax invoices are collateral damage. Push marketing to a subdomain so transactional mail keeps its own standing.

The second is assuming DMARC is a single whole-domain switch. Records are published per hostname, and subdomains inherit from the organizational domain unless you set an sp= value. If the root says p=reject and mail.yourdomain.com has no SPF or DKIM of its own, some receivers apply the strict policy there anyway. Publish records on every hostname you actually send from.

An illustrative case: a 40-person B2B company in Gurgaon sends roughly 4,000 transactional emails a month plus a 20,000-address newsletter. Its SPF record had grown to 12 lookups after three vendor changes, DMARC had sat at p=none for two years, and the DKIM selector was stale from an ESP migration. After trimming SPF to 5 lookups, rotating DKIM to 2048 bits and moving the newsletter to a subdomain, aggregated pass rates climbed from the low 70s into the high 90s in about six weeks. If a fifth of the newsletter was previously missing the inbox, that is 4,000 emails a month nobody read, against a few hours of DNS work.

Where to start

Order of operations matters more than tooling:

• Check the current state: SPF lookup count, DKIM key length, DMARC policy, and whether reports are arriving at all.
• Publish p=none with a reporting address on every domain and subdomain you send from.
• Trim SPF to under 8 lookups, remove dead includes, and move to -all once your own mail passes consistently.
• Rotate DKIM to 2048 bits and confirm dkim=pass with your domain in the d= field.
• Move campaigns to a subdomain, watch reports for two to four weeks, then move to quarantine, then reject.

If babysitting DNS for a month is not how you want to spend your quarter, this is the kind of groundwork Maysan Labs does for B2B teams, usually alongside the sending tools they already use. The goal is not a perfect score in a checker. It is invoices that arrive and newsletters that get read.