Business Email That Reaches the Inbox

The failure mode that costs the most

A contractor sends invoices at the end of the month from an address at their own domain. Some are paid. Several are not, and those customers are not avoiding the bill: they never received it. The message was accepted and filed straight into spam, or rejected and bounced to a mailbox nobody reads. Weeks later, chasing the money, the contractor finds a pattern.

Nothing in that sequence produced an error message. Email authentication does not fail loudly. It fails as customers who did not respond, quotes that went nowhere, and a slow suspicion that business is quieter than it used to be.

Behind it are three DNS records most small businesses have never looked at: SPF, DKIM and DMARC. Together they let a receiving mail server answer one question - was this message, claiming to be from your domain, actually authorized by you? When the records are right, your mail is trusted and forgeries are rejected. When they are wrong, half-configured, or still set up for a provider you left two years ago, your own mail is what looks suspicious.

All three are free and none requires new software. What they require is somebody setting them up for every service that sends email on your behalf, and that is where it falls apart.

SPF: which machines are allowed to send as you

SPF stands for Sender Policy Framework, specified in RFC 7208. It is a single text record published in your domain's DNS listing the servers permitted to send mail for your domain. A receiving server looks it up and asks: did this message arrive from a machine on the list?

Two details cause most of the real trouble. First, SPF checks the envelope sender, not the From line the human reads. Email carries two sender addresses - the one used during delivery and the one shown in the mail program - and SPF checks the delivery one. That gap is exactly why SPF alone was never enough and why DMARC exists.

Second, SPF breaks on forwarding by design. If a customer forwards your message, or a mailing list relays it, it arrives from a machine you never authorized and the check fails. That is a known limitation, not a mistake in your setup.

Two ways the record goes wrong are easy to create and hard to notice. There must be exactly one SPF record on a domain, so pasting in a second one for a new service rather than merging it produces a permanent error and every check fails at once. And SPF has a hard limit of ten DNS lookups; a business that has added entries for its mail provider, newsletter tool, accounting software, booking system and customer database can quietly exceed that ceiling, at which point the record protects nothing.

DKIM: a signature that proves the message was not altered

DKIM stands for DomainKeys Identified Mail, specified in RFC 6376. Where SPF is a list of addresses, DKIM is a cryptographic signature. Your sending provider holds a private key and signs each outgoing message with it; the matching public key is published in your DNS under a name combining a selector chosen by the provider with your domain. The receiving server fetches that key and verifies the signature.

What a valid signature proves is narrow but useful: the message really was signed by something holding the key for that domain, and the signed parts have not been altered in transit. Because that proof travels inside the message rather than depending on which machine delivered it, DKIM survives forwarding where SPF does not. The two are complementary rather than redundant, which is why the advice is to have both.

The characteristic DKIM failure happens during a move. A provider rotates its signing key, or you migrate providers, and the DNS record holding the public key is not updated to match. Signatures then fail for every message you send, and with no bounce and no warning the damage accumulates for weeks. Anyone who has changed providers, hosts or nameservers should check that the DKIM record still matches.

DMARC: what to do when the first two disagree

DMARC is the layer that makes the other two meaningful to a human reader, and it does two things.

The first is alignment. SPF checks the delivery sender and DKIM checks a signing domain, and neither necessarily matches the address a person sees. DMARC requires that a passing SPF or DKIM result correspond to the visible From address. Without alignment, a forger can pass SPF for a domain they control while displaying your name.

The second is a published policy telling receiving servers what to do with mail claiming to be from you that passes neither aligned check. Three settings: none, take no action but send reports; quarantine, treat it as spam; reject, refuse it at the door. The record also requests aggregate reports showing who has been sending as your domain - the whole point of starting at none.

DMARC is worth dating precisely. The original 2015 specification was informational; DMARC is now standardized in RFC 9989, published in May 2026, which obsoletes RFC 7489 and RFC 9091, with RFC 9990 for aggregate reports and RFC 9991 for failure reports. Much published guidance still cites the old numbers.

The specifications are shorter and more readable than their reputation: RFC 7208 for SPF, RFC 6376 for DKIM, and RFC 9989 for DMARC.

What breaks, and what it looks like from your desk

