Email & deliverability 2026-08-03 11 min read

Anyone can send email as you. Here is how to stop them.

Three pieces of internet plumbing decide whether your email reaches inboxes and whether a scammer can convincingly pretend to be you. Most businesses have some of it set up, few have all of it working, and almost nobody finds out until something breaks quietly.

Every business that sends email from its own domain depends on three layers of anti-fraud machinery built into the internet’s plumbing. Invoices, quotes, appointment reminders, the automated “thanks for your enquiry”: all of it passes through this machinery, and most people never see any of it. It runs in the background and decides two things. Whether your email lands in the inbox or the spam folder, and whether someone can convincingly pretend to be you.

The three layers are Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting and Conformance (DMARC). The names are a mouthful and you can forget them immediately. What they do is simple, and this guide explains each one in plain terms, why it matters, and then, for whoever administers your DNS, the technical detail, including the one limit that quietly breaks more setups than any other.

Most of what follows is drawn from a real health check we ran for a US non-profit whose email was “partly set up” in the way most businesses’ email is partly set up. Not broken enough to notice, not working well enough to trust.

The one-sentence version

Think of every email as a letter arriving in your name. SPF is the postmark, proving it was posted from a place you approved. DKIM is the signature and the wax seal, proving the letter is genuinely yours and nobody opened it on the way. DMARC is the recipient’s standing instruction for a letter that fails either test, plus a register, sent back to you, of everyone who has been posting in your name.

You want all three. Here is why.

SPF: the postmark

Your domain publishes a list of every email service allowed to send mail in your name. Microsoft 365, a CRM, a newsletter tool, an invoicing platform: each one that sends on your behalf has to be on the list. Think of it as telling the postal service which of your post rooms are allowed to frank letters with your name on them.

When a letter arrives, the receiver reads the postmark and checks it against that list. Posted from an approved room, the message passes the SPF check. Posted from somewhere not on the list, it looks like someone writing in your name from an address you never authorised.

The trouble is that the list has a hard length limit, and it is smaller than most people expect. Over the years a business signs up for more sending services, one for marketing, one for the CRM, one for appointment automation, one for surveys, and each new post room has to be added. The list grows. Past a certain point, the sorting clerk gives up reading partway down, and even your genuine letters start getting set aside.

This is exactly what we found on the non-profit’s domain. Their approved-sender list had accumulated entries for Microsoft 365, a Zoho CRM, a bulk-mail service, a marketing platform and several others, and it had grown past the limit. The consequence was invisible. Every automated email, an appointment confirmation, a workbook download, a feedback survey, had an elevated chance of landing in a spam folder rather than an inbox. No bounce, no error, no warning. The email simply was not seen. For an organisation whose busiest season ran on appointment reminders, that is quietly expensive.

The fix was not to delete services blindly, because some were still in use. It was to work out which senders were genuinely active, consolidate the record so it stayed within the limit, and route the legacy CRM’s mail so those senders no longer each ate one of the ten precious lookups.

DKIM: the signature and the wax seal

The postmark says where a letter was posted. It says nothing about whether the letter inside is genuinely yours, or whether someone steamed it open and changed the contents on the way. That is DKIM’s job.

DKIM attaches a cryptographic signature to every message you send. The receiver checks the signature against a key you have published in your DNS. If it matches, two things are proven: the message really came from your domain, and nobody tampered with it in transit.

It is the signature and the wax seal on the letter itself. The signature, compared against a specimen the receiver can look up, proves the hand is genuinely yours. The seal, unbroken, proves nobody opened the envelope between you and the reader. A postmark can be faked by anyone standing near the right post box; a signature and an intact seal are far harder to counterfeit together.

On the non-profit’s domain, Microsoft 365 was perfectly capable of signing their mail. The feature had simply never been switched on. Their email was going out unsigned: right return address, no seal. That costs a little deliverability everywhere, because receivers trust signed mail more, and it makes a forger’s job easier, because a fake email and a real one look closer to identical from the receiver’s side. For an audience that scammers actively target, an easily-forged domain makes their customers’ risk worse, even though the scam never touches the business itself.

DMARC: the standing instruction, and the register

SPF and DKIM produce a verdict on each letter, pass or fail. DMARC is what the recipient’s post room does with that verdict, and it does two genuinely separate jobs that are easy to confuse.

The standing instruction. DMARC tells the world’s email systems how to treat a letter in your name that fails the postmark check or the seal: deliver it anyway (p=none, “just watch”), set it aside in the spam pile (p=quarantine), or bin it unopened (p=reject). A great many domains publish DMARC at p=none and stop there. The instruction is lodged, but it says do nothing. That is still better than no instruction, because of the second job.

The register. DMARC asks receivers to send you a regular register of every letter posted in your name, the genuine ones and the forgeries alike. This is the part people skip, and it is the most useful part. You cannot safely change the instruction to quarantine or reject until the register has shown you every legitimate sender, or you will start binning your own mail. The sequence is always the same. Publish p=none, read the register until you recognise everything, fix what is missing, and only then tighten.

The non-profit’s domain was at p=none, and alongside it sat an old, invalid duplicate DMARC record in the wrong place, the kind of leftover that accumulates when records are edited over years by different hands. Cleaning that up came first. Tightening the policy came only after the reports were understood.

