Your emails shouldn’t be going to spam

If you run a business on your own domain and you’ve ever opened an email inbox to find your messages sitting in a prospect’s spam folder, you know the cost. Missed replies. Lost invoices. Trust that evaporates before anyone reads your subject line.

The problem is rarely your copy or your offer. It’s almost always three text records hiding in your DNS settings that nobody told you existed: SPF, DKIM and DMARC.

These aren’t optional security luxuries. They’re the minimum identity credentials every business domain needs so that Gmail, Outlook and every other mail provider can verify you are who you say you are. Set them up correctly and your deliverability improves. Skip them and you’re asking major providers to guess whether your mail is legitimate — they will guess wrong, consistently.

What each record actually does

Think of email authentication as a three-layer ID check.

SPF (Sender Policy Framework) is the simplest layer. It’s a DNS TXT record that lists which mail servers are allowed to send on behalf of your domain. If a receiving server sees mail arriving from an IP not on your list, it knows something is off. SPF protects against casual spoofing — someone typing your domain into the “From” field and hitting send.

DKIM (DomainKeys Identified Mail) is the content layer. Every email you send gets a digital signature attached to it. The receiving server checks that signature against a public key you publish in DNS. If the message was altered in transit — by a hacker, a forwarding service, or a glitchy relay — the signature breaks and the receiver knows the email didn’t come from you intact. DKIM proves the message itself is authentic, not just the server it arrived from.

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy layer. It tells receiving servers what to do when an email fails SPF or DKIM, and it requires alignment — the domain in the visible From: address must match the domain that passed SPF or DKIM verification. DMARC also sends you reports so you can see who is sending mail using your domain, even if they shouldn’t be. It turns a blind spot into visibility.

Taken together, a correct SPF-DKIM-DMARC setup blocks easy spoofing, reduces phishing risk against your brand, and gives you daily insight into who is using your domain. That last point matters more than most founders realize.

Before you touch DNS, do this inventory step

This is the step everyone skips and then spends hours debugging. List every system that sends email on your behalf:

  • Your primary workspace (Google Workspace or Microsoft 365)
  • Your website contact forms and transactional mail
  • Marketing platforms like Loops.so or Klaviyo
  • CRM systems
  • Help desk or support tools
  • Invoicing and payment platforms
  • Scanners, phone systems, or any IoT device that emails notifications
  • Any subdomains you own (billing.yourdomain.com, status.yourdomain.com)

If you skip even one of these during your setup, you’ll either leave a security gap or — worse — accidentally block legitimate mail when you flip your DMARC policy to enforcement mode. The inventory takes twenty minutes and prevents two days of panic later.

How the three controls work together

SPF validates the path the mail took. DKIM validates the content inside it. DMARC requires that the visible From: domain aligns with whichever of those two checks passed. Both SPF and DKIM can pass independently, but DMARC cares about whether the identity the recipient sees matches the identity that was actually authenticated.

If both SPF and DKIM fail, or if they pass but are misaligned with the From: header, DMARC applies whatever policy you’ve published. That’s how you decide whether suspicious mail goes to spam, stays in the inbox flagged, or is rejected outright.

The setup order matters — and it’s not what you might expect

You must configure SPF and DKIM before you publish a DMARC record. DMARC references both of them, so having them in place first prevents your policy from breaking mail that was already flowing.

Step 1: Start with SPF

Locate your DNS management console — this is wherever you bought your domain or manage your nameservers. Look for existing TXT records. If an SPF record already exists, you’ll edit it. If not, you’ll create one.

The SPF record declares which servers may send for your domain. Most email platforms will give you the exact values to paste. If you’re using a shared sending domain through your marketing platform, SPF authentication may already be handled automatically. With a branded sending domain, you’ll need to publish the records the platform generates during setup.

The critical part is the qualifier at the end. A record ending in ~all means softfail — mail from unauthorized servers goes to spam but isn’t rejected. A record ending in -all means hardfail — those messages are rejected. Start with ~all, verify everything works, then move to -all only when you’re confident your sender list is complete.

Step 2: Add DKIM

Your email platform will generate a DKIM public key and tell you the exact DNS record to publish. Copy the values and add them to your DNS. Some platforms generate multiple keys for different selector names — publish all of them if asked.

DKIM keys rotate. When your platform rotates a key, you’ll need to publish the new one while keeping the old one active long enough for the change to propagate. Don’t remove the old key until the new one is confirmed working.

