Setting Up Email Authentication So Nobody Can Send As You

Why this matters

Out of the box, anyone on the internet can send an email whose From line says [email protected], and your customer's inbox has no reliable way to tell it from the real one. A fake past-due notice with your logo and a payment link is the cheapest fraud there is to run. Three DNS records, set up in the right order over about two months, let receiving mail servers check whether a message really came from you and throw away the ones that did not. Set them up in the wrong order and the first thing you block is your own invoices.

The three records in plain words

SPF (Sender Policy Framework) is a published list of the servers allowed to send mail for your domain. A receiving server looks at the machine that handed it the message and checks whether that machine is on your list. Its weakness is forwarding: when a customer's mail is auto-forwarded, the forwarding server is not on your list, so SPF fails on perfectly genuine mail.

DKIM (DomainKeys Identified Mail) is a signature. Your sending service signs each message with a private key, and you publish the matching public key in DNS. A receiving server checks the signature against the key. It survives forwarding, because the signature travels inside the message.

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the instruction that ties the other two to the address the customer actually sees. It tells receivers three things: a message claiming to be from your domain must pass SPF or DKIM, the domain that passed must match the one in the visible From line (this matching is called alignment), and here is what to do with mail that fails (nothing, quarantine it to spam, or reject it outright). It also asks receivers to email you daily reports of who has been sending as you. Those reports are what make the rollout safe.

Here is what the three look like in DNS, with placeholders where your values go:

yourshop.com  TXT
  v=spf1 include:_spf.MAILPROVIDER
  include:SENDER2 ~all

SELECTOR._domainkey.yourshop.com  TXT
  v=DKIM1; k=rsa; p=LONG-PUBLIC-KEY-FROM-SENDER

_dmarc.yourshop.com  TXT
  v=DMARC1; p=none;
  rua=mailto:[email protected]

Each record is one line in your DNS settings; it is wrapped here to fit. The SPF line ends in ~all (soft fail, meaning "treat anything else as suspicious") during the rollout. The DKIM record is usually handed to you by the sending service, sometimes as a CNAME (an alias record) pointing at a key they manage. The DMARC record starts at p=none, which changes nothing about delivery and only switches the reports on.

Before you start

You need a login to wherever your DNS is hosted, which is usually your registrar; if you do not have one, stop and fix that first, see related: Your Domain Name Is the Master Key. You need an admin login to your mailbox provider. And you need one person who will open a report summary once a week for two months. DMARC reports arrive as compressed XML files that are unreadable by eye; most shops point the rua address at a mailbox that a report-reading service processes, or use the report viewer some mail providers include. Either is fine. Ignoring the reports is not, because the reports are the only way you find the sender you forgot.

The rollout, step by step

1. List every service that sends mail with your domain in the From line. Walk it by asking what emails a customer or supplier gets from you: the office mailboxes, invoices and payment reminders from your field service software, appointment confirmations, estimates sent for e-signature, review requests, the newsletter tool, the website contact form, and the scan-to-email on the office copier. Each one is a sender that needs to be in SPF or signing with DKIM. Skip this and the list is wrong from the start; the reports will eventually reveal what you missed, but only if you are still at p=none when they do.

2. Publish one SPF record that names every sender on the list. Add an include: for each service that gives you one (their setup page will say). Check for an existing SPF record first: a domain may have only one, and two SPF records is an error that makes every receiver treat SPF as failed. Keep it under ten DNS lookups; each include costs at least one, and RFC 7208 makes an SPF record that needs more than ten fail. A shop with six or seven sending tools can hit that ceiling, and the fix is to have the services that support it rely on DKIM instead of being listed in SPF.

3. Turn on DKIM signing at every sender that offers it. Your mailbox provider has a DKIM page in its admin settings; most field service, invoicing and marketing tools have one under "custom sending domain" or "email authentication." Each gives you a record to publish, with a selector (the label before ._domainkey) unique to that service, so several can coexist. Use a 2048-bit key where offered. Skip DKIM and you are relying on SPF alone, which means every customer who forwards your mail from one address to another becomes a failure once you enforce.

4. Publish DMARC at p=none with a reporting address. This is the step people want to skip straight past, going directly to p=reject because that is the setting that stops spoofers. Do not. At p=none nothing is blocked, so you can see the whole picture with no risk to your own mail.

