SPF, DKIM, and DMARC Explained - Why Your Emails Go to Spam

The Three Records That Control Your Email Reputation

If your legitimate business emails are landing in spam, or if someone is spoofing your domain to send phishing emails, the root cause is almost always a missing or misconfigured SPF, DKIM, or DMARC record. These three DNS records form a chain of email authentication that receiving mail servers use to decide whether to trust email that claims to come from your domain.

Understanding what each one does - and what the different values actually mean - is practical knowledge for anyone who runs a business with a custom domain.

SPF - Who Is Allowed to Send Email From Your Domain

SPF (Sender Policy Framework) is a TXT record that lists the mail servers authorized to send email on behalf of your domain. When a mail server receives an email claiming to be from you@yourcompany.com, it looks up your domain's SPF record and checks: is the sending server on the approved list?

A basic SPF record looks like this: v=spf1 include:_spf.google.com ~all. Breaking this down:

• v=spf1 - identifies this as an SPF record
• include:_spf.google.com - authorizes Google's mail servers (for Google Workspace users)
• ~all - the "all" mechanism defines what to do with email from servers not on the list

The "all" qualifier is where many people get confused:

• -all - hard fail: reject email from unauthorized servers. The strictest option.
• ~all - soft fail: accept but mark suspicious email. The most common setting.
• ?all - neutral: no policy. Provides no protection and is effectively useless.
• +all - pass everything. Never use this - it authorizes anyone to send as you.

If you send email from multiple services (your mail host, plus a CRM, plus a transactional email provider like SendGrid or Postmark), each needs to be included in your SPF record. A common mistake is adding a new service and forgetting to update SPF - emails from that service then fail authentication.

DKIM - Cryptographic Proof That Email Wasn't Tampered With

DKIM (DomainKeys Identified Mail) uses a public/private key pair to sign outgoing emails. Your mail server signs each outgoing email with a private key. The receiving mail server looks up your public key (stored as a TXT record in your DNS) and verifies the signature. If the email was altered in transit - even by a single character - the signature fails.

You will not write a DKIM record by hand. Your email provider generates the key pair and gives you a TXT record to add to your DNS. For Google Workspace, you go to the Admin Console, generate a key, and add the resulting TXT record at a subdomain like google._domainkey.yourdomain.com.

DKIM does two things: it proves the email came from your domain's mail infrastructure, and it proves the email content was not modified after it was sent. This is why DKIM is important even if SPF is passing - a spammer who routes email through your server would pass SPF but fail DKIM.

DMARC - The Policy That Ties It Together

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a policy record that tells receiving mail servers what to do when email fails SPF or DKIM - and asks them to report back to you about what they see.

A DMARC record lives at _dmarc.yourdomain.com as a TXT record. A typical record looks like: v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100

The p= tag is the policy:

• p=none - monitor only. Take no action on failures, just collect reports. Use this when you first set up DMARC to understand your email traffic before enforcing anything.
• p=quarantine - send failing email to spam. Not rejected, but flagged. This is the most common production setting.
• p=reject - reject failing email outright. The strictest option. Only use this once you are confident all your legitimate email is passing DMARC.

The rua= tag specifies where aggregate reports should be sent. These reports show you which servers are sending email that claims to be from your domain - which is how you discover if someone is spoofing you.

How They Work Together

For DMARC to pass, the email needs to pass either SPF or DKIM - and the domain in the From header needs to align with the domain that passed. This alignment requirement is what makes DMARC actually effective at preventing spoofing, rather than just checking individual records in isolation.

A common failure scenario: a company sets up SPF and DKIM for their primary mail server but not for their marketing email platform. The marketing emails pass through the platform's servers, the SPF record for the platform is not in the company's DNS, and DMARC fails - even though the emails are legitimate. This is why checking all your email sending sources is essential before moving DMARC to p=reject.

How to Check If Your Records Are Correct

The Queldrex Email Deliverability Checker looks up your SPF, DKIM, and DMARC records and flags anything missing or misconfigured. It checks whether your DMARC policy actually enforces anything (p=none does not), whether your SPF record has syntax errors, and whether DKIM records are present for common selectors. Enter your domain and you get a pass/fail breakdown in seconds.

If you find issues: SPF and DMARC are straightforward to add yourself through your DNS provider's dashboard. DKIM setup requires working with your email provider's admin console - Google Workspace, Microsoft 365, and most major email platforms have step-by-step guides for generating and deploying DKIM keys.