Why your business emails go to spam: SPF, DKIM and DMARC explained

TL;DR: Email lands in spam mostly because the receiving server cannot verify that you actually sent it. Three DNS records fix that. SPF lists which servers may send on your behalf. DKIM cryptographically signs messages so tampering is detectable. DMARC tells receivers what to do when the first two fail, and tells you when it happens.

Two details cause most of the failures. SPF has a hard limit of ten DNS lookups, and businesses using several sending services exceed it without realising, which invalidates the record entirely. And DMARC requires alignment, meaning the domain in the visible From address must match the domain that passed SPF or DKIM, which is why mail sent through a third-party service can pass both checks and still fail DMARC.

Why deliverability broke

Email was designed without authentication. Anyone could claim to be anyone, and for a long time receivers largely accepted that.

Spam and phishing made that untenable. Receiving providers now treat unauthenticated mail with deep suspicion, and the major mailbox providers have progressively tightened requirements for bulk senders, with authentication moving from recommended to effectively mandatory.

The practical consequence for a small Indian business: if your domain has no SPF, no DKIM and no DMARC, your invoices, order confirmations and quotes are being filtered at a meaningful rate, and you have no visibility into it because a spam-foldered message produces no bounce.

The failure is silent. You send, nothing errors, and the customer says they never received it.

There is a second consequence that matters more than filtering. Without DMARC, anyone can send mail claiming to be from your domain, and receivers have no instruction on what to do about it. Invoice fraud targeting Indian businesses frequently works exactly this way: a spoofed message from what appears to be a supplier's domain, requesting payment to changed bank details.

SPF: who is allowed to send

Sender Policy Framework is a TXT record listing the servers permitted to send mail for your domain. A receiving server compares the sending IP against that list.

A record looks like:

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

Reading it: version 1, permit servers listed by Google's and SendGrid's SPF records, and soft-fail anything else.

The mechanisms you will use:

include: pulls in another domain's SPF record, which is how you authorise a service such as Google Workspace or a transactional email provider. a and mx authorise your domain's A record or mail servers. ip4: and ip6: authorise specific addresses, which is how you authorise your own web server if it sends mail directly.

The ending qualifier matters:

-all is hard fail: anything not listed should be rejected. ~all is soft fail: treat as suspicious but usually still deliver. ?all is neutral and effectively useless.

Start with ~all while you confirm you have listed everything, then move to -all once you are confident. Going straight to -all with an incomplete record blocks your own mail.

One SPF record per domain. This is the most common configuration error. Two SPF TXT records make the domain's SPF invalid entirely, and it fails rather than merging. If you add a service, edit the existing record rather than adding a second one.

Inventory everything that sends as your domain. Mail provider, transactional email service, marketing platform, CRM, invoicing software, helpdesk, your own web server sending contact form notifications. Anything missing from SPF fails authentication.

The ten-lookup limit

The trap that catches growing businesses.

SPF evaluation is capped at ten DNS lookups. Every include:, a, mx, ptr and exists mechanism counts, and crucially, nested includes count too. A single include: pointing at a provider whose record contains three more includes consumes four lookups, not one.

Exceed ten and the result is permerror, which most receivers treat as a failure. Your SPF stops working entirely, and nothing warns you.

A business using Google Workspace plus a transactional provider plus a marketing platform plus a CRM can hit the limit with four apparently simple includes.

How to handle it:

Check your current count with any SPF validation tool. Do this now if you have more than two includes; a lot of records are silently over the limit.

Remove services you no longer use. The most common cause of bloat is an include for a platform abandoned two years ago.

Prefer ip4: where the sender has stable IPs, since a direct IP mechanism costs no lookup.

Use SPF flattening carefully. Flattening resolves includes into literal IPs, reducing lookups. The risk is that provider IP ranges change and a flattened record goes stale, so if you flatten, use a service that monitors and updates it rather than doing it once by hand.

Do not use ptr. It is deprecated, slow, and consumes a lookup.

DKIM: proving the message was not altered

DomainKeys Identified Mail adds a cryptographic signature to outgoing messages. The sending server signs selected headers and the body with a private key; the receiver retrieves the corresponding public key from your DNS and verifies the signature.

If verification succeeds, the message genuinely came from a system holding your key, and it was not modified in transit.

Setup is per-service and mercifully simple: your provider generates a key pair, gives you a TXT record to publish at a selector subdomain such as google._domainkey.yourdomain.com, and you paste it into DNS. The provider then signs outgoing mail automatically.

Points worth knowing:

Each sending service gets its own selector, so multiple DKIM records coexist without conflict. Unlike SPF, there is no single-record constraint.

Use 2048-bit keys where offered. Some older DNS interfaces struggle with the record length, which is the usual reason people fall back to 1024.

Rotate keys periodically. Providers increasingly automate this.

