Business Emails Going to Spam? How SPF, DKIM and DMARC Misconfiguration Hurts Deliverability

A legitimate invoice, password reset or sales proposal can still land in spam when the sending domain is not authenticated correctly. Mailbox providers assess many signals, but SPF, DKIM and DMARC are among the foundations of domain trust. If they are missing, contradictory or misaligned, recipients may question whether a message truly came from your business.

This is especially important for companies in Morocco serving local and international customers. A domain may send through Microsoft 365, Google Workspace, a CRM, a support platform and a website at the same time. Every additional sender creates another place where authentication can fail.

What SPF, DKIM and DMARC actually do

The three standards work together, but each answers a different question. Configuring one does not compensate for ignoring the others.

SPF authorizes sending infrastructure

Sender Policy Framework, or SPF, is a DNS TXT record listing the servers permitted to send mail for a domain. When a server receives a message, it checks whether the connecting IP address is authorized by the SPF policy associated with the envelope sender.

SPF commonly fails when a business changes providers without updating DNS, creates multiple SPF records, omits a CRM or exceeds the protocol's DNS lookup limit. Forwarding can also break SPF because the forwarding server's IP may not be authorized by the original domain.

DKIM proves that a message was signed

DomainKeys Identified Mail adds a cryptographic signature to outgoing messages. The receiving server retrieves the corresponding public key from DNS and verifies that signed parts of the message were not altered after sending.

DKIM can fail because the selector is incorrect, the public key was pasted incompletely, signing was never enabled in the mail platform or an intermediary modified signed content. Old and forgotten selectors also create operational and security risks.

DMARC checks identity alignment and sets policy

Domain-based Message Authentication, Reporting and Conformance connects authentication to the domain visible in the From address. A message passes DMARC when SPF or DKIM passes and the successful identifier aligns with that visible domain.

DMARC also tells receivers whether to take no special action, quarantine suspicious mail or reject it. Its aggregate reports reveal which systems are sending on behalf of the domain, making it both a policy and a valuable discovery tool.

How misconfiguration damages deliverability

An authentication result is not the only factor in inbox placement. Reputation, content, complaint rates, recipient engagement and sending patterns also matter. Nevertheless, broken authentication removes an important trust signal and can expose the domain to impersonation.

• Missing SPF authorization: a new newsletter, billing system or application sends from infrastructure absent from the SPF record.
• Multiple SPF records: separate TXT policies are published instead of being consolidated into one valid SPF record.
• Valid DKIM without alignment: a platform signs with its own domain rather than a domain aligned with the address recipients see.
• Premature DMARC enforcement: a reject policy is activated before every legitimate sender has been identified and authenticated.
• Stale DNS records: migrations leave obsolete providers, selectors and reporting destinations in place.
• Subdomain gaps: marketing or transactional subdomains are used without a deliberate authentication policy.

The result may be spam placement, inconsistent delivery between providers or outright rejection. More importantly, strict policies applied incorrectly can block genuine business mail, while weak policies can leave spoofed messages unchallenged.

A practical diagnostic process

1. Inventory every source of outgoing email

List employee mailboxes, website forms, e-commerce notifications, CRM campaigns, help desks, accounting tools, monitoring systems and custom applications. Include systems used only occasionally. Review the infrastructure behind your hosting packages, because websites often send mail separately from the main office platform.

2. Inspect headers from real messages

Send test messages to accounts at several major mailbox providers and examine the full headers. Look for SPF, DKIM and DMARC results, the envelope sender, the DKIM signing domain and the visible From domain. A simple “pass” is not enough; verify alignment as well.

3. Review DNS as the receiver sees it

Check authoritative DNS rather than relying only on an administration dashboard. Confirm that there is one SPF policy, each active DKIM selector resolves correctly and the DMARC record has valid syntax. DNS propagation and cached answers can make recent changes appear inconsistent.

4. Read DMARC aggregate reports

Aggregate reports group sending IPs and authentication outcomes. Use them to distinguish approved platforms from unknown or abusive sources. Reporting data should be handled carefully because it can reveal infrastructure and vendor relationships.

5. Separate authentication from reputation issues

If alignment passes but messages still go to spam, investigate domain and IP reputation, sudden volume changes, inactive mailing lists, user complaints, URL reputation and message quality. Authentication establishes identity; it does not make unwanted mail desirable.

How to fix the records without interrupting email

Start with discovery rather than immediately publishing a strict DMARC policy. Consolidate SPF authorization around current providers and remove obsolete entries only after confirming they are unused. Because SPF has a DNS lookup limit, avoid chains of unnecessary includes.

Enable DKIM for every platform that supports it, preferably using your own aligned domain. Keep a record of selectors, owners and rotation dates. When rotating a key, publish and validate the new selector before retiring the old one.

Introduce DMARC with monitoring, review reports and correct legitimate failures. Once normal mail streams consistently align, move toward quarantine or rejection in controlled stages. Subdomains, third-party vendors and regional systems should be included in the plan rather than treated as exceptions.

Authentication also belongs within a broader cybersecurity strategy. Access controls, multi-factor authentication, mailbox auditing, vendor governance and incident response are necessary because SPF, DKIM and DMARC do not stop a criminal from using a genuinely compromised account.

Operational habits that protect deliverability

• Assign ownership of DNS and email authentication records.
• Require an authentication review before onboarding a new sending platform.
• Monitor DMARC reports and delivery errors continuously.
• Use separate, clearly managed subdomains for different mail streams when appropriate.
• Remove retired vendors from SPF, DKIM and application settings.
• Test important transactional messages after infrastructure or DNS changes.
• Keep mailing lists permission-based and process unsubscribes promptly.

For businesses operating across Morocco and international markets, testing should include the providers most commonly used by actual customers. Delivery behavior can differ by recipient network, region and message type.

Conclusion: treat email authentication as infrastructure

SPF, DKIM and DMARC are not one-time DNS tasks. They are living controls that must evolve whenever a business adds a platform, changes hosting, launches an application or replaces a mail provider. The safest approach is to inventory senders, validate alignment, monitor reports and increase enforcement gradually.

If legitimate messages are being rejected or disappearing into spam, avoid changing several records blindly at once. Preserve the current configuration, collect headers and reports, identify every authorized sender, then apply testable changes in sequence. For help auditing the complete sending path and planning remediation, contact the developer.ma team.