Why Does Business E-mail Land in Spam? An SPF, DKIM and DMARC Guide

A proposal that never reaches the client is the quietest lost sale there is. In most cases the cause is not the e-mail's content but missing or misconfigured authentication records on the domain.

Where does the problem come from?

The e-mail protocol was designed in 1982 for an internet where identity was not questioned. Anyone can appear to send from any address. Three layers were developed to close that gap: SPF, DKIM and DMARC. Today Gmail and Outlook filter senders who fail to implement all three increasingly harshly.

SPF — who may send on my behalf?

SPF is a TXT record listing which servers are authorised to send mail for your domain.

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Three things to watch:

• There must be exactly one SPF record. Two separate v=spf1 records invalidate SPF entirely. Merge all sources into a single line.
• The 10 DNS lookup limit. Every include consumes a lookup. Exceed the limit and the record returns "permerror" and stops working.
• ~all or -all? Start with ~all (softfail); move to -all once every sending system is verified.

DKIM — was the message altered in transit?

DKIM adds a cryptographic signature to every outgoing message. The receiving server validates it against the public key in DNS. If the signature holds, the message was not altered in transit and genuinely came from your domain.

Setup depends on the provider: Google Workspace generates the key from its admin panel, cPanel enables it with one click under "Email Deliverability". Key length should be 2048 bits; 1024 bits is now considered weak.

A common failure: the key being truncated because of TXT record line-length limits at the DNS provider. Always test with a validation tool after setup.

DMARC — what should happen on failure?

DMARC combines SPF and DKIM results, gives the receiver an instruction and sends you reports.

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100

The policy is tightened in stages:

1. p=none — Do nothing, just report. Stay here for at least 30 days.
2. p=quarantine — Send failing messages to spam. Monitor for 30 days.
3. p=reject — Reject failing messages outright. This is the end goal.

The XML reports arriving at your rua address are hard to read by hand; use a free report visualisation service. These reports are the only reliable source showing who is sending mail in your name.

Setup checklist

• One valid SPF TXT record exists
• DKIM is enabled with a 2048-bit key and validates
• A DMARC record is live and the rua address works
• Every system sending on your behalf (CRM, invoicing, newsletter) is authorised in SPF
• A PTR (reverse DNS) record is correctly defined for the sending IP
• MX records point to a single provider with no stale entries
• The domain is not on a blacklist

Verification

Send yourself a test message and choose "Show original" in Gmail. Look for three lines in the headers:

spf=pass    dkim=pass    dmarc=pass

If all three read pass, the infrastructure is sound. Everything beyond that is a matter of content and sending reputation: do not blast hundreds of recipients at once, clean lists that never open, and include a working unsubscribe link in every message.