DKIM survives forwarding better than SPF. When a message is forwarded, the sending IP changes and SPF breaks, but the DKIM signature usually remains valid. This is why having both matters rather than choosing one.

Verify it is actually signing. Send a message to an address you control at a major provider, open the original message headers, and look for a DKIM pass result. A published record with the provider not actually signing is a common half-configured state.

DMARC: policy and visibility

Domain-based Message Authentication, Reporting and Conformance does two things: it tells receivers what to do when SPF and DKIM fail, and it sends you reports about mail claiming to be from your domain.

A record looks like:

v=DMARC1; p=none; rua=mailto:[email protected]; pct=100

Published at _dmarc.yourdomain.com.

The policy tag p= is the important one:

p=none monitors only. Nothing is blocked; you simply receive reports. This is where every rollout starts. p=quarantine sends failing mail to spam. p=reject instructs receivers to refuse it outright.

rua= is where aggregate reports go. These are XML files, sent daily by major receivers, listing what sources sent mail claiming to be your domain and whether it authenticated. Raw XML is unpleasant to read, so use a DMARC reporting service, several of which have free tiers.

pct= lets you apply the policy to a percentage of mail, which is how you ramp gradually.

The reports are the underrated part. Before publishing DMARC, most businesses do not actually know everything that sends as their domain. The reports reveal the invoicing tool nobody documented, the marketing platform a former employee configured, and any spoofing attempts against you.

Alignment, the part that confuses everyone

DMARC does not simply check whether SPF or DKIM passed. It checks whether they passed and aligned.

Alignment means the domain in the visible From address matches the domain that authenticated.

For SPF, the check is against the return-path domain, which is often the sending service's own domain rather than yours. So a message can pass SPF against sendgrid.net while your From address says yourdomain.com, and DMARC fails because those do not align.

For DKIM, alignment means the signing domain d= matches your From domain.

This is why mail sent through third-party services frequently passes SPF and DKIM individually while failing DMARC.

The fix is to configure a custom return-path or custom DKIM signing domain at each service, so authentication happens against your domain rather than theirs. Every serious provider supports this, usually documented as domain authentication or custom sending domain setup, and it requires publishing a couple of CNAME records.

DMARC passes if either SPF or DKIM passes with alignment. You do not need both, though having both is more resilient.

Record	Purpose	Where published	Limit	Failure symptom
SPF	Authorises sending servers	TXT at root domain	One record, ten lookups	Mail marked suspicious
DKIM	Signs message integrity	TXT at selector subdomain	None, multiple selectors fine	Signature fails on modified mail
DMARC	Policy plus reporting	TXT at _dmarc	One record	No policy, no visibility
Alignment	Ties auth to From domain	Configured at each service	—	DMARC fails despite SPF and DKIM passing

Rolling out DMARC safely

The staged approach, because publishing p=reject on day one will block your own legitimate mail.

Weeks 1 to 2: publish p=none. Set up a reporting address and a DMARC reporting service. Change nothing else. Collect data.

Weeks 3 to 4: read the reports. Identify every source sending as your domain. Expect surprises: an invoicing tool, a form plugin sending directly from your web server, a legacy marketing platform. For each legitimate source, configure SPF, DKIM and alignment properly. For each illegitimate source, you have just discovered spoofing against your domain.

Weeks 5 to 6: verify alignment. Confirm each legitimate source now passes DMARC with alignment, not merely SPF or DKIM in isolation. This is where custom return-path and custom DKIM domain configuration happens.

Weeks 7 to 8: move to p=quarantine with pct= ramped. Start at a small percentage, watch reports, increase gradually. Failing mail goes to spam rather than being lost, which makes this a safe intermediate step.

Week 9 onward: p=reject if appropriate. Full protection against spoofing. Only move here once reports show all legitimate mail passing with alignment consistently.

Do not skip stages. The businesses that break their own mail with DMARC are the ones that published p=reject immediately because a checklist said DMARC was required.

Keep monitoring afterwards. New services get added, and a marketing platform configured by someone in a hurry will start failing.

What else sends you to spam

Authentication is necessary and not sufficient.

Sending from a web server directly. PHP mail() from your hosting sends from an IP shared with many other sites, with no authentication and frequently poor reputation. Route transactional mail through an SMTP service or your mail provider instead. This alone resolves a large share of "contact form emails going to spam" complaints.

Poor list hygiene. Sending to purchased lists, old addresses, or people who never opted in generates spam complaints and bounces, both of which damage domain reputation. Reputation is slow to build and quick to lose.

No unsubscribe mechanism on bulk mail. Major providers expect one-click unsubscribe on marketing messages, and absence is treated as a negative signal.

Sudden volume changes. Going from 50 messages a day to 50,000 looks like a compromise. Warm up gradually when starting a new sending domain or IP.

Content signals. Excessive capitals, aggressive punctuation, a single large image with almost no text, link shorteners, and mismatched display names all contribute.

