You send a quote. It goes to spam. You send a reminder. Same thing. Meanwhile someone you have never met sends an invoice to your customer with your name on it, and that one lands fine.

Both problems have the same fix. Three records in your domain settings tell the world which servers may send mail as you and what to do with mail that fails the test. They are called SPF, DKIM and DMARC. Here is what each does, in plain words.

SPF: the list of who may send

SPF is a list you publish. It says, in effect, "mail from ourcompany.com comes from these servers." Google's servers, Microsoft's, your invoicing tool, your newsletter service.

When your mail arrives, the receiving server checks the sender against the list. On the list, good. Not on the list, suspicious.

The common mistakes are simple. The list is missing a tool you added last year, so your invoices fail the check. Or the list has grown so long it breaks a technical limit and stops working for everything. SPF is worth a review every time you add a service that sends email on your behalf.

DKIM: the seal on the envelope

SPF says where mail may come from. DKIM proves the message was not changed on the way. Your mail server signs each message with a private key. The matching public key sits in your domain settings. The receiver checks the signature. If it matches, the message is intact and really came from a server you control.

You turn DKIM on at your email platform and add the key it gives you to your domain. Each sending service has its own key, so your newsletter tool needs one too. Many businesses have DKIM on for their main mail and off for everything else, which is why the newsletter lands in promotions and the invoice lands in spam.

DMARC: the instructions

SPF and DKIM are checks. DMARC is the rule that says what to do with mail that fails them, and it asks receivers to send you reports.

A DMARC record has a policy. None means watch and report, but deliver anyway. Quarantine means send failures to spam. Reject means refuse them. Most domains that have DMARC at all sit on none forever, which is a smoke alarm with the battery out. Spoofed mail still lands.

The goal is reject. You get there in steps. Start on none, read the reports for a few weeks, fix every real sender that fails, then move to quarantine, then reject. Once you are there, a stranger sending mail as you gets bounced before your customer ever sees it.

Why this matters more than it used to

Gmail and Yahoo now require SPF or DKIM from anyone sending in volume, and DMARC from bulk senders. Microsoft has followed. Mail without them is not just risky. It is increasingly refused outright. If your deliverability got worse in the last two years and you did not change anything, this is often why.

How to check yours in five minutes

  • Look up your domain's TXT records. You want one starting v=spf1, a DMARC record at _dmarc.yourdomain.com, and a DKIM key for each service that sends.
  • Send a message to a personal Gmail account. Open it, choose Show original, and look for SPF, DKIM and DMARC each marked PASS.
  • Read the DMARC policy. If it says p=none, your protection is not switched on yet.

If any of those come back wrong, do not guess at the fix. A broken SPF record can stop your own mail cold. Make the change on a quiet afternoon and test again.

What ALCO does

For every Google Workspace and Microsoft 365 client, SPF, DKIM and DMARC are set up, aligned and enforced, and we read the reports so you do not have to. Adding a new tool that sends email is a request, not a project. Details for each platform are at https://alcohq.com/services/google-workspace and https://alcohq.com/services/microsoft-365

One more thing

These records protect your name. They do not stop a scammer from registering ourcompany-billing.com and sending from that. Train your team to check the sender's address, not just the display name, and to confirm any change of bank details by phone. The records close the front door. Your people watch the side door.