You buy a domain, hook up email, send a few cold emails or invoices…and Gmail quietly drops them into spam. Nothing looks obviously broken, but prospects don’t reply and clients say “your email never arrived”.
In most cases, this isn’t about copy, volume, or some mysterious “deliverability score”. It’s because your domain isn’t properly authenticated with SPF, DKIM and DMARC – the three basic protocols inbox providers use to decide whether to trust you or treat you like a spammer.
This article breaks those three down in plain language so you can sanity-check your setup, talk clearly to your DNS/IT person, and avoid painful deliverability issues as a small business or agency.
The 5-minute mental model: email delivery vs authentication
Before the acronyms, separate two ideas:
- Email delivery: Can your message technically be delivered from server A to inbox B?
- Email authentication: Can the receiving inbox prove that the message really came from your domain and wasn’t tampered with on the way?
You can have perfect delivery (no hard bounces) and still fail authentication, which leads to:
- Emails going to spam or “Promotions” instead of the inbox
- “via some-random-server.com” showing in Gmail
- Warning banners like “Be careful with this message” or “Sender failed authentication”
SPF, DKIM and DMARC are simply three layers that help inboxes answer:
- Who is allowed to send as this domain? (SPF)
- Was this exact message tampered with? (DKIM)
- If checks fail, what should we do with the email, and who should we report to? (DMARC)
What is SPF?
SPF (Sender Policy Framework) is a DNS record that lists which servers are allowed to send email for your domain.
In founder terms: SPF is your “approved sender list” published publicly in DNS. When Gmail or Outlook receive an email claiming to be from you, they ask your domain’s SPF record: “Is this sending server on the list?”
If yes, SPF can pass. If not, SPF can fail and the message is more likely to be rejected or filtered as spam.
Why SPF matters
- Reduces spoofing: Makes it harder for attackers to send fake emails pretending to be your domain.
- Helps inbox trust: Passing SPF contributes to domain reputation and improves your chances of landing in the inbox.
- Basic hygiene: Almost every modern mail provider expects an SPF record today.
Common SPF failure patterns
In practice, small businesses often run into SPF issues because of:
- Adding multiple SPF records instead of a single, combined one
- Forgetting to include third-party senders (CRMs, marketing tools, billing systems)
- Copy-pasting vendor examples that conflict or exceed DNS lookup limits
- Changing email providers and never updating the SPF record
“Emails rejected due to SPF” or “SPF softfail” errors typically trace back to one of those email configuration problems.
What is DKIM?
DKIM (DomainKeys Identified Mail) is a cryptographic signature added to each outgoing message. Think of it as a tamper-evident seal on a physical letter:
- Your sending service signs the email with a private key.
- The receiving server looks up your public key in DNS and checks that the signature still matches.
If the message content or certain headers were changed in transit, the DKIM signature no longer matches and DKIM fails.
Why DKIM matters
- Confirms message integrity: Proves the content wasn’t altered after it left your provider.
- Strengthens your identity: Ties the email to a domain that takes responsibility for it.
- Important for marketing & bulk senders: Many inbox providers give extra weight to DKIM for newsletters, campaigns and transactional volumes.
Because DKIM relies on both your provider settings and DNS, it tends to break when domains are migrated, aliases are added, or mail is routed through different tools (e.g. sending from Gmail web vs Outlook using the same account).
What is DMARC?
DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of SPF and DKIM. It does two big things:
- Alignment: Checks that the domain that passed SPF or DKIM aligns with the visible From: domain the user sees.
- Policy: Tells receivers what to do with email that fails those checks (do nothing, quarantine, or reject) and where to send reports.
So DMARC is your set of instructions to inbox providers: “If an email pretends to be from my domain but fails authentication or doesn’t align, here’s how hard I want you to be on it – and please send me the logs.”
Why DMARC matters
- Strong spoofing protection: When you move to a strict policy, it becomes very hard for attackers to abuse your domain at scale.
- Better visibility: DMARC reports show which services are sending as you, which helps catch misconfigurations and unauthorized senders.
- Signal of maturity: Many large providers treat properly configured DMARC as a sign you take security seriously.
Do small businesses need DMARC? In practice, yes, but it doesn’t have to be aggressive from day one. Many start with a monitoring-only policy (p=none) while they clean up SPF and DKIM, then move to quarantine or reject.
What different SPF, DKIM and DMARC records actually look like
If your’re wondering, “What does a good record even look like?”, here are common variations and what they practically change for your email.
SPF record examples
| SPF record example | Meaning | Practical impact |
|---|---|---|
v=spf1 include:spf.your-provider.com ~all | Authorizes whatever hosts your provider publishes in its SPF record; ~all = soft fail for everything else. | Balanced starting point for small businesses; non‑authorized senders are usually accepted but treated as suspicious or lower trust by many providers. |
v=spf1 ip4:203.0.113.10 include:spf.your-provider.com -all | Only the listed IP and the provider’s SPF hosts are authorized; -all = hard fail for everything else. | Stronger protection against direct spoofing if DNS is correct; mail from forgotten or misconfigured senders is more likely to be rejected or spam‑folded. |
v=spf1 include:spf.service1.com include:spf.service2.com include:spf.service3.com include:spf.service4.com … ~all | Tries to authorize multiple third‑party services via many include: mechanisms. | Easy to hit SPF’s 10‑DNS‑lookup limit, causing “PermError” and making SPF effectively fail or be ignored, which leads to inconsistent delivery while you think SPF is configured. |
Practical takeaway:
Aim for one clean SPF record, only the senders you actually use, and avoid copy‑pasting includes you don’t need.
DKIM record examples
| DKIM DNS pattern | Meaning | Practical impact |
|---|---|---|
selector1._domainkey.yourdomain.com CNAME selector1.yourprovider.net. | Delegates DKIM to your provider; their DNS hosts the TXT record with the public key and they rotate/manage keys. | Very low‑maintenance and ideal for ESPs (SES, SendGrid, Mailchimp, etc.); if you later move away and forget to remove it, the old service can technically still sign mail for your domain with that selector. |
s1._domainkey.yourdomain.com and s2._domainkey.yourdomain.com (each as TXT or CNAME) | Uses multiple selectors so different systems (primary mailboxes, app/transactional, marketing) can sign independently. | Healthy pattern for larger setups; lets you rotate or revoke keys for one sender without touching others, and makes for cleaner key management over time. |
Selector exists but tools show dkim=fail or dkim=none | DNS selector doesn’t match what the provider is actually using, or the TXT value was truncated/altered by the DNS UI. | DKIM stops contributing to DMARC; DMARC may fall back to SPF only, and if your policy expects aligned DKIM more messages can be quarantined or rejected. |
Practical takeaway:
Keep DKIM provider‑managed where possible, verify selectors after changes, and remove old keys when you retire a service.
DMARC policy variations
| DMARC record example | Meaning | Practical impact |
|---|---|---|
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; | Monitoring‑only mode: ask receivers to send aggregate reports but do not change delivery based on DMARC yet. | No real spoofing protection; fraudulent mail can still reach inboxes, but you get data on who is sending as your domain and how often they pass SPF/DKIM. Ideal starting point. |
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=50; | Tell receivers to quarantine (usually spam-folder) about half of the messages that fail DMARC; pct lets you phase enforcement in. | Noticeably cuts down successful spoofing while still letting you see some failures in spam to fine‑tune configuration; good “transition” mode before full enforcement. |
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; pct=100; | Instruct receivers to reject messages that fail DMARC checks for all traffic. | Strongest protection against direct domain spoofing; any legitimate sender that isn’t correctly authenticated/aligned is likely to hard bounce until fixed. |
aspf=r; adkim=r | Relaxed alignment: subdomains and related domains can count as “aligned” with the visible From: domain. | More forgiving when you have multiple subdomains or slightly different sending domains, but leaves a bit more room for abuse if naming isn’t tightly controlled. |
aspf=s; adkim=s | Strict alignment: SPF/DKIM domains must match the From: domain exactly to count as aligned. | Smaller attack surface and clearer relationships, but can cause more alignment failures if legitimate senders use neighboring domains or subdomains you haven’t fully standardized. |
Practical takeaway:
Most small businesses should move from p=none to p=quarantine to p=reject over time, while watching reports and fixing legitimate senders along the way.
What we see in practice
Working with small businesses and agencies, a few patterns repeat over and over:
- Works for some, fails for others: Emails to Gmail pass, but Outlook shows authentication errors, or vice versa. This often comes down to slightly different implementations and stricter checks by some providers.
- Everything passes, still in spam: SPF, DKIM, DMARC all show PASS in tools, but deliverability is poor. In these cases, authentication is necessary but not sufficient – content, engagement, sending history and list quality still matter.
- Partial protection: SPF and DKIM are configured on the primary email provider, but not on the CRM, newsletter tool, or billing system that also send as the same domain. Those unauthenticated sources quietly drag down reputation.
- Forgotten DNS after vendor changes: A team switches from one email platform to another and never removes old SPF includes or updates DKIM keys. Over time, this leads to SPF bloat and inconsistent results.
In practice, small businesses that slow down and properly align all their senders – mailbox provider, marketing tool, transactional email, helpdesk – see far more stable inbox placement over the long term.
With Greenmor Mail, the goal is to keep that surface area simpler: fewer moving parts, clearer DNS guidance, and defaults that push you toward authenticated sending instead of “it kind of works until it doesn’t”.
Modern spoofing: when everything “passes” and attacks still work
SPF, DKIM and DMARC mainly stop attackers from sending mail as your domain from unauthorized servers, not from abusing real accounts on legitimate infrastructure.
A recent case involved scam emails sent from real @google.com mailboxes through the Gmail API: SPF passed, DKIM was signed by Google, and DMARC with p=reject still passed. From the receiver’s perspective, everything looked authentic because the mail flowed through Google’s normal servers, used Google’s real signing domain, and aligned perfectly with the visible From address. This isn’t classic spoofing; it’s abuse of legitimate access to a real mailbox.
In practice, that level of abuse usually comes from compromised credentials, stolen OAuth tokens (“send mail as X” permissions), or third‑party tools that have been granted API access and are then misused. Once an attacker can send from an actual account using the official API, your authentication checks can’t distinguish them from a real employee.
For small businesses, you can’t fully prevent what big providers face, but you can narrow your own risk:
- Lock down account access (MFA on every mailbox, review and revoke unused app/OAuth permissions).
- Limit who and what can send as sensitive identities.
- Watch behavior, not just records (spikes in volume, strange destinations, unusual “Sent” content).
- Make it normal to verify high‑risk requests (money, credentials, access) via a second channel before acting.
A practical way to wrap all of this is: don’t just configure SPF, DKIM and DMARC and assume you’re done. Actually test how your domain looks from the outside. Running your domain through a tool like learndmarc.com shows, step by step, which server is talking to which domain, how SPF, DKIM and DMARC are evaluated, and whether alignment really works the way you think. Building a habit of sending test emails and reviewing those reports is one of the simplest ways a non‑technical founder can catch configuration mistakes early and spot patterns that don’t look right.