SPF, DKIM, and DMARC are three DNS records that prove your email really comes from your company. They matter in both directions: they stop criminals from sending mail as your exact domain, and since 2024 they decide whether your own mail reaches the inbox, because Google and Yahoo now filter unauthenticated senders into spam.

The problem they fix is as old as email itself. Email was designed in the 1980s, when the internet was a few thousand researchers who trusted each other, and verification was never built in. By default, anyone can send a message that displays your exact domain and your exact name, and the recipient’s mail app will show it just as confidently as the real thing.

The three records retrofit the missing verification. Each is a small text entry attached to your domain, and together they let the receiving mail server answer one question: did this message really come from the company it claims to come from? The rest of this guide covers what each record does and what a properly configured domain looks like.

The problem they solve

Email fraud built on impersonation is not a niche threat. The FBI’s Internet Crime Complaint Center has tracked business email compromise, meaning attacks where someone poses as an executive, a vendor, or a payroll contact, as one of the costliest categories of cybercrime for years, with reported losses in the billions annually.

The playbook is simple. An attacker sends your bookkeeper an email that appears to come from you: “Please update the wire details for this vendor before Friday.” There is no malware and no suspicious link, just a convincing message from a trusted name. Authentication records are what make that message fail verification and land in spam instead of an inbox.

SPF: the approved-senders list

SPF (Sender Policy Framework) is a list, published in your DNS, of the servers allowed to send email for your domain. Think of it as the guest list at the door: when a message arrives claiming to be from your domain, the receiving server checks whether the server that sent it is on your list.

Your list typically includes your email provider (Microsoft 365, Google Workspace) plus every third-party service that sends as you: your CRM, your invoicing software, your marketing platform. Anything not on the list fails the check.

The most common SPF problems we see are records that were set up once and never maintained: a marketing tool added two years ago that nobody authorized, or an old provider still listed long after the company moved on.

DKIM: the tamper-proof seal

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every message you send. The receiving server checks the signature against a public key published in your DNS. If the message was altered in transit, or the signature does not match your domain, the check fails.

If SPF is the guest list, DKIM is the wax seal on the envelope: it proves the message genuinely originated from your systems and arrived unmodified. It also survives forwarding better than SPF does, which is why the two are used together rather than either alone.

DMARC: the policy and the paper trail

SPF and DKIM verify. DMARC (Domain-based Message Authentication, Reporting and Conformance) decides what happens next. It is a policy you publish that tells receiving servers what to do with mail that fails verification:

  • p=none: deliver it anyway, but send me reports (monitor mode)
  • p=quarantine: send it to spam
  • p=reject: refuse it entirely

The reporting is the underrated part. DMARC reports show you every server on the internet sending email as your domain, including the ones you did not know about. That is how you discover both the forgotten marketing tool and the attacker in another country using your name.

A domain without DMARC, or one left permanently at p=none, has effectively told the world’s mail servers: “if verification fails, deliver it anyway.” Most of the value arrives when you enforce quarantine or reject.

Why this stopped being optional

For years, authentication was a best practice that mostly diligent companies bothered with. Two things changed that.

Mailbox providers now require it. In early 2024, Google and Yahoo began enforcing authentication requirements for senders: SPF and DKIM at minimum, and DMARC for anyone sending in volume. Microsoft has followed the same direction for Outlook. This is not just about spam senders; it applies to ordinary business email. Unauthenticated mail is increasingly filtered or refused, which means missed invoices, missed quotes, and missed replies that nobody ever tells you about.

Insurers and auditors ask about it. Cyber-insurance questionnaires and security frameworks now routinely include email authentication. A domain with no DMARC policy is an easy red flag, and one of the cheapest ones to fix.

What a well-configured domain looks like

The end state is straightforward to describe:

  1. SPF lists exactly the services that send as you, with nothing missing and nothing stale.
  2. DKIM signing is enabled for your mail provider and every third-party sender.
  3. DMARC is published and enforcing (quarantine or reject, not monitor-only), with reports going somewhere a human, a monitoring service, or your IT partner actually reviews.

Getting there is a staged rollout, not a single change: publish DMARC in monitor mode, watch the reports for a few weeks, authorize every legitimate sender you find, then tighten the policy. Done in that order, nothing legitimate breaks. Done impatiently, you block your own invoices, which is why this is worth doing carefully.

For Microsoft 365 businesses, this is part of the broader tenant hardening we cover in our Microsoft 365 service: authentication records, anti-phishing policies, and the settings Microsoft leaves loose by default.

How to check where you stand

You do not need to take anyone’s word for this. Free tools like MXToolbox will show you in seconds whether your domain publishes SPF, DKIM, and DMARC records and what your DMARC policy is. If the answer is “no DMARC” or “p=none since 2022,” you now know exactly what that means.

And if you would rather have it reviewed and fixed properly, including the monitoring phase and the third-party senders, that is a small, well-defined project. Get in touch and we will tell you where your domain stands.