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

If your business emails land in spam folders, the cause is almost always missing or misconfigured authentication records. The three records that matter — SPF, DKIM, and DMARC — tell receiving servers whether an email genuinely came from your domain. This guide explains what each one does and how to check that yours are working.

Why emails go to spam

Email providers use a scoring system. Every message earns or loses points based on sender reputation, content, engagement history, and authentication. The authentication check is the quickest filter: if the receiving server cannot verify that your email came from a server authorised to send for your domain, it is likely to be flagged as spam regardless of content quality.

Three DNS records control this verification. The first, SPF, is a simple allowlist of sending servers. The second, DKIM, adds a cryptographic signature. The third, DMARC, tells the receiving server what to do when SPF or DKIM checks fail and sends you reports about unauthorised email sent from your domain. They work as a stack — each one builds on the previous.

SPF explained

Sender Policy Framework (SPF) is a DNS TXT record that lists every server authorised to send email from your domain. When a receiving server gets a message from your domain, it looks up the SPF record and checks whether the sending server's IP address is on the list.

A typical SPF record looks like this:

v=spf1 mx include:_spf.google.com ~all

This says: allow email from the servers listed in your domain's MX records, include Google's sending servers (for Google Workspace), and mark all other sources as soft-fail. The tag at the end — ~all (soft-fail) or -all (hard-fail) — determines what happens to email from unauthorised servers.

The most common SPF mistake is the 10-lookup limit. Every include: statement counts as a DNS lookup, and if your record triggers more than 10 lookups, SPF validation is permanently skipped — meaning your authentication provides zero protection. If you use multiple email services (Google Workspace, a newsletter platform, a CRM, a transactional email service), the lookups add up fast. Consolidate where possible.

DKIM explained

DomainKeys Identified Mail (DKIM) adds a digital signature to every outgoing email. The signature is created using a private key held by your email provider, and receiving servers verify it against a public key published in your DNS records.

DKIM is the strongest of the three authentication methods because it detects tampering. If an email is intercepted and modified in transit, the signature breaks and the message fails verification. It also protects against display-name spoofing, where an attacker sends a message that looks like it comes from your domain even though the header shows a different sender.

Each email provider generates its own DKIM key pair. If you send through Google Workspace, the public key goes in a DNS record called google._domainkey.yourdomain.com. If you also send through a CRM like HubSpot or a transactional service like SendGrid, each one needs its own DKIM selector record. Missing a DKIM record for one sending service is a common blind spot — email from that service fails DKIM and hurts your overall repuration.

DMARC explained

Domain-based Message Authentication, Reporting and Conformance (DMARC) tells receiving servers what to do when an email fails SPF and DKIM checks. Without DMARC, each receiving server decides independently, which means one provider may deliver your email while another flags it.

DMARC has three policy levels:

• p=none — Monitor only. No email is blocked. Receiving servers send you daily aggregate reports about all email claiming to be from your domain. This is the starting point.
• p=quarantine — Suspect email goes to the spam folder. Use this after you have reviewed reports and confirmed legitimate email passes authentication.
• p=reject — Failed email is rejected outright. This is the destination for businesses that send high volumes of transactional email and cannot afford any impersonation risk.

A DMARC record also includes a reporting address where you receive XML-based aggregate reports. These reports are hard to read raw — you need a DMARC analysis tool to make sense of them — but they are the only way to see all the services sending email from your domain, including ones you did not authorise.

Checking your current setup

You can check all three records with a single DNS lookup. Run this command for your domain to see your SPF record:

dig TXT yourdomain.com +short

For DKIM, substitute the correct selector. If you use Google Workspace:

dig TXT google._domainkey.yourdomain.com +short

For DMARC:

dig TXT _dmarc.yourdomain.com +short

Each of these should return a record. If any returns empty or NXDOMAIN, that authentication method is not configured for your domain. Free online tools that send a test email and analyse the headers are the easiest way to check all three at once without touching a terminal.

When you check, pay attention to SPF lookup count. If your SPF record uses many include: statements, validate that the total lookups stay at nine or fewer. An SPF record that silently exceeds the limit is a common reason why email authentication works on paper but fails in practice.

Fixing common issues

If you found problems, here is the fix order.

Start with SPF. List every service that sends email from your domain — your website contact form, your CRM, your newsletter platform, your transactional email service, any third-party booking or invoicing system. Add each one as an include: statement, and if the count passes eight, consolidate by using a single ESP that relays for the others, or move services to fewer providers.

Next, add DKIM for each sending service. Your email provider publishes the public key in its setup documentation. Copy the DNS record exactly as specified — DKIM records are sensitive to spacing and field order. If you manage multiple providers, each gets a different DKIM selector.

Finally, implement DMARC starting at p=none with a reporting address. Monitor the reports for a week. Look for legitimate services sending email that fails authentication — those need SPF or DKIM fixes. Once the failure rate drops below five percent, move to p=quarantine, then p=reject after another two weeks of clean reports.

If you host your domain with us, we configure SPF, DKIM and DMARC as part of the hosting setup. We also monitor DMARC reports for clients on managed plans and flag any unrecognised senders.