SPF, DKIM and DMARC: why your emails land in spam

You spent weeks writing the perfect newsletter. You sent it to 5,000 contacts. You opened the report the next day: 62% delivery rate. The rest went to spam — or never arrived.

The fault is rarely the content. It's three acronyms you probably didn't configure right: SPF, DKIM and DMARC.

The problem these acronyms solve

Email is a protocol from the 1980s. When it was created, any server could send a message claiming to be anyone. Right now I can configure an SMTP server and send an email with From: president@gov.br — the protocol doesn't stop it.

For 40 years, that was the entry point for phishing, spam and corporate fraud. SPF, DKIM and DMARC are the three layers the industry added so the receiving server can verify that the email really came from who it claims.

Whoever doesn't have these three configured today is treated as suspicious by default. Gmail and Yahoo, since February 2024, require all three for senders with volume.

SPF — "who may send email in my name"

SPF (Sender Policy Framework) is a DNS record listing the servers authorized to send email with your domain in the From.

Typical look:

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

Reads as: "emails from my domain may come from Google Workspace OR SendGrid. Any other server, mark as suspicious (~all = softfail)."

What goes wrong:

• The 10 DNS lookup limit (RFC 7208 §4.6.4). Each include: counts. If you have include:_spf.google.com include:sendgrid.net include:mailchimp.com include:mailgun.org include:_spf.mandrillapp.com… you've probably already blown the limit. Result: all SPF validation returns permerror and the email goes to spam.
• +all at the end — means "any server may send in my name". It's like leaving the door open. Never use it.
• Forgetting a service. You sent the invoice via a new system, forgot to add it to SPF, and the invoice went to the customer's spam. It happens.

DKIM — "this email wasn't altered in transit"

DKIM (DomainKeys Identified Mail) signs each sent email with a cryptographic key. The receiving server queries DNS, gets the matching public key, and verifies the signature.

If they match, two facts are proven:

1. The email really came from whoever has the private key (the authorized server).
2. The content wasn't modified in transit.

What goes wrong:

• Not configuring it. The sending service generates the keys, but you need to add the DNS record (a TXT record at selector._domainkey.yourdomain.com). Without it, there's no DKIM.
• Wrong selector. Each provider uses a different name: Google uses google, SendGrid uses s1/s2, Mailchimp uses k1/k2. Configure the wrong selector, DKIM fails.
• Weak key. 1024-bit DKIM keys are still accepted but the industry asks for 2048+.

DMARC — "what to do when SPF or DKIM fails"

SPF and DKIM say "this email is legitimate" or "this email is suspicious". But who decides what to do with the suspicious one? Without DMARC, each provider decides its own way.

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy. You say in DNS:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; pct=100

Reads as: "if SPF and DKIM fail, reject the email. And send me a weekly report on who's trying to impersonate me."

The three policy modes:

• p=none — only monitors, does nothing. Use it at the start.
• p=quarantine — sends to spam when it fails.
• p=reject — blocks entirely.

What goes wrong:

• Jumping straight to p=reject without monitoring. You find out that your own HR tool or internal system sent with your domain and never passed SPF/DKIM. Suddenly no employee gets their payslip by email. Always start at p=none, read the reports for 2-4 weeks, then move up.
• Not publishing DMARC. Gmail and Yahoo now require at least p=none for senders with volume. Without DMARC, your deliverability slowly collapses.
• Lack of alignment. The From: must match the domain signed by DKIM and/or authorized by SPF. If you send as marketing@yourdomain.com but SPF authorizes mail.third-party-service.com, there's no alignment and DMARC fails.

How to check now

You can check manually:

dig +short TXT yourdomain.com | grep spf
dig +short TXT _dmarc.yourdomain.com
dig +short TXT google._domainkey.yourdomain.com   # or the selector you use

But for a continuous diagnosis — because DNS changes, new services are added, and DKIM can be disabled in key rotation — the ideal is to monitor from outside.

What Sentinela checks

Sentinela's Email probe analyzes, in every audit:

• SPF exists? How many DNS lookups does it consume? Is it near or above the limit of 10? Does it have +all? Does it have multiple records (which violates the RFC)?
• DKIM — tests common selectors (default, google, selector1, selector2, k1, k2, s1, s2, mail, etc.). Reports which exist, key size, whether it's revoked.
• DMARC is published? At which policy (none, quarantine, reject)? Does it have rua configured to receive reports?
• MX points to valid, responsive servers?
• DNSSEC is enabled for the domain?

The result goes into an audit PDF with a severity per finding (critical/high/medium/low/info) — exactly the kind of document your IT team or your client will want to see.

Create a free account and run the first audit in under 1 minute. You find out right away if your deliverability is compromised — before spending the next campaign.

The simple rule

If you send email from your domain — newsletter, transactional, support, anything — you need all three configured. It's no longer optional. Big providers (Gmail, Outlook, Yahoo, iCloud) already treat it as mandatory, and that will only tighten.

The good news: configure it once correctly, monitor periodically, and it lasts years. The bad: most companies configured half of it, two years ago, and nobody looks anymore. Look today.