Blog · November 2, 2026
Three acronyms come up every time someone tries to explain why business email fails. SPF, DKIM, and DMARC. They are usually presented as a wall of technical detail, which is unfortunate, because the underlying ideas are simple enough to explain to anyone who has ever mailed a letter.
Here is the whole thing in one sentence. SPF says which post offices may send your mail, DKIM puts a wax seal on each letter so it cannot be tampered with, and DMARC tells the recipient what to do when either check fails.
SPF stands for Sender Policy Framework. It is a single line of text in your domain's DNS records that lists the servers permitted to send email on your behalf. When a receiving server gets a message claiming to be from your domain, it looks up that list and checks whether the server that delivered the message is on it.
The list is written as a series of include: statements, each naming a provider. If you use Google Workspace, one include covers Google. If you use Microsoft 365, another covers Microsoft. If your website sends order confirmations through your web host, that host needs an include too. If your booking system sends reminders from its own servers, it needs one as well.
Two limits matter in practice. First, an SPF record can contain at most ten DNS lookups, and each include counts against that. Businesses that have accumulated providers over the years routinely exceed the limit without knowing it, and the failure is silent: the record exists, but receivers cannot evaluate it, so it fails. Second, SPF checks the envelope sender, not the visible From address, which is a technical distinction that becomes important when a third-party tool sends on your behalf. That gap is exactly what DMARC was invented to close.
DKIM stands for DomainKeys Identified Mail. Where SPF is a list, DKIM is a signature. Your mail server signs each outgoing message with a private key, and publishes the matching public key in your DNS. The receiving server uses the public key to verify that the signature is valid and that the message was not altered between sending and delivery.
The practical benefit is that DKIM survives forwarding. This is why it matters more than people expect. When a client forwards your invoice to their accountant, SPF breaks, because the message is now coming from the accountant's mail server rather than yours. DKIM, being attached to the message itself, usually still verifies. A business with strong DKIM and weak SPF will still get its forwarded mail delivered. The reverse is not true.
DKIM keys are identified by a selector, a short name that appears in the DNS record and in the message header. This is why you will sometimes see a record named something like google._domainkey or selector1._domainkey. Different providers use different selectors, and a domain can have several at once, which is normal.
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It does two jobs, and the second one is the reason it exists.
The first job is to set a policy. DMARC requires that a message pass either SPF or DKIM, and critically, that the domain that passed aligns with the domain in the visible From line. This closes the gap SPF leaves open. If a third-party tool passes SPF using its own domain, that does not count as aligned for your domain, and DMARC will fail it. The policy then says what the receiver should do with failing mail: p=none means deliver it anyway, p=quarantine means send it to spam, and p=reject means refuse it outright.
The second job is reporting. When you publish a DMARC record with a reporting address, receivers send you regular XML reports listing every server that sent mail as your domain, how much it sent, and whether it passed. This is the only reliable way to discover that someone is spoofing you, or that a tool you forgot about is sending mail you did not know about.
Most businesses start at p=none, which is a monitoring posture rather than a protection. It is the right place to start, because moving straight to p=reject without knowing what your reports look like can cut off legitimate mail from a system you forgot to authorize. The sequence is to publish p=none, read the reports for a few weeks until everything legitimate is passing, then tighten to quarantine and eventually reject.
Each one covers a gap the others leave. SPF alone breaks on forwarding and does not check the visible sender. DKIM alone does not tell receivers what to do when a signature is missing, and a message with no signature at all simply has nothing to check. DMARC alone does nothing, because it depends on SPF and DKIM to produce a result it can act on.
Together they answer the question a receiving server actually cares about. Can I prove this message came from the domain it claims, and if I cannot, has that domain told me to be strict about it? A domain with all three correctly configured is a domain that is hard to impersonate and easy to trust. A domain with none of them is a domain anyone can forge, and receivers know it.
You do not need to understand the record syntax. You do need to know three things about your own setup. Which systems send email as your domain, whether every one of those systems is authorized in your records, and what your DMARC policy currently says.
That third one is worth checking today, because a surprising number of businesses have a DMARC record that looks like protection and is not. p=none with no reporting address is a record that does nothing at all. It satisfies a checkbox on a vendor questionnaire and provides no actual defense.
The fastest way to see where you stand is to check your domain. It reads your published records and reports what it finds, in plain language, in about ten seconds. If you would rather have someone handle the configuration and keep watching it, that is what our service does.