You sent a client a quote, and two days later they call asking why they never got it. You check their spam folder and there it is. It's not bad luck or a one-off glitch on their end: it's almost always a direct consequence of how the domain you send from is (or isn't) configured.

Gmail, Outlook, and the other major providers rely on three DNS records to decide whether an email is legitimate or gets shipped straight to spam: SPF, DKIM, and DMARC. None of the three is complicated once you break it down, but rarely does anyone sit down to explain them in plain language. Here it is.

SPF: who's allowed to send on your behalf

SPF (Sender Policy Framework) is a list of servers authorized to send email using your domain. It lives as a TXT record in your DNS and basically says "these are the servers allowed to claim they're @yourcompany.com, anyone else is suspicious".

The typical problem: the more services you use (your email provider, your CRM, your invoicing system, your newsletter tool), the more servers you need to add to that list. Forget to add one, and emails sent from it will fail SPF verification and lose trust points with the recipient's spam filter.

DKIM: the digital signature on every email

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every email leaving your domain. The receiving server uses a public key, also published in your DNS, to verify the email really came from where it claims and that nobody tampered with it along the way.

Unlike SPF, which authorizes entire servers, DKIM signs each message individually. That makes it more resilient against forwarding and certain kinds of spoofing, but it also means every service sending on your behalf needs its own correctly configured DKIM key.

DMARC: the policy that ties it together

DMARC (Domain-based Message Authentication, Reporting and Conformance) tells the receiving server what to do when an email fails SPF or DKIM: let it through anyway, send it to spam, or reject it outright. It also sends you periodic reports on who is attempting to send email using your domain, useful both for catching configuration mistakes and for spotting impersonation attempts (phishing using your brand).

Without DMARC, SPF and DKIM work as loose references: they exist, but nobody gives them a clear instruction on what to do when something doesn't add up. It's the piece most SMBs simply don't have configured.

How to check yours right now

You don't need to pay for this. Two free tools are enough:

  • Google Admin Toolbox Check MX: paste your domain and it shows you in seconds whether SPF, DKIM, and DMARC are published, and whether they're well-formed.
  • MXToolbox: besides the three records, it checks whether your domain or sending IP shows up on any blacklist, which also tanks deliverability even when SPF, DKIM, and DMARC are perfect.

Five minutes with either one tells you exactly where you stand.

The mistakes we see over and over

  • Two SPF records on the same domain. The standard only allows one; with two, many servers ignore both or treat the result as invalid. This happens a lot when two different providers (say, your hosting and your CRM) each ask you to "add this SPF", and you end up with two separate TXT lines instead of one combined record.
  • Migrating email providers and forgetting DKIM. When a company moves from Exchange to Google Workspace, or from generic hosting to another provider, it usually updates the MX and SPF records but forgets to publish the new DKIM key. Emails go out unsigned and deliverability drops overnight.
  • Leaving DMARC at p=none forever. p=none is the "just observe" mode: it blocks nothing, it only sends you reports. That's fine as a first step, but staying there indefinitely means you're collecting the information and never acting on it. After reviewing the reports for a few weeks and confirming everything legitimate passes, it's worth moving up to p=quarantine and eventually p=reject.

What changes when you move to Google Workspace

Moving from generic hosting-based email to Google Workspace is generally a deliverability upgrade: Google maintains a far stronger infrastructure reputation than most shared hosting providers. But the migration doesn't fix SPF, DKIM, and DMARC on its own. You need to publish the SPF record that includes Google's servers, generate and publish the Workspace-specific DKIM key, and review whether your DMARC policy still matches the new sending setup, especially if you keep using other tools (invoicing, CRM, marketing) that send on behalf of the same domain.

It's exactly the kind of work that tends to get left half-finished: someone activates the new mailboxes, imports the old mail, and assumes the rest "was already configured". Our sister team at TecnoMagallanes builds the Google Workspace setup with SPF, DKIM, and DMARC as part of the same migration process, so it doesn't depend on someone remembering later.

The part you don't see, until you do

SPF, DKIM, and DMARC don't have a nice screen or a dashboard you check every day. They work well when nobody notices: emails arrive, nobody asks, nobody complains. The catch is they're almost always discovered misconfigured only after they've already cost a lost quote or a client who got tired of asking "did you send me something?". Ten minutes with Check MX or MXToolbox today is worth more than the next invoice that lands in spam.