Why this matters even if nothing is “broken”

None of the three issues on that domain was on fire. That is precisely the problem with email authentication: the failure mode is silent. You do not get an error when your appointment reminder lands in spam. You do not get a warning when someone spoofs your domain to phish your customers. The cost is reach and trust, bled slowly and invisibly, until one day a customer says “I never got your email”, or worse, “I got an email from you that I do not think was really you”.

If your business sends anything that matters by email, all three layers are worth getting right, in order, once.

Technical detail

This section is for whoever administers your DNS and Microsoft 365 or Google Workspace tenant. It assumes you are comfortable with DNS TXT records.

SPF and the lookup limit (RFC 7208)

SPF is a single DNS TXT record beginning v=spf1. The limit that breaks real setups is defined in RFC 7208 section 4.6.4: an SPF evaluation may trigger at most 10 DNS-lookup-causing mechanisms (include, a, mx, ptr, exists, and redirect). Exceed it and a conformant receiver must return PermError. A PermError is not a pass. SPF alignment then fails, which in a DMARC world means the message can be treated as unauthenticated.

Two subtleties catch people out.

  • The limit counts mechanisms, not raw DNS queries, and it is recursive. Every include: you add can itself contain more include: entries, nested inside one another. A single include: for a large provider can consume four or five of your ten before you have added anything else. This is why a record with only four or five visible include: entries can still blow the limit. The nesting is where the count actually lives.
  • PermError is a receiver-side “must”, not a matter of one receiver being strict. You cannot assume tolerant receivers will let it slide. Google, Microsoft and Yahoo all enforce it.

The fixes, in order of preference:

  1. Remove services you no longer use. The commonest cause of an over-length record is legacy senders, an old CRM or a retired marketing tool, added once and never removed. This is what we found on the non-profit’s domain: multiple legacy CRM and automation senders, each with its own include:, several no longer in active use.
  2. Where a provider offers it, use a single consolidated include: rather than several sub-records.
  3. If you genuinely need many senders, SPF flattening resolves the include: entries to their underlying IP ranges and publishes those directly. It trades maintainability for lookup count, so use it deliberately and only with monitoring, because the underlying IPs can change beneath you.

Do not solve an over-length record by splitting it into two TXT records beginning v=spf1. A domain must publish exactly one SPF record. Two is itself a PermError.

DKIM (RFC 6376)

DKIM, defined in RFC 6376, is enabled at the sending platform: in Microsoft 365 via the Defender portal or PowerShell, in Google Workspace via the Admin console. That gives you two CNAME or TXT selector records to publish in DNS. Once the records resolve and signing is switched on, outbound mail carries a DKIM-Signature header and receivers can verify it. Use a 2048-bit key where the platform allows it.

DMARC (RFC 7489), and the sequence that keeps your mail flowing

DMARC, defined in RFC 7489, is a TXT record at _dmarc.yourdomain. A monitoring record looks like this:

v=DMARC1; p=none; rua=mailto:reports@yourdomain; fo=1

The rua address receives the aggregate reports. Read them, ideally through a DMARC reporting service that turns the raw XML into something legible, until every legitimate sender shows as aligned. Only then raise the policy to p=quarantine, and later p=reject, ideally with a pct= ramp so you tighten on a fraction of mail first.

Alignment is the subtle part. A message passes DMARC if it passes SPF or DKIM, and the passing domain aligns with the visible From: domain. This is why DKIM matters even once SPF is healthy: DKIM alignment survives forwarding in cases where SPF alignment does not.

Watch for the same leftovers we found. A single _dmarc record only, with no duplicate or invalid record sitting alongside it. And confirm your MX records route where you think they do before changing anything, because authentication changes are safe to make methodically and risky to make in a hurry.

The order to do it in

  1. Fix SPF so it is one record, within the ten-lookup limit, listing only active senders.
  2. Enable DKIM and confirm signed mail verifies.
  3. Publish DMARC at p=none with reporting, and read the reports.
  4. Once every legitimate sender is recognised, tighten DMARC to quarantine, then reject.

Done in that order, you never block your own mail, and you end with a domain that reaches inboxes and cannot be casually forged.

Check your own domain

You do not need us to see where you stand. The following tools run in a browser and will tell you the state of your SPF, DKIM and DMARC records in seconds:

  • MXToolbox (mxtoolbox.com/SuperTool.aspx) runs SPF, DKIM, DMARC, MX and blacklist checks from one box. The spf:yourdomain and dmarc:yourdomain lookups are the quickest way to see your records and, crucially, your SPF lookup count.
  • Google Admin Toolbox (toolbox.googleapps.com/apps/checkmx) gives a thorough read of MX and authentication for any domain.
  • dmarcian and Postmark’s DMARC tool both offer plain-language DMARC record checks and can set up the reporting side.

If those tools show a PermError, a too-long SPF record, missing DKIM, or a DMARC policy stuck at p=none you have never read the reports from, that is worth fixing, in the order above.

And if the reports turn out to be a mess of legacy senders nobody remembers signing up for, that is precisely the untangling we do. It is a fixed-scope piece of work with a plain verdict, and sometimes the honest verdict is that you are already fine.

Prepared by 1NM · 2026-08-03 · More guides