Introduction
When a CRM, email marketing service, website SMTP forms, or new email hosting is connected to a domain, DNS settings are often updated piecemeal. As a result, the SPF record becomes bloated, DKIM selectors conflict, DMARC starts logging errors, and customers’ emails end up in spam. People usually blame “email,” even though the problem lies in the overall sending setup.
Symptoms
Symptoms: Some emails are delivered, while others are not; Gmail or Outlook flags messages as suspicious; customer replies get lost; the mailing service asks to add records, but no one deletes the old ones; the SPF record contains too many `include` statements; there is a DKIM signature, but the “From” domain does not match the authorized sender.
What is being checked
- Which services actually send emails on behalf of a domain?
- Does the SPF exceed the DNS lookup limit?
- Is there a DKIM record for each sender?
- Does the From/Return-Path match the DMARC policy?
- Are there any old TXT records from deactivated services?
- Which DMARC policy is enabled, and where do the reports go?
- How the website sends requests: PHP mail, SMTP, or API
Correction Process
The process begins with an inventory of all sending sources. Next, the SPF record is simplified to include only the necessary entries, DKIM is verified for each service, and DMARC is configured so that the policy aligns with the domain’s actual readiness. The website’s forms are switched to standard SMTP or an API if they were sending emails directly from the server without authorization.
Normal result
A normal result is a clear table showing who the sender is, which DNS record verifies it, which DKIM selector is used, and what happens if the service is disabled. After testing, emails are checked across multiple providers, not just in a single inbox.
Conclusion
Email reputation isn't ruined by a single bad email, but by chaos in the sending sources. The sooner you get your system in order, the lower the risk of losing customer requests and responses.