Step 3: Publish DMARC — carefully

This is where most founders make a costly mistake. DMARC has three policy modes:

  • p=none — gather mode. Failing emails are treated normally, but you receive reports.
  • p=quarantine — failing emails go to spam.
  • p=reject — failing emails are blocked entirely.

Start with p=none. This gives you visibility without risking lost mail. Publish the record and wait. Review the reports your platform provides — or sign up for a dedicated DMARC monitoring service, because most email platforms don’t include robust DMARC reporting. You need to see who is sending mail as your domain before you start enforcing anything.

Once you’ve reviewed the reports and confirmed nothing legitimate is failing authentication, move to p=quarantine. After another review period, if everything looks clean, you can escalate to p=reject.

Going straight to p=reject without seeing the reports first is how legitimate customer receipts, password resets and partner communications get blocked. The incremental approach costs you nothing and saves you from support tickets that could have been avoided.

Step 4: Verify and monitor

After publishing each record, use a DNS lookup tool or your platform’s deliverability dashboard to confirm the records are live and correctly formatted. SPF, DKIM and DMARC records can look right in your DNS console but fail validation if there’s a typo, a missing character, or a conflict with an existing record.

Check back after 24 to 48 hours — DNS propagation isn’t instant, and some records take longer to reach all resolvers.

Common mistakes that send valid mail to spam

Even with all three records in place, mail can still land in spam. Here are the ones that surprise founders most.

Multiple SPF records. You can have only one SPF record per domain. If you accidentally create two — maybe one through your workspace provider and another through a marketing tool — SPF validation fails entirely and your mail gets tagged as unauthenticated. Check for duplicate SPF records regularly.

Forgetting subdomains. SPF, DKIM and DMARC apply per domain. If you send from newsletter.yourdomain.com but only configured records for yourdomain.com, the subdomain is unprotected. Map your subdomains and configure authentication for each one that sends mail.

DMARC alignment gaps. Your visible From: address and your SPF or DKIM authenticated domains need to align. If your marketing platform sends mail from mail.platform.com but your From: says you@yourdomain.com, the DMARC check can fail even when both SPF and DKIM pass. Most platforms offer authenticated sending domains or dedicated subdomains to solve this — use them.

Not monitoring after setup. Publishing the records is the easy part. The ongoing work is watching the reports. Spam filters change, your sending infrastructure changes, and third-party apps get added or removed. Without monitoring, you won’t know when your configuration drifts from what’s actually working.

What this saves you

A proper SPF-DKIM-DMARC setup is not a one-time chore. It’s ongoing visibility into your domain’s email reputation. But the return is immediate and measurable: fewer support requests about missing emails, higher inbox placement rates, and a domain that’s harder for attackers to impersonate.

For a solo founder managing everything from invoicing to customer onboarding, the time invested in getting these records right pays for itself in recovered replies and prevented phishing incidents. The alternative — assuming your domain is fine because it seems to work — is a gamble that major email providers are steadily making less viable every day.

FAQ

Do I need all three records, or is DMARC enough? No. DMARC depends on SPF and DKIM being present and passing. Without them, DMARC has nothing to enforce and reports will be empty. Set up all three, in the recommended order.

My marketing platform says authentication is automatic. Should I still check? Shared sending domains handle SPF automatically, but branded domains usually require you to publish records yourself. Log into your DNS console and verify that SPF, DKIM and DMARC records exist for your domain. Don’t assume.

How long does setup take? Reading and inventorying your senders: about 20 minutes. Publishing SPF and DKIM records: 10 to 15 minutes. Waiting for DNS propagation and reviewing DMARC reports before enforcing: 24 to 72 hours. Total hands-on time is under an hour; the rest is waiting and verifying.

What happens if I set DMARC to reject too early? Legitimate mail from any sender you forgot to list — a partner’s automated system, a legacy scanner, a subdomain you didn’t inventory — will be blocked. Recipients won’t get your emails, and you won’t know why unless you’re monitoring reports. That’s why the none-to-quarantine-to-reject progression matters.

Can I use a tool instead of managing DNS myself? Yes. Several services specialize in DMARC monitoring and reporting, making the ongoing visibility part much easier. They won’t replace the DNS records themselves, but they handle the reports and alerting so you don’t have to decode raw DMARC XML files. Whether a monitoring service is worth the cost depends on how many sending domains you manage and how much time you want to save on ongoing verification.

Sources