Mixing mail types. Sending marketing campaigns and transactional receipts from the same subdomain means a poor campaign response damages delivery of your order confirmations. Separate them: transactional from one subdomain, marketing from another.

No reverse DNS if you run your own mail server, which is a strong reason for most small businesses not to run their own mail server.

FAQs

Why do my business emails go to spam?

Most commonly because the receiving server cannot verify you sent them. Without SPF, DKIM and DMARC, mail from your domain is treated with suspicion by default. Other frequent causes are sending directly from a shared web server IP, poor list hygiene generating complaints, and mixing marketing with transactional mail on the same domain.

What is the difference between SPF, DKIM and DMARC?

SPF lists which servers may send for your domain. DKIM cryptographically signs messages so any alteration is detectable and proves the sender held your key. DMARC tells receivers what to do when SPF and DKIM fail, and sends you reports about all mail claiming to be from your domain. They work together rather than as alternatives.

Can I have two SPF records?

No. A domain must have exactly one SPF TXT record, and publishing two makes SPF invalid entirely rather than merging them. When adding a new sending service, edit the existing record to include it. This is one of the most common email configuration errors.

What is the SPF ten-lookup limit?

SPF evaluation is capped at ten DNS lookups, counting every include, a, mx and exists mechanism, including nested includes inside your providers' records. Exceeding it produces a permanent error that most receivers treat as failure, silently breaking your SPF. Businesses using four or more sending services frequently exceed it without knowing.

Why does my email fail DMARC when SPF and DKIM pass?

Because of alignment. DMARC requires that the domain that authenticated matches the domain in the visible From address. Mail sent through a third-party service often passes SPF against the service's own return-path domain, which does not align with yours. Configure a custom return-path or custom DKIM signing domain at each service to fix it.

Should I start DMARC with p=reject?

No. Start with p=none, which monitors without blocking anything, and collect reports for a few weeks to discover every source sending as your domain. Then fix alignment for legitimate sources, move to p=quarantine with a ramped percentage, and only reach p=reject once reports consistently show all legitimate mail passing.

Why do my WordPress contact form emails go to spam?

Because PHP mail() sends directly from your web server, using an IP shared with many other sites, with no authentication and often poor reputation. Configure an SMTP plugin to route mail through your mail provider or a transactional email service instead. This resolves most contact form delivery problems on its own.

How do I check if SPF, DKIM and DMARC are working?

Send a message to an address you control at a major provider, open the original message headers, and look for SPF, DKIM and DMARC pass results. Free online tools also let you send a test message and receive a full authentication report. Check each sending service separately, since they can be configured differently.

Do I need DKIM if I already have SPF?

Yes, ideally both. SPF breaks when a message is forwarded, because the sending IP changes, while the DKIM signature usually survives forwarding intact. DMARC passes if either authenticates with alignment, so having both makes delivery considerably more resilient.

What DMARC policy should I use?

Begin at p=none for monitoring, progress to p=quarantine once legitimate sources pass with alignment, and move to p=reject for full spoofing protection when reports are consistently clean. p=reject is the strongest position and only safe once you genuinely know every source sending as your domain.

Should marketing and transactional email use the same domain?

Better to separate them using subdomains. A poorly received marketing campaign generates complaints that damage domain reputation, and if transactional mail shares that domain, your order confirmations and password resets suffer for it. Separate subdomains isolate the reputations.

How long does it take to fix email deliverability?

DNS records take effect within hours, but reputation recovery is slower. If your domain has accumulated a poor sending reputation, expect several weeks of consistent authenticated sending with good list hygiene before delivery normalises. Authentication is the prerequisite; reputation is the thing that takes time.

Conclusion

Three records, and most of the difficulty is in two details.

The SPF ten-lookup limit is the one that silently breaks working configurations as a business adds services. Check your current count today if you have more than two includes, because a record over the limit fails completely and nothing tells you.

Alignment is the one that makes DMARC confusing. Passing SPF and DKIM is not enough; the authenticated domain must match your visible From domain, and third-party sending services default to their own. Configuring custom return-path and DKIM domains at each service is the fix, and it is the step most half-finished setups are missing.

Roll DMARC out in stages. p=none first, read the reports, fix what they reveal, then quarantine, then reject. The reports are worth publishing DMARC for on their own, because most businesses discover at least one sending source they had forgotten.

Then handle the non-authentication half: route mail through a proper SMTP service rather than your web server, keep your lists clean, and separate marketing from transactional sending.

Authentication gets you accepted. Reputation gets you into the inbox, and that one takes weeks of consistency rather than an afternoon of DNS edits.

HostCloud includes business email hosting with SPF, DKIM and DMARC guidance during setup, and DNS management in the same panel as your hosting so the records are one screen away. Plans start at ₹99 a month at https://hostcloud.in.