The consequence chain explains every symptom on this page. A message goes out with no valid DKIM signature, from a machine SPF does not cover. Both aligned checks fail, and DMARC applies whatever policy you published: reject bounces your own legitimate message, quarantine drops it into a spam folder, and none delivers it with no positive signal at all, leaving the receiving system to decide on its own.

The configurations that produce it:

• Going straight to a rejection policy with no monitoring period. Everything you forgot about - point-of-sale receipts, appointment reminders, the accountant's mail merge - stops being delivered, silently and all at once.
• A strict SPF record on a domain that still has an unlisted sender. Same outcome, narrower blast radius.
• Two SPF records, or more than ten lookups. The record errors, nothing passes SPF, and if DKIM is also unset, DMARC fails for all of your mail.
• A DMARC record with no reporting address. All of the enforcement risk, none of the visibility that would have warned you.
• A contact form that sends mail using the visitor's address in the From field. That message fails authentication for the visitor's domain and makes your server look like a forger. Send from your own address and put the visitor in reply-to.

And one that is not a configuration problem at all: hosting email on the same shared server as the website. If a neighboring account is compromised and starts sending spam, the server's address is blocklisted and your mail stops delivering. Keeping mail with a dedicated provider removes that risk entirely.

What Gmail and the other large receivers now require

Google's sender guidelines, effective 1 February 2024, set an explicit floor: every sender delivering to Gmail must have either SPF or DKIM configured. That is not a recommendation any more, it is the entry requirement.

Above that floor sits a bulk sender tier, defined as more than 5,000 messages a day to Gmail addresses. Bulk senders must have SPF and DKIM and DMARC, valid forward and reverse DNS, encryption in transit, a From header aligned with the authenticated domain, and one-click unsubscribe on marketing mail, while keeping reported spam rates below a low threshold.

That 5,000 a day figure is useful in a specific way: it tells you that you are almost certainly not a bulk sender, so the heavier requirements are not aimed at you - and it shows how low the bar sits for anyone running a newsletter from their own domain. The practical reading for a two-person business around Cedar Creek Lake is that getting SPF and DKIM right, which your mail provider will do if you ask, clears the requirement that applies to you.

What to check first, in order

If mail is going missing, work down this list before anyone is paid to do anything.

1. Find the shape of the problem. Is it one recipient's company, one mail provider, or everybody? A single corporate recipient blocking you is a different problem from a general failure.
2. Look up your SPF record and count the records. More than one is your answer; merge them into a single record.
3. Count the lookups in it. Every entry referring to another provider costs at least one and the ceiling is ten. Removing entries for services you no longer use is usually the fastest fix available.
4. Confirm DKIM signing is actually on at your provider, and that the published key matches. This is the step most often skipped after a migration.
5. Look at your DMARC record. A quarantine or reject policy with no reporting address is the likeliest cause of silent losses, and setting it back to monitoring while you investigate is safe and reversible.
6. List every system that sends mail as you - mail provider, contact form, newsletter tool, invoicing software, booking system, point-of-sale. Each has to be covered by SPF or signed by DKIM, and the forgotten ones are why this breaks.
7. Check whether your sending address has been blocklisted, particularly if mail runs on shared web hosting.

Then open a message you sent that was delivered and view its full headers. The authentication results line states plainly whether SPF, DKIM and DMARC passed - free, and it turns a vague worry into a specific finding.

When you do not need a DMARC project

DMARC monitoring services are a real product with a real purpose, and they are not a purchase for a two-person shop.

If your business sends ordinary person-to-person email from one provider, does no bulk sending and has never been impersonated, correct SPF and DKIM plus a monitoring-only DMARC record captures nearly all the benefit at none of the risk. Enforcement matters most for domains actually being forged: recognizable brands, invoice-heavy operations, and anyone whose client has already wired money to a fraudster.

Two other things a small sender does not need. A dedicated sending address of your own is usually wrong at low volume, because a machine sending a handful of messages a day has no reputation and often delivers worse than a well-managed shared pool. And you do not need a paid mailbox for every address you receive at: sales, service, info, billing and your own name can all be aliases delivering into one mailbox. A four-person business needs four mailboxes and a dozen aliases.

One more, and it costs us a line item to say it: a business already on a major email platform that works should not move its email to a small host's mail server. The large providers' deliverability reputation is better than any small host can match, and the migration risk is real.