5. Read the reports for at least three weeks. Sort every sending source into three piles: yours and passing aligned, yours and failing, not yours. Fix the second pile at the sender's settings, by adding it to SPF or turning on its DKIM with your domain. Three weeks is a starting point, chosen so that a monthly statement run and a monthly newsletter each show up at least once; tune it to whatever your rarest legitimate sender is. A sender that only fires quarterly needs you to wait for it or test it by hand.

6. Move to p=quarantine with pct=25. The pct tag applies the policy to that percentage of failing mail and leaves the rest at the next-lower policy. Quarantine means failing mail goes to spam, not into the void, so a mistake is recoverable: someone finds the missing message in a junk folder. Hold it two weeks, then raise it to pct=100 and hold another two.

7. Move to p=reject. Now a message claiming to be from your domain that fails both checks is refused by receivers that honor DMARC. Keep the reports flowing; they now show you the spoofing attempts being stopped.

8. Protect the domains that never send mail. If you own extra domains (an old company name, a misspelling you bought defensively), publish v=spf1 -all and a DMARC record at p=reject on each. Without them, they are the domains a scammer will send from, because nobody is watching them.

9. Repeat steps 1 and 5 every time you add a tool that sends email. The common way a fully enforced shop starts losing its own mail is a new booking or review tool set up by someone who did not know about DMARC. Its messages fail alignment and get rejected, and nobody notices for weeks because rejected mail simply does not arrive.

Worked example: a roofing shop that found its fifth sender

A nine-person roofing shop lists four senders in step 1: its mailbox provider, its field service software, its accounting software's invoice email, and a newsletter tool. It publishes SPF with four includes, turns on DKIM at all four, and publishes DMARC at p=none.

The first week's report summary shows 1,840 messages sent as the shop's domain. Of those, 1,610 passed aligned, which is 87.5 percent of the 1,840. Another 190, or about 10.3 percent, came from a server belonging to the e-signature service the estimator uses to send roof estimates, which nobody had listed because the estimator set it up himself. Those 190 failed SPF (not on the list) and carried a DKIM signature from the e-signature service's own domain, which does not align with the shop's From address. The last 40, about 2.2 percent, came from servers the shop had never heard of, in two countries the shop does not work in. That is 1,610 plus 190 plus 40, which closes to 1,840.

The reasoning on each pile: the 1,610 need nothing. The 190 are genuine and important (they are estimates, which is revenue), so the shop turns on custom domain authentication in the e-signature tool, which hands it a DKIM record to publish. The 40 are spoofers, and at p=none they are still being delivered. That is the price of the cautious start, and it is why the shop does not linger.

Week 3's report shows the e-signature mail passing aligned. The shop moves to p=quarantine; pct=25 in week 4, to pct=100 in week 6, and to p=reject in week 9. In week 10 the report shows 52 messages from unknown sources, all rejected.

What would have happened if the shop had gone straight to p=reject in week 1: up to 190 estimates a week refused by customers' mail servers, with the e-signature tool reporting them as sent. The estimator would have spent a month wondering why nobody was signing, and the shop would have blamed the market.

What this does not stop

DMARC protects your exact domain and nothing else. It does nothing about a lookalike domain (yourshop-billing.com, or yourshop.co), a free webmail address with your shop's name as the display name, or a text message; see related: Customers Got Texts Pretending to Be Your Company. It also does nothing if a real office mailbox is broken into, because that mail passes every check. Treat it as closing one door properly, not as making your customers safe.

How to verify you got this right

• Send a message from each sender on your list to a mailbox at a large free provider, open it, and use "show original" (or the equivalent). Each should read SPF pass, DKIM pass, DMARC pass. Do this for the copier and the contact form too.
• Look up your SPF record with a DNS lookup tool and confirm there is exactly one, and that it reports fewer than ten lookups.
• Confirm your DMARC record shows the policy you think it does. A typo in the tag name silently makes the whole record invalid.
• Read the latest weekly report summary and confirm the "yours and failing" pile is empty before each policy step up.

Large mailbox providers have required DMARC and alignment from high-volume senders since early 2024, and they tighten requirements over time. That is current as of 2026; re-check your mailbox provider's sender guidelines once a year as part of the annual review, see related: The Annual Security Review SOP.

References

• RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 (DMARC)
• Your mailbox provider's and each sending tool's email authentication setup documentation
• See related: Your Domain Name Is the Master Key, Customers Got Texts Pretending to Be Your Company, The Annual Security Review SOP